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

实操要点

• 先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
• 对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
• 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

• 资源定义与业务意图一致。
• Namespace、权限、镜像与环境匹配。
• 上线前具备健康探针与可观测日志。

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 与配额配置合理；启动与终止行为符合真实流量模式。

实战补充

把快速入门应用到真实业务时，建议固定一套检查项：资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复，并随仓库一起维护，这样每次发布都能快速对齐标准。

排障路径

从现象入手，不要先猜原因。先看事件，再看日志，最后验证流量路径和配置版本是否一致。若访问异常，先确认 readiness 和 endpoints，再逐段排查入口到后端的链路。记录每一步改动，方便回滚和复盘。

小练习

在测试环境做几次常见操作：扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习，你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口，准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划，确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次：访问核心接口、观察延迟和错误率，确认新旧 Pod 的状态稳定。如果涉及存储或网络，顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤，包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原，而不是现场临时拼步骤。

参考链接

• Pod
• Pod 生命周期