为什么说 GCE 是“现成的网络模型”？

主流公有云都能做到，只是实现方式不同。

GCE：Google Compute Engine，谷歌云（GCP）里的虚拟机服务，相当于 AWS EC2、阿里云 ECS。

GKE：Google Kubernetes Engine，基于 GCE 搭建的托管 K8s 集群。

• GCE（公有云）：
Google 的 VPC 原生支持 Pod 网段，每个节点绑一个“Pod 子网”，Pod IP 是 VPC 内真实可路由 IP，底层路由器直接转发 → K8s 扁平网络假设“天然满足”，不用装 CNI 插件。

• 私有云（自建机房/VMware）：
物理交换机/路由器 只认识节点 IP，不认识 Pod IP（10.244/16 这类），跨节点 Pod 不通 → 必须装 Flannel/Calico 做 overlay 网络，才能满足 K8s 假设。

K8s 的网络模型要求（核心 3 条）：

1. 每个 Pod 有唯一、可路由的 IP（IP-per-Pod）。

2. 所有 Pod 直接互通，跨节点也不用 NAT/端口映射。

3. 节点和 Pod 也能直接互通。

在 GCE/GKE 上，这些都已经做好了

同样，

AWS EKS

• 默认用VPC CNI，Pod IP来自VPC子网

• 底层AWS VPC路由打通，跨节点直连

• ✅ 符合K8s扁平网络，“现成”

3. 阿里云 ACK

• 默认 Terway（VPC路由/ENI）：Pod IP走VPC网段，路由打通

• 可选 Flannel（隧道）：传统overlay

• ✅ 默认符合扁平网络

4. 腾讯云 TKE

• 默认 VPC-CNI：Pod IP在VPC内，底层路由可达

• 可选 Flannel

• ✅ 默认符合扁平网络

5. Azure AKS（关键例外）

• 默认是 Kubenet（岛式网络）：
Pod IP是私有网段，节点做NAT，跨节点Pod不能直连，不符合K8s扁平假设

• 需手动选 Azure CNI 才是扁平网络

• ⚠️ 默认不具备，要额外配置

二、一句话总结

• GKE/EKS/ACK/TKE：默认具备K8s扁平网络，不用自己搭CNI，“现成”

为什么私有云里“不存在”？

你在自己机房/私有云（VMware、OpenStack、裸金属）建 K8s：

• 物理交换机/路由器 只认识节点 IP，不认识 Pod IP（Pod IP 是 K8s 自己规划的，比如 10.244.0.0/16）。

• 跨节点 Pod 通信，物理网络不知道怎么转发，直接不通。

• 所以 K8s 的“扁平网络假设”在私有云里不成立，必须自己实现。

四、私有云怎么解决？（一句话）

用 网络插件（CNI） 做 Overlay 网络（隧道）或 Underlay 路由：

• Flannel（VXLAN）：最常见，简单，适合中小集群。

• Calico（BGP/IPIP）：网络策略强，性能好，生产常用。

• Weave：简单，自动组网，适合测试。

它们的作用：把所有节点上的 Pod 网络，虚拟成一个跨节点互通的扁平网络，满足 K8s 的假设。