大家好！今天，我们来聊聊在使用云原生环境时，大家可能都遇到过“陌生的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 网段的秘密 🇬
“我的集群是私有的，为什么Master节点却使用公网IP？”
当你创建GKE集群并执行kubectl cluster-info时，你会发现Master（Control Plane）的地址被分配为类似34.118.x.x的Google公网IP。
🏗️ 结构原因：管理域的隔离
GKE拥有独特的架构。
- 用户VPC (Worker Nodes): 这是我们付费并控制的区域，实际的Pod在此运行。
- Google托管VPC (Control Plane): Master节点存在于Google管理的独立项目/VPC中。
这两个网络在物理上是隔离的，并通过VPC Peering（对等连接）进行通信。
🧐 为何偏偏是公网IP (34.x)？
这里就出现了一个困境。如果Google为Master节点使用10.x或192.168.x这样的私有IP，会怎样呢？
当用户创建的VPC也使用相同的10.x网段时，就会发生IP地址冲突（Overlap），导致无法进行对等连接。
因此，Google将一个“全球范围内不会冲突的IP”——即公网IP（Public IP）网段（如Google拥有的34.x等）分配给了Master节点。
💡 核心要点
- 防止冲突: 无论用户VPC使用何种私有网段，都能确保连接性。
- 可访问性: 作为开发者从外部（互联网）执行
kubectl命令的端点。 - 安全性: 即使启用了Private Cluster选项，Master和Worker节点之间的通信（如隧道）也需要使用此公网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等资源后，用于启动数千个Pod的IP很快就会变得不足。
🛠️ 解决方案：添加Secondary 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 (Master节点) | Pod (Worker节点内部) |
| 使用目的 | 与用户VPC的IP冲突防止及外部访问 | 解决VPC IP枯竭及 확보 Pod专用网段 |
| 网络结构 | Google托管VPC ↔ 用户VPC 对等连接 | 单个VPC内的Secondary CIDR扩展 |
—
📝 结论
在使用云服务时，遇到“非我配置的IP”出现可能会让人感到困惑。但其背后，蕴藏着云服务提供商（CSP）为了防止冲突和实现可扩展性所做的深思熟虑。
- GKE的34.x: 这是Google托管的区域，可以安心地理解为“啊，这是Master节点！”
- EKS的100.64.x: 可以将其视为解决Pod IP不足问题的“扩展槽”。
理解这些差异，将有助于你在设计混合云或多云网络时，更加灵活地应对！👍
如果觉得有帮助，请点赞支持！👏
发表回复