大家好！今天我想和大家聊聊在处理云原生环境时，可能会遇到的一些“陌生IP网段”。
在运营Kubernetes时，你可能会偶尔产生疑问：“咦？我们公司的VPC网段是10.0.0.0/16，怎么会看到34.x.x.x呢？”或者“为什么AWS EKS Pod的IP是100.64.x.x？”
这两种情况虽然产生的原因不同，但最终都围绕着一个共同的主题：云网络的结构性限制和IP资源管理。接下来，我们将详细探讨GKE和EKS各自如何处理网络！🚀
1. GKE (Google Kubernetes Engine) 和 34.x.x.x 网段的秘密 🇬
“我的集群是私有的，为什么主节点会使用公有IP？”
创建GKE集群并运行`kubectl cluster-info`后，你会看到主节点（控制平面）的地址被分配为Google的公有IP，例如34.118.x.x。
🏗️ 结构性原因：管理区域的隔离
GKE的架构非常独特。
- 用户VPC (工作节点): 这是我们付费并控制的区域。实际的Pod会在这里运行。
- Google Managed VPC (控制平面): 主节点存在于Google管理的独立项目/VPC中。
这两个网络在物理上是隔离的，并通过VPC Peering（对等连接）进行通信。
🧐 为什么偏偏是公有IP (34.x)？
这里就出现了两难。如果Google在主节点上使用10.x或192.168.x这样的私有IP会怎样呢？
如果用户将自己的VPC也创建在相同的10.x网段，就会发生IP冲突（Overlap），导致对等连接无法建立。
因此，Google将“全球范围内都不会重叠的IP”，即公有IP (Public IP) 网段（如Google拥有的34.x等）分配给了主节点。
💡 核心总结
- 避免冲突: 无论用户VPC使用何种私有网段，都能进行连接。
- 可访问性: 作为开发人员从外部（互联网）执行`kubectl`命令的端点。
- 安全性: 即使开启了私有集群选项，该公有IP网段仍会在内部用于路由，例如主节点和工作节点之间的隧道。
2. AWS EKS 和 100.64.x.x (Secondary CIDR) 的身份 🅰️
“VPC IP不够用！我们需要一个Pod专用网段！”
在运营AWS EKS时，你经常会看到Pod IP被分配到100.64.x.x网段。这与AWS VPC CNI插件的特性密切相关。
😱 问题：IP耗尽 (IP Exhaustion)
AWS VPC CNI为每个Pod分配一个实际的VPC IP。虽然性能极佳，但IP消耗巨大。
例如，即使你用10.0.0.0/16 (65,536个)创建了VPC，但随着子网的划分以及EC2、ELB、RDS等的部署，很快就会出现IP不足以启动数千个Pod的情况。
🛠️ 解决方案：添加辅助CIDR
此时使用的技术是在VPC中添加辅助IP网段 (Secondary CIDR)。其中最常推荐的网段就是100.64.0.0/10。
🧐 100.64.x.x 是什么？ (CGNAT)
该网段是RFC 6598标准中定义的CGNAT (Carrier Grade NAT) 网段。
- 不是公有IP: 不会在互联网上路由。
- 也不是普通私有IP (10.x, 192.168.x): 与企业内部网络常用的网段重叠的可能性非常低。
换句话说，它是一个“非常适合用于私有网络扩展，且不会发生冲突的备用网段”。EKS将此网段专门分配给Pod，从而将节点（EC2）使用的IP网段与Pod使用的IP网段分开，解决了IP不足的问题。
💡 核心总结
- IP获取: 突破现有VPC带宽的限制，可以无限(?)地创建Pod。
- 易于管理: 节点IP和Pod IP明确区分，便于管理。
- 符合标准: 利用CGNAT网段避免私有IP冲突。
🥊 一目了然的比较
| 类别 | GKE (Google) | EKS (AWS) |
|---|---|---|
| 观察到的IP | 34.118.x.x (示例) | 100.64.x.x |
| IP类型 | Public IP (公有IP) | CGNAT IP (共享地址) |
| 目标资源 | Control Plane (主节点) | Pod (工作节点内部) |
| 使用目的 | 与用户VPC避免IP冲突及外部访问 | 解决VPC IP耗尽并 확보Pod专用网段 |
| 网络结构 | Google管理VPC ↔ 用户VPC对等连接 | 单一VPC内扩展辅助CIDR |
—
📝 结论
使用云服务时，有时会遇到“我没有配置的IP”突然出现，让人感到困惑。然而，这背后蕴含着云服务提供商（CSP）为避免冲突和实现可扩展性而深思熟虑的设计。
- GKE的34.x: 这是Google管理的区域，所以请放心，“啊，这是主节点！”
- EKS的100.64.x: 可以将其视为解决Pod IP不足的“扩展槽”。
理解这些差异，将使你在设计混合云或多云网络时，能够更加灵活地应对！👍
如果这篇文章对您有帮助，请点赞！👏
发表回复