K8S之pod生命周期

Pod的生命周期是通过Replication Controller来管理的。Pod的生命周期过程包括：通过模板进行定义，然后分配到一个Node上运行，在Pod所含容器运行结束后Pod也结束。在整个过程中，Pod处于一下4种状态之一：

Pending：Pod定义正确，提交到Master，但其所包含的容器镜像还未完成创建。通常Master对Pod进行调度需要一些时间，之后Node对镜像进行下载也需要一些时间；正在初始化中的Pod处于Pending状态
Running：Pod已被分配到某个Node上，且其包含的所有容器镜像都已经创建完成，并成功运行起来；
Succeeded：Pod中所有容器都成功终止，并且不会被重启，这是Pod的一种最终状态（所有容器都以“0”的状态退出）；
Failed：Pod中所有容器都结束了，至少有一个容器以非0状态退出。
Unknown：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

Kubernetes为Pod设计了一套独特的网络配置，包括：为每个Pod分配一个IP地址，使用Pod名作为容器间通信的主机名等。关于Kubernetes网络的设计原理将在第2章进行详细说明。
另外，不建议在Kubernetes的一个Pod内运行相同应用的多个实例。

Pod生命周期的几个阶段

1.当kubectl创建指令下达到api接口，被调度到kubelet上，kubelet首先调用CRI完成容器环境的初始化。

2.开始进入pod的生命周期，pod开始创建。

3.首先进行Pause基础容器创建，Pause负责网络和存储卷的共享等基础操作。

4.如果定义了Init容器，先进行Init容器(Init C)的创建，Init容器叫初始化容器，可以做一些初始化的操作，比如生成一些应用容器需要的文件。Init C只是用来初始化的，在初始化完成后Init C就会死亡，并不会跟随一直跟随pod的生命周期存在。Init C可以是多个，它不是必须的，也可以没有。多个Init C不能并行运行，一个Init C完成后，才能进行下一个Init C的构建。如果Init容器失败，k8s会不断重启该Pod，直到Init容器运行成功为止。然而，如果pod对应的restartPolicy为Never，那么它不会重启。在所有的nit容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。

需要注意的是：Init容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：

他们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的
它们可以包含实用工具和定制化代码来安装，但是不能出现在应用程序镜像中
应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
Linux Namespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。

5.开始创建主容器（Main C）

6.主容器Main C运行过程中，如果定义了start操作，首先进行一个start操作。

7.然后如果定义了readiness就绪检测，就执行readiness就绪检测，readiness检测成功完成后，pod才会显示running，才会对外提供服务。

8.如果定义了liveness存活检测，也会同时开始执行，如果liveness检测失败，kubelet杀死该Pod，然后根据重启策略restartPolicy决定是否对pod执行重启。若容器中不包含liveness探针，则kubelet认为该pod的liveness探针返回值永远是success。liveness存活检测是持续过程，一直持续到stop操作完成之后，Main C结束之前。

9.主容器Main C结束退出时，如果定义了stop操作，则先进行stop操作，stop操作完成以后才允许退出。

Pod的重启策略：

Pod 的重启策略有 3 种，默认值为 Always。

Always ：容器失效时，kubelet 自动重启该容器；
OnFailure ：容器终止运行且退出码不为0时重启；
Never ：不论状态为何， kubelet 都不重启该容器。

失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行十分钟后重置。

如果 restartpolicy 没有设置，那么默认值是 Always。RC 和 DaemonSet 必须指定重启策略为 Always。

Pod 的活性与就绪探针

探针机制

在 Kubernetes 中 Pod 是最小的计算单元，而一个 Pod 又由多个容器组成，相当于每个容器就是一个应用，应用在运行期间，可能因为某也意外情况致使程序挂掉。那么如何监控这些容器状态稳定性，保证服务在运行期间不会发生问题，发生问题后进行重启等机制，就成为了重中之重的事情，考虑到这点 kubernetes 推出了活性探针机制。

有了活性探针后能保证程序在运行中如果挂掉能够自动重启，但是还有个经常遇到的问题，比如说，在 Kubernetes 中启动 Pod，显示明明 Pod 已经启动成功，且能访问里面的端口，但是却返回错误信息。还有就是在执行滚动更新时候，总会出现一段时间，Pod 对外提供网络访问，但是访问却发生 404，这两个原因，都是因为 Pod 已经成功启动，但是 Pod 的的容器中应用程序还在启动中导致，考虑到这点 Kubernetes 推出了就绪探针机制。

Pod 两种探针

**LivenessProbe（存活探针）：**存活探针主要作用是，用指定的方式进入容器检测容器中的应用是否正常运行，如果检测失败，则认为容器不健康，那么Kubelet将根据Pod中设置的restartPolicy （重启策略）来判断,Pod 是否要进行重启操作，如果容器不提供存活探针，则默认状态为Success

**ReadinessProbe（就绪探针）：**用于判断容器中应用是否启动完成，当探测成功后才使 Pod 对外提供网络访问，设置容器 Ready 状态为 true，如果探测失败，则设置容器的 Ready 状态为 false。对于被 Service 管理的 Pod，Service 与 Pod、EndPoint （端点）的关联关系也将基于 Pod 是否为 Ready 状态进行设置，如果 Pod 运行过程中 Ready 状态变为 false，则系统自动从 Service 关联的 EndPoint （端点）列表中移除，如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint （端点）列表。通过这种机制就能防止将流量转发到不可用的 Pod 上。

容器探针的探测方式：

探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序：

ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。

两种探测方式的区别

ReadinessProbe 和 livenessProbe 可以使用相同探测方式，只是对 Pod 的处置方式不同：

livenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。
readinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。