一 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清单。
- 文件：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: /
16 port: 8080
17 httpheaders:
18 - name: x-custom-header
19 value: awesome
20 initialdelayseconds: 5
21 timeoutseconds: 1
22 #kubelet发送一个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 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）采集和存储。
如对本文有疑问，
点击进行留言回复！！
我要评论
网友评论