Kubernetes 的网络模型设计非常独特，其核心目标是创建一个扁平的、直接的网络结构，使得应用程序从虚拟机或物理机迁移到容器时，不需要对网络架构做太大的修改。

Kubernetes 网络模型主要由以下 3 个基本原则（黄金法则） 加上 1 个 Pod 内部原则 组成：

1. 核心原则（黄金法则）

Kubernetes 强制要求任何网络实现（CNI 插件）必须满足以下三个连通性要求：

1. Pod 与 Pod 之间可以直接通信，无需 NAT（网络地址转换）：

   • 集群中的任何一个 Pod 都可以直接连接到集群中的任何其他 Pod（无论它们是在同一个 Node 上还是不同的 Node 上）。
   • 这意味着不需要像 Docker 默认模式那样进行端口映射（Port Mapping）或链接。

2. Node 与 Pod 之间可以直接通信，无需 NAT：

   • 节点上的系统守护进程（如 Kubelet）可以直接与该节点上运行的所有 Pod 通信。

3. Pod 看到的自己的 IP 与别人看到的它的 IP 是同一个：

   • Pod 不需要通过宿主机的 IP + 端口来被访问。
   • 这被称为 "IP-per-Pod" 模型。每个 Pod 都有自己独立的 IP 地址。

---

2. Pod 内部原则（容器间通信）

除了上述跨 Pod/Node 的原则外，还有一个关于 Pod 内部容器的原则：

• 同一个 Pod 内的所有容器共享同一个网络命名空间（Network Namespace）：
  • 这意味着它们共享同一个 IP 地址和端口范围。
  • 容器之间可以通过 localhost 直接通信。
  • 这也意味着同一个 Pod 内的不同容器不能绑定到相同的端口（否则会冲突）。

---

3. 这种设计解决了什么问题？

在传统的 Docker 网络（Bridge 模式）中，容器通常获得一个私有 IP，外部访问需要通过宿主机 IP + 端口映射（NAT）。这带来了很多问题：

• 服务发现复杂： 容器不知道外部看到的 IP 和端口是什么，导致自注册机制很难实现。
• 端口管理困难： 需要手动管理宿主机的端口分配，避免冲突。
• 性能损耗： NAT 转换会带来 CPU 开销和延迟。

Kubernetes 的模型优势：

• 像虚拟机一样： 每个 Pod 就像网络上的一个独立的虚拟机或物理机，拥有唯一的 IP。
• 兼容性好： 现有的应用程序通常假设它们拥有独立的 IP 和端口，K8s 模型使得应用迁移变得平滑。
• 架构简单： 不需要复杂的 NAT 规则表。

---

4. 现实中的网络通信路径

基于上述原则，Kubernetes 网络主要处理以下四种通信场景：

1. 容器到容器（Container-to-Container）：

   • 发生在同一个 Pod 内部。
   • 通过 localhost 通信。

2. Pod 到 Pod（Pod-to-Pod）：

   • 这是 K8s 网络的核心。
   • 通过 CNI 插件（如 Flannel, Calico, Cilium）构建的 Overlay 网络或路由网络实现。
   • 默认情况下，所有 Pod 之间都是互通的（没有防火墙限制），除非配置了 Network Policy。

3. Pod 到 Service（Pod-to-Service）：

   • Service 提供了一个虚拟 IP（ClusterIP），用于负载均衡一组 Pod。
   • 通过 kube-proxy（使用 iptables 或 IPVS）拦截流量并转发到后端的 Pod。

4. 外部到 Service（External-to-Service）：

   • 通过 NodePort、LoadBalancer 或 Ingress 将集群外部流量引入集群内部。

总结

简单来说，Kubernetes 的网络模型就是一个全连通的扁平网络。Kubernetes 本身不直接实现这个网络，而是制定了标准（CNI - Container Network Interface），由第三方插件（如 Flannel, Calico 等）来具体实现这些原则。