云原生入门系列｜第 3 集：一文吃透 Pod 生命周期！零基础看懂容器创建、重启与销毁全流程

前言各位云原生入门的小伙伴们大家好欢迎回到我们《云原生入门系列》专栏。在上一集第 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 来管理应用的底层原因手把手带你用控制器实现应用多副本部署、版本更新、回滚扩容敬请期待。