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）地址，仅用于公有云环境。

提示：通常可能每个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）采集和存储。