在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次 |||