Kubernetes Pod管理与资源清单实战：从生命周期到故障排查

接着说 Kubernetes，上一篇把集群搭建、基础概念和常用 kubectl 命令过了一遍，这一篇专门深入到 Pod 管理和资源清单。平时运维排查，绝大部分时间都花在 Pod 上：不是起不来，就是起来了又崩，或者资源不够被挤掉。你如果能把 Pod 的底层逻辑和资源清单这块吃透，后面遇到任何“玄学”问题基本都能从根上找到方向。

这篇文章适合刚上手 K8s 的运维、开发，也适合已经用了一段时间但老是被 OOMKilled、CrashLoopBackOff 折腾的人。我会把 Pod 为什么要这样设计、生命周期里有哪些坑、资源清单怎么写才算合理，以及我用 kubectl 排查问题的一整套习惯全讲清楚。里面的命令和 YAML 都可以直接抄，但更建议你理解后再改，因为无脑复制最容易踩坑。

1. Pod 是 K8s 的最小调度单元：先搞清楚它为什么设计成这样

很多初学者刚接触 Pod 时都会问一句：我直接用容器不就行了吗？为什么要多套一层 Pod 出来？这个问题想不明白，后面写资源清单就会不自觉瞎写，排障时也会走很多弯路。

1.1 为什么不直接调度容器

K8s 不直接管理单个容器，而是管理 Pod。Pod 可以理解为一组容器的“合集”，里面的容器共享同一个网络命名空间、同一批存储卷，彼此通过 localhost 就能互相访问。这带来一个非常实用的效果：Pod 的 IP 才是调度和访问的单元，容器自身的 IP 反而没有那么重要。

这么设计的关键原因在于，容器本身是“易碎”的。一个容器挂了，重启之后 IP 会变，文件系统状态也可能被重置。如果直接拿容器 IP 做服务发现，整个集群会乱成一团。而 Pod 作为外层包装，给内部容器提供了一个相对稳定的“身份”，你访问某个业务，只要访问 Pod IP 或 Service 的抽象地址就行，不用关心里面容器到底重启了几次。

还有一个现实原因：很多业务不是单一进程就能搞定的。比如一个 Web 服务旁边可能要挂一个日志采集容器，一个网络代理容器，或者一个负责初始化配置的容器。它们需要紧密协作、共享网络，这种场景用“一个 Pod 内多容器”的方式来组织，比拆到多个 Pod 再靠网络通信要简单可靠得多。

1.2 Pod 内多容器的协作模型

Pod 里多容器最经典的搭档方式是“主容器 + 边车容器”。主容器跑核心业务，边车容器做辅助工作。举个例子，业务容器把日志写到本地文件，边车容器用 emptyDir 共享目录读到日志，再转发到日志平台，这种模式下业务代码根本不用关心日志上报逻辑。

还有人会把配置变更、启动前置检查放到 InitContainer 里来做。InitContainer 是 Pod 启动时先执行的容器，它跑完且成功退出后，主容器才会启动。比如应用依赖某个数据库表结构初始化完成，你可以写一个 InitContainer 循环探测数据库，等条件满足之后主容器再起来，这样可以避免主容器一启动就连不上依赖而反复崩溃。

不过我个人建议，不要为了“炫技”硬往一个 Pod 里塞多个容器。绝大多数业务场景就是一个 Pod 一个容器，多容器只在确实有强耦合需求时才用。塞多了会带来额外的问题，比如日志收集要单独处理、容器间协调变复杂、出问题时的排查链路更长。

1.3 从业务角度看 Pod 对外提供的三种能力

从使用角度，Pod 对外核心能力就是三个。

第一是网络入口。Pod 有自己的 IP，通过 Service 或 Ingress 暴露出来。这里记住一句话：Service 背后挂的是 Pod，不是容器。你做网络排查时，先看 Pod IP 通不通，再看 Service 转发对不对，层次就清晰了。

第二是监听生命周期。Pod 本身有状态机，从 Pending 到 Running 到 Succeeded/Failed，每一步都对应具体的调度和运行状态。后面我会专门讲这部分。

第三是接收资源配额。你给 Pod 写的 requests 和 limits，是集群调度器做决策的重要依据，也是 Pod 在节点上被驱逐和限流时的重要依据。很多线上事故，最后都能归结到资源清单写得不合理。

把这三个能力想清楚，你就明白 Pod 不是简单地把容器包一层，而是一整套“调度、网络、资源”的最小抽象单元。

