kubelet启动失败_《蹲坑学kubernetes》之10-1：kubelet原理详解

在kubernetes集群中，每个Node节点上都运行一个Kubelet服务进程，默认监听10250端口，接收并执行Master发来的指令，管理Pod及Pod中的容器。每个Kubelet进程会在API Server上注册所在Node节点的信息，定期向Master节点汇报该节点的资源使用情况，并通过cAdvisor监控节点和容器的资源。

一、Kubelet内部结构

如下kubelet内部组件结构图所示，Kubelet由许多内部组件构成：

图1：kubelet内部结构

1)Kubelet API：包括 10250 端口的认证 API、4194 端口的 cAdvisor API、10255端口的只读API以及10248端口的健康检查 API。

2)syncLoop：从API或者manifest 目录接收 Pod 更新，发送到podWorkers处理，大量使用channel处理来处理异步请求。

3)辅助的manager：如cAdvisor、PLEG、Volume Manager等，处理syncLoop以外的其他工作。

4)CRI：容器执行引擎接口，负责与container runtime shim通信。

5)容器执行引擎：如dockershim、rkt 等(注：rkt 暂未完成CRI的迁移)。

6)网络插件：目前支持CNI和kubenet。

二、了解Kubelet

1、节点管理

节点管理主要是节点自注册和节点状态更新：

• Kubelet可以通过设置启动参数 --register-node来确定是否向API Server注册自己；
• 如果Kubelet没有选择自注册模式，则需要用户自己配置Node资源信息，同时需要告知Kubelet集群上的API Server的位置；
• Kubelet在启动时通过 API Server 注册节点信息，并定时向 API Server 发送节点新消息，API Server在接收到新消息后，将信息写入Etcd中。

2、Pod管理

Kubelet以PodSpec的方式工作。PodSpec 是描述一个 Pod 的YAML或JSON对象。kubelet采用一组通过各种机制提供的PodSpecs(主要通过apiserver)，并确保这些PodSpecs中描述的Pod正常健康运行。

向Kubelet提供节点上需要运行的Pod清单的方法：

文件：启动参数--config指定的配置目录下的文件 (默认/ etc/kubernetes/manifests/)。该文件每 20 秒重新检查一次(可配置)。

HTTP endpoint (URL)：启动参数--manifest-url设置。每20秒检查一次这个端点(可配置)。

API Server：通过API Server监听Etcd目录，同步Pod清单。

HTTP server：kubelet 侦听 HTTP请求，并响应简单的API以提交新的Pod清单。

本章主要学习通过API Server监听Etcd目录，同步Pod列表的方式。

Kubelet 通过API Server Client(Kubelet启动时创建)使用Watch加List的方式监听"/registry/nodes/$当前节点名"和“/registry/pods”目录，将获取的信息同步到本地缓存中。

Kubelet监听Etcd，所有针对Pod的操作都将会被Kubelet监听到。如果发现有新的绑定到本节点的Pod，则按照Pod清单的要求创建该Pod。

如果发现本地的Pod被修改，则Kubelet会做出相应的修改，比如删除Pod中某个容器时，则通过Docker Client删除该容器。 如果发现删除本节点的Pod，则删除相应的Pod，并通过Docker Client删除Pod中的容器。

Pod 启动流程

图2：Pod 启动流程图

启动流程如下：

1)、用户通过Kubectl或其他API客户端提交Pod spec给API Server；

2)、API Server尝试着将Pod对象的相关信息存入Etcd中，待写入操作执行完成，API Server即会返回确认信息至客户端；

3)、API Server开始反映Etcd中的状态变化；

4)、所有的Kubernetes组件均使用Watch机制来跟踪检查API Server上的相关变动；

5)、Kube-scheduler通过其Watch觉察到API Server创建了新的Pod对象但尚未绑定至任何工作节点

6)、Kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新至API Server；

7)、调度结果信息由API Server更新至Etcd，而且API Server也开始反映此Pod对象的调度结果；

8)、Pod被调度到目标工作节点上的kubelet尝试在当前节点上调用Docker启动容器，并将容器的结果状态回送至API Server；

​9)、API Server将Pod状态信息存入Etcd中；

10)、在Etcd确认写入操作成功完成后，API Server将确认信息发送至相关的Kubelet，时间将通过它被接受。

3、容器健康检查

Pod通过两类探针检查容器的健康状态:

(1) LivenessProbe(存活探针)探针：用于判断容器是否健康，告诉Kubelet一个容器什么时候处于不健康的状态。如果LivenessProbe探针探测到容器不健康，则Kubelet 将删除该容器，并根据容器的重启策略做相应的处理。

(2)ReadinessProbe(就绪探针)探针：用于判断容器是否启动完成且准备接收请求。如果ReadinessProbe探针探测到失败，则Pod的状态将被修改。

Kubelet定期调用容器中的LivenessProbe探针来诊断容器的健康状况。LivenessProbe包含如下三种实现方式：

ExecAction：在容器内部执行一个命令，如果该命令的退出状态码为 0，则表明容器健康；

TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果端口能被访问，则表明容器健康；

HTTPGetAction：通过容器的IP地址和端口号及路径调用HTTP GET方法，如果响应的状态码大于等于200且小于400，则认为容器状态健康。

LivenessProbe和ReadinessProbe探针包含在Pod定义的某个主容器中。

4、Kubelet驱逐

Kubelet会监控资源的使用情况，并使用驱逐机制防止计算和存储资源耗尽。在驱逐时，Kubelet将Pod的所有容器停止，并将PodPhase设置为Failed。

5、cAdvisor资源监控

cAdvisor是一个开源的分析容器资源使用率和性能特性的代理工具，集成到Kubele中，当Kubelet启动时会同时启动cAdvisor，且一个cAdvisor只监控一个Node节点的信息。cAdvisor自动查找所有在其所在节点上的容器，自动采集CPU、内存、文件系统和网络使用的统计信息。cAdvisor通过它所在节点机的Root容器，采集并分析该节点机的全面使用情况。

6、Container Runtime

容器运行时(Container Runtime)是Kubernetes最重要的组件之一，负责真正管理镜像和容器的生命周期。Kubelet通过 容器运行时接口(Container Runtime Interface，CRI) 与容器运行时交互，以管理镜像和容器。

基于CRI容器引擎包括：

1)Docker

2)RKT

3)Virtlet

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！