Containers & Kubernetes

IPv4 クラス E アドレス空間を活用して GKE での IPv4 枯渇の問題を軽減する

2024年10月10日

Basant Amarkhed

Software Engineer, GKE Networking

Gopinath Balakrishnan

Customer Engineer, GCP Networking

※この投稿は米国時間 2024 年 9 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）上でホストされるアプリケーションやサービスの数が増え続けているのに伴い、プライベート IPv4 アドレス（RFC 1918）の需要も高まっています。多くの大規模な組織では、RFC1918 アドレス空間がますます不足してきており、アプリケーションのスケールに影響する IP アドレス枯渇の課題が生じています。IPv6 を導入すれば、使用可能なアドレスが大幅に増えるため、このアドレス枯渇の問題を解決できますが、現状ではすべての企業やアプリケーションが IPv6 に対応しているわけではありません。そこで、IPv4 クラス E アドレス空間（240.0.0.0/4）を活用すれば、この問題に対処し、ビジネスの成長を継続させることができます。

Google VPC ネットワークの有効な IPv4 範囲で説明されているように、クラス E アドレス（240.0.0.0/4）は、RFC 5735 と RFC 1112 に記載されているとおり、将来の使用のために予約されています。とは言え、特定の状況で現在クラス E アドレスを使用できないわけではありません。このブログ投稿では、クラス E アドレスに関するよくある誤解について深く掘り下げ、クラス E アドレスを使用することのメリットと考慮事項について説明し、クラス E を活用した GKE クラスタの計画と使用のガイダンスを示します。また、お客様である Snap がクラス E を活用して IP アドレス枯渇の課題を克服した実例も紹介します。

クラス E アドレスについて

クラス E アドレスの使用に関するよくある否定的な意見または誤解を以下にいくつか示します。

クラス E アドレスは他の Google サービスでうまく機能しない - これは正しくありません。Google Cloud VPC の有効な IPV4 アドレス範囲にはクラス E アドレスが含まれています。さらに、多くの Google マネージドサービスには、クラス E アドレスによるプライベート接続方法でアクセスできます。
クラス E アドレスを使用すると、Google の外部（インターネット / オンプレミス環境との相互接続 / 他のクラウド）のサービスとの通信が制限される - これは誤解です。クラス E アドレスはルーティングできず、インターネット経由や、Google Cloud の外部でアドバタイズされませんが、NAT または IP マスカレードを使用してクラス E アドレスをパブリックまたはプライベート IPv4 アドレスに変換することで、Google Cloud の外部の宛先にアクセスできます。また、以下の事実もあります。

注目すべき例外として Microsoft Windows があるものの、多くのオペレーティングシステムは現在、クラス E アドレスをサポートしています。
多くのオンプレミスベンダー（Cisco、Juniper、Arista など）が、プライベート DC 用にクラス E アドレスのルーティングをサポートしています。

クラス E アドレスにはパフォーマンスやスケールの制限がある - これは正しくありません。クラス E アドレスと、Google Cloud で使用される他のアドレス範囲に、パフォーマンスの違いはありません。NAT または IP マスカレードを使用しても、パフォーマンスに影響を与えることなく、エージェントをスケールして多数の接続をサポートできます。

このように、クラス E アドレスは、将来の使用のために予約されており、インターネット経由でルーティングできず、公共のインターネット経由でアドバタイズできませんが、Google Cloud VPC 内でプライベートに使用することは可能です。GKE の Compute Engine インスタンスでも、Kubernetes の Pod / Service でも使用できます。

メリット

クラス E アドレスには、上記のような注意点があるものの、多くのメリットがあります。

広大なアドレス空間 - クラス E アドレスは、従来の RFC 1918 プライベートアドレスと比べて、IP アドレスのプールが非常に大規模です（RFC 1918: 最大 1,790 万のアドレス、クラス E: 最大 2 億 6,840 万のアドレス）。この豊富な IP アドレスは、IP アドレス枯渇に直面している組織にとって大きなメリットです。これにより、限定的なアドレス空間の制約なしにアプリケーションやサービスをスケールできます。
スケーラビリティと成長 - クラス E の広大なアドレス空間により、Google Cloud および GKE 内でアプリケーションやサービスを簡単にスケールできます。IP アドレスの制限なしにインフラストラクチャをデプロイし、拡大できるため、使用量がピークになる期間でも成長とイノベーションを促進できます。
リソースの効率的な利用 - クラス E アドレスにより、IP アドレス割り振り戦略を最適化し、アドレス競合のリスクの最小化と、IP リソースの効果的な使用を実現できます。これが、コストの削減と業務の効率化につながります。
将来への対応 - すべてのオペレーティングシステムがクラス E をサポートしているわけではありませんが、より多くの IP アドレスが必要になるのに伴い、クラス E への対応は拡大すると予測されています。早い段階でクラス E を導入することで、将来的なインフラストラクチャのスケールに対応し、今後何年にもわたってビジネスの成長を支えることができます。

