kubelet作用概述
在Kubernetes集群中，在每个Node上都会启动一个 kubelet服务进程。kubelet作为连接Kubernetes Master和各Node之间的桥梁，用于处理Master下发到本节点的任务，管理 Pod及Pod中的容器。每个kubelet进程都会在api-server上注册本节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控 容器和节点资源。
节点管理
kubelet在启动时通过API Server注册节点信息，并定时向API Server 发送节点的新消息，API Server在接收到这些信息后，将这些信息写入 etcd。这里有一些启动参数可以设置，比如，是否希望在启动的时候就进行注册本节点的信息（这个叫自注册模式），可以通过设置启动参数“--register-node”为true；比如，可以设置kubelet每隔多长时间向api-server报告节点状态，通过启动参数“--node-status- update-frequency”。等等。
Pod管理
kubelet通过以下几种方式获取自身Node上要运行的Pod清单。
- 文件：
- HTTP端口：
- API Server：kubelet通过API Server监听etcd目录，同步Pod列表。
所有以非API Server方式创建的Pod都叫作Static 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通过两类探针来检查容器的健康状态。
LivenessProbe探针，用于判断容器是否健康并反馈给kubelet。如果LivenessProbe探针探测到容器不健康，则kubelet将删除该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的值永远是Success。ReadinessProbe探针，用于判断容器是否启动完成，且准备接收请求。 如果ReadinessProbe探针检测到容器启动失败，则Pod的状态将被修改， Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的IP 地址的Endpoint条目。（这里需要补充“Endpoint Controller”的概念）
kubelet定期调用容器中的LivenessProbe探针来诊断容器的健康状况。那么到底通过什么特征来判断容器是否“健康”呢？有以下3种实现方式：
- ExecAction：在容器内部执行一个命令，如果该命令的退出状态码为0，则表明容器健康。
- TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果端口能被访问，则表明容器健康。
- HTTPGetAction：通过容器的IP地址和端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于等于400，则认为 容器状态健康。
LivenessProbe探针被包含在Pod定义的spec.containers.{某个容器}中。比如下面这个例子，展示了通过在容器内部执行一个命令来检查健康状态。
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/health
initialDelaySeconds: 5
periodSeconds: 5
kubelet在容器中执行cat /tmp/health命令，如果该命令返回的值为 0，则表明容器处于健康状态，否则表明容器处于不健康状态。
每次探测都将获得以下三种结果之一：
- Succeed：容器通过了诊断。
- Failed：容器未通过诊断。
- Unknown：诊断失败，因此不会采取任何行动。
cAdvisor资源监控
在Kubernetes集群中，应用程序的执行情况可以在不同的级别上监测到，这些级别包括：容器、Pod、Service和整个集群。用户如何查看各个级别的资源使用情况，从而更深入的了解应用的执行情况呢？——这就需要用到了cAdvisor。cAdvisor是一个开源的分析容器资源使用率和性能特性的代理工具，kubelet则通过cAdvisor获取其所在节点及容器的数据。cAdvisor自动查找所有在其所在Node上的容器，自动采集CPU、内存、文件系统和网络使用的统计信息。
从Kubernetes 1.8版本开始，性能指标数据的查询接口升级为标准的Metrics API，后端服务则升级为全新的 Metrics Server（cAdvisor在4194端口提供的UI和API服务于1.12版本关闭）。在新的Kubernetes监控体系中，Metrics Server用于提供Core Metrics（核心指标），包括Node和Pod的CPU和内存使用数据。其他 Custom Metrics（自定义指标）则由第三方组件（如Prometheus）采集和存储。
本文参考《kubernetes 权威指南》第4版