刚把集群搭好、kubeadm那套流程跑通之后接下来真正进入日常使用时你会发现大部分时间都在和 Pod 打交道。这篇继续上一篇的内容把 Pod 的管理、应用方式以及资源清单YAML这些最常用、也最容易踩坑的部分说透。我见过不少刚从二进制部署或者容器单机环境转过来的工程师第一反应是Pod 不就是容器吗我直接docker run不就好了。结果真上了 Kubernetes 才发现Pod 的调度、重启策略、健康检查、资源限制这些机制每一个都在影响你业务能不能稳定跑。这篇从 Pod 的本质讲起再落到具体的资源清单编写和日常排障希望能帮你把这块彻底打通。1. Pod 的定位为什么 Kubernetes 的最小调度单元不是容器1.1 容器与 Pod 的关系从进程到业务组先想一个问题Docker 时代我们管理的是容器到了 Kubernetes 这里最小调度单元突然变成了 Pod为什么因为大多数互联网业务往往不是由一个进程独立完成的。典型的场景前端 Nginx 需要转发请求到后端服务后端服务需要读取共享配置请求日志可能要单独采集上报。如果把这些功能全塞进一个容器里你就回到了单体容器的老路——镜像越来越大、进程互相干扰、日志没法分开管理任何一个子功能升级都要重新打包整个镜像。Pod 解决的核心问题是把一组必须紧密协作、共享生命周期的容器打包成一个整体。同一个 Pod 里的容器天然满足三个特性共享同一个网络命名空间都通过127.0.0.1就能互相访问、共享同一个数据卷可以直接读写同一份文件、保证被调度到同一个节点上。打个比方容器像一节节车厢Pod 像一整列编组好的火车。车厢可以各自装载不同的货物但它们必须走同一条轨道、到达同一个站台。所以 Pod 里的容器不会出现一个在东一个在西的情况它们的生与死、启动与销毁都是一体的。理解了这一点就明白为什么 Kubernetes 调度器调度的是 Pod 而不是容器——它需要保证一组容器的原子性。1.2 什么时候该把多个容器塞进一个 Pod这不是一句能塞就塞能解决的。我在实际项目里见过有人把 Redis、MySQL、业务服务塞进同一个 Pod理由是部署方便。这是典型的理解偏差。判断两个容器该不该进同一个 Pod核心标准就三条是否必须同生共死——一个挂了另一个就没意义是否必须共享网络或存储——比如两个进程必须通过 localhost 通信或者必须实时读写同一份日志文件是否必须保持副本一致——比如业务容器和日志采集容器必须一一对应。最常见且合理的组合是应用容器 Sidecar 容器。举个真实场景某个老项目只有 HTTP 访问日志没有结构化输出。我在生产环境里给业务 Pod 加了一个 Fluentd 或 Filebeat 容器作为 Sidecar它和业务容器共享一个emptyDir卷业务容器把日志写到/var/log/appSidecar 读出来转发到日志平台。这样业务镜像完全不用改造日志能力却直接补齐了。反面例子如果你只是觉得这两个服务都在同一个项目里或者它们依赖同一个基础镜像那完全不该塞进一个 Pod。该拆的时候就拆成多个 Deployment各自管理副本数和升级节奏。2. Pod 日常管理实操从创建到排障的完整命令链路2.1 用 kubectl 跑起第一个业务 PodKubernetes 创建 Pod 最常见的方式是直接跑kubectl run也可以在后端通过 Deployment 间接管理。两者的区别在于.run命令创建的裸 Pod 没有控制器兜底删了就是删了而通过kubectl create deployment创建的 Pod 由 ReplicaSet 管理删掉会自动重建保证期望副本数不变。先看一个最简单的裸 Podkubectl run nginx-test --imagenginx:1.25 --port80 kubectl get pods kubectl get pods -o wide这段命令跑完kubectl get pods看到nginx-test处于Running状态。-o wide会额外显示 Pod 所在的节点、IP、对应的 Node 名称排查网络问题时几乎必用。正常情况下一个 Pod 从创建到 Running 只需要几秒钟如果卡在ContainerCreating超过一分钟多半是镜像拉取慢、存储卷挂载失败或者节点资源不足。这时候别干等用这招快速定位kubectl describe pod nginx-testdescribe会把事件的完整流水账列出来包括调度结果、镜像拉取、容器启动每一步的状态。排障第一反应永远是describe而不是反复get pods干瞪眼。2.2 日志、进入容器与端口转发一个业务 Pod 跑起来之后日常操作基本离不开三件事看日志、进容器、做端口转发。看日志最常用的是kubectl logs如果容器反复崩溃一定要加--previous看上一次容器的日志很多时候崩溃原因只在上一份日志里kubectl logs -f nginx-test kubectl logs -f nginx-test --previous如果 Pod 里有多个容器需要指定容器名不然 kubectl 会直接报错kubectl logs -f nginx-test -c sidecar-log进入容器调试kubectl exec是最常见的操作。新版 Nginx 镜像基于 Alpine进来之后可能是/bin/sh而不是/bin/bashkubectl exec -it nginx-test -- /bin/sh还有一个在本地联调时特别好用的命令kubectl port-forward。比如你要在本地浏览器访问集群内的某个服务不需要暴露任何 Service 类型直接做端口转发kubectl port-forward nginx-test 8080:80本地访问http://127.0.0.1:8080就能打到集群里这个 Pod 的 80 端口。这个命令当前端连不上集群内服务、需要临时排查接口数据时尤其有用。2.3 删除 Pod 的正确姿势删除动作看着简单里面的坑不少。裸 Pod 直接用kubectl delete pod name就能删掉但被 Deployment 管理的 Pod 这样删是没有意义的——控制器会立刻重新拉起一个。所以真正要缩容或者下线应该去改 Deployment 的副本数而不是直接删 Pod。如果kubectl get pods发现某个 Pod 一直卡在Terminating状态不要急着--force --grace-period0强删。先想想它为什么卡住通常是 Pod 里的容器对 SIGTERM 没有响应或者 preStop 钩子里的脚本在死循环。强删只是帮你拔掉插头但插头为什么不自动弹出原因还得查。另外一个经典坑kubectl delete deployment只会删除控制器本身但如果你之前手动创建过同名的 Service 或者 ConfigMap它们是独立资源不会被连带删除。删资源之前一定要把关联关系理清楚。3. 生命周期、重启策略与健康检查别让你的 Pod 带病运行3.1 Pod 的五个状态与状态流转看 Pod 状态时经常看到一堆英文单词背后的含义理清了排障就快了一半。常见状态我用一张表整理下状态含义常见原因PendingPod 已被集群接受但尚未运行还在调度、拉镜像、等待资源RunningPod 已经绑定到节点至少一个容器运行中正常状态Succeeded所有容器正常退出完成即结束Job 或一次性任务Failed至少一个容器以非 0 状态退出业务异常、崩溃UnknownAPI Server 联系不上 kubelet节点网络异常或 kubelet 挂掉CrashLoopBackOff容器启动后反复崩溃Kubelet 在退避重启启动命令错误、配置错误、探针失败EvictedPod 被节点驱逐节点资源压力、磁盘不足CrashLoopBackOff是最常见的异常状态。它并不是 bug而是保护机制容器崩溃后 Kubelet 先重启它如果连续失败就按指数退避算法延长重启间隔10s、20s、40s、80s……最多 5 分钟防止疯狂占资源。Evicted也很常见。节点内存不足时 Kubelet 会优先驱逐那些内存使用超限limit 超配的 Pod。此时基本靠kubectl describe pod看事件里面明确写了The node was low on resource: memory。解决办法是调整资源限制或者清理节点上的无用镜像释放磁盘空间。3.2 restartPolicy重启策略与 Job 场景restartPolicy只支持三个值Always、OnFailure、Never默认是Always。这个默认值坑了很多人——尤其是跑一次性任务的人。举个例子你写了个批处理脚本镜像手动kubectl run batch-job --imagemy-batch:latest --restartNever。如果漏掉了结尾的--restartNeverPod 里的脚本正常跑完容器退出了但 Kubelet 会按Always把它重新拉起来然后脚本又跑一遍又退出又重启……形成一个无限循环你的一次性任务变成了永动机。所以裸 Pod 跑批处理restartPolicy建议显式写成Never或OnFailure。而 Deployment 管理的业务 Pod 一般保持Always因为业务容器就是要保证一直活着、挂了自己重启。3.3 三种探针与参数建议健康检查是 Pod 管理里最容易忽略、但生产环境必须配置的部分。Kubernetes 提供了三种探针livenessProbe决定容器是否存活。失败后 Kubelet 会杀掉容器并按重启策略重启。readinessProbe决定容器是否就绪是否加入 Service 的负载均衡池。失败时 Pod 状态显示NotReady但容器不会被杀。startupProbe专门给慢启动应用用的。启动阶段用 startup 探针做总闸启动成功后转入 liveness 探针避免启动慢的应用被 liveness 误杀。看一个完整的探针配置apiVersion: v1 kind: Pod metadata: name: app-probe spec: containers: - name: app image: myapp:1.0 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 10 periodSeconds: 15 timeoutSeconds: 3 failureThreshold: 3 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10几个参数的实际含义我用大白话翻译一遍initialDelaySeconds容器启动后先给多少秒缓冲期不检查。设置太小服务还没起来就被探针打挂了设置太大故障发现就被拖慢了。periodSeconds每隔多少秒探测一次。timeoutSeconds单次探测最多等几秒超时算失败。failureThreshold连续失败多少次后才把容器判死/判不健康。生产环境里我见过最典型的翻车场景镜像里的服务启动需要 40 秒要初始化缓存、加载模型但livenessProbe的initialDelaySeconds只设了 5 秒。结果容器每次刚启动还没就绪就探针失败被杀掉重启陷入死循环。这类问题正确的解法是加startupProbe给它 120 秒甚至更长的启动窗口等启动好了再交给 liveness 管。探针不光是活着/死了的检测readinessProbe还直接参与了流量路由。如果某个 Pod 依赖的后端 Redis 暂时连不上readiness 探针失败这个 Pod 会立即从 Service Endpoints 中摘除外部请求就不会打到它。这是保证滚动更新和扩容时不中断服务的关键机制。4. 资源清单的骨架apiVersion、kind、metadata、spec 到底装了什么4.1 四段式结构与每一段的含义所谓资源清单就是写在 YAML 里的 Kubernetes 资源定义。理解它的关键在于记住一套相对固定的四段结构apiVersion、kind、metadata、spec。每个资源都有这套骨架无非是各段的取值不同。apiVersion很容易让人困惑为什么有些资源是v1有些是apps/v1有些是batch/v1我的理解方式是它不是随便写的版本号而是资源分组加版本的组合。v1是核心组最早期的资源Pod、Service、ConfigMap、Secret都在这里apps/v1是应用组管理 Deployment、StatefulSet、ReplicaSetbatch/v1管 Job、CronJob。不同分组的作用是隔离不同团队管理的资源类型方便单独演进和废弃。kind就是你要创建的资源类型。metadata是身份信息其中name是唯一标识namespace决定资源属于哪个命名空间labels是键值对标签annotations是不影响选择器逻辑的备注信息。spec是最核心的部分描述你期望的目标状态——比如期望几个副本、用什么镜像、多少资源。而资源被实际运行后的结果会写到status字段里。这个spec 是期望、status 是现实的模型是整个 Kubernetes 声明式设计的基石。4.2 一个完整 Pod 清单逐字段拆解下面这个例子很典型新手照着写基本不会错apiVersion: v1 kind: Pod metadata: name: web-pod namespace: default labels: app: web env: prod spec: containers: - name: web image: nginx:1.25 imagePullPolicy: IfNotPresent ports: - containerPort: 80 protocol: TCP resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi每个字段展开说spec.containers是必填项至少一个容器。image指定镜像名注意nginx:1.25这种带 tag 的写法。生产环境更推荐写具体 tag如nginx:1.25.3或者使用 digest避免latest带来的不可控更新。imagePullPolicy有三种取值Always总是拉取、IfNotPresent本地没有才拉、Never永远不拉。不写时规则是镜像 tag 为latest或没有 tag默认Always其他 tag 默认IfNotPresent。不少人在内网环境用私有镜像仓库镜像 tag 每次构建都相同但内容变了结果等半天拿到的还是旧版本——就是因为imagePullPolicy默认值让它没去拉新镜像。ports是声明容器监听的端口。有一点要说清楚containerPort只是自我介绍不是帮你做端口映射。真正决定流量能不能进来还要靠 Service。resources.requests和limits分别对应调度占用和运行上限后面第 5 节细讲。写 YAML 时最常见的低级错误是缩进。YAML 靠缩进表达层级字段一旦错位整个清单结构就乱了。另一个常见错误是把containerPort写成hostPort——hostPort是让容器端口直接暴露在宿主机上属于高危操作会和节点端口冲突生产环境几乎不会用。4.3 为什么生产环境推荐用 Deployment 而不是裸 Pod既然手写 Pod 清单这么简单能直接用裸 Pod 吗答案是可以跑但不建议。裸 Pod 没有控制器管理一旦 Pod 异常退出或被驱逐不会自动重建你的服务就默默挂了。生产环境里我用裸 Pod 的场景非常少基本都是临时调试用的。更多时候应该用 Deployment 来管理。Deployment 在 Pod 之上加了一层控制器提供了四个实用能力保证期望副本数Pod 挂了自动补新支持滚动更新逐个替换老版本业务不中断支持一键回滚到历史版本配合 ReplicaSet 实现版本管理和故障恢复。Deployment 管理的 Pod 名称后面会带一串随机字符因为 Pod 的名字是控制器生成的每次重建都会变。不需要过于关注 Pod 名字本身只要关心副本数和状态即可。5. Deployment 资源清单实战从业务需求到 YAML 的翻译5.1 一份可直接抄的 Deployment YAML光讲概念不够直接给一份可以在测试环境使用的 Deployment 完整示例apiVersion: apps/v1 kind: Deployment metadata: name: web-deployment namespace: default labels: app: web spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: web image: nginx:1.25 imagePullPolicy: IfNotPresent ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 10这个清单里有三个容易搞混的关键字段selector.matchLabels、template.metadata.labels、spec.replicas。template描述的是 Pod 的模板即每个 Pod 长什么样它的metadata.labels是实际生成出的 Pod 会带的标签。selector.matchLabels是 Deployment 用来选择属于自己的 Pod 的条件。三个副本的状态更新时Deployment 就是靠selector匹配到带app: web的 Pod 来管理它们。有个常见坑把selector.matchLabels写成app: web但template.metadata.labels里忘了加app: web或者把app改成了web2。结果就是 selector 匹配不到任何 PodDeployment 一直达不到期望副本数。这类问题用kubectl describe deployment一眼能看到。5.2 标签与标签选择器资源清单里的寻址系统标签Labels是 Kubernetes 里非常灵活的资源组织结构。你可以给任意资源打任意标签然后通过选择器把一组资源筛选出来。比如kubectl get pods -l appweb,envprod kubectl get pods -l env in (dev,test)第一个命令要求同时满足appweb和envprod第二个命令的in操作符表示env只要匹配dev或test任一个即可。标签的价值在于解耦。比如 Service 通过selector选择后端 Pod那你就可以用不同标签区分不同版本、不同环境、不同团队。滚动发布时老版本和新版本的 Pod 可以通过version标签区分然后通过 Service 切换流量。不过要小心一点Deployment 的selector一旦创建就不再允许修改。如果手滑写错了只能删掉重建会短暂中断所以创建之前一定仔细检查。5.3 resources 的 requests 与 limits为什么要给 Pod 饭碗resources这个字段很多人觉得写不写无所谓但它是调度决策的依据和运行时保护的边界。我见过太多线上事故都是因为资源限制没配好。requests是至少需要的资源量调度器根据它决定 Pod 放到哪个节点。比如一个节点剩余 200m CPU你要求 150m 的 Pod 可以调度上去如果requests不写调度器会认为这 Pod 只要 0 资源导致多个无限制的 Pod 挤到同一个节点最终节点 CPU 打满、内存爆掉。limits是最多能用多少超过这个上限后CPU 会被限流而不是直接杀内存超过后容器会被 OOM Kill。很多人只写limits不写requests这种做法也会出问题——调度仍然按 0 资源来看等 Pod 跑起来后突然超过节点实际可用资源结果被驱逐。一个简单的实践建议requests 和 limits 成对写日常业务 requests 按实际经验稍微偏低limits 给到 2~3 倍余量。比如服务平时稳定占用 200m CPU、512Mi 内存那我通常写resources: requests: cpu: 200m memory: 512Mi limits: cpu: 1 memory: 1GiCPU 的计算单位是millicores1 个 CPU 核心等于 1000m内存单位是 Mi/Gi对应 1024 的进制。别把1000m和1Qi之类的单位写错不然要么调度不到要么启动即被 OOM。6. 静态 Pod、Init 容器与钩子生产落地离不开的细节6.1 静态 Podkubelet 自己拉的清单前面讲的 Pod 都是通过 API Server 提交、由控制器管理的。但还有一类特殊的 Pod 叫静态 PodStatic Pod它不经过 API Server而是由节点上的 kubelet 直接读取指定目录下的 YAML 文件来创建。这个目录默认是/etc/kubernetes/manifests。Kubernetes 控制面组件如 kube-apiserver、kube-controller-manager、kube-scheduler基本都是静态 Pod 形式跑在对应节点上的。这个机制怎么排查问题静态 Pod 有个特征kubectl get pods看到的 Pod 名称后缀会带有节点名比如kube-apiserver-master01。如果你改了/etc/kubernetes/manifests下的 YAML不用重启 kubelet它会自动感知并重新创建。但我们也要知道静态 Pod 的删除不能直接kubectl delete需要把对应 YAML 文件移走或改名kubelet 检测到文件消失后才会把它清理掉。6.2 initContainers业务启动前的前置准备initContainers是 Pod 里一组在业务容器启动前依次执行的容器。它们按顺序跑全部成功后业务容器才会启动任何一个失败整个 Pod 会重启重新执行。最常见的用法有几种数据库表结构初始化、等待依赖服务就绪、预加载配置或数据。下面这个例子是等某个外部服务可达后再启动主业务initContainers: - name: wait-for-db image: busybox:1.36 command: - sh - -c - until nc -z mysql-svc 3306; do echo waiting for mysql; sleep 2; done这个思路在生产环境里很有用。比如某个 Java 应用启动时如果连不上数据库就会直接崩溃退出CrashLoopBackOff如果用 Init 容器先卡住直到数据库就绪主容器再启动就能大幅降低启动期的失败率。6.3 lifecycle 钩子与优雅终止lifecycle钩子有两个postStart和preStop。前者在容器启动后立即执行后者在容器停止前执行。很多人忽略preStop觉得 Pod 删除时系统自动发 SIGTERM 就够了。但在实际生产里往往需要先做摘流动作——让 Pod 从 Service 的 Endpoints 里摘除不再接收新请求然后再优雅地处理存量请求。我之前遇到一个案例一个 Java 服务每次发布都会出现少量 5xx。排查后发现Pod 收到 SIGTERM 后立即退出但此时还有正在处理中的请求没完成客户端自然报错。解决办法是在preStop里等待几秒给 Service 摘流和存量请求处理留出时间窗lifecycle: preStop: exec: command: - sh - -c - sleep 5调大terminationGracePeriodSeconds默认 30 秒同样能延长优雅终止时间适合需要处理大量存量请求或慢请求的场景。6.4 实战排障从 describe 和 logs 里快速定位 Pod 问题做运维的人最怕的不是问题本身而是出了问题不知道从哪查起。这里分享一段真实的排查链路完全可以用在实际工作中。某天监控告警一个业务 PodImagePullBackOff。第一步别去看代码先kubectl describe pod pod-name。事件里会明确写Failed to pull image registry.example.com/app:v1.0: pull access denied看到pull access denied基本可以判断镜像不存在或者拉取凭证不对。接着kubectl get secret、检查 Node 上是否有对应的imagePullSecret在 Deployment 的template.spec里补上即可。另一个常见情形Pod 卡在Pendingdescribe 里写着0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory翻译过来就是节点资源不足、没有可调度的位置。要么加节点要么调低requests释放资源要么先把不重要的 Pod 挪走。如果节点明明空着但依然Pending那要检查节点是否有污点Taint看事件里是否有matched node(s) but couldnt schedule。CrashLoopBackOff的排查稍微绕一点。先看日志kubectl get pods kubectl logs pod-name --previous如果是no such file or directory或者 exec format error多半是镜像的启动命令和容器架构不匹配比如 x86 镜像跑在 ARM 节点、或者入口脚本没有执行权限。如果是connection refused基本是服务监听的端口与containerPort声明不一致。最后给一张快速决策表方便你以后对着定位现象第一时间查什么常见根因Pod 一直 Pendingdescribe 看 Scheduling 事件资源不足、污点、存储卷冲突容器一直 ContainerCreatingdescribe 看 Events镜像拉取慢、卷挂载失败CrashLoopBackOfflogs describe启动命令错、配置错、探针失败启动后反复重启查探针配置和容器日志livenessProbe 失败、进程崩溃服务时通时不通查 readinessProbe 和 Endpoints就绪探针失败、Pod 未入池这套排查链路基本能解决日常 90% 的 Pod 异常问题。核心思路就一句话先看describe的 Events再看容器日志最后结合重启策略和探针配置综合判断。最后再分享一个我自己的小习惯任何新环境或者新版本上线前都会先用kubectl apply --dry-runclient -o yaml做一次离线校验再kubectl diff对比线上配置和期望配置的差异。这个习惯帮我提前发现过好几次字段拼写错误和 selector 不匹配的问题。希望这篇文章也能帮你在 Pod 管理这条路上少踩几个坑。
