7. Pod生命周期与探针

# 一、Pod相位

1. Pod 生命周期的变化，主要体现在 Pod API 对象的 Status 部分，这是它除了Metadata 和 Spec 之外的第三个重要字段。其中，pod.status.phase，就是 Pod的当前状态，它有如下几种可能的情况：
- Pending。这个状态意味着，Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。
- Running。这个状态下，Pod已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。
- Succeeded。这个状态意味着，Pod里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。
- Failed。这个状态下，Pod 里至少有一个容器以不正常的状态（非 0的返回码）退出。这个状态的出现，意味着你得想办法 Debug这个容器的应用，比如查看 Pod 的 Events 和日志。
- Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给kube-apiserver，这很有可能是主从节点（Master 和Kubelet）间的通信出现了问题。

# 二、Pod创建过程

![未命名图片.png](/media/202406/4.7.15262251_image1.png)

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（调度器）通过其“watcher”觉察到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将确认信息

# 三、Pod生命周期中行为

![未命名图片.png](/media/202406/4.7.15262251_image2.png)

# 四、初始化容器

1. 初始化容器（init container）即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征。
- 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么Kubernetes需要重启它直到成功完成。
- 每个init容器都必须在下一个init容器启动之前成功完成
2. 初始化容器作用
- 包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的
- 包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这样的工具。
- 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
- Init容器使用LinuxNamespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
- 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。
3. 特殊说明
- 在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出
- 如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用RestartPolicy策略
- 在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true
- 如果Pod重启，所有Init容器必须重新执行
- 对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod
- Init容器具有应用容器的所有字段。除了readinessProbe，因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行
- 在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误

# 五、生命周期钩子函数

1. 容器生命周期钩子使它能够感知其自身生命周期管理中的事件，并在相应的时刻到来时运行由用户指定的处理程序代码。Kubernetes为容器提供了两种生命周期钩子。
- postStart：于容器创建完成之后立即运行的钩子处理器（handler）
- preStop：于容器终止操作之前立即运行的钩子处理器，它以同步的方式调用，因此在其完成之前会阻塞删除容器的操作的调用。
2. 钩子处理器的实现方式有“Exec”和“HTTP”两种，
- exec：执行一段命令
- HTTP：发送HTTP请求

# 六、容器探测

1. kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器（handler）进行定义。Kubernetes支持三种处理器用于Pod探测。
- ExecAction：在容器中执行一个命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态。
- TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。
- HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，否则为失败。
2. 每次探测都将获得以下三种结果之一：
- 成功：容器通过了诊断。
- 失败：容器未通过诊断。
- 未知：诊断失败，因此不会采取任何行动

# 七、容器的重启策略

1. 容器程序发生崩溃或容器申请超出限制的资源等原因都可能会导致Pod对象的终止，此时是否应该重建该Pod对象则取决于其重启策略（restartPolicy）属性的定义。
- Always：但凡Pod对象终止就将其重启，此为默认设定。
- OnFailure：仅在Pod对象出现错误时方才将其重启。
- Never：从不重启。
2. 需要注意的是，restartPolicy适用于Pod对象中的所有容器，而且它仅用于控制在同一节点上重新启动Pod对象的相关容器。首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长依次为10秒、20秒、40秒、80秒、160秒和300秒，300秒是最大延迟时长。事实上，一旦绑定到一个节点，Pod对象将永远不会被重新绑定到另一个节点，它要么被重启，要么终止，直到节点发生故障或被删除。

# 八、存活性检测

## 简介

用于判定容器是否处于“运行”（Running）状态；一旦此类检测未通过，kubelet将杀死容器并根据其restartPolicy决定是否将其重启；未定义存活性检测的容器的默认状态为“Success”。

## exec探针
设置exec探针：通过在目标容器中执行由用户自定义的命令来判定容器的健康状态，若命令状态返回值为0则表示“成功”通过检测，其值均为“失败”状态。 示例：使用busybox镜像创建/tem/headthy文件，1分钟后删除。如果文件存在，检测通过，否则为失败 定义liveness-exec.yaml文件 ![未命名图片.png](/media/202406/4.7.15262251_image3.png) 在60秒之内使用“kubectl describe pods/liveness-exec”查看其详细信息，其存活性探测不会出现错误。而超过60秒之后，再次运行“kubectl describe pods/liveness-exec”查看其详细信息可以发现，存活性探测出现了故障 ![未命名图片.png](/media/202406/4.7.15262251_image4.png) 待容器重启完成后再次查看，容器已经处于正常运行状态，直到文件再次被删除，存活性探测失败而重启。从下面的命令显示可以看出，liveness-exec已然重启 ![未命名图片.png](/media/202406/4.7.15262251_image5.png)

