CFN Cloud
2025-10-04

Pod: 容器的最小调度单元

理解 Pod 的共享网络、存储与生命周期。

Pod 是 Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个容器，它们共享网络与存储。

什么时候需要多容器

  • sidecar：日志/代理/监控
  • 共享数据：同一个 emptyDir
  • 生命周期绑定：一起启动和销毁

示例 Pod

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: app
      image: nginx:1.25
      ports:
        - containerPort: 80
    - name: sidecar
      image: busybox:1.36
      command: ["sh", "-c", "while true; do echo ok; sleep 5; done"]

常用命令

kubectl get pods
kubectl describe pod demo-pod
kubectl logs demo-pod -c app

真实排障的时候，我只先看这几样

Pod 出问题时，先别急着改 YAML。大多数“看起来很复杂”的问题，describe + events + logs 三件套就能把方向指出来。

kubectl get pod -n <ns> -o wide
kubectl describe pod -n <ns> <pod>
kubectl get events -n <ns> --sort-by=.lastTimestamp
kubectl logs -n <ns> <pod> -c <container> --previous

你重点盯这些关键词就行：

  • ImagePullBackOff：镜像/凭证/网络
  • CrashLoopBackOff：应用退出、配置错、依赖连不上
  • OOMKilled：内存不够或者泄漏
  • Readiness probe failed：探针写得太激进，或者依赖还没起来

还有一个很常见但容易忽略的点：Pod 本身“在跑”不等于能接流量。只要 readiness 没过，Service 很可能就不会把流量打进来。

Pod 的工作负载视角

无论是 Pod、探针还是 Namespace，它们都在帮助工作负载变得可预测。Pod 负责把业务意图映射成可运行的单元，并保障生命周期、调度与隔离的稳定性。理解这一层后，后续排障会更有方向。

标签、选择器与归属关系

标签是资源的索引，选择器是控制器和 Service 发现目标的方式。建议统一使用 app、component、env 等标签键。归属关系决定资源的重建逻辑，没有清晰标签和 ownerReferences，排障和清理都会变得困难。

调度与资源请求

调度器依赖 requests 来分配资源。缺少 requests 会导致调度不公平，容易过载。小服务可以先给保守请求，再基于监控调整。Namespace 层面的 ResourceQuota 和 LimitRange 则是约束规则的载体。

启动、就绪与终止

探针应该反映“可用性”，而不是仅仅“进程活着”。readiness 控制流量入口，liveness 需要更宽松避免重启风暴。终止阶段也很关键，设置合理的 terminationGracePeriodSeconds，并处理 SIGTERM，让服务能优雅退出。

隔离与安全基础

Namespace 只负责组织资源，真正的隔离需要配合 RBAC、NetworkPolicy 和安全上下文。像 runAsNonRoot、readOnlyRootFilesystem、capabilities 限制都能显著降低风险。需要提升权限时要说明理由并最小化范围。

资源隔离与噪声邻居

CPU 限额过低会导致节流，内存限额过低会触发 OOM。延迟敏感服务建议设置合理 requests 并留出余量，批处理作业则通过 limits 保护核心业务。

配置与密钥管理

ConfigMap 和 Secret 应作为工作负载契约的一部分。要明确配置变更是触发滚动更新还是热加载，并用 RBAC 控制访问范围。跨环境推广时要保持配置版本一致。

排障流程

推荐固定排障路径：先 describe 看事件，再看日志，必要时进入容器确认探针或依赖是否可用。Namespace 或配额问题时，检查 ResourceQuota 与 LimitRange 能快速定位原因。

kubectl get pods -n demo
kubectl describe pod demo-app -n demo
kubectl logs demo-app -n demo --tail=200
kubectl exec -it demo-app -n demo -- sh

可观测信号

事件说明调度失败或拉取失败，日志解释业务行为，指标显示趋势与瓶颈。三者结合能减少盲目猜测，提高排障效率。

稳定性检查清单

确认每个工作负载有标签、requests 和探针；Service 能找到 Pod；Namespace 的 RBAC 与配额配置合理；启动与终止行为符合真实流量模式。

收个尾：别把 Pod 当成“运行着就行”

线上最容易踩的坑是：Pod “Running” 了，你就以为服务可用了。其实只要 readiness 过不去，Service 就可能根本不会把流量打进来；或者相反，readiness 太激进，服务一忙就被踢出 endpoints，表现出来就是“偶发超时/偶发 502”。

我比较推荐的习惯是：

  • requests/limits 别长期空着（至少给个保守值，后面用监控修正）
  • readiness 宁可先保守一点，别把自己打死；liveness 更要谨慎
  • 配置/密钥变更要有回滚路径（回到哪个版本，怎么 apply 回去）

你只要把 events -> describe -> logs 这条证据链跑熟，Pod 大多数问题都能很快缩小范围。

参考链接

查看原文