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 --all-containers，别漏掉 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。
