Pod是容器编排中进程组概念的对应物用来实现超亲密协作

Docker倡导一个容器封装一个进程的最佳实践，代价是失去了Linux传统进程组 天然共享访问权限和资源配额的能力。设想两个容器要协作（如Nginx+Filebeat 采集其日志），最初只能靠手动挂载共享Volume、用--ipc/--uts/--net 参数让容器共享特定名称空间——这种做法能工作但零散不优雅，本质上是在 “临时拼凑”容器领域里本该存在、却被Docker单进程模型抹掉的”进程组”概念。 Kubernetes的Pod正是补上这个空缺：同一个Pod内的容器”超亲密协作”，默认 共享UTS名称空间（相同主机名域名）、网络名称空间（相同网卡/IP，因此同 Pod内容器端口不能冲突）、IPC名称空间（可用信号量/共享内存通信）、时间 名称空间；只有PID和文件名称空间默认保持隔离（PID隔离让每个容器仍有 自己的1号进程；文件隔离让容器间不冲突，但可以通过Volume共享存储）。 这套共享是靠一个几十行代码、只有几十KB的Infra Container（也叫Pause Container）实现的——它是Pod里第一个启动的容器，其他容器都以它为父容器， UTS/IPC/网络名称空间实质上都来自它；如果Pod设置共享PID空间，Infra Container的进程就变成PID 1，负责清理僵尸进程等管理工作，自己则永远 停留在pause()方法的无限循环里。

结构图：

flowchart TD
    A["超亲密协作: 同一Pod内的容器"] --> B[共享UTS名称空间: 同主机名域名]
    A --> C[共享网络名称空间: 同网卡IP, 端口不可冲突]
    A --> D[共享IPC名称空间: 信号量/共享内存通信]
    A --> E[共享时间名称空间]
    A --> F[默认隔离: PID/文件名称空间]
    G[Infra Container/Pause Container] -->|作为父容器提供UTS/IPC/网络| A