認識すべき事項

クラス E IP アドレスには大きなメリットがありますが、重要な考慮事項がいくつかあります。

オペレーティング システムの互換性: 現在、すべてのオペレーティングシステムがクラス E アドレスをサポートしているわけではありません。クラス E を実装する前に、ご利用のオペレーティングシステムとツールに互換性があることをご確認ください。
ネットワーク機器とソフトウェア: ルーターやファイアウォール（Google Compute Engine で実行されるサードパーティの仮想アプライアンスソリューション）などのネットワーク機器でクラス E アドレスを処理できることを確認します。また、IP アドレスと通信するソフトウェアやアプリケーションが、クラス E をサポートするように更新されていることも確認します。
移行: 現在 RFC 1918 プライベートアドレスを使用している場合、クラス E に移行するには、中断を回避するための慎重な計画とその遂行が必要になります。

Snap がクラス E を導入した経緯

GKE のような、マイクロサービスとコンテナ化のプラットフォームを使用する頻度が高まると、特に Snap のような大規模企業のお客様の場合、ネットワーク IP 管理の課題が生じます。Snap では、数十万もの Pod をデプロイしたことで、同社の限られた RFC1918 プライベート IPv4 アドレスプールはすぐに枯渇してしまいました。そのため、クラスタのスケーラビリティが妨げられ、アドレスを解放するために多大な手作業が必要でした。

当初、Snap は IPv6 への移行を検討していましたが、アプリケーションの準備状況と相互運用性に関する懸念から、デュアルスタックの GKE ノードおよび GKE Pod（IPv6 + クラス E IPv4）を採用することにしました。このソリューションにより、IP 枯渇が軽減され、今後の成長のサポートと運用オーバーヘッドの削減に必要な IP アドレスを何年も確保できる余裕が生まれました。また、このアプローチは、IPv6 に移行する Snap の長期的な戦略にも沿ったものでした。

「IPv4 クラス E アドレス空間の導入により、当社の IP 容量は倍増し、スケーリングの問題が解決しただけでなく、アドレス枯渇とサブネット管理の問題も解消されました。今では、ゲートウェイや ML のワークロードなど、大規模で複雑なユースケースも、複数のリージョンにわたってクラス E アドレス空間でスムーズに実行されています。」- Snap、ソフトウェアエンジニアリングマネージャー Mahmoud Ragab 氏

クラス E を使用したクラスタの構成

新しいクラスタ

要件VPC ネイティブクラスタを作成します。

手順

セカンダリ範囲があるサブネットワークを作成します。このセカンダリ範囲で、クラス E 範囲（240.0.0.0/4）の CIDR を使用できます。
Pod および Service の CIDR 範囲に、上記で作成したセカンダリ範囲をクラスタ作成時に使用します。これは、こちらで示されているユーザー管理のセカンダリ範囲割り当て方法です。
必要に応じて、Pod IP アドレスから基盤となるノードの IP アドレスへの送信元ネットワークアドレス変換（SNAT）を行うように IP マスカレードを構成します。

クラスタの移行

要件クラスタは VPC ネイティブクラスタである必要があります。

手順

クラスタのデフォルトの Pod IPv4 範囲を更新することはできません。ただし、クラス E 範囲を使用できる新しいノードプールの Pod 範囲を追加することはできます。
必要に応じて、ワークロードを古いノードプールから（Pod にクラス E を使用する）新しいノードプールに移行できます。

IPv4 クラス E から IPv6 への移行

今では、IPv4 クラス E アドレスと IPv6 アドレスを使用するデュアルスタックのクラスタへの移行は、IP 枯渇に直面している組織にとってスマートな戦略的対応です。使用可能な IP アドレスプールの拡大により、問題が即座に解消され、Google Cloud および GKE 内でスケーラビリティの確保と成長の促進が可能になります。さらに、デュアルスタックのクラスタの導入は、IPv6 のみを使用する段階へのスムーズな移行に向けた重要な第一歩となります。