欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  科技

031.核心组件-kubelet

程序员文章站 2022-03-05 17:16:24
一kubelet概述 1.1kubelet作用 在Kubernetes集群中,在每个Node(又称Minion)上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务,管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息,定 ......

一 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)地址,仅用于公有云环境。
提示:通常可能每个kubelet都被授予创建和修改任何节点的权限。生产环境中,建议kubelet的权限进行限制,仅允许它修改和创建所在节点的权限。
如果在集群运行过程中遇到集群资源不足的情况,用户就很容易通过添加机器及运用kubelet的自注册模式来实现扩容。
在某些情况下,kubernetes集群中的某些kubelet没有选择自注册模式,用户需要自己去配置node的资源信息,同时告知node上kubelet api server的位置,需要手动创建和修改节点信息。
如果需要手动创建节点信息,则通过设置kubelet的启动参数“--registernode=false”即可关闭自注册模式。
kubelet在启动时通过api server注册节点信息,并定时向api server发送节点的新消息,api server在接收到这些信息后,将这些信息写入etcd。通过kubelet的启动参数“--node-status-update-frequency”设置kubelet每隔多长时间向api server报告节点状态,默认为10s。

三 pod管理

kubelet通过以下几种方式获取自身node上要运行的pod清单。
  1. 文件:kubelet启动参数“--config”指定的配置文件目录下的文件(默认目录为“/etc/kubernetes/manifests/”)。通过--file-checkfrequency设置检查该文件目录的时间间隔,默认为20s。
  2. http端点(url):通过“--manifest-url”参数设置。通过--http-check-frequency设置检查该http端点数据的时间间隔,默认为20s。
  3. 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任务,则做如下处理:
  1. 为该pod创建一个数据目录。
  2. 从api server读取该pod清单。
  3. 为该pod挂载外部卷(externalvolume)。
  4. 下载pod用到的secret。
  5. 检查已经运行在节点上的pod,如果该pod没有容器或pause容器(“kubernetes/pause”镜像创建的容器)没有启动,则先停止pod里所有容器的进程。如果在pod中有需要删除的容器,则删除这些容器。
  6. 用“kubernetes/pause”镜像为每个pod都创建一个容器。该pause容器用于接管pod中所有其他容器的网络。每创建一个新的pod,kubelet都会先创建一个pause容器,然后创建其他容器。“kubernetes/pause”镜像大概有200kb,是个非常小的容器镜像。
  7. 为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种实现方式:
  1. execaction:在容器内部执行一个命令,如果该命令的退出状态码为0,则表明容器健康。
  2. tcpsocketaction:通过容器的ip地址和端口号执行tcp检查,如果端口能被访问,则表明容器健康。
  3. 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)采集和存储。