草庐IT

Debian11之基于kubeadm安装K8S(v1.26.0) 集群

硬件要求1、Master主机:2核CPU、4G内存、20G硬盘2、Node主机:4+核CPU、8G+内存、40G+硬盘2、集群中的所有机器的网络彼此均能相互连接(公网和内网都可以)3、节点之中不可以有重复的主机名、MAC地址或product_uuid4、开启机器上的某些端口5、为了保证kubelet正常工作,必须禁用交换分区各服务器初始化配置配置各主节点的主机名称hostnamectlset-hostnamek8smaster&&hostname#设置主节点1的主机名称配置各从节点的主机名称hostnamectlset-hostnamek8snode1&&hostname#设置从节点1的主机名

Flink on-k8s operator application 模式

flink-kubernetes-operator官方文档中给出的application模式demoapiVersion:flink.apache.org/v1beta1kind:FlinkDeploymentmetadata:namespace:defaultname:basic-examplespec:image:flink:1.16flinkVersion:v1_16flinkConfiguration:taskmanager.numberOfTaskSlots:"2"serviceAccount:flinkjobManager:resource:memory:"2048m"cpu:1t

(二)云原生&k8s的架构及基本组件原理

1.iaas基础设施即服务 公司:服务器购买、建设机房、dns路由器、硬件、存储...--抽象成服务提供给公司(用户)使用2.paas平台即服务在iaas层上进行了更高级层次抽象,iaas提供硬件服务,paas提供基础软件服务3.saas软件即服务钉钉,企业微信云原生:架构:软件开发思想(软件架构思想)应用:就是为了让应用程序(项目、mysql、elasticsearch...)都运行在云上容器中,这样的技术就叫做云原生特点:1.容器化:容器项目部署,起到了隔离的作用2.微服务:实现原生最好采用微服务架构,微服务按照function拆分后,可以做到高内聚,低耦合,实现CI/CD3.devops

【测试开发】突破瓶颈必学技能——什么是k8s的核心概念?

目录Docker和K8sk8s中的重要概念 Master节点Node节点集群(Cluster)标签(Label)命名空间(Namespace)容器组(Pod)无状态部署(Deployment)有状态部署(StatefulSet)任务(Job)服务(Service)PodPod的理解Pod生命周期Pod资源清单定义结语你是否在测试开发的道路上遇到了瓶颈,想要突破自己的技能瓶颈?Kubernetes作为容器编排领域的翘楚,已经成为现代企业构建可靠、可伸缩的应用程序的重要基础。但是,它的复杂性经常令人望而却步。因此,深入理解Kubernetes核心概念对于测试开发工程师来说至关重要。本文将重点介绍K

k8s之POD资源限制和健康监测

写在前面本文一起看下POD的资源限制配置和健康监测的相关内容。1:资源限制如果是不对POD设置资源限制的话,若任由其占用系统资源,可能会造成非常严重的后果,所以我们需要根据具体情况来设置资源限制,如使用多少内存,多少CPU,多少IOPS等,实现这些限制使用的是cgroup技术,而配置这些限制使用到属性是resources。在看具体的例子之前需要先来看下cpu资源的表示方法,cpu标识的最小单位是0.001m,这里的m是milli的意思,1000m就代表使用一个cpu,500m就代表0.5cpu,具体配置cpu限制的话使用Xm,X这种,后者是直接指定使用CPU的个数。如下yaml:apiVers

k8s编写配置文件解析

一、创建命名空间1、编写yaml文件vim namespace.yaml---apiversion: v1   # api版本kind: Namespace  # 创建类型----(Namespace命名空间)metadata:      # 元数据  name: ns-monitor  # 起个名字  (给元数据的名字)  labels:          # 标签    name: ns-monitor    # 标签的名字2、创建资源#  kubectl apply -f namespace.yaml回显 namespace/ns-monitor created   (以创建成功)#  

【JVM故障问题排查心得】「内存诊断系列」Docker容器经常被kill掉,k8s中该节点的pod也被驱赶,怎么分析?

##背景介绍>最近的docker容器经常被kill掉,k8s中该节点的pod也被驱赶。我有一个在主机中运行的Docker容器(也有在同一主机中运行的其他容器)。该Docker容器中的应用程序将会计算数据和流式处理,这可能会消耗大量内存。该容器会不时退出。我怀疑这是由于内存不足,但不是很确定。我需要找到根本原因的方法。那么有什么方法可以知道这个集装箱的死亡发生了什么?###容器层级判断检测提到dockerlogs$container_id查看该应用程序的输出。这永远是我要检查的第一件事。接下来,您可以运行dockerinspect$container_id以查看状态的详细信息,例如:```"St

k8s拉取镜像失败处理 ImagePullBackOff ErrImageNeverPull

目录一、环境描述二、pod失败状态三、整体解决方案四、补充一下Pod状态解释一、环境描述系统环境:CentOSLinuxrelease7.9.2009(Core)系统内核:Linuxk8s-master015.4.153-1.el7.elrepo.x86_64#1SMPTueOct1208:16:11EDT2021x86_64x86_64x86_64GNU/Linuxk8s版本:Kubernetesv1.20.14docker:Dockerversion20.10.12集群有外网,docker已经对接好网络镜像仓库。二、pod失败状态   1.拉取k8s网上的镜像失败后的状态[root@k8s

k8s部署生产级elasticsearch+kibana 步骤、踩坑及解决方案

目录写在最前支持版本环境准备部署ECKelasticsearch创建配置文件部署验证kibana创建配置文件部署验证踩坑及解决方案elasticsearchpvc配置不对导致无法正确启动elasticsearch存储配置对了但无法启动,不配置存储能启动kibana默认配置下不能访问写在最前本文中的流程思路大体上与ECK文档相近,如果你已经在看这个文档,可以直接跳到踩坑及解决方案部分进行阅读。官方文档在elasticsearch存储相关设置,以及kibana配置公网可访问上有一些坑。补充filebeat部署步骤:k8s部署filebeat步骤、踩坑及解决方案支持版本Kubernetes1.18-

k8s master 实现高可用

Kubernetes高可用master架构k8s的高可用,主要是实现Master节点的高可用。那么我们看看各个组件是如何解决高可用的。Kubelet、Kube-proxy:只工作在当前Node节点上,无需高可用。etcd:etcd如果是放在集群内部的,在kubeadm1.5之后,对于多Master集群,一个Master节点加入集群后将自动实现集群化扩展。所以集群已经自动实现高可用,无需再人工干预。kube-controller-manager:对于多Master集群,这个组件只会有一个正常工作,其它处于休眠挂起状态。当工作节点发生故障时才会唤醒另一个接管。所以集群已经自动实现高可用,无需再人工