Pod间如何实现直接通信？

在Kubernetes集群中，Pod间的直接通信是网络模型设计的核心要求。与传统虚拟机网络不同，每个Pod都拥有独立的IP地址，这些IP地址在整个集群内必须是可达的。这种设计消除了端口映射的复杂性，使得微服务架构下的应用通信变得直观而高效。

网络命名空间的隔离与共享

每个Pod内部都运行着一个特殊的基础容器——pause容器，它承载着Pod的网络命名空间。当其他业务容器加入Pod时，它们通过Container网络模式共享这个命名空间。这就好比同一套公寓里的多个租客共用同一个门牌地址，数据包在Pod内部通过localhost就能直接流转。

CNI插件的实现机制

真正实现Pod间通信的是CNI插件。当kubelet创建Pod时，它会调用配置好的CNI插件，为Pod的网络命名空间配置虚拟网卡、IP地址和路由规则。常见的实现方案主要分为覆盖网络和路由网络两种模式。

覆盖网络：Flannel的VXLAN方案

Flannel通过在每个节点上创建flannel.1虚拟设备，构建了一个跨节点的虚拟二层网络。数据包在离开源节点时被封装进UDP包，通过底层网络传输到目标节点后再解封装。这种方案对底层网络要求较低，但封装开销会导致约10-20%的性能损耗。

路由网络：Calico的BGP方案

Calico采用了截然不同的思路。每个节点都作为BGP路由器，通过交换路由信息让所有节点都知道如何到达其他Pod子网。数据包直接在节点间通过三层路由转发，避免了封装开销，性能接近物理网络。

• 节点A上的calico-node组件宣告：10.244.1.0/24 via 192.168.1.101
• 节点B学习到该路由，将目标为10.244.1.x的流量直接转发到节点A

服务发现与负载均衡

虽然Pod间可以直接通过IP通信，但在动态调度环境下，Pod的IP地址可能频繁变化。Service资源通过kube-proxy维护的iptables或ipvs规则，为Pod集合提供了稳定的虚拟IP和负载均衡能力。

有趣的是，当两个Pod位于同一节点时，数据包通过cni0网桥在本地转发；当它们位于不同节点时，数据包要么被封装进隧道，要么根据路由表直接转发。这种设计既保证了通信效率，又提供了足够的灵活性。

实际部署中，网络策略的使用往往被忽略。Calico和Cilium等插件支持NetworkPolicy资源，可以精细控制Pod间的访问权限，这在多租户场景下尤为重要。