聊到容器编排Pod 几乎是绕不开的第一个门槛。很多人刚开始接触 K8s 时第一反应是“Pod 不就是一组容器的集合嘛”等真正上了生产环境就会发现这个理解既不准确也足够折磨人。我在维护一个模拟订单服务集群时踩过不少 Pod 的坑今天这篇就当是把自己对 Pod 的理解重新梳理一遍从为什么需要这种抽象、底层结构是什么、一份 YAML 如何变成真实运行的进程到多容器协作、探针配置和故障排查完整走一个来回。适合刚从 Docker 切换过来的同学也适合已经被 Pod 问题坑过、想系统性补一遍常识的同行。1. 为什么要单独造一个“Pod”从单容器到调度单元1.1 单容器方案的最小边界如果你是从 Docker 时代过来的脑子里默认的边界是“一个容器 一个进程 一个服务”。在开发环境里跑几个容器这个模型足够简单也足够快。但放到多节点集群里真实业务很难切成那么干净的“一个容器一个服务”。举一个最常见的例子日志采集。业务进程在容器里跑日志要实时送到统一的日志平台但业务进程本身不该负责日志转发更合适的做法是旁边再跑一个轻量的日志代理容器。问题来了这两个容器需要看到同一份日志文件需要互相访问最好还能一起启动、一起退出。如果平台依然只把容器当成最小单位就得靠人为拼凑“先起 A、再起 B、停止时先停 A、再停 B”的剧本一旦节点重启或者网络抖动这种顺序很容易乱成一团。我当时第一次接触 K8s 时也有一个误解以为 Pod 无非是把容器“绑得更紧一点”。后来发现完全不是这么回事Pod 是重新划了一条边界Pod 之外所有容器彼此隔离、通过网络通信Pod 之内一组容器共享环境、协同工作由平台统一管理命运。1.2 多进程绑定关系需要一个新的抽象单容器解决不了“强绑定”场景。所谓强绑定不光是“我要访问你”而是更苛刻的我要和你共享同一个本地网络栈、我要和你读取同一份本地文件、我要和你保持相同的调度位置。以网络为例。两个 Docker 容器要通信通常会走自定义 bridge 网络加端口映射跨节点之后还要考虑网络插件、服务发现、负载均衡。只要进程 A 和进程 B 必须同机部署、同网络栈、同生命周期这些机制全是多余的工作量。Pod 把这些常见的强绑定场景硬编码成了平台的原始能力不用你再单独写编排脚本。你可以把 Pod 想象成火车车厢Pod 是车厢容器是坐在里面的乘客车厢挂在列车上一起移动而不是把每个乘客都单独绑在轨道上自己跑。车厢决定了乘客在哪里出发、在哪里停靠、什么时候被整体挪走。1.3 “调度单元”最终解决了哪几类问题归纳起来Pod 作为调度单元解决了三类问题网络共享同一个 Pod 内所有容器共享网络命名空间容器之间用 localhost 直接访问不需要经过 Service 或负载均衡。存储共享同一批存储卷可以挂载给 Pod 内的多个容器数据在不同容器间流转时不需要走网络拷贝。生命周期绑定整个 Pod 作为一个整体被调度、被删除、被迁移容器层面的重启策略则交给 restartPolicy 分别控制。这三个能力组合起来才让 Sidecar、日志采集、服务网格这类伴生进程模式变得真正可用。你不需要再操心“伴生进程和主进程能不能落在同一台机器上”平台已经替你解决了。2. Pod 的内部构成沙箱容器、共享视角与状态机2.1 pause 沙箱那个一直占着位置却不执行业务的容器很多人第一次 describe 一个运行中的 Pod会发现容器列表里除了业务容器还有一个看起来没什么业务含义的容器。这个容器叫 pause也叫 infra 容器它才是 Pod 里最先启动、最晚退出的那个进程。pause 容器不执行业务代码它的职责是“占住资源”。K8s 在启动任何业务容器之前会先创建这个沙箱容器把网络命名空间、PID 命名空间按需、IPC 命名空间等内核资源都初始化好然后再让业务容器加入这些命名空间。这样即使业务容器崩溃被重启或者因为镜像问题被反复拉起Pod 的网络配置、IP 地址、挂载点不会因为容器销毁而全部重建。有一类排障场景特别能体现 pause 的意义业务容器里可能没有 ip、ss 这类网络排查工具你想看 Pod 的网络连接却无从下手。由于 pause 容器和业务容器共享网络命名空间在节点上通过 pause 容器的网络命名空间运行 netstat、tcpdump 这类工具就能直接看到业务容器的网络状态。这个技巧在排查“端口被占用”“连接数打满”时非常实用。2.2 网络、存储与主机文件共享边界在哪里Pod 内共享网络不仅是“能访问”还包括端口空间、回环接口、IP 地址。也就是说一个 Pod 对外只有一个 IP里面所有容器监听端口都不能冲突否则会直接报地址占用错误。很多新手在同一个 Pod 里放了两个都监听 8080 的容器结果第二个容器一直起不来就是没理解端口空间是共享的。另一个容易被忽略的是 hosts 文件。Pod 里容器的 /etc/hosts、/etc/resolv.conf 都是共享同一份配置如果你修改其中一个容器的 hosts其他容器也会跟着变。因为共享的实际是同一个文件视图不是各拷贝一份。这会在调试本地域名映射时带来幻觉你以为只改了一个容器实际上改了整辆车。存储方面最常用的是 emptyDir它的生命周期和 Pod 完全一致。容器崩溃重启emptyDir 里的数据还在Pod 被删除emptyDir 内容一并清空。多个容器挂载同一个 emptyDir就能实现“主容器写日志、伴生容器读日志”这种典型协作。但要注意如果两个容器同时写同一个文件日志轮转、文件锁、格式化一致性这类问题会被放大建议明确“谁写谁读”不要谁都往里写。2.3 五种状态与 restartPolicy 之间的微妙关系Pod 有五种状态Pending、Running、Succeeded、Failed、Unknown。Pending 表示调度的或创建还未完成Running 表示 Pod 已调度完成且至少一个容器在运行Succeeded 表示所有容器正常结束且不会重启Failed 表示至少一个容器非 0 退出且不会重启Unknown 通常是节点失联API Server 拿不到 Pod 的最新状态。这里有个很绕但必须记住的点Pod 显示 Running不代表里面所有容器都活着。如果 restartPolicy 是 Always某个业务容器失败后 kubelet 会一直重启它此时 Pod 整体状态依然是 Running直到用户主动删除。很多人看 Web 界面发现 Pod 是绿色的但业务就是 502排查半天才发现容器在内部反复 CrashLoopBackOff原因就是没有分清“Pod 状态”和“容器状态”。restartPolicy 有三种取值Always、OnFailure、Never。它只控制 Pod 内容器失败后是否重启不负责“把 Pod 重新调度到别的节点”。如果节点本身宕机了Pod 会被标记为 Unknown然后由控制器比如 Deployment重建一个全新 Pod而不是在原来地方拉起来。3. 一份 Pod YAML 到运行态全链路与关键配置一份完整的 Pod YAML 看着不长背后却要经过 API Server、etcd、调度器、kubelet、容器运行时多个环节。先把示例写出来再逐个拆解它到底做了什么。apiVersion: v1 kind: Pod metadata: name: demo-pod labels: app: demo spec: restartPolicy: Always initContainers: - name: init-mydata image: busybox:1.36 command: [sh, -c, echo init done /data/init.txt] volumeMounts: - name: data mountPath: /data containers: - name: nginx image: nginx:1.27-alpine imagePullPolicy: IfNotPresent ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 3 periodSeconds: 5 lifecycle: preStop: exec: command: [sh, -c, nginx -s quit] volumes: - name: data emptyDir: {}3.1 从 API Server 到 kubelet 的漫长旅程你提交的 YAML 首先到 API Server它负责鉴权、校验和写入 etcd。这一步失败通常是因为字段拼写错误、权限不足或者命名空间不对。写入成功后API Server 会把 Pod 对象放到待调度队列。调度器拿到 Pod 后开始为它选节点。选完节点并不会直接启动容器而是把“Pod 绑定到某节点”这个结果写回 API Server。节点上的 kubelet 通过 watch 机制发现“有个 Pod 分给本节点了”才会调用容器运行时真正创建容器。这里有个容易被忽略的点API Server 和 kubelet 之间是异步事件驱动中间任何一步延迟都会表现成 Pod 长时间 Pending。如果发现 Pod 卡住不要一开始就怀疑网络可以先看事件里有没有调度器抛出的具体原因。3.2 调度器选节点时到底在看什么调度器选节点不是简单找一个 CPU 空闲的机器它会综合很多信息资源满足度节点剩余可用资源必须大于 Pod 的 requests否则直接不选。端口冲突如果 Pod 声明了 hostPort调度器会检查节点上该端口是否已被占用。亲和性与反亲和性想让 Pod 和某些 Pod 同节点或者避免和其他 Pod 同节点都靠这里控制。污点与容忍节点上有污点Pod 没有对应容忍就不会被调度上去。存储约束有状态服务通常要求 Pod 和绑定的 PV 在同一区域网络存储可以宽松一些。我在测试环境遇到过一次诡异的 Pending调度器事件显示 “0/3 nodes available: 1 Insufficient memory, 2 node(s) had taint”。当时第一反应是节点内存不够加机器后来才发现是其中一台节点被打了污点Pod 又没写 toleration压根不被纳入候选列表。所以看事件比猜原因快得多。3.3 kubelet 的创建顺序init 容器为什么总在前面kubelet 真正执行创建时顺序很固定创建沙箱容器也就是 pause。通过 CNI 插件为沙箱配置网络。串行启动所有 initContainers前一个成功才执行后一个。并行启动普通 containers。容器启动后执行 postStart 钩子。持续执行探针。init 容器存在的意义是准备前置条件初始化数据、等待依赖服务可用、修改文件权限、生成配置文件。因为它是串行且一次性的天然适合作为“启动门槛”。如果 init 容器失败主容器永远不会启动Pod 会反复重跑 init直到成功或达到策略上限。一个实战经验不要把耗时超过几分钟的初始化操作放在 init 容器里因为调度器和 kubelet 对 Pending 状态的时间预期很有限长时间卡在 init 会让故障定位变得困难。如果需要跑较重的数据迁移宁可放在 Deployment 启动后的 Job 里或者至少把 init 容器拆细让事件能看清楚卡在哪一步。3.4 两个非常容易理解错的配置imagePullPolicy 和 restartPolicyimagePullPolicy 控制镜像拉取策略有三个取值Always、IfNotPresent、Never。默认规则是镜像标签是 latest 或未显式指定标签时默认 Always其他标签默认 IfNotPresent。很多线上事故都出在“改了代码 push 了 newtag 但 YAML 没改 tag”或者反过来用 latest 导致每次都要远程拉取网络抖动时 Pod 长时间 ImagePullBackOff。我的建议是生产环境永远使用明确版本号并且显式写出 imagePullPolicy不依赖默认值。restartPolicy 前面提过只控制容器重启。实际部署中如果把有状态服务的 restartPolicy 从 Always 改成 OnFailure容器非 0 退出后 kubelet 不会重启它Pod 会进入 Failed。这只适合“跑完即结束”的批处理任务。对普通在线服务来说Always 几乎是唯一选择但你心里要清楚Always 代表 kubelet 会无限重启容器容器可能处于一直失败一直在退避的状态Pod 却还显示 Running。4. 单容器还是多容器协作模式、资源配置与常见坑4.1 默认先做一个容器拆多容器的前提是“强绑定”我见过不少同学喜欢把一堆辅助进程全部塞进同一个 Pod美其名曰“便于管理”。实际上多容器 Pod 会放大资源争抢和故障定位的难度除非有强绑定理由否则一个 Pod 一个主容器是第一原则。什么算强绑定可以问三个问题两个进程必须共享同一个网络栈吗必须读写同一份本地卷吗必须保持同生命周期吗如果三项都是否那应该拆成两个独立的 Deployment通过 Service 通信。如果至少两项为是才值得考虑多容器。4.2 Sidecar、Adapter、Ambassador 三种典型组合多容器协作有三个经典模式模式典型场景说明Sidecar日志采集、监控指标、服务网格代理伴生容器与主容器同生共死负责“主业务之外的横切能力”Adapter日志格式转换、协议归一主容器输出自定义格式Adapter 容器负责改成外部系统能识别的格式Ambassador访问外部服务的代理层主容器只需要连 localhost由 Ambassador 负责路由到不同环境的后端Sidecar 最典型的应用是日志采集。主容器把日志写入共享的 emptyDirSidecar 容器读同一个目录解析后转发到日志平台。这样做的好处是主容器镜像可以保持很小不需要内置日志客户端日志采集升级也不影响业务容器。我在做某个模拟服务日志改造时就是靠这个模式把业务镜像从包含 300MB 日志 SDK 的体积降到了 120MB。4.3 共享 localhost 与 emptyDir 的冲突清单共享带来便利也带来四个高频坑端口冲突同一 Pod 内两个容器不能监听同一端口部署前先把端口清单列出来。hosts 文件全局生效改任何一个容器的 hosts等于改整个 Pod可能误影响伴生进程的域名解析。emptyDir 并发写多个容器同时写同一个日志文件时容易出现截断或格式错乱最好只让一个容器写。资源互相挤压Sidecar 容器没设资源上限时可能突然吃掉大量内存导致同 Pod 的业务容器被 OOMKilled。给 Sidecar 设 requests/limits 和给主容器设一样重要。真实项目里我还遇到过一个问题两个容器使用同一个 emptyDir其中一个容器用 root 用户写文件另一个容器用非 root 用户读文件结果读不到。这跟 Linux 文件权限有关容器虽然共享卷但 UID 并不共享。解决方式是在镜像里统一固定 UID或者把 emptyDir 挂载目录的权限调整成 777 并做好安全权衡。5. 探针、优雅退出与资源边界把 Pod 调成“抗造”的样子5.1 startupProbe / readinessProbe / livenessProbeK8s 提供三种探针各有分工千万别混用livenessProbe决定是否重启容器。失败次数超阈值kubelet 会杀掉容器重新拉起用于发现“进程活着但业务卡死”的隐患。readinessProbe决定是否把流量转发到该 Pod。失败时不会重启容器而是把 Pod 从 Service 后端摘除用于避免把请求打到没准备好的实例上。startupProbe专门解决慢启动问题。在它成功之前其他探针不会生效避免 liveness 在启动阶段误杀容器。我强烈建议所有重要服务都配 readinessProbe。没有 readinessProbe 的 Pod一旦创建成功就会立刻被加入 Service 后端如果业务还没就绪请求会瞬间超时线上表现为“偶发连接拒绝”。这比 liveness 挂了重启更常见也更隐蔽。探针类型一般有三种HTTP 接口探针适合 Web 服务TCP 探针适合只关心端口能连的情况exec 探针适合非网络型进程比如定时任务 Worker。参数里 initialDelaySeconds 是启动后多久开始探测periodSeconds 是探测频率timeoutSeconds 是单次超时。调参时要结合压测数据别把 timeout 设得太短否则高峰期一次 GC 停顿就可能触发连续失败。5.2 用户删除 Pod 后那几十秒发生了什么Pod 的优雅终止流程值得细讲因为它涉及“用户点击删除到容器真正被杀”之间的全部事件API Server 把 Pod 状态置为 Terminating。同时从 Service Endpoints 摘除该 Pod 的 IP新流量不再进来。如果定义了 preStop 钩子kubelet 会先同步执行它。然后给容器主进程发送 SIGTERM 信号。进程收到 SIGTERM 后应自行清理并退出。如果超过 terminationGracePeriodSeconds默认 30 秒进程还没退出kubelet 发送 SIGKILL 强制杀死。这里最容易踩坑的是顺序问题很多人以为 terminationGracePeriodSeconds 是从 preStop 执行完之后开始计时的实际上preStop 执行时间也包含在这个宽限期之内。如果 preStop 里写了一个 sleep 30grace period 又是默认 30 秒那业务进程可能连处理 SIGTERM 的时间都没有就被 SIGKILL 了。想让优雅退出真正生效代码层面必须处理 SIGTERM停止接收新请求、排空存量请求、关闭连接池再退出。如果进程收到 SIGTERM 直接忽略那无论平台怎么配置最终都会被 SIGKILL 强杀造成正在处理的请求全部中断。5.3 资源 requests 与 limits以及三档 QoS 的命运K8s 根据 requests 和 limits 的组合把 Pod 分成三档 QoSGuaranteed、Burstable、BestEffort。不设置任何 resources 的 Pod 是 BestEffort节点内存压力大时最先被驱逐。很多开发环境没事一到生产高负载就“莫名其妙”被删原因基本都在这里。正确姿势是至少给 requests 和 limits 都写上。requests 决定调度器把你放到哪台机器limits 决定运行时最多能用多少。CPU 是可压缩资源超限会降速而不是杀掉内存不可压缩超过 limits 会被 OOMKilled。内存超限的典型场景是 JVM 类的应用。JVM 的堆内存设置如果超过容器 limits容器本身会被内核 OOM但 JVM 可能还没触发自己的进程内 OOM。排障时看到 Pod 反复 OOMKilled先在容器启动命令里把 -Xmx 数值压到 limits 以下并留出堆外内存余量。6. 排障实录从 Pending 到 CrashLoopBackOff 的完整链路6.1 Pending调度器把 Pod“卡”在哪一层Pending 是一个很宽泛的状态从提交 YAML 到容器真正创建之前都可能发生。最直接的做法是看事件kubectl describe pod pod-name输出的最后部分是 Events里面会明确写着调度器拒绝的理由。常见的调度失败事件有 Insufficient cpu、Insufficient memory、node(s) had taint、didnt match node selector 等。先用kubectl get nodes看剩余资源再用kubectl describe node node-name看每个节点的已分配资源。很多 Pending 不是没资源而是节点被打了污点或者 Pod 的 nodeSelector 指向一个不存在的节点标签。事件里一般都会给出答案问题只在于你有没有认真看。6.2 CrashLoopBackOff容器反复启动失败的排查顺序CrashLoopBackOff 意味着容器启动后很快就退出kubelet 按指数退避策略不断重试重试间隔从 10 秒起步逐步拉长到 300 秒封顶。看到这个状态先别急着删 Pod 重来按下面的顺序查# 查最近一次退出的日志 kubectl logs pod-name --previous # 查容器状态和退出码 kubectl describe pod pod-name # 查启动时执行的命令是否正确 kubectl get pod pod-name -o yaml退出码是一个重要线索退出码 0 但进程立刻结束多半是启动命令写错比如把 Java 程序用 sh -c 包了一层却忘记传参。退出码 1 或 2通常是应用层报错看业务日志。退出码 137 代表被 SIGKILL 杀死最常见的不是别人杀了它而是内存超限触发 OOM。退出码 143 代表 SIGTERM可能是人为删除或优雅终止没处理好。很多 CrashLoopBackOff 其实是启动命令和环境变量的问题不是程序本身 bug。进入容器手动跑一次启动命令往往能比看日志更快定位。6.3 ImagePullBackOff镜像阶段的“假 Running”ImagePullBackOff 是另一个高频状态。它表示镜像拉取失败kubelet 反复重试但一直没成功。常见原因有三类镜像名写错或 tag 不存在、私有仓库认证失败、网络无法访问镜像仓库。排障时同样先看事件里面会有具体错误信息。如果是认证问题要检查 imagePullSecrets 是否配置正确这经常发生在从本地 docker login 环境切到集群环境时。如果确认镜像存在但就是拉不下来可以手动在节点上执行一次 containerd 或 docker 的拉取命令直接观察网络层错误。值得注意ImagePullBackOff 并不代表 Pod 创建失败Pod 状态可能还是 Pending 或 ContainerCreating只是卡在“容器运行时无法获取镜像”这一步。先把镜像这一关打通后面的容器启动问题才有讨论的前提。6.4 一次虚构的多层问题复盘从调度失败到 OOM最后分享一个我在测试环境完整走了一遍的排障过程问题层层嵌套很能说明“不要只看一个现象”的道理。某个订单服务的 Pod 部署后一直 Pending。describe 看到事件写着 Insufficient cpu但节点明明还有空闲。再细看发现 Pod 的 requests 写了 2000m节点可用只有 1500m。把 requests 调低到 1000m 后Pod 变成 Running。还没高兴两分钟业务日志里开始大量报连接拒绝。原因是这个服务没配 readinessProbePod 一 Running 就被加进 Service但业务进程实际上花了十几秒才完成注册。给容器加上 readinessProbe并且把 initialDelaySeconds 调成 10 秒后问题缓解。又跑了半天Pod 开始反复重启describe 看到容器退出码 137。查日志发现 JVM 的堆内存设置是 2GB但容器 limits 只给了 1536Mi。调整启动参数的 -Xmx 后Pod 稳定下来。这个过程看起来很琐碎但排障经验就是在这些琐碎里积累的。正确顺序永远是现象 → 事件 → 容器日志 → 网络和存储 → 代码配置不要跳过 Events 直接扎进业务日志那会浪费大量时间。最后说一个我自己的习惯每次写新的 Pod 定义都会先加 startupProbe 而不是调大 liveness 的 initialDelaySeconds保证慢启动容器不会被无关探针误杀所有业务容器必须写 requests 和 limits不留 BestEffort 的隐患给主进程写好 SIGTERM 优雅退出逻辑再配合 preStop 做最后的保险。这三件事做扎实生产环境里 80% 的 Pod 莫名其妙的问题都能提前避免。希望这篇关于 Pod 的梳理能让你少走一点我当年走过的弯路。