2. Pod 的完整生命周期：从创建到销毁，每个阶段都要盯什么

Pod 创建之后不会一直稳定在一个状态，它会经历创建、运行、终止等不同阶段。运维排查第一件事就是看 Pod 当前处于什么状态，所以状态机的解读必须熟练。

2.1 常见状态解读

kubectl get pod看到的 STATUS 列常见值大概有下面几个。

Pending 表示 Pod 已经被 API Server 接受，但还没有完成调度，或者镜像还在拉取中。最常见的两种原因：一是没有节点能满足资源请求，二是节点上有污点而 Pod 没有对应容忍。注意，Pending 并不等于卡死，有时候大镜像拉取确实会在这里停留一段时间。

Running 是健康和准备就绪的常见状态，表示 Pod 已绑定到节点，至少有一个容器在运行，或者正在启动。但这不代表业务就正常，后面还得结合 Ready 列和具体探针来看。

Succeeded 表示 Pod 中所有容器都成功退出，这种一般出现在任务型 Pod 上，比如跑完一个批处理任务。Failed 则相反，容器以非零状态退出。这两种状态对于普通常驻服务来说都属于异常，尤其是 Failed，往往说明业务进程起不来或者中途崩了。

Unknown 表示 API Server 无法获取 Pod 状态，比如节点失联、网络分区。遇到这个状态，往往不是 Pod 本身的问题，而是节点层面的故障。

除了 Pod 状态，你还会在 describe 里看到容器状态：Waiting、Running、Terminated。Waiting 可能是镜像拉取中、依赖初始化中；Terminated 说明容器已经退出，要重点关注退出码。退出码 137 通常是内存超限被 kill，143 是 SIGTERM，0 是正常退出。

2.2 重启策略怎么选

restartPolicy 参数有三个可选值：Always、OnFailure、Never。它决定的是 Pod 内容器退出后 kubelet 是否自动重启容器，不是重启 Pod。

Always 是默认值，也是常驻服务最常用的策略。不管容器正常退出还是异常退出，都会重启，保证服务尽量在线。OnFailure 只在容器异常退出时才重启，适合批处理任务，正常跑完就不重跑了。Never 就是不重启，适合那种你希望它只跑一次、结果明确的任务。

有个容易踩的坑：这个策略是写在 Pod 层面的，而 Deployment 这类控制器创建出来的 Pod，往往会把 restartPolicy 强制设为 Always。如果你试图在 Deployment 里写 OnFailure，kubectl apply 时可能会报错或者被忽略。如果是临时跑一次性任务，用 Job 而不是裸 Pod 更合理。

2.3 静态 Pod 与普通 Pod 的区别

静态 Pod 是个容易忽略但非常重要的概念。它不经过 API Server 调度，而是由 kubelet 直接根据节点上/etc/kubernetes/manifests目录下的 YAML 文件来创建和维护。控制平面的 etcd、kube-apiserver、kube-controller-manager 等组件通常就是用静态 Pod 方式跑起来的。

静态 Pod 的排障思路和普通 Pod 不一样。普通 Pod 出问题你去看 Deployment、看 ReplicaSet；静态 Pod 出问题要检查节点上的 manifests 目录和 kubelet 日志。另外，静态 Pod 在kubectl get pod里能看到，但通常不能直接通过 API 删除，你删除后 kubelet 会立即再拉起一个，除非你先把对应的 YAML 文件移走。

3. 资源清单：写 Pod 的 YAML 时应如何定义资源

资源清单这个词，说人话就是 YAML 文件，它描述了你希望集群帮你跑成什么样。Pod 的 YAML 是所有工作负载的基础，Deployment、DaemonSet、StatefulSet 本质上都是在 Pod 模板外面再加一层控制逻辑。

3.1 资源清单的核心字段与结构

先看一个最简但完整的 Pod 资源清单，后面我会逐步加上资源配额和探针。

apiVersion: v1 kind: Pod metadata: name: demo-pod namespace: default labels: app: demo env: prod spec: containers: - name: demo-container image: nginx:1.25 imagePullPolicy: IfNotPresent ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi

apiVersion 和 kind 决定这个 YAML 要被哪个控制器处理。metadata 里的 name、namespace、labels 用来标识和筛选对象。spec 是核心，容器列表、镜像、端口、资源配额都在这里。

