在Kubernetes集群中，在每个Node（又称为Minion）上都会启动一个Kubelet服务进程。该进程用于处理Master下发到本节点的任务，管理Pod及Pod中的容器。每个Kubelet进程都会在API Server上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源。

1.节点管理

        节点通过设置kubelet的启动参数“--register-node”，来决定是否向API Server注册自己。如果该参数的值为true，那么kubelet将试着通过API Server注册自己。在自注册时，kubelet启动参数还包含下列参数。

        --api-servers：API Server的位置

        --kubeconfig：kubeconfig文件，用于访问API Server的安全配置文件

        --cloud-provider：云服务商（IaaS）地址，仅用于公有云环境中

        kubelet 在启动时通过API Server注册节点信息，并定时向API Server发送节点的新消息，A PI Server在接收到这些信息后，会将其写入etcd中。通过kubelet的启动参数--node-status- update-frequency 可设置kubelet每隔多长时间向API Server报告节点的状态，默认为10s。

2.Pod管理

        kubelet主要通过下面三种方式来获取自身Node上要运行的Pod清单：

        1.静态Pod配置文件：kubelet通过启动参数--config指定目录下的Pod YAML文件（ 默认目录为/etc/kubernetes/manifests/),kubelet会持续监控指定目录下的文件变化，以创建或删除Pod。这种类型的Pod没有通过kube-controller-manager进行管理，被称为“静态Pod”。另外，可以通过启动参数--file-check-frequency设置检查该目录的时间间隔，默认为 20s。
        2.HTTP端点（URL)：通过--manifest-ur]参数设置，通过--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需要被删除，则kubelet会删除相应的Pod,并通过Docker Client删除Pod中的容器。

3.容器健康检查

        Pod 通过两 类探针来检查容器的健康状态。一类是 LivenessProbe 探针 ，用于判断容器是否健康并反馈给 kubelet, 如果 LivenessProbe 探针探测到容器不健康，则 kubelet 将删除该容器，并根据容器的重启策略做相应的处理；如果一个容器不包含 LivenessProbe探针，则 kubelet 会认为该容器的 Liveness Probe 探针返回的值永远是 Success 。 另一类是Readiness P robe 探针，用于判断容器是否启动完成，且准备接收请求 。 如果 ReadinessProbe探针检测到容器启动失败，则 Pod 的状态将被修改， Endpoint Controller 将从 Service 的Endpoint 中删除包含该容器所在 Pod 的 IP 地址的 Endpoint 条目 。目前还有第三种startup Probe探针，下面会列个表说出三个探针的差别

LivenessProbe 探针	Readiness Probe探针	startup Probe探针
存活探针，探测容器是否处于running	绪探针，探测容器服务是否可用	启动检查机制
存活探针是将检查失败的容器杀死，创建新的启动容器来保持pod的正常工作	就绪探针检查失败后，并不重启容器，而是将pod移除endpoint，就绪探针是保证了service中的pod都是可用的，确保客户端在与正常的pod交互，并且客户端是永远不知道存在问题的pod	避免一些容器因为业务长时间启动而被以上两种探针kill掉
initialDelaySeconds:初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败 periodSeconds:检查间隔，多久执行probe检查 timeoutSeconds：检查超时时间，探测应用timeout后为失败 successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次