こんにちは！今日は、クラウドネイティブ環境を扱っていると一度は目にする「見慣れないIP帯域」についてお話ししたいと思います。
Kubernetesを運用していると、時折「あれ？うちのVPC帯域は10.0.0.0/16なのに、なぜ34.x.x.xが表示されるんだ？」とか、「AWS EKSのPod IPがなぜ100.64.x.xなんだ？」といった疑問を持つことがあります。
これら2つのケースは異なる理由で発生しますが、最終的にはクラウドネットワークの構造的な限界とIPリソース管理という共通のテーマを持っています。GKEとEKSがそれぞれネットワークをどのように扱っているのか、詳細に掘り下げていきましょう！🚀
1. GKE (Google Kubernetes Engine)と34.x.x.x帯域の秘密 🇬
「私のクラスターはプライベートなのに、なぜマスターノードはパブリックIPを使うの？」
GKEを作成してkubectl cluster-infoを実行すると、マスター（Control Plane）のアドレスが34.118.x.xのようなGoogleのパブリックIPで設定されていることが確認できます。
🏗️ 構造上の理由：管理領域の分離
GKEはユニークなアーキテクチャを持っています。
- User VPC (ワーカーノード): 私たちが費用を支払い、制御する領域です。ここに実際のPodが起動します。
- Google Managed VPC (コントロールプレーン): Googleが管理する別のプロジェクト/VPCにマスターノードが存在します。
これら2つのネットワークは物理的に分離されており、通信のために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コマンドを実行できるエンドポイントの役割を果たします。 - セキュリティ: Private Clusterオプションをオンにしても、マスターとワーカーノード間のトンネリングなどのために、この公衆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が明確に区別され、管理が容易になります。
- 標準準拠: プライベートIPの衝突を避けるためにCGNAT帯域を活用します。
🥊 一目で比較
| 区分 | 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内でのSecondary CIDR拡張 |
—
📝 結論
クラウドを利用していると、「自分が設定していないIP」が出現して戸惑うことがあります。しかし、その裏には衝突防止と拡張性のためのクラウドプロバイダー（CSP）たちの深い配慮が込められています。
- GKEの34.x: Googleが管理する領域なので、「ああ、マスターノードだな！」と安心してください。
- EKSの100.64.x: Pod IP不足を解決するための「拡張スロット」だと考えれば良いでしょう。
この違いを理解することで、ハイブリッドクラウドやマルチクラウドのネットワーク設計において、より柔軟に対応できるようになります！👍
お役に立てたら、いいねをお願いします！👏
コメントを残す