有一个字段要提醒一下：imagePullPolicy。默认规则是，如果镜像 tag 是 latest，则总是拉取；如果是具体版本号，则本地有就用本地的。但如果你想省流量、提高启动速度，可以显式写 IfNotPresent。反过来，如果你希望每次发布都拉最新镜像，可以写 Always。这个字段不写也行，但养成显式写的习惯，避免镜像更新策略不统一引起线上环境差异。

3.2 requests 和 limits：调度与运行的两道门槛

requests 是 Pod 在调度阶段的需求声明。调度器看到这个值，就会去找一个“剩余可分配资源足够”的节点。limits 是 Pod 运行阶段不能超过的资源上限。CPU 属于可压缩资源，超过 limits 会被限流但不被杀；内存属于不可压缩资源，超过 limits 会触发 OOMKilled。

CPU 单位是核心数，1 表示完整一个核，也可以写成 1000m，100m 就是 0.1 核。内存单位支持 E、P、T、G、M、K，也有对应的 Ei、Pi、Ti、Gi、Mi、Ki。特别注意 Mi 和 M 的差异，Mi 是 1024 的二进制单位，M 是 1000 的十进制单位。你写 128M 和 128Mi 对最终内存的分配结果不一样，关键业务请统一用 Mi、Gi 这种单位，避免理解偏差。

requests 不是越高越好，也不是越低越好。调高了，节点调度容易不满足，Pod 会一直 Pending；调低了，节点上可能超卖，高负载时服务质量没保证。limits 也不是必须写的。CPU limits 写得太低会导致应用被频繁节流，CPU 使用率看着不高但延迟很高。内存 limits 写太低会直接触发 OOMKilled，而且往往是流量稍微一涨就崩。

我遇到过很多次线上事故，原因都是这一类：业务正常流量下内存占用 300Mi，limits 写了 256Mi，结果高峰期直接被 kill。反过来也有，requests 写得过高，比如一个 low traffic 的 Pod 请求了 4 核，结果一台 8 核节点只放了两个 Pod 就满了，剩下业务全部 Pending。

合理的做法是先不设 limits，或者设一个平时不会触及的比较宽的值，跑一段时间看监控，取 P99 或者峰值的 1.2 到 1.5 倍作为 limits，requests 则取平时稳态的 70% 到 80% 左右。等你有足够的监控数据后，再来收紧也不迟。

3.3 资源清单实战：加上探针和健康检查

Pod 资源清单里最容易被忽略但又极其重要的就是探针。没有探针，K8s 只能靠进程是否活着来判断状态。有时候进程活着但已经无法服务，比如线程池满了、端口卡死、数据库连不上但进程没退出，这种情况流量打过来就会大量超时。

探针有三类：livenessProbe、readinessProbe、startupProbe。

livenessProbe 决定容器是否要重启。如果失败了，kubelet 会按照 restartPolicy 杀掉并重启容器。readinessProbe 决定 Pod 是否要接入 Service 的流量。如果失败了，Pod 的 Ready 列会变成 0/1，但从集群角度看 Pod 不会重启。startupProbe 是给那些启动时间很长的应用准备的，它先于另外两个探针执行，探针成功后才开始由 livenessProbe 接管。

一个具备探针的 Deployment 示例如下：

apiVersion: apps/v1 kind: Deployment metadata: name: demo-deploy namespace: default spec: replicas: 3 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: - name: demo image: registry.example.com/demo:v1.2.3 ports: - containerPort: 8080 resources: requests: cpu: 200m memory: 256Mi limits: cpu: 1 memory: 512Mi readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 2 failureThreshold: 3 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 15 timeoutSeconds: 2 failureThreshold: 3

这里有三个关键细节值得展开。第一个，探针的initialDelaySeconds不能拍脑袋定。如果你的业务启动需要 30 秒，你写 5 秒，那 Pod 启动后很快就会被 liveness 杀掉，陷入反复重启。我见过不少“启动时间特别长的 Java 应用”被探针误杀，就是因为 initialDelaySeconds 太短。现在有 startupProbe 的情况下，可以把启动阶段判断交给它，initialDelaySeconds 不必设太长。

第二个，探针的路径要和业务实际健康检查接口对齐。很多团队统一用/healthz，但有些服务根本没有这个接口，或者接口需要鉴权，探针一发就返回 403，导致 Pod 永远不 Ready。最省心的方法是让业务暴露一个不依赖外部中间件、只检查自身进程状态的最小健康接口，探针就走这个接口。