## 设置HTTP探针
基于HTTP的探测（HTTPGetAction）向目标容器发起一个HTTP请求，根据其响应码进行结果判定。“spec.containers.livenessProbe.httpGet”字段用于定义此类检测，它的可用配置字段包括如下几个。

- host <string>：请求的主机地址，默认为Pod IP
- port <string>：请求的端口，必选字段。
- httpHeaders <[]Object>：自定义的请求报文首部。
- path <string>：请求的HTTP资源路径，即URL path。
- scheme：建立连接使用的协议，仅可为HTTP或HTTPS，默认为HTTP。

示例：通过nginx生成一个index.html页面文件，请求的资源路径为“/index.html”，地址默认为Pod IP，端口使用了容器中定义的端口名称HTTP，然后删除文件，再次查看pod信息 定义liveness-http.yaml文件 ![未命名图片.png](/media/202406/4.7.15262251_image6.png) 而后查看其健康状态检测相关的信息，健康状态检测正常时，容器也将正常运行：![未命名图片.png](/media/202406/4.7.15262251_image7.png) 接下来借助于“kubectl exec”命令删除index.html测试页面： `$ kubectl exec liveness-httpget rm /usr/share/nginx/html/index.html`  而后再次使用“kubectl describe pod/liveness-httpget”查看其详细的状态信息 ![未命名图片.png](/media/202406/4.7.15262251_image8.png)

## 设置TCP探针
向容器的特定端口发起TCP请求并尝试建立连接进行结果判定，连接建立成功即为通过检测。“spec.containers.livenessProbe.tcpSocket”字段用于定义此类检测，它主要包含以下两个可用的属性。

- host <string>：请求连接的目标IP地址，默认为Pod IP。
- port <string>：请求连接的目标端口，必选字段。

下面是一个定义在资源清单文件liveness-tcp.yaml中的示例，它向Pod IP的80/tcp端口发起连接请求，并根据连接建立的状态判定测试结果： ![未命名图片.png](/media/202406/4.7.15262251_image9.png)

# 九、就绪性检测

## 简介

1. 用于判断容器是否准备就绪并可对外提供服务；未通过检测的容器意味着其尚未准备就绪，端点控制器（如Service对象）会将其IP从所有匹配到此Pod对象的Service对象的端点列表中移除；检测通过之后，会再次将其IP添加至端点列表中。
2. 与存活性探测机制相同，就绪性探测也支持Exec、HTTP GET和TCP Socket三种探测方式。
3. 与存活性探测触发的操作不同的是，探测失败时，就绪性探测不会杀死或重启容器以保证其健康性，而是通知其尚未就绪，并触发依赖于其就绪状态的操作（例如，从Service对象中移除此Pod对象）以确保不会有客户端请求接入此Pod对象。

## 检测参数
存活检测与就绪检测都可以配置如下参数：

- initialDelaySeconds：容器启动后要等待多少秒后才启动启动、存活和就绪探针， 默认是 0 秒，最小值是 0。
- periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
- timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
- successThreshold：探针在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。
- failureThreshold：探针连续失败了 failureThreshold 次之后， Kubernetes 认为总体上检查已失败：容器状态未就绪、不健康、不活跃。 对于启动探针或存活探针而言，如果至少有 failureThreshold 个探针已失败， Kubernetes 会将容器视为不健康并为这个特定的容器触发重启操作。 kubelet 会考虑该容器的 terminationGracePeriodSeconds 设置。 对于失败的就绪探针，kubelet 继续运行检查失败的容器，并继续运行更多探针； 因为检查失败，kubelet 将 Pod 的 Ready 状况设置为 false。
- terminationGracePeriodSeconds：为 kubelet 配置从为失败的容器触发终止操作到强制容器运行时停止该容器之前等待的宽限时长。 默认值是继承 Pod 级别的 terminationGracePeriodSeconds 值（如果不设置则为 30 秒），最小值为 1。

# 十、启动检测
有时候，会有一些现有的应用在启动时需要较长的初始化时间。这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。 技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对糟糕情况下的启动时间。 以gitlab为例，探针配置如下，需要注意的是配置了startupProbe就无需在readinessProbe和livenessProbe配置initialDelaySeconds
```yaml
readinessProbe:
 httpGet:
 path: /-/health
 port: http
livenessProbe:
 httpGet:
 path: /-/health
 port: http
startupProbe:
 httpGet:
 path: /-/health
 port: http
 failureThreshold: 10 # 失败次数
 periodSeconds: 60 # 检测间隔
```
应用程序将会有最多10分钟（60 * 10 = 600s）的时间来完成其启动过程。 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 restartPolicy 来执行进一步处置。