Kubernetes之Pod生命周期

简括：首先kubectl向 API 接口发送指令，随后kube-api 会调度到我们的kubelet,这个调度过程是由我们的etcd完成的存储，随后kubelet操作CRI ,由CRI完成容器环境的初始化。在初始化的过程中会先启动一个pause的基础容器（谷歌制作的一个非常简洁的一个容器），pause容器负责pod中容器的网络已经存心卷共享的。随后，pause进行一个或者多个或者没有 init C 的初始化。init初始化完成了。会正常退出。退出码为0，如果非零为不正常，会再根据我们的重定策略去判断是否继续重新执行。多个初始化的容器做完了之后，会进入到主容器main C .main C 在刚运行的时候，我们可以允许它启动一条命令，或者执行一个脚本都可以。main C 在结束的时候也会执行一个STOP的命令，交代一下后事，这个过程中会有readiness和liveness的参与，readiness只有成功检测了。pod的状态才会ready或者running。当我们的主容器里面的进程和liveness中检测不一致时候，那么就可以执行对应的重启命令，或者删除。

Pod简介

Pod 是 kubernetes 系统的基础单元，是由用户创建或部署的最小组件，也是 kubernetes 系统上运行容器化应用的资源对象。Kubernetes 集群中其他资源对象都是为 pod 这个资源对象做支撑来实现 kubernetes 管理应用服务的目的。 Kubernetes 集群组件主要包括主节点组件API Server、Controller Manager、Scheduler 以及子节点组件 kubelet、container Runtime（如docker）、kube-proxy 等。从与集群各组件交互角度讲述 pod 的创建、运行、销毁等生命周期，Pod 生命周期中的几种不同状态包括pending、running、succeeded、failed、Unknown。

与API Server交互

API Server 提供了集群与外部交互的接口，通过 kubectl 命令或者其他 API 客户端提交 pod spec 给 API Server 作为pod创建的起始。 Pod 与 API Server 交互的主要流程如下：

1. API Server 在接收到创建pod的请求之后，会根据用户提交的参数值来创建一个运行时的pod对象。
2. 根据 API Server 请求的上下文的元数据来验证两者的 namespace 是否匹配，如果不匹配则创建失败。
3. Namespace 匹配成功之后，会向 pod 对象注入一些系统数据，如果 pod 未提供 pod 的名字，则 API Server 会将 pod 的 uid 作为 pod 的名字。
4. API Server 接下来会检查 pod 对象的必需字段是否为空，如果为空，创建失败。
5. 上述准备工作完成之后会将在 etcd 中持久化这个对象，将异步调用返回结果封装成 restful.response，完成结果反馈。
6. 至此，API Server 创建过程完成，剩下的由 scheduler 和 kubelet 来完成，此时 pod 处于 pending 状态。

与scheduler交互

当提交创建 pod 的请求与 API Server 的交互完成之后，接下来由 scheduler 进行工作，该组件主要是完成 pod 的调度来决定 pod 具体运行在集群的哪个节点上。注意，此处声明一点，API Server 完成任务之后，将信息写入到 etcd 中，此时 scheduler 通过 watch 机制监听到写入到 etcd 的信息然后再进行工作。 Scheduler 读取到写入到 etcd 中的 pod 信息，然后基于一系列规则从集群中挑选一个合适的节点来运行它，调度时主要通过三步来确定 pod 运行节点：

• 节点预选：基于一系列预选规则（如 PodFitsResource 和 MatchNode-Selector 等）对每个节点进行检查，将不符合的节点过滤掉从而完成节点预选。
• 节点优选：对预选出的节点进行优先级排序，以便选出最适合运行 pod 对象的节点。
• 从优先级结果中挑选出优先级最高的节点来运行 pod 对象，当此类节点多个时则随机选择一个。

注：如果有特殊 pod 资源需要运行在特殊节点上，此时可以通过组合节点标签以及 pod 标签和标签选择器等来实现高级调度，如 MatchInterPodAffinity、MatchNodeSelector 和 PodToleratesNodeTaints 等预选策略，他们为用户提供自定义 Pod 亲和性或反亲和性、节点亲和性以及基于污点及容忍度的调度机制。

当 scheduler 通过一系列策略选定 pod 运行节点之后将结果信息更新至 API Server，由 API Server 更新至 etcd 中，并由 API Server 反映调度结果，接下来由 kubelet 在所选定的节点上启动 pod。

Kubelet组件启动pod