第三个，探针的failureThreshold不要太小。网络抖动、进程短时间高负载都可能导致探针失败一次。如果 threshold 是 1，那一次抖动就可能让 Pod 反复重启，故障波动反而被放大。生产中我一般用 2 到 3。

4. Pod 管理实战操作：通过 kubectl 管理一个高可用应用

资源清单写好了，怎么把它落到集群里，怎么排查，这就要靠 kubectl。这部分我直接按实际运维场景来讲，每一步都是我自己验证过的高频用法。

4.1 创建、更新和删除的正确姿势

创建业务应用时，我不建议直接kubectl run或kubectl create一个裸 Pod。裸 Pod 没有控制器管理，节点挂了 Pod 就没了，不会自动重建。生产环境最低标准也是 Deployment。

最常用的流程是先把 YAML 写好，然后执行：

kubectl apply -f demo-deploy.yaml

apply 是声明式操作，它会对比集群中现有状态和 YAML 期望状态，然后做增量更新。用 apply 比 create 更安全，因为同样的 YAML 你重复执行不会报错，而且可以随时通过修改 YAML 再 apply 来变更配置。

查看应用状态：

kubectl get deployment demo-deploy kubectl get pods -o wide -l app=demo kubectl describe pod demo-deploy-xxxx

describe 是我排查问题的第一步。它会把事件历史、容器状态、探针结果、调度情况都列出来，比看单纯的 get 输出信息量大多了。

删除时注意，如果这个 Deployment 后面还要继续发布，建议保留 YAML，删除只是临时操作：

kubectl delete deployment demo-deploy

如果线上不通、业务异常，需要快速隔离，可以采用 scale 到 0 的方式停服：

kubectl scale deployment demo-deploy --replicas=0

这个操作不会删除 Deployment，之后你随时可以 scale 回来，很适合临时维护或故障止血。

4.2 进入容器看日志和排查问题

容器日志收集是每个运维都会面临的问题。在 Pod 正常运行时候，我可以直接看日志并存档：

kubectl logs -f demo-deploy-xxxx --tail=200

如果 Pod 里有两个容器，要指定-c 容器名，否则会提示你选择。如果容器崩溃导致看不到日志，可以使用--previous看上一次失败的日志：

kubectl logs -p demo-deploy-xxxx -c demo

需要进入容器内部排查时，前提是基础镜像里有 shell：

kubectl exec -it demo-deploy-xxxx -- /bin/sh

进入容器后重点关注：当前工作目录、环境变量、配置文件是否挂载、网络连通性。很多业务问题本质就是容器内环境和本地开发环境不一致，尤其是时区、字符集、依赖库版本这几类。

如果容器本身连 shell 都没有，或者应用启动即崩溃，进不去容器，可以临时起一个调试用的边车容器挂到同一个 Pod 里，但这种方式在生产环境比较折腾。更实用的做法是使用临时诊断 Pod，把业务 Pod 的 PVC 挂过来，或者直接抓业务日志文件。对于极端场景，我会把有问题的容器换成同镜像的 sleep 版本，等容器稳定下来再进内部排查。

4.3 标签、选择器和故障隔离

生产环境一旦有多个应用、多个版本，标签就非常重要。标签可以理解为给 Pod 贴的便签，selector 则是通过这些标签筛选操作对象的方式。

我在实践中养成了一个习惯：所有应用至少打上app、env、version三个标签。这样我可以实现流量的精细管理。比如发布新版本时，先单独灰度一批 Pod：

kubectl label pod demo-deploy-xxxx env=gray

然后配合 Service 的 selector，临时把某个版本的 Pod 从负载均衡中摘掉，或者只让测试流量进来。用暂停发布的方式做金丝雀更稳妥。具体做法是，在 Deployment 的更新策略里设置maxUnavailable: 0、maxSurge: 1，保证滚动更新期间服务不中断。新版起来后，如果监控指标正常，再逐步扩大到全量。

标签还能用来排查流量异常。比如 Service 转发到多个 Pod，某台节点上的 Pod 网络异常，你可以通过kubectl get pods -o wide --all-namespaces把 Pod 和节点对应起来，再用节点的网络工具做进一步诊断。

5. 常见问题排查与故障处理实录

到了这篇内容最实用的部分。我平时在群里看很多人问的问题，翻来覆去就那几类，这里我直接把高频问题和排查思路整理成清单，大家以后遇到类似情况可以直接对照。

5.1 高频问题速查表

