pod的内部结构

我们知道Pod 是 K8s 能够创建、管理和部署的最小计算单元。由一个或多个紧密耦合的容器组成，它们之间共享网络、存储等资源以及如何运行这些容器的声明。pod中的容器会一起启动或停止。 但是Pod 的内部结构是怎样的呢？

很多人第一次接触 Pod，会下意识把它当成“一个容器”。但真跑起来你就会发现：Pod 更像一个容器的组合外壳——外面看是一个整体，里面其实分了好几层：有个“打地基”的基础设施容器，有主业务容器，还有可能挂着 sidecar 这种“跟班容器”，再加上它们共同使用的网络和存储。说白了，Pod 更像一套合租房：人（容器）可以换，但房子的一些公共资源是共享的。

为什么一定要有 Pause（Infra）容器？

Pod 里最容易被忽略、但又最关键的角色，就是 Pause/Infra 容器。它不负责跑业务，反而像“房产证持有人”：把 Pod 的网络命名空间牢牢占住。那问题来了：为啥非得搞这么个“看起来没用”的东西？因为业务容器可能崩溃、可能重启，难道每次一重启 Pod 的 IP 和网络状态也跟着洗牌吗？有了 Pause，网络这块就稳定了——容器重启只是在同一个“网络房间”里重新入住而已。

虽然有了pause可以共享网络，但是同一个 IP、同一个 localhost，也更容易“撞车”

同一个 Pod 里的容器，网络层面就是“一家人”：整个 Pod 只有一个 IP，容器之间甚至可以直接用localhost:端口通信，像本机进程互相调用一样省事。可共享的东西总要付点代价——既然都用一个 IP，那如果两个容器都想监听 8080 端口怎么办？没得商量，端口冲突就是硬约束。

一个pod中通常把同一个 Volume 当“公共储物间”来用，共享存储。

Pod 里的 Volume，可以被多个容器同时挂载。最典型的画面就是：一个容器负责产生日志（写入某个目录），另一个容器负责把这些日志读走并转发。你可以把 Volume 理解成合租房的“公共储物间”：谁都能进，谁都能用，前提是你们确实要一起生活、一起承担后果。

pod中的应用容器多数时候一个就够，多容器通常是 Sidecar 在“打辅助”

现实里最常见的还是单容器 Pod：一个业务一个 Pod，简单直接。那多容器 Pod 什么时候用？通常是 Sidecar 模式——主容器跑业务，sidecar 做日志收集、监控、代理之类的“辅助活”，像给摩托车挂个斗：不改变主车用途，但能把配套能力带上。

元数据是Pod 的“身份证”，靠它才能被 Service/Deployment 找到

Pod 不光要能跑，还得能被“识别”和“管理”。Name、Namespace 这些是基础，而更常用的是 Labels：Service、Deployment 等资源就是靠标签去“筛人”的；另外还有 Annotations，更像备注信息，通常不拿来做选择匹配，但很适合塞一些构建信息、说明信息。你可以理解为：Labels 是“门牌号+分组标签”，Annotations 是“贴在门上的便签”。

那么K8s 为啥要发明 Pod，而不是直接管容器呢？

归根结底，Pod 是给那些“必须黏在一起”的进程准备的：它们要共享网络、共享存储、生命周期还要一致，那就别硬拆成两个独立容器到处调度了。Pod 还相当于给容器套了一个统一的“外壳”，让 K8s 可以用同一套方式去调度和管理，而不必纠结底层到底是 Docker 还是 containerd。

总结：Pod 可以当成一台“逻辑主机”来看——有稳定的网络身份、有共享的存储空间、也有一堆容器住在里面各司其职。