031.核心组件-kubelet
2020-03-18 09:21:07来源:博客园 阅读 ()
031.核心组件-kubelet
一 kubelet概述
1.1 kubelet作用
在Kubernetes集群中,在每个Node(又称Minion)上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务,管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息,定期向Master汇报节点资源的使用情况,并通过cAdvisor监控容器和节点资源。二 节点管理
节点通过设置kubelet的启动参数“--register-node”,来决定是否向API Server注册自己。如果该参数的值为true,那么kubelet将试着通过API Server注册自己。在自注册时,kubelet启动时还包含下列参数。- --api-servers:API Server的位置。
- --kubeconfig:kubeconfig文件,用于访问API Server的安全配置文件。
- --cloud-provider:云服务商(IaaS)地址,仅用于公有云环境。
三 Pod管理
kubelet通过以下几种方式获取自身Node上要运行的Pod清单。- 文件:kubelet启动参数“--config”指定的配置文件目录下的文件(默认目录为“/etc/kubernetes/manifests/”)。通过--file-checkfrequency设置检查该文件目录的时间间隔,默认为20s。
- HTTP端点(URL):通过“--manifest-url”参数设置。通过--http-check-frequency设置检查该HTTP端点数据的时间间隔,默认为20s。
- API Server:kubelet通过API Server监听etcd目录,同步Pod列表。
所有以非API Server方式创建的Pod都叫作Static Pod。kubelet将Static Pod的状态汇报给API Server,API Server为该Static Pod创建一个Mirror Pod和其相匹配。Mirror Pod的状态将真实反映Static Pod的状态。当Static Pod被删除时,与之相对应的Mirror Pod也会被删除。 对于通过API Server获得Pod清单的方式,kubelet会使用API Server Client的Watch加List的方式监听“/registry/nodes/$”当前节点的名称和“/registry/pods”目录,将获取的信息同步到本地缓存中。 kubelet监听etcd,所有针对Pod的操作都会被kubelet监听。如果发现有新的绑定到本节点的Pod,则按照Pod清单的要求创建该Pod。如果发现本地的Pod被修改,则kubelet会做出相应的修改,比如在删除Pod中的某个容器时,会通过Docker Client删除该容器。 如果发现删除本节点的Pod,则删除相应的Pod,并通过Docker Client删除Pod中的容器。 kubelet读取所监听的信息,如果是创建和修改Pod任务,则做如下处理:
- 为该Pod创建一个数据目录。
- 从API Server读取该Pod清单。
- 为该Pod挂载外部卷(ExternalVolume)。
- 下载Pod用到的Secret。
- 检查已经运行在节点上的Pod,如果该Pod没有容器或Pause容器(“kubernetes/pause”镜像创建的容器)没有启动,则先停止Pod里所有容器的进程。如果在Pod中有需要删除的容器,则删除这些容器。
- 用“kubernetes/pause”镜像为每个Pod都创建一个容器。该Pause容器用于接管Pod中所有其他容器的网络。每创建一个新的Pod,kubelet都会先创建一个Pause容器,然后创建其他容器。“kubernetes/pause”镜像大概有200KB,是个非常小的容器镜像。
- 为Pod中的每个容器做如下处理:
- 为容器计算一个Hash值,然后用容器的名称去查询对应Docker容器的Hash值。若查找到容器,且二者的Hash值不同,则停止Docker中容器的进程,并停止与之关联的Pause容器的进程;若二者相同,则不做任何处理。
- 如果容器被终止了,且容器没有指定的restartPolicy(重启策略),则不做任何处理。
- 调用Docker Client下载容器镜像,调用Docker Client运行容器。
四 容器健康检查
4.1 健康检查方法
Pod通过两类探针来检查容器的健康状态,LivenessProbe探针和ReadinessProbe探针。4.2 LivenessProbe探针
LivenessProbe探针,用于判断容器是否健康并反馈给kubelet。如果LivenessProbe探针探测到容器不健康,则kubelet将删除该容器,并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针,那么kubelet认为该容器的LivenessProbe探针返回的值永远是Success。 kubelet定期调用容器中的LivenessProbe探针来诊断容器的健康状况。LivenessProbe包含以下3种实现方式:- ExecAction:在容器内部执行一个命令,如果该命令的退出状态码为0,则表明容器健康。
- TCPSocketAction:通过容器的IP地址和端口号执行TCP检查,如果端口能被访问,则表明容器健康。
- HTTPGetAction:通过容器的IP地址和端口号及路径调用HTTPGet方法,如果响应的状态码大于等于200且小于等于400,则认为容器状态健康。
LivenessProbe探针被包含在Pod定义的spec.containers.{某个容器}中。 示例1:HTTP检查方式 [root@k8smaster01 study]# vi myweb-liveness.yaml
1 apiVersion: v1 2 kind: Pod 3 metadata: 4 labels: 5 test: liveness 6 name: myweb 7 spec: 8 containers: 9 - name: myweb 10 image: kubeguide/tomcat-app:v1 11 ports: 12 - containerPort: 8080 13 livenessProbe: 14 httpGet: 15 path: /index.html 16 port: 8080 17 httpHeaders: 18 - name: X-Custom-Header 19 value: Awesome 20 initialDelaySeconds: 5 21 timeoutSeconds: 1 22 #kubelet发送一个HTTP请求到本地主机、端口及指定的路径,来检查容器的健康状态。示例2:运行一个具体的命令。 [root@k8smaster01 study]# vi myweb-liveness.yaml
1 apiVersion: v1 2 kind: Pod 3 metadata: 4 labels: 5 test: liveness 6 name: myweb 7 spec: 8 containers: 9 - name: myweb 10 image: kubeguide/tomcat-app:v1 11 ports: 12 - containerPort: 8080 13 livenessProbe: 14 exec: 15 command: 16 - cat 17 - /tmp/health 18 initialDelaySeconds: 5 19 timeoutSeconds: 1 20 #kubelet在容器中执行“cat /tmp/health”命令,如果该命令返回的值为0,则表明容器处于健康状态,否则表明容器处于不健康状态。
4.3 ReadinessProbe探针
另一类是ReadinessProbe探针,用于判断容器是否启动完成,且准备接收请求。如果ReadinessProbe探针检测到容器启动失败,则Pod的状态将被修改,Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的IP地址的Endpoint条目。五 cAdvisor资源监控
5.1 cAdvisor概览
在Kubernetes集群中,应用程序生命周期内的信息可以在不同的级别上进行监测,如:容器、Pod、Service和整个集群。 Kubernetes尽可能提供用户详细的各个级别的资源使用信息,从而能深入地了解应用的执行情况,并找到应用中可能的瓶颈。 cAdvisor是一个开源的分析容器资源使用率和性能特性的代理工具,它是因为容器而产生的,因此也支持Docker容器。在Kubernetes项目中,cAdvisor被集成到Kubernetes代码中,kubelet则通过cAdvisor获取其所在节点及容器的数据5.2 cAdvisor原理及作用
cAdvisor自动查找所有在其所在Node上的容器,自动采集CPU、内存、文件系统和网络使用的统计信息。通常cAdvisor通过它所在Node的4194端口暴露一个简单的UI。 kubelet作为连接Kubernetes Master和各Node之间的桥梁,管理运行在Node上的Pod和容器。kubelet将每个Pod都转换成它的成员容器,同时从cAdvisor获取单独的容器使用统计信息,然后通过该REST API暴露这些聚合后的Pod资源使用的统计信息。 cAdvisor只能提供2~3min的监控数据,对性能数据也没有持久化,因此在Kubernetes早期版本中需要依靠Heapster来实现集群范围内全部容器性能指标的采集和查询功能。 从Kubernetes1.8版本开始,性能指标数据的查询接口升级为标准的Metrics API,后端服务则升级为全新的Metrics Server。因此,cAdvisor在4194端口提供的UI和API服务从Kubernetes1.10版本开始进入弃用流程,并于1.12版本完全关闭。 若需要重新启用该服务,可手动部署一个DaemonSet在每个Node上启动一个cAdvisor来提供UI和API,参考:https://github.com/google/cadvisor。 在新的Kubernetes监控体系中,Metrics Server用于提供CoreMetrics(核心指标),包括Node和Pod的CPU和内存使用数据。其他CustomMetrics(自定义指标)则由第三方组件(如Prometheus)采集和存储。原文链接:https://www.cnblogs.com/itzgr/p/12516417.html
如有疑问请与原作者联系
标签:
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有
- 运维基础 2020-05-14
- shell脚本之五:bash内置核心命令read基础及实践 2020-04-28
- 030.核心组件-Scheduler 2020-03-18
- 028.核心组件-API Server 2020-03-17
- 操作系统-核心级线程实现 2020-03-10
IDC资讯: 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营: 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程: Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术: Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧: 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作: FrontPages Dreamweaver Javascript css photoshop fireworks Flash