こんにちは！今日は、クラウドネイティブ環境を扱う中で一度は遭遇するであろう「見慣れない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`を実行すると、マスター（コントロールプレーン）のアドレスが34.118.x.xのようなGoogleのパブリックIPとして表示されるのがわかります。
🏗️ 構造的理由：管理領域の分離
GKEはアーキテクチャが独特です。
- User 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などを起動していくと、数千個の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不足を解決するための「拡張スロット」だと考えればよいでしょう。
この違いを理解することで、ハイブリッドクラウドやマルチクラウドネットワークを設計する際に、より柔軟に対応できるようになります！ 👍
お役に立てましたら、ぜひ「いいね」をお願いします！ 👏
コメントを残す