Pod是Kubernetes最小可调度单元，由一个或多个共享网络、存储和生命周期的容器组成；其状态包括Pending、Running、Succeeded、Failed、Unknown；常用操作有kubectl run、exec、logs、delete；调度受nodeSelector、affinity、taints/tolerations、resources影响；排查启动失败需先kubectl describe查看Events，再检查镜像、资源、配置及日志。

Kubernetes 中 Pod 是最小的可调度单元，管理好 Pod 是集群稳定运行的基础。 它不是独立运行的进程，而是由一个或多个紧密关联的容器组成的逻辑主机，共享网络、存储和生命周期。理解 Pod 的创建、状态、调度机制和常见问题处理方式，是日常运维和应用部署的核心能力。

Pod 的生命周期与状态解析

Pod 从创建到终止会经历多个阶段，Kubelet 持续监控并上报其状态。常用状态包括：

• Pending：已提交但尚未被调度（如资源不足、镜像拉取中、节点未就绪）
• Running：已绑定到节点，且至少一个容器正在运行（含初始化容器完成）
• Succeeded：所有容器成功退出且不会重启（多见于 Job）
• Failed：至少一个容器以非零码退出，且不满足重启策略
• Unknown：节点失联或状态无法获取（需检查 kubelet 或网络）

通过 kubectl get pods 查看简略状态，用 kubectl describe pod 查看事件（Events）和容器详细状态，这是定位启动失败最直接的方式。

手动管理 Pod 的常用操作

虽然生产环境推荐使用控制器（如 Deployment）管理 Pod，但调试和临时任务仍需直接操作：

• 创建临时 Pod：kubectl run debug-pod --image=busybox:1.35 -- sleep 3600
• 进入容器执行命令：kubectl exec -it debug-pod -- sh（注意指定容器名若 Pod 含多个容器）
• 查看日志：kubectl logs debug-pod；查看前 10 行：kubectl logs debug-pod --tail=10；跟踪实时日志：kubectl logs -f debug-pod
• 删除 Pod：kubectl delete pod debug-pod（控制器会自动重建，除非是裸 Pod）

影响 Pod 调度的关键配置

Kubernetes 默认使用默认调度器将 Pod 分配到合适节点，但可通过以下方式干预调度行为：

• 节点选择器（nodeSelector）：要求 Pod 只能运行在带指定 label 的节点上，例如 disktype: ssd
• 亲和性与反亲和性（affinity）：比 nodeSelector 更灵活，支持软硬约束，比如“尽量和某类服务部署在同一可用区”或“避免和数据库 Pod 同节点”
• Taints 和 Tolerations：给节点打“污点”，只有带对应“容忍”的 Pod 才能调度上去，常用于专用节点（如 GPU 节点、系统组件节点）
• 资源请求（requests）与限制（limits）：决定 Pod 是否能被调度（requests 影响调度决策）、是否会被 OOMKilled（limits 影响 cgroup 限制）

排查 Pod 启动失败的典型路径

当 Pod 卡在 Pending 或 CrashLoopBackOff，按顺序检查：

• 运行 kubectl describe pod ，重点看 Events 区域（如 “FailedScheduling”、“ImagePullBackOff”、“Failed to pull image”）
• 确认镜像名称是否正确、仓库是否可达、是否需要 secret 拉取私有镜像
• 检查节点资源是否充足（kubectl describe nodes 查看 Allocatable 和 Used）
• 验证容器启动命令和参数是否合法（如 CMD 不存在、挂载路径错误、权限不足）
• 若为 CrashLoopBackOff，先查日志：kubectl logs --previous（上一次崩溃的日志）