上面最容易被忽视的是 ImagePullBackOff 和 OOMKilled 这两类。很多人遇到镜像拉取失败，第一反应是网络问题，但生产环境里更多是私有仓库的认证过期，或者镜像 tag 不存在。我之前在某公司就遇到过一次事故，新版本镜像推上去，YAML 里 tag 写错一个字母，结果所有节点都报 ImagePullBackOff，业务直接断服，整个排查过程因为没先看事件，浪费了十几分钟。现在我的习惯是任何排障第一步都先执行kubectl describe pod，把事件看明白再动手。

OOMKilled 这类问题也很有代表性。容器退出码是 137，状态里写着 OOMKilled，原因多半是内存 limits 设得太死。有时候也不一定是要调 limits，而是业务代码确实有内存泄漏。如果内存占用一直上涨不回落，先查代码和 JVM 或运行时配置；如果只是高峰期短暂超出，才是调 limits 的合理时机。

5.2 排障时的三个习惯

排障思路比具体命令更重要。我总结成三个习惯。

第一个习惯是“先 describe，再 logs”。很多人一上来就 logs，但 log 只能看到业务输出，看不到调度事件和探针结果。describe 里能看到容器为什么被重启、探针为什么失败、镜像为什么拉不到，这些信息很多时候比应用日志更直接。

第二个习惯是“分清 Pod 和容器”。Pod 重启不代表容器重启，容器重启也不代表 Pod 重建。Deployment 滚动更新时 Pod 会重建；CrashLoopBackOff 时是容器在重启，Pod 还在。搞清楚这两层，你才能判断服务中断的范围和恢复方式。

第三个习惯是“保留现场”。应用崩溃后，容器被反复重启，日志也会被覆盖。排查前先想办法把现场日志和指标拉下来，尤其是 OOMKilled 前后的内存快照、崩溃时的访问日志。不然你可能连复现的机会都没有。

我还有一个偏“土”但很实用的小技巧：kubectl 默认的--namespace是当前上下文里的 namespace，很多人漏掉这个导致看错对象。排查多环境问题时，我会在命令前明确写-n 业务命名空间，避免在错误环境里操作。长时间操作的终端，我会先设置一个环境变量：

export KUBECONFIG=/path/to/prod-kubeconfig

这样能避免手滑把测试环境的配置应用到生产集群。实际上，更稳妥的做法是用不同上下文名称区分环境，比如prod、staging、dev，操作前先kubectl config get-contexts确认当前上下文。

5.3 资源监控是资源清单的地基

前面讲了这么多 requests 和 limits 的配置方法，但真正决定配置是否合理的，是你对业务资源使用情况的把握程度。没有监控数据，所有参数都是拍脑袋。

集群层面建议部署 metrics-server，配合kubectl top node和kubectl top pod查看实时资源占用。指标采集会有一定延迟，而且只能看当前值，不够用于趋势分析。更完整的方案是接入 Prometheus 这类时序监控系统，至少保留两周以上的数据，这样你才能看到业务高峰、低峰、扩容时的资源画像。

我每次给新业务设置资源配额时，会先按以下步骤走：不设 limits，只设一个保守的 requests，保证调度能过；运行一周后看监控，取内存和 CPU 的峰值数据；再结合未来流量预期，设置 limits 和最终 requests；之后每两周复盘一次监控数据，及时调整。

这套流程听起来简单，但真正能坚持做下来的团队并不多。很多线上事故的根源不是 K8s 不够稳定，而是资源参数从未根据真实负载校准过。

6. 最后分享一点个人体会

写到这里，K8s Pod 管理和资源清单的主要内容基本都覆盖了。这些命令和 YAML 本身都不复杂，真正复杂的，是在生产环境里面对各种意外时不慌不乱、有章法地排查。

我个人最深的感受是：K8s 运维的本质不是学会敲命令，而是建立一套“期望状态”的管理思维。你在资源清单里写清楚你要什么，集群会自动帮你维持这个状态。写不清楚的地方，K8s 就会拿你的偏差反复“折磨”你。所以别把资源清单当成例行公事的配置文件，它其实是你和集群之间的一份契约。把这份契约写严谨了，Pod 管理这件事就成功了一大半。

如果你现在正被某个 Pod 问题困扰，我建议你先冷静下来，执行一次 describe，看看事件里说什么；再拿日志和资源占用对照一下；最后回到资源清单，看看 requests、limits、探针和镜像配置，绝大多数问题的影子都能在这里找到。