GKE における IP アドレス管理の理解

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

 IP アドレスを提供する際、Kubernetes には需要と供給の問題が生じます。供給側の問題は、RFC1918 アドレス（限定公開インターネット用のアドレス割り振り）を使用する大規模なオンプレミス ネットワークとマルチクラウド デプロイが原因で、組織の IP アドレスが不足することです。需要側の問題は、Pod、ノード、Service といった、それぞれが IP アドレスを必要とする Kubernetes リソースです。この需要と供給の問題から、Kubernetes のデプロイ中に IP アドレスが枯渇するという懸念が生じます。さらに、これらの IP アドレスの管理によって大量のオーバーヘッドが生じます。クラウド アーキテクチャを管理しているチームが、オンプレミス ネットワークを管理しているチームと異なる場合はなおさらです。このような場合、クラウドチームはしばしば、未使用の IP ブロックを確保するためにオンプレミス チームと交渉しなければなりません。

Kubernetes 環境における IP アドレスの管理が困難であることに疑問の余地はありません。IP アドレスの枯渇を解決してくれる特効薬はありませんが、Google Kubernetes Engine（GKE）にはこの問題を解決または回避するための方法があります。

たとえば、Google Cloud Partner である NetApp は、Cloud Volumes Service ファイル サービスをユーザーに提供するうえで GKE とその IP アドレス管理機能に大きく依存しています。

NetApp のシニア テクニカル ディレクターである Rajesh Rajaraman 氏は、次のように述べています。「NetApp の Cloud Volumes Service は、お客様に柔軟かつスケーラブルで、クラウドネイティブなファイル サービスを提供しています。GKE のおかげで非 RFC IP アドレスを柔軟に利用できるので、お客様に IP アドレスの追加を依頼することなく、スケーラブルなサービスをシームレスに提供できるようになりました。Google Cloud と GKE を利用することで、お客様と一緒に安全な SaaS オファリングを作成し、スケーリングを実現できます。」

IP アドレス指定自体が比較的複雑なトピックであり、多数の書籍やウェブ記事の題材となっています。このブログでは、読者が IP アドレス指定の基礎を理解していることを前提としています。そこで、すぐに本題に入り、GKE における IP アドレス指定の仕組み、IP アドレス指定でよく発生する問題、それらの問題を解決するための GKE の機能について見ていきましょう。皆さんが取るアプローチは、組織、ユースケース、アプリケーション、スキルセットによって異なり、IP アドレス管理（IPAM）ソリューションが導入されているかどうかによっても異なります。

GKE における IP アドレス管理

GKE では、IP アドレス管理のために基盤となる GCP アーキテクチャを活用して、VPC サブネット内でクラスタを作成し、そのサブネット内でPod 用のセカンダリ範囲（Pod 範囲）と Service 用のセカンダリ範囲（Service 範囲）を作成します。ユーザーは、クラスタの作成時に GKE に範囲を指定することも、GKE で自動的に範囲が作成されるようにすることもできます。ノードの IP アドレスは、クラスタに関連付けられているサブネットに割り振られた IP CIDR から取得されます。クラスタに割り振られた Pod 範囲が分割され、ノードごとに 1 つのサブ範囲がいくつかできます。新しいノードがクラスタに追加されると、GCP によって自動的に Pod 範囲からサブ範囲が選択され、それがノードに割り当てられます。新しい Pod がこのノードで起動すると、Kubernetes は、そのノードに割り振られたサブ範囲から Pod IP を 1 つ選択します。これを次の図で示します。

プロビジョニングの柔軟性

GKE では、この IP CIDR を 2 つの方法のいずれかで取得できます。1 つはサブネットを定義してそれを GKE クラスタにマッピングすること、もう 1 つは自動モード、つまり GKE に特定のリージョンから自動的にブロックを選択させることです。

まだ始めたばかりで、Google Cloud のみを使用しており、Google Cloud で自動的に IP アドレスを管理させることをご希望の場合は、自動モードをおすすめします。一方、すでに複数の環境にデプロイ済みで、複数の VPC があり、GKE における IP 管理をご自身で制御する場合は、GKE クラスタが使用する CIDR を手動で定義できるカスタムモードの使用をおすすめします。

Flexible Pod CIDR 機能

次に、Pod の IP アドレスの割り振りを見ていきましょう。デフォルトでは、Kubernetes は Pod の IP 割り当て用にノードごとに /24 のサブネット マスクを割り当てます。しかし、ノードごとに 30 個以下の Pod で作成される GKE クラスタの割合が 95% を超えています。このノード当たりの Pod 密度の低さを考えると、Pod ごとに /24 CIDR ブロックを割り振ることは IP アドレスの無駄使いです。多数のノードを持つ大規模なクラスタでは、クラスタ内のすべてのノードについてこの無駄が積み重なります。これにより、IP の使用効率が大幅に悪化する恐れがあります。

