Kubernetes 入门最绕不开的一条主线就是 Pod 管理、资源清单的使用、Pod 生命周期、控制器这四件事。它们看起来是四个独立知识点实际是一条完整的逻辑链你在资源清单里用 YAML 描述期望的 Pod 长什么样控制器负责盯着集群里的实际状态朝这个期望收敛Pod 从提交到运行再到退出每一步都受生命周期规则约束。这篇文章就围绕这条主线展开把每个环节的原理、实操方法和踩坑经验一次讲透适合刚接触 Kubernetes 的开发者也适合写了几天 YAML 却总被各种异常状态绕晕的运维同学。1. 先把 Pod 这个最小单元彻底想明白1.1 为什么 Kubernetes 不直接管容器非要包一层 Pod很多人刚上手时最不习惯的就是这一点明明业务跑在容器里为什么操作的时候却总在跟 Pod 打交道要理解这个设计先记住一个结论Pod 是 Kubernetes 集群里的最小调度单元容器只是 Pod 内部的组成元素。之所以不直接把容器当作调度单位是因为现实里的很多应用并不是“一个容器就能搞定”的。比如一个 Web 服务旁边要跟一个收集日志的辅助进程或者一个主程序需要本地缓存进程协同工作。这些进程之间的协作非常紧密共享本地网络栈、共享同一个临时目录、需要一起被调度到同一台机器上。如果平台只认识单个容器就得靠各种外部机制去处理“把哪些容器放在一起”的问题复杂度会高很多。Pod 把这一层逻辑天然封装好了Pod 内的多个容器共享网络命名空间和存储卷彼此通过 localhost 就能通信数据目录也不用额外打通。换句话说Pod 是一个“调度盒子”盒子里装的是需要紧密协作的一组容器。盒子外部只关心它的整体状态盒子内部怎么分工是你自己说了算。这个抽象让平台的设计和用户的使用都简单了不少。1.2 Pod 内部共享了什么又为什么说它天生是临时的一个 Pod 真正运行时除了你声明的业务容器还会有一个基础设施容器来“占住”网络命名空间、PID 命名空间这类底层资源。业务容器启动后加入这个命名空间所以你会发现同一个 Pod 里的容器都能通过 localhost 访问彼此端口这在多个容器协作时非常方便。存储方面Pod 上挂载的 volume 对所有容器都是共享的。这也是 sidecar 模式能够成立的基础主容器把日志写到共享目录日志采集容器直接读同一个目录双方不需要额外协调。但 Pod 有两个天生特性决定了它不可被当作“长期固定资产”Pod 会被分配一个集群内唯一的 IPPod IP但这个 IP 不保证长期不变。Pod 的存储、文件系统、进程状态都是临时的重建之后一切归零。所以生产环境里你很难靠“记住某个 Pod 的名字和 IP”来设计架构。真正要依赖的是 Service、控制器这些上层机制让 Pod 可以被随时替换而业务不受影响。这也引出了下一节的问题到底用什么方式去创建和管理这些“随时可能被替换”的 Pod。1.3 命令式和声明式两种管理方式的分界线实际工作中管理 Pod 有两条路线。一条是命令式比如直接在终端里执行创建命令指定镜像名、副本数让系统立刻帮忙拉起资源。这种方式在调试、临时验证时非常高效几秒钟就能起一个环境。但问题也很明显命令是一次性的集群从头重建时所有操作还得再来一遍而且命令执行之后没有任何记录别人根本不知道这个环境是怎么来的。另一条是声明式核心就是资源清单YAML。你把期望的最终状态写进一个文件然后用命令提交给集群剩下的创建、维持、更新都由系统自动完成。这份清单可以放进版本管理走评审随时回滚也能被自动化流程调用。可以说凡是打算长期运行、需要多人协作、需要进生产的工作负载都应该走声明式。我自己刚入门时也觉得写 YAML 麻烦但真正接手长时间运行的服务后才体会到声明式的价值出问题时翻历史记录就能知道谁改了什么、改了为什么出错。下面这一节我就详细讲讲怎么把资源清单写明白。2. 资源清单 YAML 的编写思路与实操方法2.1 顶层字段先立住apiVersion、kind、metadata、spec一份 Kubernetes 资源清单最常见的就是四个顶层字段apiVersion、kind、metadata、spec。还有一个 status 是系统根据实际运行情况回填的写清单时不需要手工维护。apiVersion声明资源由哪个 API 组、哪个版本来解释。比如 Deployment 通常用apps/v1Service、Pod 这类基础资源用v1定时任务用batch/v1。版本写错提交时会直接报错。kind资源类型也就是你这份清单描述的是什么对象常见的有 Pod、Deployment、StatefulSet、Service、ConfigMap 等。metadata元信息包括名字、命名空间、标签labels、注解annotations。其中 labels 是后续 Service、控制器识别和选择 Pod 的关键规划得越早后面改起来越省事。spec对期望状态的完整描述。不同 kind 的 spec 内容差别很大这也是写清单时花时间最多的地方。刚写 YAML 时最容易犯的错是缩进问题。YAML 对空格极其敏感不能用 Tab 缩进冒号后面必须跟一个空格数组项用-开头嵌套层级全靠缩进对齐。我建议统一用两个空格作为一级缩进编辑器里如果能看到缩进辅助线能避免大量低级错误。2.2 不背字段用 kubectl explain 逐层查用 dry-run 生成模板新手写资源清单最大的障碍不是概念而是记不住字段。我的建议很直接不要背用kubectl explain。kubectl explain pod kubectl explain pod.spec kubectl explain pod.spec.containers这个命令会逐层告诉你每个字段的类型、含义、默认值甚至标注了哪些是必填项。我实际写清单时经常是一层一层往下查比如不确定容器的探针怎么写就执行kubectl explain pod.spec.containers.livenessProbe比去翻网页文档快得多。生成初始清单的另一个好办法是命令式转声明式kubectl create deployment web-demo --imagenginx:1.25 --replicas3 --dry-runclient -o yaml加上--dry-runclient -o yaml之后命令不会真的创建资源只会把对应的 YAML 打印到终端。拿这份输出当模板再按需往上补字段比自己从零开始写省事太多而且字段格式一定是对的。2.3 手写一个 Deployment字段拆解与常见误用下面是一份完整的 Deployment 清单我会逐段拆解说明apiVersion: apps/v1 kind: Deployment metadata: name: web-demo namespace: production labels: app: web-demo spec: replicas: 3 selector: matchLabels: app: web-demo template: metadata: labels: app: web-demo spec: containers: - name: web image: nginx:1.25 ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 3 periodSeconds: 5这份清单里有四个地方特别容易理解错第一spec.selector.matchLabels必须与template.metadata.labels匹配。Deployment 通过 selector 找到自己管理的 Pod如果两边的标签对不上控制器会无法正常工作甚至无法创建资源。换句话说template 里的标签是给 Pod 贴的“身份证”selector 是控制器用这张身份证来找人的规则。第二这份清单提交之后Deployment 并不会直接创建 Pod。它会先创建一个 ReplicaSet再由 ReplicaSet 把副本数维持到 3 个。这个层级关系是理解控制器的关键后面第四节还会展开讲。第三resources.requests用于调度判断告诉调度器这个 Pod 至少需要多少资源limits用于运行时限制防止容器无节制占用节点资源。注意limits 设置过小会导致容器被频繁杀掉或限流设置过大又可能造成资源浪费需要根据实际压测结果来定。第四提交清单时建议用kubectl apply而不是kubectl create。apply是声明式的它会记录 last-applied-configuration后续你修改 YAML 后再次 apply系统只做增量变更而不是整个重建。create则是创建式命令重复执行会报“已存在”的错误。提交这份清单kubectl apply -f deployment-web-demo.yaml kubectl get deployment web-demo -n production kubectl get pods -n production -l appweb-demo如果一切正常你会看到一个 Deployment、一个 ReplicaSet 和三个 Pod 依次出现。把这份清单吃透你就已经理解了 Kubernetes 声明式管理的一半精髓。3. Pod 生命周期从提交到退出的全过程3.1 五个阶段到底是谁在更新、什么时候变Kubernetes 把 Pod 的生命周期归纳为五个阶段查看kubectl get pod时 Status 列显示的就是这些阶段只不过有些时候会显示更具体的描述信息。先记住这张表阶段含义典型场景PendingPod 已被 API Server 接受但还没完成调度或容器还没全部启动调度器正在找节点、镜像拉取中、存储卷准备中RunningPod 已绑定到节点至少有一个容器在运行或正在启动正常服务运行中SucceededPod 中所有容器都成功退出且不会再重启一次性任务执行完成FailedPod 中至少有一个容器以非零状态退出且不会重启Job 执行失败、探针最终判定容器不健康且被终止UnknownAPI Server 无法获取 Pod 状态通常是节点失联节点宕机、网络分区这里要明确一点阶段不是由用户设置的而是 kubelet 收集节点上容器的实际状态后上报再由 API Server 汇总出来的。所以你永远不要试图在清单里去“指定阶段”那没有意义。你能做的是影响容器内部的运行方式从而间接决定 Pod 最终走向哪个阶段。另外要注意区分“阶段”和“状态描述”。kubectl get pod里你经常看到的不是简单的 Pending 或 Running而是像 ContainerCreating、ImagePullBackOff、CrashLoopBackOff 这种更细的描述。这些描述不等于生命周期阶段而是 kubelet 在某个阶段内部处理问题时给出的具体原因排查时信息量更大。3.2 Init 容器与三类探针启动、就绪、存活各管一段先讲 Init 容器。Init 容器是 Pod 里业务容器启动之前先执行完的初始化容器它们按顺序执行必须全部成功退出业务容器才会开始启动。典型用途包括等待依赖的数据库就绪、生成配置文件、执行数据迁移脚本。Init 容器失败时Pod 会按重启策略不断重试而且因为业务容器还没起来Pod 会一直停留在 Pending 或类似状态。所以如果 Pod 卡在初始化很久第一反应应该是去看 Init 容器的日志而不是业务容器日志。再讲探针。一个长期运行的业务容器通常会配置三类探针分管不同阶段startupProbe启动探针判断容器是否已经完成启动。适合启动特别慢的应用防止就绪和存活探针在启动阶段误判。readinessProbe就绪探针判断容器是否准备好接收流量。只有通过就绪检查的 Pod才会被加入 Service 的后端列表没通过就说明暂时不能接流量。livenessProbe存活探针判断容器是否还活着。不通过时kubelet 会按重启策略去重启容器。三类探针都支持 httpGet、tcpSocket、exec 三种方式。一个实战中常见的配置如下startupProbe: httpGet: path: /startup port: 8080 failureThreshold: 30 periodSeconds: 10 livenessProbe: httpGet: path: /health/live port: 8080 initialDelaySeconds: 10 periodSeconds: 10 readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5这里 startppProbe 的 failureThreshold 设得比较大是允许慢启动的应用在最长 300 秒内完成启动就绪探针比存活探针更频繁地检查流量可用性存活探针的路径与就绪探针分离避免因为业务繁忙导致健康检查超时而误杀。我踩过的坑是把 liveness 和 readiness 指向同一个复杂业务接口某次数据库抖动导致接口慢所有 Pod 被反复重启最后才发现探针并不是越严格越好。3.3 postStart / preStop 钩子与优雅终止的配合Pod 里还能声明两个生命周期钩子postStart和preStop。postStart在容器启动后立即执行适合做一些初始化收尾操作。但要注意这个钩子在执行期间会阻塞容器的启动流程如果执行时间过长或一直不返回容器会卡在启动状态所以钩子里的任务要尽量短小。preStop在容器被终止前执行常用于优雅下线通知上游把流量摘掉、预留时间处理完存量请求、执行清理脚本等。一个常见的 preStop 配合方式是这样lifecycle: preStop: exec: command: [/bin/sh, -c, curl -X POST http://localhost:8080/shutdown sleep 5]这里先调用应用内部的 shutdown 接口让应用停止接收新请求并开始处理存量请求再 sleep 几秒做缓冲。与钩子高度相关的一个参数是terminationGracePeriodSeconds。默认情况下Pod 被删除时kubelet 会先给容器发送 SIGTERM 信号然后等待一段宽限期默认 30 秒超时后才会发送 SIGKILL 强制终止。如果你的应用优雅退出需要更长时间就必须把terminationGracePeriodSeconds调大如果 preStop 钩子本身执行时间较长也会占用这个宽限期所以要给钩子执行留出余量否则应用可能还没优雅退出就被强杀了。3.4 restartPolicy 的边界它只管容器不管 PodrestartPolicy是 Pod 级别的一个字段有三个取值Always默认、OnFailure、Never。它决定的是当 Pod 内的容器异常退出时kubelet 是否在同一 Pod 内重启该容器。这里最容易产生误解。很多人以为 restartPolicy 会决定“整个 Pod 是否被重建”实际上不是。Pod 被重建这件事是控制器干的比如 ReplicaSet 发现 Pod 挂了会重新创建一个新 Pod而 restartPolicy 只管“同一个 Pod 内部kubelet 是否重启容器”。比如一个裸 Pod 的 restartPolicy 是 Always容器退出了kubelet 会在同一个 Pod 里反复拉起容器如果 restartPolicy 是 Never容器退出后 Pod 就停留在 Failed 状态没有人会帮你在别处重建。而放到 Deployment 下管理时容器的反复崩溃最终会让控制器认定 Pod 不健康进而按控制器的逻辑替换整个 Pod。搞清楚这条边界排查问题时才不会被“我明明配了重启策略为什么 Pod 还是没了”这种事绕进去。4. 控制器声明式运维的调度大脑4.1 控制循环到底在循环什么控制器是 Kubernetes 能实现“声明式运维”的核心机制。一句话概括它的工作方式不断观察实际状态然后向期望状态收敛。以 Deployment 为例当你声明期望 3 个副本时控制器会检查当前实际有几个 Pod。如果只有 2 个它就会新建一个如果 Pod 被人工删除它会补上一个如果你修改了镜像版本它会触发滚动更新把旧版本 Pod 逐步换成新版本。用户要做的只是描述“我想要什么”而不是一步步告诉系统“怎么去做”。这套机制的底层是控制循环Reconcile Loop控制器通过 API Server 的 watch 机制监听资源事件一旦发现某个时刻实际状态与期望状态不一致就调用 API 调整资源。因为循环是持续运转的所以即使中间出了问题只要集群还在运行控制器就会一直尝试把状态拉回正轨。这里有一条铁律必须记住不要手工去修改由控制器管理的 Pod。你手动删除或修改一个 Deployment 管理的 PodDeployment 会立刻按照期望副本数重新创建一个你手动改它的标签控制器会认为它不再属于自己同样会新建 Pod。想要变更就去改 Deployment 清单再重新 apply。4.2 五类控制器对比Deployment 不是万能钥匙控制器不止 Deployment 一种不同控制器对应不同的工作负载类型。最常用的五类可以看这张表控制器适用场景关键特征Deployment无状态服务Web 应用、API 服务等滚动更新、回滚、扩缩容日常最常用StatefulSet有状态服务数据库、消息队列等稳定网络标识、顺序启停、可绑定独立存储DaemonSet每个节点都要跑一个的守护进程日志采集、监控采集组件、节点级组件Job一次性批处理任务跑完就退出可配置失败重试次数CronJob定时任务按 Cron 表达式周期性触发 Job选型其实可以口诀化无状态应用默认选 Deployment需要固定身份标识、每个副本要独立存储、启动顺序有严格要求时选 StatefulSet需要和节点绑定的守护型组件选 DaemonSet跑完就结束的批处理任务选 Job定时周期性的任务选 CronJob。很多人一上来就用 Deployment 管理一切结果遇到有状态应用就出事。比如一个数据库实例被 Deployment 管着Pod 被删后新 Pod 是全新身份网络标识变了、数据也没了相当于把数据库推倒重建。StatefulSet 的存在就是解决这类问题每个 Pod 有稳定且唯一的标识可以按顺序启动和停止还能配合独立持久化存储保证重建后身份和数据都能恢复到之前的样子。4.3 滚动更新、回滚和扩缩容的实操参数Deployment 的更新策略有两种Recreate 和 RollingUpdate。Recreate 会把旧版本 Pod 全部删掉再创建新版本操作简单但有明确的停机窗口生产环境基本不用。RollingUpdate 是默认策略逐个替换保证服务不中断。滚动更新有三个关键参数需要理解spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25%maxUnavailable滚动更新过程中最多允许有多少比例的副本处于不可用状态。默认 25%即在更新期间集群内最多只会有 75% 的副本同时可用。maxSurge最多允许超出期望副本数的比例。比如期望 4 个副本maxSurge 25%更新时系统最多可以同时存在 5 个 Pod多出的一个用来先启动新版本确认可用后再删旧版本。revisionHistoryLimit保留多少个历史版本方便后续回滚。默认是 10保留太多会占用 etcd 存储保留太少则无法回滚到较远的版本。日常操作命令如下kubectl rollout status deployment/web-demo kubectl rollout history deployment/web-demo kubectl rollout undo deployment/web-demo --to-revision2 kubectl scale deployment/web-demo --replicas5rollout status可以查看滚动更新的实时进度rollout history列出历史版本rollout undo回滚到指定版本scale直接调整副本数。一个要记住的限制Deployment 创建之后spec.selector.matchLabels是不能修改的较新版本的 API Server 会直接校验拒绝。想改标签选择器只能删除 Deployment 重建。所以设计标签时一定要想清楚前期命名规则太随意后期改造成本很高。5. 高频故障的排查思路与避坑记录5.1 CrashLoopBackOff先看上一轮的日志再动手术CrashLoopBackOff 可能是新手遇到最多的故障状态。它的含义是容器反复启动后很快又退出系统不断拉长重启退避时间。排查的第一步永远不是去看 YAML 哪里写错而是看日志——尤其是上一次退出的容器日志kubectl logs pod-name --previous--previous参数取的是容器上一次退出的日志。因为容器一直在崩溃重启当前容器的日志可能是空的或者只包含启动瞬间内容上一轮的完整日志才有真正的错误信息。我处理过的 CrashLoopBackOff真正原因五花八门启动参数写错导致应用起不来、依赖的数据库没就绪、配置文件格式不对、健康检查接口路径不匹配。但所有问题最后都能在日志或 Events 里找到线索。所以记住排查顺序先kubectl describe pod看事件再kubectl logs --previous看日志最后才去检查清单配置。5.2 ImagePullBackOff原因就这几类逐个排除ImagePullBackOff 和 ErrImagePull 的根源都在拉镜像这一步常见的就几类镜像名打错或 tag 不存在比如把nginx:1.25写成了nginx:latest-typo镜像仓库需要认证但清单里没有配置 imagePullSecrets或者凭据过期镜像比较大拉取时间超过系统预期被判定为超时节点访问不到镜像仓库网络层面的问题。排查命令是kubectl describe pod pod-nameEvents 区域会直接给出具体错误。比如 message 里出现 manifest unknown 或 not found多半是 tag 或仓库地址写错出现 denied access 或 unauthorized则是认证问题。根据关键词对症处理不要盲目把 Pod 删了重来那样只会继续拉同一个盘。5.3 Pod 一直 Pending调度器为什么不选我的节点Pod 长时间停在 Pending基本可以断定是调度没有完成。用kubectl describe pod看 Events 时调度器通常会写明原因。最常见的几种所有节点 CPU 或内存不足无法满足 Pod 的 requests节点上有污点taint而 Pod 没有对应的容忍tolerationsPod 配置了 nodeSelector、节点亲和性条件但没有节点匹配依赖的存储卷没有就绪比如 PVC 一直处于 Pending 状态导致 Pod 无法挂载。这里面最容易让人懵的是明明集群里有好几台节点Pod 却一直 Pending。原因往往不是“没有节点”而是“没有满足条件的节点”。比如节点内存全被占满、有污点但你没容忍、或者节点有某种标签限制而你压根没注意到。排查时直接看 describe 输出的 Events 里 scheduler 的报错它会写清楚候选节点被排除的原因比瞎猜高效得多。5.4 探针配置不当引发的“假死”与“无限重启”探针配置错误比应用本身出错更难排查因为现象很具有迷惑性有时你看 Pod 明明是 Running但 Service 后面就是没有可用后端有时容器被无限重启却找不到任何业务报错。常见问题有这几类readinessProbe 端口写错探针永远失败Pod 永远不会被加入 Service 后端表现为服务间歇性不可用livenessProbe 路径写错健康检查返回 404kubelet 反复重启容器健康检查超时时间设得太短应用处理请求稍慢就被判定失败把依赖外部服务的接口当作健康检查一旦数据库抖动所有 Pod 被集体摘除或重启。我现在的避坑习惯是新服务第一次上线时先只配置 readinessProbe等运行稳定后再考虑 liveness健康检查接口要单独做一个轻量接口不依赖外部资源不加鉴权否则探针请求会被登录态拦截导致永久失败。5.5 我的固定排查顺序和常用命令清单最后分享一套我自己固定的排查顺序能省下很多绕弯路的时间先看状态概览kubectl get pod -o wide确认 Pod 状态和所在节点再看事件详情kubectl describe pod name重点读 Events 区域再看退出前日志kubectl logs name --previous如果涉及流量问题查kubectl get endpoints确认 Pod 是否在 Service 后端列表里如果怀疑节点资源问题查kubectl describe node node看资源分配和压力情况。常用命令整理成速查表场景命令查看 Pod 概览和节点kubectl get pods -o wide查看事件与详细状态kubectl describe pod查看实时日志kubectl logs -f查看上一轮退出日志kubectl logs --previous登录容器内部排查kubectl exec -it -- /bin/sh查看命名空间下所有资源kubectl get all -n最后说点我自己的习惯。每次遇到新环境的问题我都先把 describe 里的 Events 从头到尾读一遍再动手而不是急着翻业务日志——Events 是调度、拉镜像、挂存储、探针检测全过程的浓缩记录很多时候问题原因一句话就写在里面。Pod 管理、资源清单、生命周期、控制器这四块说白了就是“描述期望、观察现实、让系统自动收敛”的一整套工程实践。把这条主线想清楚后面再去学 Service、Ingress、存储持久化都会顺很多。