kubelet 组件的作用不单单是创建 pod，另外还包括节点管理、cAdvisor 资源监控管理、容器健康检查等功能。 启动pod流程分析 kubelet 通过 API Server 监听 etcd 目录，同步 pod 列表。如果发现有新的 pod 绑定到本节点，则按照 pod 清单要求创建 pod，如果是发现 pod 被更新，则做出相应更改。 读取到 pod 的信息之后，如果是创建和修改 pod 的任务，则做如下处理：

1. 为该 pod 创建一个数据目录
2. 从 API Server 读取该 pod 清单
3. 为该 pod 挂载外部卷
4. 下载 pod 所需的 Secret
5. 检查已经运行在节点中 pod，如果该 pod 没有容器或者 Pause 容器没有启动，则先停止pod里所有的容器进程。
6. 使用 pause 镜像为每个pod创建一个容器，该容器用于接管 Pod 中所有其他容器的网络。
7. 为 pod 中的每个容器做如下处理：1.为容器计算一个 hash 值，然后用容器的名字去查询对于 docker 容器的 hash 值。若查找到容器，且两者的 hash 值不同，则停止 docker 中容器中进程，并停止与之关联的 pause 容器，若相同，则不做处理。若容器被终止了，且容器没有指定的重启策略，则不做任何处理调用 docker client 下载容器镜像，并启动容器。

详述pod声明周期中的重要行为 除了创建应用容器（主容器及辅助容器之外，注意，如果集群中部署了 istio，则会在 pod 启动的时候注入一个新的和 istio 相关的容器，那是另一个美好故事的开端），还可以为 pod 对象定义其声明周期中的多种行为，如初始化容器、容器探测以及就绪性探测等。 容器生命周期的几种行为 初始化容器 初始化容器即 pod 内主容器启动之前要运行的容器，主要是做一些前置工作，初始化容器具有以下特征：

1. 初始化容器必须首先执行，若初始化容器运行失败，集群会一直重启初始化容器直至完成，注意，如果 pod 的重启策略为 Never，那初始化容器启动失败后就不会重启。
2. 初始化容器必须按照定义的顺序执行，初始化容器可以通过 pod 的 spec.initContainers 进行定义。

声明周期钩子函数

• Kubernetes 为容器提供了两种生命周期钩子：
• Poststart:于容器创建完成之后立即运行的钩子程序。
• preStop:容器终止之前立即运行的程序，是以同步方式的进行，因此其完成之前会阻塞 删除容器的调用

备注：钩子程序的执行方式有“Exec”和“HTTP”两种。 容器探测 容器探测分为存活性探测和就绪性探测容器探测是kubelet对容器健康状态进行诊断，容器探测的方式主要以下三种：

• ExecAction：在容器中执行命令，根据返回的状态码判断容器健康状态，返回0即表示成功，否则为失败。
• TCPSocketAction: 通过与容器的某TCP端口尝试建立连接进行诊断，端口能打开即为表示成功，否则失败。
• HTTPGetAction：向容器指定 URL 发起 HTTP GET 请求，响应码为2xx或者是3xx为成功，否则失败。

Pod终止过程 终止过程主要分为如下几个步骤：

1. 用户发出删除 pod 命令
2. Pod 对象随着时间的推移更新，在宽限期（默认情况下30秒），pod 被视为“dead”状态
3. 将 pod 标记为“Terminating”状态
4. 第三步同时运行，监控到 pod 对象为“Terminating”状态的同时启动 pod 关闭过程 5.第三步同时进行，endpoints 控制器监控到 pod 对象关闭，将pod与service匹配的 endpoints 列表中删除
5. 如果 pod 中定义了 preStop 钩子处理程序，则 pod 被标记为“Terminating”状态时以同步的方式启动执行；若宽限期结束后，preStop 仍未执行结束，第二步会重新执行并额外获得一个2秒的小宽限期
6. Pod 内对象的容器收到 TERM 信号
7. 宽限期结束之后，若存在任何一个运行的进程，pod 会收到 SIGKILL 信号
8. Kubelet 请求 API Server 将此 Pod 资源宽限期设置为0从而完成删除操作

此外 kubelet 除了启动之外，kubelet 中还有 cAdvisor，用于收集容器 CPU、内存、文件系统和网络使用情况等信息，与 prometheus 结合实现对集群内 pod 监控。 此外，除了上述三个组件在创建 pod 过程中的交互，还有 controller-manager 来保证 pod 处于用户期望状态（即保证 pod 永远处于存活状态）等功能以及 proxy 用于集群内 pod 之间通信等。