Flexible Pod CIDR 機能を使用すると、ノード当たりの Pod 密度を定義できるので、使用するノード当たり IP ブロック数が少なくなります。この設定をノードプール単位で使用できるので、明日 Pod 密度が変更されても、単に新しいノードプールを作成して、より高い Pod 密度を定義すれば済みます。このため、特定の Pod CIDR 範囲により多くのノードを収めたり、同じ数のノードに対してより狭い CIDR 範囲を割り振ったりすることが可能で、GKE クラスタのネットワーク全体における IP アドレス スペースの使用を最適化できます。

Flexible Pod CIDR 機能は、GKE クラスタサイズの代替可能性を高めるために役立ち、次の 3 つの状況でよく使用されます。

• ハイブリッド Kubernetes デプロイの場合: クラスタに大きな CIDR ブロックを割り当てるとオンプレミス IP アドレス管理と重複する確率が高くなるので、そのような割り当てを避けることができます。デフォルト サイズ設定の使用も、IP の枯渇を引き起こす可能性があります。
• IP 枯渇を緩和するため: 小規模なクラスタの場合は、この機能を使用してクラスタのサイズを Pod の大きさに合わせることで、IP を保持できます。
  
• クラスタサイズを柔軟に制御するため: コンテナ アドレス範囲と柔軟な CIDR ブロックを組み合わせて使用することで、デプロイのクラスタサイズを調整できます。柔軟な CIDR ブロックには、クラスタサイズを制御する 2 つのパラメータが用意されています。ご使用のコンテナ アドレス範囲スペースを使用し続けることができるので、IP を保持しながら同時にクラスタサイズを大きくできます。または、（より小さい範囲を使用して）コンテナのアドレス範囲を縮小しながら、同じクラスタサイズを保持することもできます。
  

IP 在庫の補充

IP 枯渇の問題を解決するための別の方法は、IP 在庫を補充することです。RFC 1918 アドレスを使い果たしたお客様は、次の 2 つの新しいタイプの IP ブロックを使用できるようになりました。

1. RFC 1918 以外の予約済みアドレス

2. プライベートで使用されるパブリック IP（PUPI）。現在はベータ版

詳しく見ていきましょう。

RFC 1918 以外の予約済みアドレス

IP が不足しているお客様のために、GCP では RFC 1918 範囲外の追加の予約済み CIDR 範囲に対するサポートを追加しました。機能の観点からは、これらは RFC 1918 アドレスと同様に扱われ、ピアリングを介してデフォルトで交換されます。これらのアドレスを、限定公開クラスタと一般公開クラスタの両方にデプロイできます。これらは予約済みですから、インターネット上ではアドバタイズされません。また、そのようなアドレスを使用する場合、トラフィックはご使用のクラスタと VPC ネットワーク内に留まります。使用可能な最大ブロックは /4 で、これはかなり大きなブロックです。

プライベートで使用されるパブリック IP（PUPI）

RFC 1918 以外の予約済みアドレスと同様に、PUPI では任意のパブリック IP を使用できます（ただし GKE 上で Google が所有するパブリック IP を除く）。これらの IP はインターネットにアドバタイズされません。

たとえば、追加の IP アドレスが必要で、IP 範囲 A.B.C.0/24 を限定公開で使用しているとします。この範囲が MiscellaneousPublicAPIservice.com サービスによって所有されている場合、ご使用のルーティング ドメイン内のデバイスは MiscellaneousPublicAPIservice.com に到達できなくなり、代わりに、それらの IP アドレスを使用する限定公開サービスにルーティングされます。

この理由で、PUPI を使用する際には一般的なガイドラインがいくつかあります。PUPI はお客様の VPC 内に属しており、そのトラフィックは VPC 外には出ないので、インターネット上の実際の IP より優先されます。したがって、PUPI を使用する際には、どの内部サービスからもアクセスされないことが確実にわかっている IP 範囲を選択することをおすすめします。

また、PUPI には、VPC ピアリングを介して選択的に PUPI をエクスポートおよびインポートできるという特別な性質があります。この機能を使用すれば、ユーザーは異なる VPC 内の複数クラスタにデプロイして、Pod IP で同じ PUPI を再利用できます。

クラスタどうしが互いに通信する必要がある場合は、内部 LB アノテーションを付けて servicetype loadbalancer を作成できます。こうすると、これらのサービス VIP のみをピアにアドバタイズできるので、複数のクラスタで PUPI を再利用しながら、同時にクラスタ間の接続を確保できます。

上記の機能は、GCP 上のみで運用している場合でも、ハイブリッド環境で運用している場合でも使用できます。ハイブリッド環境を運用している場合は、他にもソリューションがあります。つまり、重複する IP を使って異なる環境にクラスタの島を作成し、NAT またはプロキシ ソリューションを使用して異なる環境を接続できます。

必要な IP アドレス

IP アドレスの枯渇は、簡単な解決方法のない難しい問題です。しかし、GKE では CIDR ブロックを柔軟に割り当てて IP 在庫を補充できるので、実行する必要があるリソースを確保できます。詳細は、エイリアス IP 範囲を使用して VPC ネイティブ クラスタを作成する方法に関するドキュメントと、GKE アドレス管理に関するソリューションをご覧ください。