Kubernetes之Pod生命周期详解

简述

Kubernetes 是一种用于在一组主机上运行和协同容器化应用程序的系统，提供应用部署、规划、更新维护的机制。应用运行在 kubernetes 集群之上，实现服务的扩容、缩容，执行滚动更新以及在不一样版本的应用程序之间调度流量以测试功能或回滚有问题的部署。Kubernetes 实现管理服务的各项功能是经过定义各类类型的资源来实现的，如 deployment、pod、service、volume 等。下面经过该文章来简述 pod 的基础信息并详述 pod 的生命周期。

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 亲和性或反亲和性、节点亲和性以及基于污点及容忍度的调度机制。

预选策略

预选策略就是节点过滤器，例如 MathNodeSelector 实现的规则，以及 PodFitsResources 实现的规则等。执行预选操做时，若是不存在适合的节点，此时 pod 会一直处于 pending 状态，直到至少有一个可用节点。

支持的预选策略列举一下（1.10版本）：

CheckNodeCondition

General

NoDiskConflict

PodToleratesNodeTaintsPodToleratesNodeNoExecuteTaints

CheckServiceAffinity

MaxEBsVolumeCount

MaxGCEPDVolumeCount

MaxAzureDiskVolumeCount

CheckVolumeBinding

NoVolumeZoneConflict

CheckNodeMemoryPressure

CheckNodePIDPressure

CheckNodeDiskPressure

MatchInterPodAffinity

简单介绍几种：

• CheckNodeCondition：检查是否能够在节点报告磁盘、网络不可用或未准备好的状况下将 pod 对象调度其上。
• NoDiskConflict：检查 pod 对象请求的存储卷在此节点上是否可用，若不存在冲突则经过检查。
• MathNodeSelector：若 pod 对象定义了 spec.NodeSelector 属性，则检查节点标签是否能匹配此属性值。

优选函数

经常使用优选函数：

BalancedResourceAllocation

LeaastRequstedPriority

NodePreferAvoidPodsPriority

NodeAffinityPriority

TaintTolerationPriority

InterPodAffinityPriority

SelectorSpreadPriority

NodeLabelPriority

MostRequestedPriority

ImageLoccalityPriority

此外调度器支持为每一个优选函数指定一个简单的整数值表示权重，进行节点优先级分值的计算，计算公式以下：

FinalScoreNode = (weight1 priorityFunc1) + (weight2 priorityFunc2)+ ....

列举说明几个优选函数：

• TaintToleraionPriority：基于Pod资源对节点的污点容忍调度偏好进行其优先级的评估，它将 Pod 对象的 tolerations 列表与节点的污点进行匹配度检查，成功匹配的条目越多，则节点得分越低。
• NodeAffinityPriority：基于节点亲和性调度偏好进行优先级评估，它将根据 Pod 资源中的 nodeSelector 对给定节点进行匹配度计算，成功匹配到的条目越多则节点得分越高。

对于上述节点调度中还包括一些节点亲和度：硬亲和度和软亲和性、资源亲和调度。硬亲和调度和软亲和调度以及反亲和调度、污点容忍度等，都是 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 列表中删除
6. 若是 pod 中定义了 preStop 钩子处理程序，则 pod 被标记为“Terminating”状态时以同步的方式启动执行；若宽限期结束后，preStop 仍未执行结束，第二步会从新执行并额外得到一个2秒的小宽限期
7. Pod 内对象的容器收到 TERM 信号
8. 宽限期结束以后，若存在任何一个运行的进程，pod 会收到 SIGKILL 信号
9. Kubelet 请求 API Server 将此 Pod 资源宽限期设置为0从而完成删除操做

此外 kubelet 除了启动以外，kubelet 中还有 cAdvisor，用于收集容器 CPU、内存、文件系统和网络使用状况等信息，与 prometheus 结合实现对集群内 pod 监控。

此外，除了上述三个组件在建立 pod 过程当中的交互，还有 controller-manager 来保证 pod 处于用户指望状态（即保证 pod 永远处于存活状态）等功能以及 proxy 用于集群内 pod 之间通讯等。

本文由博云研究院原创发表，转载请注明出处。