前言
各位云原生入门的小伙伴们大家好，欢迎回到我们《云原生入门系列》专栏。在上一集第 2 篇内容中，我们带着大家通过minikube搭建完了专属的 K8s 本地实验环境，拥有了自己可以随意折腾、练手的单机 K8s 集群；而在系列开篇第 1 集里，我们搞懂了K8s 到底是什么、容器技术带来了怎样的运维革命，也初步认识了 Pod 是 K8s 世界里最小、最基础的运行单元。
很多刚入门的同学都会陷入一个误区：Pod 不就是一个装着容器的小盒子吗？只知道 Pod 里跑着我们的业务应用，却完全不了解 Pod 从创建到消亡的完整一生，搞不懂为什么 Pod 会无故重启、为什么应用一直处于Pending状态、容器启动失败到底卡在了哪个环节、K8s 又是怎么管控应用存活状态的。
今天这第 3 集内容，我们就抛开枯燥的官方文档定义，用大白话、生活化的比喻，把Pod 完整生命周期从头到尾拆解透彻，覆盖 Pod 从创建、调度、启动、运行、异常自愈、到最终销毁的全部阶段，讲清每个阶段的状态含义、底层执行逻辑、触发条件，顺便解决新手 90% 都会踩坑的 Pod 状态异常问题。学完本篇，你再看集群里的 Pod 状态，一眼就能读懂应用运行现状，彻底打通 K8s 最核心的底层运行逻辑。
一、先厘清基础：Pod 到底是什么？
在深入生命周期之前，我们先快速回顾巩固基础概念，和前两集内容做好衔接。
K8s 官方定义里：Pod 是 Kubernetes 集群中能够创建和部署的最小可部署计算单元。用生活化的比喻来讲：Docker 容器就像是一间单独的小房间，里面装着你的业务程序、运行环境、代码服务；而Pod 就是装了一间 / 多间小房间的独栋小屋，K8s 所有的调度、管理、扩缩容、自愈、运维操作，全部都是以 Pod 为单位，而不是单独的 Docker 容器。
绝大多数业务场景下，一个 Pod 里只会运行一个业务容器；只有日志采集、代理边车、服务网格这类配套辅助程序，才会在同一个 Pod 里运行多个容器。同一个 Pod 内的所有容器，共享同一个网络命名空间、存储卷、IP 地址、端口空间，天生内网互通。
你可以这么理解：Pod 是 K8s 的应用载体，你的所有代码服务，最终都会打包成容器，塞进 Pod 里运行。而 Pod 的一生，也就是我们业务应用的一生，它的完整生命周期，就是 K8s 管控应用的底层底层规则。
二、Pod 完整生命周期全流程拆解
官方把 Pod 的生命周期划分为 6 个核心阶段，全程用不可逆的状态流转推进，从创建到销毁一共一条完整链路，我全部转换成零基础能听懂的大白话，逐个阶段拆解底层逻辑、状态含义、集群执行的操作。
1. 阶段一：Pending（挂起待调度）
这是所有 Pod 诞生的第一个初始状态。当你通过kubectl命令、yaml 配置文件，向 K8s 的 API 服务器提交了创建 Pod 的请求之后，Pod 并不会立刻启动，首先会进入Pending挂起状态。
这个阶段 K8s 后台会做两件核心工作：
- 集群的调度器 Scheduler开始工作，遍历集群里所有的工作节点 Node，根据节点资源剩余、亲和性规则、污点容忍、资源限制等一系列配置，为这个 Pod 挑选一个最合适的服务器节点；
- 拉取 Pod 配置里声明的容器镜像，提前做好镜像拉取的前置校验。
新手踩坑高频问题：Pod 长时间卡在 Pending 不动怎么办？99% 的原因只有两个：① 集群节点资源不足，CPU、内存配额全部占满，没有节点能承接这个 Pod；② 你配置的节点亲和性、污点规则过于严格，集群里没有任何节点符合调度要求。
2. 阶段二：Running（正常运行态）
当调度器完成节点绑定，Pod 成功被调度到目标工作节点之后，就会进入整个生命周期里最核心的Running 正常运行状态。
这个阶段节点上的kubelet组件会全权接手工作：依次启动 Pod 内的所有容器、挂载声明的存储卷、注入配置信息、开通 Pod 网络、完成所有初始化程序，最终业务容器正常启动对外提供服务。
只要 Pod 不发生异常、不被手动删除、不触发驱逐规则，就会一直稳定保持在Running状态，你的业务服务也就一直在线运行。同时这个阶段，K8s 内置的探针机制会全程监控容器存活、服务可用性，为后续的自愈重启做准备。
3. 阶段三：Succeeded（所有容器成功执行完毕正常退出）
这个状态专门对应一次性任务 Pod。比如我们后续会学到的 Job 定时任务、离线批处理任务，这类 Pod 的设计逻辑就是：容器跑完指定任务就自动结束，不需要长期后台运行。
当 Pod 内所有容器都顺利执行完自身业务逻辑，正常退出、返回成功状态码之后，Pod 就会流转到Succeeded状态，代表任务圆满完成，Pod 生命周期正常收尾。
4. 阶段四：Failed（容器异常失败终止）
和上面的 Succeeded 刚好相反，当 Pod 内的任意业务容器，运行过程中报错崩溃、代码异常、启动失败、被系统强制终止，并且返回非 0 的异常退出码时，Pod 就会进入Failed失败状态。
常见触发场景：程序代码 bug 崩溃、容器启动命令错误、配置文件缺失、依赖服务无法连接、内存溢出 OOM 被杀掉，全部都会触发这个状态。同时这里会引出 K8s 核心的重启策略：绝大多数无状态服务配置了重启规则，Pod 不会停在 Failed 不动，kubelet 会自动触发容器重启，重新回到启动流程。
5. 阶段五：Terminating（终止销毁中）
当你手动删除 Pod、节点资源不足被集群驱逐、节点下线、生命周期超时触发销毁时，Pod 就会进入Terminating终止状态。
很多新手误区：以为删除 Pod 就是瞬间消失。实际上 K8s 有优雅删除机制：进入这个状态后，K8s 不会直接强制杀掉容器，首先会发送终止信号给业务容器，给程序预留默认 30 秒的优雅关闭时间，让服务完成请求收尾、数据落盘、连接断开；等待超时或者容器主动退出后，才会彻底删除 Pod 资源。
6. 最终状态：Pod 资源彻底清除
优雅删除流程全部走完后，集群里的 Pod 资源记录被完全清除，这个 Pod 完整生命周期正式结束。如果是 Deployment 控制器管理的 Pod，删除旧 Pod 的同时，控制器会立刻新建一个全新的 Pod 补位，保证服务副本数量稳定，这就是 K8s 自愈能力的底层来源。
三、新手必懂：Pod 重启策略与自愈底层原理
结合生命周期，给大家讲透前两集埋下的伏笔：为什么 K8s 的应用自带高可用自愈？
K8s 针对 Pod 一共内置 3 种默认重启策略，全部由节点 kubelet 组件管控：
- Always（默认策略）：只要容器异常退出，无条件重启 Pod。绝大多数线上无状态业务服务都用这个策略，实现服务故障自动自愈；
- OnFailure：只有容器异常失败（Failed 状态）才重启，正常跑完退出（Succeeded）就不重启；
- Never：永不重启，无论容器成功还是失败，都不会自动重启，专门用于一次性任务 Pod。
我们日常开发的 Web 服务、接口服务，全部默认使用Always策略。这也是云原生最大的优势：业务容器崩了不用人工运维，集群自动检测、自动重启、自动恢复服务，全程无需人工干预。
四、本篇总结 & 系列预告
到这里，我们就完整走完了 Pod 从无到有、从运行到消亡的完整一生。本篇核心知识点复盘：
- Pod 是 K8s 最小运行单元，是所有业务应用的运行载体；
- 完整生命周期 5 大状态：
Pending → Running → Succeeded/Failed → Terminating → 销毁； - 看懂 Pod 状态，就能瞬间判断集群里应用的运行问题；
- K8s 自愈能力、故障自动重启，全部依托 Pod 生命周期与重启策略实现。
弄懂了 Pod 的生命周期，你就摸到了 K8s 运维的门槛。下一集第 4 集，我们就来深入拆解管理 Pod 的灵魂控制器 ——Deployment，搞懂我们从来不会直接手动创建 Pod，全部用 Deployment 来管理应用的底层原因，手把手带你用控制器实现应用多副本部署、版本更新、回滚扩容，敬请期待。
