第 03 篇：为什么 K8s 的最小调度单元是 Pod 而不是容器：pause 容器与边车模式（底座认知 03）

从容器到 Pod

底座认知 · 第 03 篇

为什么 K8s 的最小调度单元是 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 开始看整个集群的「大脑」如何工作。