刚接触 Kubernetes 的开发者十个里有八个都卡在 Pod 这个门上。倒不是因为它有多难而是因为它和 Docker 容器的概念太像了容易让人产生这个我学过的错觉。实际写第一个 YAML 时有人把端口映射写上去了有人把 restartPolicy 忽略了有人发现容器怎么删都删不掉还有人看着 Pending 状态半天不知道去哪里找原因。这个系列前两篇分别讲了集群搭建和 kubectl 常用操作这篇就彻底停在 Pod 这一个对象上把它掰开揉碎讲清楚。名字叫精简版但生产环境里真正用得上、需要理解到的核心点一个都不会少。Pod 是 Kubernetes 里你操作频率最高的东西也是后面学习 Deployment、Service、调度策略的基石把这篇文章消化了你再看后面那些控制器会轻松很多。1. 为什么说 Pod 是最小调度单元不是容器的包装袋1.1 从 Docker 到 Pod变化的不只是名字Docker 的时代我们习惯把一个容器当成一个应用。到了 Kubernetes最小调度单位变成了 Pod而不是容器。这个变化背后藏着一个核心转变Kubernetes 不再假设一个应用只能由一个进程组成而是允许你把一群必须紧密协作、共享命运的进程打包在一起管理。一个 Pod 里的多个容器共享同一个网络命名空间和存储卷。网络共享意味着它们可以互相用 localhost 访问存储共享意味着它们能读写同一份数据。这解决了一个实际问题有些进程之间耦合度极高放在同一台机器上才靠谱但你又不想让它们挤进同一个容器镜像里。最典型的例子是主业务容器加 Sidecar 容器的组合——比如一个 Web 服务配一个日志采集容器日志采集器直接从共享目录里读文件不再需要额外的 agent 进程。这比在镜像里塞一堆进程干净得多也方便单独升级、替换某个辅助进程。1.2 用一桌人吃饭来理解 Pod 的内部结构把 Pod 想象成一张餐桌Pod 里的容器就是围坐在桌边的人。所有坐在同一张桌子前的人用着同一个桌面共享的存储卷可以直接递盘子通过 localhost 互相访问但每个人手里的筷子碗是自己的各自的进程、文件系统、资源限制。这张桌子的存在感很强只要桌子被撤走坐在桌上的人全部都要走。Pod 就是这样一个一起存活、一起结束的打包单位。这个类比还能推导出两个实际结论。第一同一个 Pod 里的容器端口绝对不能冲突因为只有一个网络命名空间localhost:8080 只能被一个进程占用。第二Pod 的 IP 是这组容器共同的门牌号外部访问一个 Pod 里的不同容器只能通过不同端口来区分。记住了这两点很多写在 YAML 里的奇怪报错你一眼就能看出来原因。1.3 什么时候该拆、什么时候该合这是新手面对的第一个真实设计问题两个组件到底放一个 Pod 还是放两个我一般只问自己三个问题它们是否必须运行在同一台节点上它们共享数据或本地通信吗它们是不是要么一起活着要么一起死去的关系如果三个答案都是是那就该放同一个 Pod。比如一个业务进程需要从一个本地文件里读配置而另一个进程负责每隔一段时间从远端拉取配置写进这个文件这两个就是典型的共生关系拆开了反而要引入额外的网络配置和状态同步。反过来如果两个服务只是单纯的调用关系比如订单服务调支付服务那绝对不合适塞进同一个 Pod。它们需要独立伸缩、独立更新、独立承受故障。强耦合的才放一起弱耦合的必须分家这个判断标准比任何理论都好用。2. 从 YAML 到运行一个 Pod 的诞生全程2.1 最小可运行 Pod 的逐字段拆解先写一个能跑起来的 Pod YAML这是所有 Pod 配置的基础骨架apiVersion: v1 kind: Pod metadata: name: nginx-demo labels: app: nginx spec: containers: - name: nginx image: nginx:1.25-alpine imagePullPolicy: IfNotPresent ports: - containerPort: 80apiVersion 是 v1kind 是 Pod这两行是给 Kubernetes API 看的开箱条码。metadata 里最重要的是 name 和 labelsname 是 Pod 的唯一标识labels 则决定了这个 Pod 如何被 Service、Deployment 这些上层对象认领。spec 是 Pod 的规格声明里面至少得有一个 containers 列表。containers 里的 image 指定镜像imagePullPolicy 有三个值Always、IfNotPresent、Never。IfNotPresent 表示本地已有镜像就不去远端仓库拉取在离线环境或想省流量时很实用Always 表示每次创建容器都重新拉后面接的是 tag 可变的镜像时建议用这个Never 则强制只用本地镜像。最坑的场景是把本地构建的镜像直接部署上去没设 imagePullPolicy碰巧标签又不带 latest节点上没有镜像时就会一直报 ImagePullBackOff。ports 里的 containerPort 很多新人当成我们要暴露端口其实它只是声明一下我这个容器监听了 80 端口属于元信息不产生任何实际效果。真正把流量送进来需要 Service 或者其他入口机制。这个声明不写也不影响容器运行但写上可以让 kubectl describe 时信息更完整。2.2 创建、查看、进容器、删掉完整命令链路Pod YAML 写好后我会按这个顺序走一遍# 创建 Pod kubectl apply -f nginx-demo.yaml # 查看 Pod 状态-o wide 能看到运行节点和 IP kubectl get pod -o wide # 持续观察状态变化新部署时很有用 kubectl get pod -w # 查看完整 YAML看实际调度结果 kubectl get pod nginx-demo -o yaml # 排错第一命令describe 会展示事件和每个容器的状态细节 kubectl describe pod nginx-demo # 看业务日志 kubectl logs nginx-demo # 进入容器 kubectl exec -it nginx-demo -- /bin/sh # 删除 Pod kubectl delete pod nginx-demo这里面 kubectl describe 是排错神器它会在最底部列出 Pod 运行至今的所有事件比如镜像拉取失败、调度失败、探针检查失败、被 OOM 杀死等等。kubectl logs加--previous可以看容器上一次退出前的日志容器发生重启时这个参数几乎是必用的不然看到的永远只有重启后的空日志。2.3 一个总是被忽略的字段restartPolicyscheduler 会把裸 Pod 调度到某个节点然后节点上的 kubelet 负责维护它重启策略 restartPolicy 就是 kubelet 的行为准则。默认值是 Always意思是只要容器退出kubelet 就会重启它——哪怕是业务进程正常跑完退出也一样。很多人第一次测试一个跑完就结束的脚本任务时发现 Pod 一直在重启就是因为忘了把 restartPolicy 改成 OnFailure 或 Never。裸 Pod 在生产环境不建议直接使用。它没有自愈能力节点挂了 Pod 就永远消失了也不支持滚动更新、副本管理这些高级能力。但学习阶段用裸 Pod 是最干净的它把概念边界缩到最小让你专注理解 Pod 本身。等理解透了再切换到 Deployment 管理同样这套配置就会非常顺。3. Pod 的七种生命状态与假死现场3.1 五种相位phase到底表示什么相位说的是 Pod 这个整体的生命周期阶段反映的是做成了一件事还是没做成。看 kubectl get pod 的 STATUS 列你会遇到这几种Pending已经被 API Server 接受但目前还没完成调度或者镜像还在拉取。很多人看到 Pending 就以为只是启动慢其实资源不足、节点有污点、镜像名写错都会让 Pod 一直停在 Pending。Running至少有一个容器还在运行状态。Succeeded所有容器都成功运行完毕退出且退出码是 0。Failed至少有一个容器以非 0 退出码结束或者被系统强制终止。Unknownkubelet 失联API Server 拿不到这个 Pod 的状态。这个状态很低概率出现出现的时候基本意味着节点有问题。还有一个常见的 STATUS 是 CrashLoopBackOff它不在五种相位里而是一种容器级别的循环故障状态容器启动后马上就崩kubelet 按指数退避策略不断重启它从 10 秒递增到 5 分钟每次重启间隔越来越长。看到这个状态你要做的不是删 Pod 重来而是排查容器为什么崩。3.2 容器级别的三个子状态容器比 Pod 多一层状态机。ContainerWaiting 是容器还在等待条件满足比如镜像没拉完、存储卷没挂上ContainerRunning 是容器正在运行ContainerTerminated 是容器已结束运行会有一个退出码。排错时真正有价值的是退出码137 表示被 SIGKILL 杀死143 是收到 SIGTERM 后终止0 是正常退出。结合退出码和 describe 里的事件大部分问题都能定位。有一个典型的假死场景主业务进程变成了 chroot 或休眠工具或者跑成了后台守护进程真正干活的服务根本没起来但这种 Pod 的 STATUS 依然是 Running。容器在跑业务不在服务这种故障最迷惑人。另外一个常见场景是容器镜像里命令行带了前台参数拉起来马上就执行完退出restartPolicy 又是 Always于是陷入 CrashLoopBackOff。遇到这种情况先kubectl logs 名字 --previous看历史日志再确认一下镜像默认的启动命令是不是阻塞式的。3.3 InitContainers主容器启动前的前置条件InitContainers 是 Pod 里一种特殊容器它们严格按顺序依次执行全部必须成功退出后主容器才开始启动。如果中间有一个失败整个 Pod 会反复重跑所有的 init 容器。它适合干这些事给数据卷初始化权限或目录结构、等待某个依赖服务就绪、执行数据库迁移、把启动所需的配置文件生成好。下面是一个最简单的示例init 容器等待某个 TCP 地址可达后再启动业务端spec: initContainers: - name: wait-for-db image: busybox:1.36 command: [sh, -c, until nc -z -w 5 db-service 3306; do echo waiting; sleep 2; done] containers: - name: app image: my-app:latest这里有个经验点放在 init 容器里的探测逻辑一定要设置超时时间不然应用里的 bug 或网络策略变更会导致 init 容器无限等待主容器永远起不来。另外 init 容器也消耗计算资源在资源紧张时资源配额要把它占用的部分算进去。3.4 Pending 状态的完整排查路径如果 Pod 一直 Pending我会按这个顺序排kubectl describe pod xxx看 Events调度器会直接告诉你哪一步失败。如果是调度失败kubectl get nodes --show-labels看节点标签和资源剩余情况。检查是否设置了资源 requests节点剩余可分配资源不足时调度器会卡住。检查节点是否有污点taints看 Pod 是否需要容忍toleration才能调度上去。这个顺序基本能覆盖九成以上的 Pending 原因。特别是资源不足这条在共享集群里非常常见不是你的 Pod 有问题而是整个集群塞满了。4. 探针Probe让 k8s 真正知道你的应用活着和能用4.1 进程活着不等于业务正常把容器跑起来只是第一步Kubernetes 还需要回答一个更关键的问题这个容器里的服务到底还能不能干活一个 Java 进程可能还活着但线程池已经耗尽HTTP 请求全部超时一个数据库容器可能没崩但磁盘满了写不进去任何数据。这些情况下进程存在可业务已经死了Kubelet 光看进程状态是没法识别的。探针Probe就是 Kubelet 定期对容器做的体检目的是让系统知道应用是否真的健康。三种探针分工不同livenessProbe存活探针只管要不要重启这个容器。如果失败次数超过阈值kubelet 会杀掉容器并按重启策略重新拉起。readinessProbe就绪探针只管要不要把这个 Pod 的 IP 加进 Service 后端。失败时流量不会打到这个 Pod 来但容器不会被重启。startupProbe启动探针给那些启动极慢的程序一个安全的缓冲期在这期间不做 liveness 判断。4.2 三种探针的典型设置一个常见的配置如下spec: containers: - name: app image: my-app:latest startupProbe: httpGet: path: /healthz port: 8080 periodSeconds: 2 failureThreshold: 30 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 3 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 2startupProbe 用较短的检查周期加较大的失败阈值给应用一个慢慢来的窗口livenessProbe 关注持续健康失败 3 次就重启readinessProbe 关注业务可用性一旦失败就摘流量。要注意的是 readiness 的检查路径和业务健康不一定相同比如主备切换中的节点、正在执行长任务的节点都可以通过 readiness 返回失败来主动退出流量池。三个关键参数的直觉感受periodSeconds是体检频率设置太大会让故障发现变慢设置太小又会让健康检查本身成为性能负担timeoutSeconds是单次检查超时时间有些慢接口在 timeoutSeconds 太小的情况下会产生大量超时误判failureThreshold决定容忍度出现偶发抖动时不会立刻重启或摘流量。4.3 三种探针类型怎么选httpGet 是最直觉的方式只要接口返回 2xx 或 3xx 就算健康适合所有业务接口也是我用得最多的。tcpSocket 只验证 TCP 端口能连上适合那些没有 HTTP 接口还不好加的内部服务它判断的是端口通没通不够细但胜在简单。exec 执行容器内命令按退出码判断适合检测内部状态比如检查 lock 文件、执行健康脚本等。探针踩过的坑不少值得单独提醒的有三个。第一健康检查接口本身不能带太多计算逻辑我一个回调接口曾把全量数据灌进去做健康检查探针一打CPU 直接飙高影响正常请求健康检查路径必须轻量化。第二探针日志要严格控制输出如果 exec 方式里命令大量打日志会把容器日志刷爆。第三httpGet 的端口一定要监听在容器内的正确端口上端口改了探针配置没同步改的场景我见过太多次。4.4 探针引出的滚动更新死锁回忆在实际维护里探针配错会导致很隐蔽的故障。有一次我给一个应用加了 readinessProbe但把检查的路径写在了业务主流程后面结果新版本启动后业务流量还没完全初始化readiness 一直不通过控制器就不断创建新 Pod旧 Pod 又一直守在线上结果新版本永远没流量还造成了一轮资源抢占。后来把探针路径改成独立的、轻量的健康接口才恢复正常。这类问题一旦发生很难一眼看到原因因为在 STATUS 层面新 Pod 还是 Running只是 readiness 一直不满足。5. resources一句配置引发的调度与驱逐差异5.1 requests 与 limits两个不同的作用域resources 字段是最被人低估的一个很多初学者甚至完全不写。但它的影响贯穿调度、运行、驱逐三个阶段。requests 用来告诉调度器我需要这么多资源才能工作是调度决策的依据limits 则用来限制运行时的资源上限是 kubelet 执行的硬性约束。CPU 是可压缩资源超过 limits 会被限流表现为 CPU 使用率被强制压低但进程不会死。内存是不可压缩资源一旦超过 limits容器会被 OOM内存溢出机制直接杀掉。这就导致两种资源超限的后果完全不同CPU 超了是变慢内存超了是死亡。所以内存的 limits 是生产环境最需要保守设置的一项。5.2 QoS 等级资源冲突时的谁先被牺牲Kubernetes 会根据容器的 requests 和 limits 设置把 Pod 划分成三个 QoS服务质量等级。这个等级决定了节点资源紧张时谁会先被驱逐Guaranteed有保障每个容器都设置了 requests且 requests 与 limits 完全相等。Burstable充满弹性至少有一个容器设置了 requests 或 limits但不完全相等。BestEffort尽力而为所有容器都没有设置 requests 和 limits。驱逐顺序是 BestEffort 先走然后是 Burstable 里实际用量超 requests 的最后才是 Guaranteed。节点内存紧张时kubelet 会优先清退最不受保护的 Pod。生产环境里最理想的状态是让核心业务达到 Guaranteed这既是对业务的保护也能避免和服务争抢时被动。5.3 OOM 与 Eviction 现场怎么判断描述了这么多资源概念落到实际排查就是两个场景。一个是容器退出码 137kubectl describe pod xxx里能看到一行OOMKilled这表示容器超过了自身 limits被内核 OOM killer 杀了。另一个是 Pod 被驱逐Evicted原因是节点级的内存压力、磁盘压力等问题和单容器超限是不同层级的两回事。实操中区分两种情况的习惯是先看容器退出码137 加 OOMKilled 基本锁定是容器级内存超限再kubectl top pod看实际内存占用和 limits 对比一下往往能发现 limits 设得太低或者业务真的有内存泄漏最后看节点状态kubectl get node和kubectl describe node里的压力条件如果节点本身有 MemoryPressure那还要关注节点级的驱逐策略。5.4 设多少合适一个保守的起步公式我一般把 requests 和 limits 的初始值定在CPU requests 为平时稳定使用的 60% 到 80%limits 为峰值使用上限加 20% 余量内存 requests 按 JVM 堆等固定开销加 30% 的余量limits 按峰值计算的 1.2 到 1.5 倍。这两项观察一两周真实监控后逐步收敛。除非有明确理由不要一开始就设得极其贴近真实值给调度和运行留出缓冲。6. 让 Pod 被正确调度和优雅退出6.1 节点选择nodeSelector 和 nodeAffinity以及污点集群里的节点并不都是一样的。有的节点挂着 GPU有的节点是高性能磁盘有的节点专门给某些团队用。这就要用到调度约束。nodeSelector 是最简单的硬性匹配要求节点必须带指定标签例如disktype: ssd就只调度到有这个标签的节点上。它的缺点是表达能力弱只能做必须等于的匹配。nodeAffinity 更进一步分为 required必须满足和 preferred尽量满足。preferred 会把满足条件的节点排在前面不满足也能调度只是优先级低。这在多可用区场景、节点资源水位不均衡的场景里比 nodeSelector 灵活太多。污点taint和容忍toleration是另一套机制和亲和性正好互补。亲和性解决Pod 想往哪跑污点解决节点不想让某些 Pod 跑。给节点打上一个 NoSchedule 污点后不带对应容忍的 Pod 就不会被调度过来。常见的用途是给专用节点加污点确保只在需要时调度指定服务过去。6.2 优雅退出的完整流水线Pod 被删除或滚动更新时不会直接被一刀砍掉。kubelet 收到终止信号后会执行这样一个流程先执行 preStop 钩子如果配置了然后向主容器发送 SIGTERM 信号接着等待终止宽限期terminationGracePeriodSeconds默认 30 秒宽限期内进程没有自行退出最后才发送 SIGKILL 强制杀掉。一段简单的 preStop 示例spec: containers: - name: app image: my-app:latest lifecycle: preStop: exec: command: [sh, -c, sleep 5 kill -QUIT $(cat /tmp/pid)]preStop 的存在价值在于有些应用收到 SIGTERM 后的清理逻辑不完整或者需要告诉上游注册中心我要下线了而主进程自身不做这件事。把所有下线动作用 preStop 接管做成可预期的流程比在应用里改造要快。6.3 一个让宽限期失效的常见场景终止宽限期最怕两类情况一类是 preStop 脚本里 sleep 时间比宽限期还长进程还没做完下线操作就被 SIGKILL 了白等另一类是应用收到 SIGTERM 后开始执行耗时的资源清理但应用内部没有监听 SIGTERM 的逻辑等于直接忽略到了宽限期照样被杀。这两种情况本质上都是信号进来后的动作超时。解决办法是把宽限期调大同时确保应用代码真的监听了 SIGTERM 并实现了优雅退出。宽限期也不建议设得无限大超过一定时间后集群的滚动更新和故障转移都会被拖慢。6.4 Pod 的 IP 是会漂移的最后提一个常被新手忽略的运维现实Pod 的 IP 是不稳定的。Pod 被删除、重新调度、在节点间迁移后IP 都会变化。因此永远不要手动把 Pod 的 IP 缓存到本地配置或硬编码进代码里要实现跨 Pod 访问必须经过 Service 或 DNS 发现机制。这也是为什么 Deployment 上层永远挂着一层 Service所有流量都走 Service 的稳定入口由它把请求转发到后端 Pod。我在实际运维里见过最离谱的事情是有人把某个 Pod 的 IP 写进了另一套系统的白名单Pod 一重建流量全部中断。Kubernetes 的设计哲学就是实例会死、IP 会变、只有约定不变不要把约定建立在易变的 IP 上要建立在 Service 和标签上。写在最后先把 Pod 的死法背熟Pod 详解讲到这里核心内容基本覆盖了它的内部结构、YAML 写法、生命周期、探针、资源管理、调度和优雅退出。总结这些经验的初衷是我在实际维护的大量问题里九成以上都发生在Pod 是怎么死的这个方向——要么探针配错导致误杀要么内存 limits 设错导致 OOM要么优雅退出超时导致业务中断。先把死法搞清楚了再谈怎么把它跑得更好。Pod 是 Kubernetes 的最小单元但它的每个字段都牵扯到集群的调度、网络、存储、监控多个维度值得多花时间认真研究。