Pod是Kubernetes调度和管理的最小单位，本质为共享网络、存储且共进退的容器协作单元；底层由pause容器占住网络命名空间并作为根进程维持Pod生命周期；调度经过滤与打分两阶段；状态需结合describe和logs深入排查。
Pod不是容器，而是容器的“协作单元”
直接运行 docker run 能起服务，但在 Kubernetes 里你不能只丢一个容器进去——Kubernetes 调度和管理的最小单位是 Pod，不是容器。它本质是一个逻辑主机（logical host），把一组需要紧密协作的容器“打包”在一起：共享网络（localhost 互通）、共享存储（volume 挂载同一路径）、共进退（同生同死）。比如 Web 容器 + 日志采集 sidecar，必须在同一个 Pod 才能挂载同一 /var/log 目录并实时转发。
每个 Pod 底层都有个“沉默管家”：pause 容器
你 kubectl get pods 看到的 Pod 里似乎只有你的 nginx 或 app 容器，但实际每个 Pod 启动时，Kubernetes 都会先拉起一个 pause（或 pod-infrastructure）容器。它不干业务，只做两件事：
• 占住 Pod 的网络命名空间，让其他容器都复用它的 IP 和端口栈
• 作为整个 Pod 的“根进程”，它的生命周期代表 Pod 的健康状态（一旦 pause 退出，整个 Pod 就被判定为失败）
你不需要写 YAML 去定义它，Kubelet 自动注入；但如果你看到 CrashLoopBackOff 却查不到业务容器日志，先 kubectl logs ，别漏掉 pause 容器的底层报错（比如 cgroup 权限拒绝、PID namespace 初始化失败）。
Pod 调度不是“随便塞”，而是两轮筛选：过滤 + 打分
当你 kubectl apply -f pod.yaml，Scheduler 不是随机挑个节点扔过去。它先做“硬过滤”（Predicates）：
• 节点有没有足够 requests 的 CPU / 内存？
• nodeSelector 标签对得上吗？
• 节点有没有你没声明 toleration 的 taint？
过滤完剩几个候选节点，再“软打分”（Priorities）：
• LeastRequestedPriority 倾向资源空闲多的节点（防热点）
• BalancedResourceAllocation 避免 CPU 用光但内存剩一半这种失衡
常见坑：resources.limits 设太高但 requests 没设 → 过滤阶段就失败（因为 Scheduler 只看 requests 做调度）；nodeName 强制指定节点 → 绕过所有调度逻辑，哪怕节点宕机或根本不存在，Pod 状态也会卡在 Pending。
Pod 状态不是“运行中就万事大吉”
Pending → Running → Succeeded/Failed 是表面状态，真正要盯的是中间细节：
• Pending 且 kubectl describe pod 显示 0/3 nodes are available: 3 Insufficient cpu → 缺资源，不是镜像拉取慢
• Running 但 READY 列是 0/1 → 主容器启动失败，可能探针（livenessProbe）超时或启动命令退出了
• CrashLoopBackOff → 容器反复崩溃重启，90% 情况是环境变量错、配置文件路径挂错、或依赖服务（如 DB）还没就绪（这时该用 initContainer 等待）
注意：RestartPolicy 默认是 Always，但 Job/CronJob 是 OnFailure 或 Never，别在普通 Deployment 里误配成 Never，否则容器一挂就永远停在那里。
