从容器到 Pod
底座认知 · 第 03 篇
为什么 K8s 的最小调度单元是 Pod，而不是容器
目 录
一、为什么需要 Pod
二、Pod 的组成
2.1 业务容器
2.2 沙箱容器（pause 容器）
2.3 init 容器
三、Pod 内容器的协作模式
四、Pod 的资源与网络
4.1 共享网络
4.2 共享存储
五、Pod 生命周期与重启策略
六、生产要点
一、为什么需要 Pod
容器之间是相互隔离的，各自有独立的命名空间。但在真实应用里，常有一组容器「必须紧密协作、共享生命周期与资源」的需求——例如应用进程与其日志采集边车、服务进程与其本地代理。
K8s 用 Pod 把这组容器打包成「一个调度单位」：它们被调度到同一节点、共享网络与存储、同生共死。Pod 才是 K8s 的最小调度单元。
二、Pod 的组成
2.1 业务容器
Pod 内承载实际业务的容器，是核心负载。
2.2 沙箱容器（pause 容器）
每个 Pod 都会有一个 pause（沙箱）容器，它是整个 Pod 的「骨架」：负责持有 Pod 级别的网络命名空间、IPC、UTS 等，业务容器共享它创建的这些资源。
- pause 容器启动最早、驻留最久，通常只做初始化与持有命名空间
- 因为网络栈由 pause 持有，Pod 内所有容器共享同一 IP 与端口空间
- 节点上看到大量 pause 容器是正常现象，不要当作残留进程清理
2.3 init 容器
在业务容器之前按顺序运行的初始化容器，用于做环境准备（等待依赖、初始化配置、权限校验），完成后退出。
三、Pod 内容器的协作模式
模式 | 说明 | 典型场景 |
Sidecar 边车 | 与主容器同生共死，辅助能力 | 日志采集、流量代理 |
Adapter 适配器 | 转换外部接口 | 指标格式转换 |
Ambassador 大使 | 作为本地代理 | 访问外部服务的代理 |
Init 初始化 | 前置准备后退出 | 等待数据库就绪 |
四、Pod 的资源与网络
4.1 共享网络
Pod 内容器共享同一个网络命名空间（由 pause 持有），因此可通过 localhost 互相访问，端口不能冲突。
4.2 共享存储
Pod 内多个容器可挂载同一个 Volume，实现数据共享。这常是边车容器读取主容器日志文件的基础。
五、Pod 生命周期与重启策略
Pod 自身的状态包括 Pending（等待调度）、Running（运行）、Succeeded（正常退出）、Failed（异常退出）、Unknown（状态未知）。
重启策略（restartPolicy）决定容器退出后如何处理：
- Always：总是重启（默认，Deployment 常用）
- OnFailure：仅失败时重启（Job 常用）
- Never：永不重启
需注意：Pod 重启策略作用于「同一 Pod 内容器」，而 Deployment 等控制器则通过新建 Pod 实现更高级别的自愈。
六、生产要点
- 单个 Pod 尽量只承载核心业务，边车能力按需加入，避免过重
- Pod 是「不可变基础设施」思维的最小单位——多通过控制器替换而非原地修改
- 排障时用 kubectl describe pod 查看事件，用 kubectl logs 查看容器日志
理解 Pod 后，下一篇进入控制面，从 kube-apiserver 开始看整个集群的「大脑」如何工作。
