GKE への移行時に IP アドレスを計画する

このドキュメントでは、Google Kubernetes Engine（GKE）で IP アドレスの使用を管理する方法と、必要に応じて GKE で代替ネットワーク モデルを使用する方法について説明します。このドキュメントでは、次のコンセプトについて説明します。

  • GKE での Pod IP アドレスの使用量を減らして、GKE がほとんどの組織の IP アドレスのニーズに合うようにする方法。
  • クラスタ アーキテクチャが組織の要件を満たしていない場合に、GKE で代替ネットワーキング モデルを実装する方法。

このドキュメントは、Kubernetes クラスタを他の環境から GKE に移行することを計画しているクラウド アーキテクト、オペレーション エンジニア、ネットワーク エンジニアを対象としています。組織が予定する GKE の使用に対して十分な内部 IP アドレスを割り当てることが難しいと思われる場合は、このドキュメントのガイダンスを使用してください。

このドキュメントは、Kubernetes とそのネットワーキング モデルを理解していることを前提としています。また、IP アドレス指定、ネットワーク アドレス変換（NAT）、ファイアウォール、プロキシなどのネットワーキングのコンセプトにも精通している必要があります。

このドキュメントでは、Service の IP アドレスに使用されるアドレス範囲の管理戦略については説明しません。Service に必要なアドレスの数は Pod よりもはるかに少なく、この数を減らすオプションは限られています。GKE では、クラスタの存続期間中に Service の IP アドレスの範囲が固定されます。そのため、Service の IP アドレスの範囲は、予想される Service の最大数のサイズにする必要があります。Service の IP アドレスはクラスタ外で到達できないため、他のネットワークで再利用できます。

このドキュメントでは、さまざまな Kubernetes ネットワーク モデル（完全統合、アイランドモード、分離）についても説明します。これらのモデルでは、ネットワーク全体で Pod の IP アドレスに到達する方法が異なります。これらの違いは、使用できる IP アドレス管理戦略に影響します。これらのモデルと GKE ネットワーク モデルの詳細については、GKE とその他の Kubernetes 実装で使用されるネットワーク モデルの比較をご覧ください。

GKE での内部 IP アドレスの使用量を減らす

GKE は完全統合ネットワーク モデルを使用します。このモデルでは、クラスタが VPC ネットワークにデプロイされ、他のアプリケーションを含めることもできます。GKE モデルには多くのメリットがあります。ただし、このタイプのモデルでは、Pod の IP アドレスを再利用できません。再利用が行われないことから、VPC ネットワーク全体で一意の Pod IP アドレスを使用する必要があります。したがって、必要な一意の IP アドレスの数を慎重に検討する必要があります。

必要な一意のアドレスの数は、IP アドレスの使用量を削減する必要があるかどうかに次のように影響します。

  • IP アドレスのニーズに対応する十分なアドレス空間がある場合は、IP アドレスの使用量を減らすための手順を行う必要はありません。ただし、IP アドレスの使用量を減らす方法がわかっていれば、使用する IP アドレスの最小数を特定する際に役立ちます。
  • 十分なアドレス空間がない場合は、アドレス空間の制約に適合する GKE クラスタを作成するために、IP アドレスの使用量を減らす必要があります。

GKE で IP アドレス使用量を減らすには、次のオプションを検討してください。

  • ノードあたりの Pod 設定を変更する。デフォルトで、GKE の Standard クラスタはノードごとに /24 サブネット範囲を予約し、最大でノードあたり 110 Pod まで許容されます。ノードあたりの Pod 数が 64 以下であると予想される場合は、ノードあたりの最大 Pod 数を調整することで、Pod IP アドレスの使用量を半分以上減らすことができます。Autopilot クラスタでは、ノードあたり 32 個の Pod を使用できます。この設定は変更できません。
  • 複数の Pod IP アドレス範囲を使用する。連続していないマルチ Pod クラスレス ドメイン間ルーティング（CIDR）を使用して、セカンダリ Pod IP アドレス範囲を既存のクラスタに追加できます。各ノードプールで使用する Pod IP アドレス範囲を選択できます。各プールで使用する IP アドレス範囲を選択すると、最初の Pod IP アドレス空間を割り振る際に、クラスタの拡張性を考慮しながら慎重に割り振る必要があります。

  • RFC 1918 以外の IP アドレスを使用する。エンタープライズ ネットワークに、Pod の IP アドレスに使用する未割り振りの RFC 1918 IP アドレスが十分にない可能性があります。未割り振りの RFC 1918 IP アドレスが十分でない場合は、RFC 1918 以外のアドレス（例:RFC 6598 アドレス空間（100.64.0.0/10））を使用できます。

    企業ネットワーク内の他の場所で RFC 6598 空間をすでに使用している場合は、Pod IP アドレスとして Class E/RFC 5735（240.0.0.0/4）のアドレス空間を使用できます。ただし、Windows ホストと一部のオンプレミス ハードウェアでは、これらの IP アドレスからのトラフィックがブロックされます。RFC 5735 アドレスのブロックを回避するには、Pod IP アドレスをオンプレミス ネットワークからのみ非表示にするの説明に従って、これらの外部宛先へのトラフィックをマスカレードすることを検討してください。ただし、外部の宛先にトラフィックをマスカレードすると、オンプレミス アプリケーションに送信されるテレメトリー データの一部が失われます。

組織に大きなパブリック IP アドレス空間がある場合は、プライベートで使用されるパブリック（PUPI）アドレスを使用することもできます。PUPI アドレスを使用する場合、NAT を使用せずにクラスタ外部と接続するには、PUPI アドレスを nonMasqueradeCIDRs リストに含める必要があります。

GKE でネットワーク モデルを選択する

GKE ネットワーキング モデルのドキュメントでは、関連する Pod IP アドレスなど、GKE での Standard クラスタの動作について説明しています。このドキュメントでは、GKE での内部 IP アドレスの使用量を減らすセクションで、クラスタに必要な内部 IP アドレスの数を減らす方法について説明します。GKE ネットワーク モデルの仕組みと内部 IP アドレスを減らす方法の両方を理解することは、GKE で使用するネットワーク モデルの基盤となります。

しかし、これらのコンセプトを理解して適用しただけでは、ニーズを満たすネットワーク実装が得られない可能性があります。以下のディシジョン ツリーを参考に、最適な GKE ネットワーク モデルを実装する方法を決定できます。

GKE での IP アドレス移行戦略に関するディシジョン ツリー。

このディシジョン ツリーは常に、完全に統合されたネットワーク モデルに基づく GKE Standard クラスタを作成することから始まります。ツリーの次のステップでは、このドキュメントで説明するすべてのオプションを適用して、IP アドレスの使用量を削減します。

IP アドレスの使用量をできるだけ削減しても、GKE クラスタに十分なアドレス スペースがない場合は、代替ネットワーク モデルが必要です。ディシジョン ツリーは、使用する代替ネットワーク モデルを決定する際に役立ちます。

このディシジョン ツリーはガイダンスとしてのみ使用してください。特定のユースケースでは、各モデルの長所と短所に基づいて、別のモデルを選ぶ場合もあります。多くの場合は複数のモデルを使用でき、組織に適したアプローチを選択できます。

ディシジョン ツリーに示されている代替モデルがニーズを満たさないことがまれにあります。このようなまれなケースでは、マルチ NIC インスタンスを使用してクラスタのアドレスを非表示にするで説明されているモデルを使用できる場合があります。

代替ネットワーク モデルをエミュレートする

完全統合ネットワーク モデルのメリットを活用するには、GKE クラスタを他のクラウド リソースと同じ論理ネットワーク内に維持することをおすすめします。ただし、この推奨事項に従うことができない場合があります。十分な IP アドレス空間がない場合や、組織の大規模なネットワークで Pod IP アドレスを非表示にする必要がある場合があります。

このセクションでは、GKE でのさまざまな代替ネットワーク モデルを模倣した、さまざまなアーキテクチャ パターンについて説明します。これにより、完全統合ネットワーク モデルを使用するためのオプションを提供します。これらの代替アーキテクチャ パターンにより、アイランド モード ネットワーク モデルや分離モード ネットワーク モデルに類似した GKE のオペレーション モードが作成されます。

それぞれの代替アーキテクチャ パターンには、次の情報が含まれています。

オンプレミス ネットワークでのみ Pod IP アドレスを非表示にする

IP アドレスをオンプレミス ネットワークで非表示にするアーキテクチャ パターンでは、次のルーティング目標を組み合わせて使用します。

  • Google Cloud 上の GKE クラスタに、Google Cloud Deploy 全体でルーティングされる Pod IP アドレスを割り当てます。
  • これらの IP アドレスが、NAT なしでオンプレミス リソースまたは、Cloud VPN または Cloud Interconnect を通して他のクラウド環境にルーティングされないようにします。

このアーキテクチャ パターンは、クラス E/RFC 5735 の IP アドレス空間でよく使用されます。これは、この空間には多くの IP アドレスが含まれているためです。使用可能な IP アドレスが大量にあると、各 Pod に一意の IP アドレスを提供する必要性に対応できます。ただし、多くのネットワーク ハードウェア ベンダーがこのトラフィックをブロックしているため、クラス E/RFC 5735 の IP アドレスはオンプレミス リソースに簡単にルーティングできません。

クラス E/RFC 5735 の IP アドレス空間を使用する代わりに、RFC 1918 の IP アドレスまたは RFC 1918 以外の IP アドレスの内部セットを使用できます。他の IP アドレスセットを使用する場合は、Pod に使用されているアドレスとオンプレミス ネットワークで使用されるアドレスの間で、IP アドレスが重複していないかどうかを確認します。重複がある場合は、それらのアドレスを使用するクラスタと、同じアドレスを使用するオンプレミス アプリケーション間の通信がないようにします。

このアーキテクチャ パターンを設定する手順の概要は次のとおりです。

  1. Pod サブネットのセカンダリ IP アドレス範囲を作成します。このセクションで前述したように、このアドレス範囲はクラス E/RFC 5735 の空間、RFC 1918 の空間、または RFC 1918 以外の IP アドレスの内部セットから作成できます。通常、クラス E/RFC 5735 の空間が使用されます。
  2. カスタム アドバタイズ ルートを使用し、Cloud Router のアドバタイズから Pod IP アドレス範囲を削除します。これらのアドレスを削除すると、Border Gateway Protocol（BGP）を介してオンプレミス ルーターに Pod IP 範囲が通知されなくなります。
  3. Pod のクラスレス ドメイン間ルーティング（CIDR）としてセカンダリ IP アドレス範囲を使用して、GKE クラスタを作成します。GKE での内部 IP アドレスの使用量を減らすで説明した方法で、IP アドレスの使用量を減らすことができます。

  4. 次の IP アドレスをマスカレード エージェントの nonMasqueradeCIDRs リストに追加します。

    • Pod に使用される IP アドレス範囲。
    • ノードに使用される IP アドレス範囲。
    • Google Cloud でのみ使用される他の IP アドレス（Google Cloud で使用されるプライマリ IP アドレス範囲など）。

    オンプレミス環境または他のクラウド環境で使用されている内部 IP アドレス範囲は含めないでください。Google Cloud に Windows ワークロードがある場合は、別のサブネットに保持し、これらの範囲も含めないでください。

上記の手順を使用してこのパターンを設定すると、クラスタが次の動作をするように構成されます。

  • Google Cloud 内で完全に統合されたネットワーク モデルのように動作する。
  • オンプレミス ネットワークとやり取りする場合は、アイランド モード ネットワーク モデルのように動作する。

この代替パターンでアイランド モードのネットワーク モデルを完全にエミュレートするには、マスカレード エージェントの nonMasqueradeCIDRs リストを、クラスタのノードと Pod の IP アドレス範囲のみを含むリストに変更する必要があります。このようなリストを作成すると、Google Cloud 内であっても、クラスタ外のトラフィックは常にノード IP アドレスにマスカレードされます。ただし、この変更を行うと、VPC ネットワーク内の Pod レベルのテレメトリー データを収集できなくなります。

次の図は、このアーキテクチャ パターンの実装を示しています。

オンプレミス ネットワークのみから IP アドレスを非表示にする実装を示すネットワーク図。

上の図は、外部ネットワークから Pod の IP アドレスを非表示にする方法を示しています。この図に示すように、Google Cloud 内の Pod はクラスタ間でも直接通信できます。この Pod 通信は、GKE モデルと似ています。この図には、クラス E/RFC 5735 の空間のアドレスを使用している Pod も示されています。

クラスタ外に送信されるトラフィックの場合、この図は送信元 NAT（SNAT）がノードから出るときにそのトラフィックに適用される方法を示しています。SNAT は、トラフィックが Cloud VPN 経由でオンプレミス アプリケーションに転送されるか、Cloud NAT 経由で外部アプリケーションに転送されるかにかかわらず使用されます。

このアーキテクチャ パターンでは、Google Cloud 内の通信に Pod IP アドレスを使用します。トラフィックがマスカレードされるのは、オンプレミス アプリケーションまたは他のクラウド環境に転送される場合のみです。オンプレミス アプリケーションから Pod に直接接続することはできませんが、内部ロード バランシングを介して公開された Service には接続できます。

Pod IP アドレスをオンプレミス ネットワークから非表示にすることには、次のようなメリットがあります。

  • ファイアウォールの使用や、Pod の IP アドレスに基づくテレメトリー データの収集など、Google Cloud 内の完全統合ネットワーク モデルの利点を活用できます。また、デバッグの目的で Google Cloud 内から Pod に直接接続することもできます。
  • Google Cloud 内の Pod IP アドレスを使用してマルチクラスタ サービス メッシュを使用できます。

ただし、Pod IP アドレスを外部ネットワークから非表示にすることには、次のようなデメリットがあります。

  • Google Cloud 内の異なるクラスタで Pod または Service の IP アドレス範囲を再利用することはできません。
  • オンプレミス ネットワーク間のトラフィック用と Google Cloud 内の完全なトラフィック用の 2 つの異なるファイアウォール ルールセットの管理が必要になることがあります。
  • Google Cloud と、オンプレミスまたはその他のクラウド サービス プロバイダ環境の両方にまたがるマルチクラスタ サービス メッシュでは、Pod 間の直接通信を行うことはできません。たとえば Istio を使用する場合は、Istio Gateway 間ですべての通信を行う必要があります。

Private Service Connect を使用して Pod IP アドレスを非表示にする

このアーキテクチャ パターンでは、Private Service Connect を使用して、Pod の IP アドレスを非表示にします。このアーキテクチャ パターンは、次のようなニーズがある場合に使用します。

  • GKE クラスタから公開する必要がある Service の数が限られている。
  • GKE クラスタが独立して動作でき、企業ネットワーク内の多くのアプリケーションへの下り（外向き）通信を必要としない。

Private Service Connect により、他のネットワークから利用されるサービスを公開できます。GKE サービスは、内部パススルー ネットワーク ロードバランサとサービス アタッチメントを使用して公開し、他の VPC ネットワークのエンドポイントを使用してこれらのサービスを利用します。

このアーキテクチャ パターンを設定する手順の概要は次のとおりです。

  1. 別の VPC ネットワークで GKE クラスタを作成します。VPC ネットワークには、そのクラスタのみを含める必要があります。
  2. クラスタ内の各 GKE サービスが、他のクラスタや別の VPC ネットワーク内のアプリケーションからアクセスできるようにする必要がある場合は、Private Service Connect を使用してパススルー ロードバランサを作成します。

  3. （省略可）GKE クラスタで企業ネットワーク内の一部のアプリケーションへの下り（外向き）通信が必要な場合は、Private Service Connect を介してサービスを公開して、それらのアプリケーションを公開します。

    次の図は、このアーキテクチャ パターンの実装を示しています。

Private Service Connect を使用して IP アドレスを非表示にする実装を示すネットワーク図。

上の図は、Private Service Connect モデルのクラスタ内およびクラスタ間の通信が、分離ネットワーク モデルとどのように類似しているかを示しています。ただし、許可された通信は、パブリック IP アドレスではなく、Private Service Connect エンドポイントを介して行われます。 この図に示すように、各クラスタは独自の VPC ネットワークを取得します。また、各 VPC ネットワークは同じ IP アドレスを共有でき、各クラスタは同じ IP アドレス空間を共有できます。互いに直接通信できるのは、クラスタ内の Pod だけです。

クラスタの外部からの通信の場合、この図は、外部アプリケーションが Private Service Connect エンドポイントを介してクラスタにアクセスする方法を示しています。このエンドポイントは、クラスタ VPC ネットワーク内のサービス プロデューサーによって提供されるサービス アタッチメントに接続します。 クラスタ間の通信も、Private Service Connect エンドポイントとサービス プロデューサーのサービス アタッチメントを介して行われます。

Private Service Connect を使用して Pod IP アドレスを非表示にすると、次のようなメリットがあります。

  • GKE クラスタの IP アドレス空間はネットワークの残りの部分から非表示になるため、IP アドレスを計画する必要はありません。このアプローチでは、サービスごとに単一の IP アドレスが利用側 VPC ネットワークに公開されます。
  • このモデルでは公開されるサービスが明確に定義されており、VPC ネットワーク内の他の部分からは公開されたサービスだけにアクセスできるため、クラスタの保護が容易になります。

ただし、Private Service Connect を使用して Pod IP アドレスを非表示にすると、次のようなデメリットがあります。

  • クラスタ内の Pod は、クラスタの外部でプライベート通信を確立できません。Pod が通信できるのは、公開サービス（Pod がインターネットに接続している場合）、または Google API（限定公開の Google アクセスを使用して）のみです。クラスタ外のサービスが Private Service Connect を介して公開されている場合、Pod はこれらのサービスにアクセスできます。ただし、すべての内部サービス プロバイダがサービス アタッチメントを作成するわけではありません。そのため、Private Service Connect の使用が有効であるのは、これらのサービスの数が、アタッチメントを提供するプロバイダに限定される場合に限ります。
  • エンドポイントには、サービスが存在するのと同じリージョンからのみアクセスできます。さらに、これらのエンドポイントには、接続された VPC ネットワーク自体からのみアクセスできます。ピアリングされた VPC ネットワークや、Cloud VPN または Cloud Interconnect 経由で接続されたネットワークからはアクセスできません。

Cloud VPN を使用して Pod IP アドレスを非表示にする

このアーキテクチャ パターンでは、Cloud VPN を使用して GKE クラスタとメイン VPC ネットワークを分離します。この分離を作成すると、作成されるネットワークはアイランド モード ネットワーク モデルと同様に機能します。 アイランドモード モデルと同様に、このパターンでは、クラスタ間で Pod と Service の IP アドレス範囲を再利用できるというメリットがあります。クラスタ外のアプリケーションとの通信では SNAT が使用されるため、再利用が可能です。トラフィックがノードを出る前に、ノードが SNAT を使用して、Pod の IP アドレスを独自のノード IP アドレスにマッピングします。

このモデルを設定する手順は次のとおりです。

  1. 別の VPC ネットワークで GKE クラスタを作成します。VPC ネットワークには、そのクラスタのみを含める必要があります。

    クラスタでは、未使用のパブリック IP アドレス割り当てを使用して、2 つの IP アドレス範囲（Pod 用に 1 つと Service 用に 1 つ）を定義します。これらの IP アドレス範囲は、使用することが予想される最大の GKE クラスタのニーズに基づいて設定します。これらの各範囲は、GKE のみで使用するために予約します。また、組織内のすべての GKE クラスタに対してもこれらの範囲を再利用します。

    このような広い範囲の IP アドレスを予約できないことがあります。組織では、他のアプリケーションで Pod と Service の IP アドレス範囲のいずれかまたは両方をすでに使用していることがあります。IP アドレス範囲が使用中であり予約できない場合は、これらの IP アドレスを使用するアプリケーションが GKE クラスタと通信する必要がないことを確認してください。

  2. 作成したクラスタについて、マスカレード エージェントの nonMasqueradeCIDRs リストを、クラスタのノードと Pod の IP アドレス範囲を含むリストに構成します。このリストにより、GKE は、Google Cloud 内であっても、クラスタから送信されるトラフィックをノード IP アドレスに常にマスカレードします。

  3. Cloud VPN を使用して、GKE クラスタを含む VPC ネットワークを既存の（メイン）VPC ネットワークに接続します。

  4. カスタム アドバタイズ ルートを使用して、クラスタの VPC ネットワークが、メイン VPC ネットワークに転送される Pod と Service の IP アドレス範囲をアドバタイズするのを停止します。

  5. 必要な他の GKE クラスタに対して手順 1～4 を繰り返します。すべてのクラスタで、Pod と Service に同じ IP アドレス範囲を使用します。ただし、各ノードには個別の IP アドレスを使用します。

  6. Cloud VPN または Cloud Interconnect を介してオンプレミス ネットワークに接続している場合は、カスタム アドバタイズ ルートを使用してノード IP アドレス範囲を手動でアドバタイズします。

  7. 他のネットワークが VPC ネットワーク ピアリングを介してメイン VPC ネットワークに接続している場合は、これらのピアリングにカスタムルートをエクスポートして、GKE クラスタノードがピアリングされたネットワークにアクセスできるようにします。

次の図は、Cloud VPN を使用して Pod IP アドレスを非表示にする実装を示しています。

Cloud VPN を使用して IP アドレスを非表示にする実装を示すネットワーク図。

上の図は、Cloud VPN を使用して Pod の IP アドレスを非表示にする方法を示しています。これにより、アイランド モードのネットワーク モデルと同様のアプローチが実現します。この図に示すように、すべての GKE クラスタは独自の VPC ネットワークを取得します。各ネットワークには、異なるノード IP アドレス空間がありますが、同じ Pod IP アドレス空間を使用します。 Cloud VPN トンネルは、これらの VPC ネットワークを相互に接続し、また企業ネットワークに接続します。Pod IP アドレス空間は、クラスタを含む VPC ネットワークからアドバタイズされません。

この図では、クラスタ内の Pod のみが相互に直接通信できます。ノードはクラスタ外から別のクラスタ、企業ネットワーク、または接続されたオンプレミス ネットワークとの通信持に、SNAT を使用して Pod IP アドレス空間をマスカレードします。他のクラスタや企業ネットワークから Pod に直接アクセスすることはできません。Cloud VPN 接続を介してアクセスできるのは、内部ロードバランサによって公開されたクラスタ サービスのみです。

Cloud VPN を使用して Pod IP アドレスを非表示にすると、次のようなメリットがあります。

  • アイランド モード ネットワーク モデルで説明されているように、クラスタ間で Pod と Service の IP アドレス範囲を再利用できます。
  • メイン VPC ネットワークに接続されたネットワークからは Pod の IP アドレスに直接到達できないため、ファイアウォールで必要な構成が少なくなる可能性があります。したがって、Pod との通信をブロックするように明示的なファイアウォール ルールを構成する必要はありません。

ただし、Cloud VPN を使用して Pod IP アドレスを非表示にする場合は、次のようなデメリットがあります。

  • アイランド モード ネットワーク モデルで説明したものと同じデメリットが適用されます。たとえば、Pod レベルではファイアウォール ルールを設定できません。また、メイン VPC ネットワークまたは接続されたネットワークで Pod レベルでテレメトリー データを収集することもできません。
  • デフォルトの GKE ネットワーキング モデルと比較して、このパターンでは Cloud VPN トンネルに関連するコストやデータ転送料金などの追加費用が発生します。
  • Cloud VPN には VPN トンネルあたりの帯域幅の上限があります。この帯域幅上限に達した場合は、複数の Cloud VPN トンネルを構成し、等価コスト マルチパス（ECMP）を使用してトラフィックを分散できます。ただし、これらの操作を行うと、GKE 実装の設定とメンテナンスの複雑さが増します。
  • ルート アドバタイズの同期を維持すると、クラスタの作成の複雑さが増します。新しい GKE クラスタを作成するたびに、Cloud VPN トンネルを設定し、それらのトンネルとオンプレミス アプリケーションへのカスタム アドバタイズ ルートを作成する必要があります。

内部で使用されるパブリック IP アドレスと VPC ネットワーク ピアリングを使用して Pod IP アドレスを非表示にする

組織が未使用のパブリック IP アドレスを所有している場合は、アイランド モード ネットワーク モデルに似たこのアーキテクチャ パターンを使用できますが、パブリック IP アドレス空間をプライベートで使用します。このアーキテクチャは Cloud VPN を使用するモデルに似ていますが、代わりに VPC ネットワーク ピアリングを使用して GKE クラスタとメイン ネットワークを分離して作成します。

このアーキテクチャ パターンを設定する手順の概要は次のとおりです。

  1. 別の VPC ネットワークで GKE クラスタを作成します。VPC ネットワークには、そのクラスタのみを含める必要があります。

    クラスタでは、未使用のパブリック IP アドレス割り当てを使用して、2 つの IP アドレス範囲（Pod 用に 1 つと Service 用に 1 つ）を定義します。これらの IP アドレス範囲は、使用することが予想される最大の GKE クラスタのニーズに基づいて設定します。これらの各範囲は、GKE のみで使用するために予約します。また、組織内のすべての GKE クラスタに対してもこれらの範囲を再利用します。

    理論上は、パブリック IP アドレスの割り当てを使用する代わりに、サードパーティが所有する大きな未使用のパブリック IP アドレス ブロックを使用できます。ただし、このような IP アドレスはいつでも販売または公開して使用される可能性があるため、このような設定は強くおすすめしません。インターネット上で公開サービスを利用する際に、アドレスの販売または使用によって、セキュリティと接続の問題が発生しています。

  2. 作成したクラスタについて、マスカレード エージェントの nonMasqueradeCIDRs リストを、クラスタのノードと Pod の IP アドレス範囲を含むリストに構成します。このリストにより、GKE は、Google Cloud 内であっても、クラスタから送信されるトラフィックをノード IP アドレスに常にマスカレードします。

  3. VPC ネットワーク ピアリングを使用して、GKE クラスタを含む VPC ネットワークを既存の（メイン）VPC ネットワークに接続します。このモデルでは PUPI アドレスを交換しないので、ピアリングを構成するときに --no-export-subnet-routes-with-public-ip フラグを設定します。

  4. 必要な他の GKE クラスタに対して手順 1～3 を繰り返します。すべてのクラスタで、Pod と Service に同じ IP アドレス範囲を使用します。ただし、各ノードに個別の IP アドレスを使用します。

  5. Cloud VPN または Cloud Interconnect を介してオンプレミス ネットワークに接続している場合は、カスタム ルート アドバタイズを使用してノード IP アドレス範囲を手動でアドバタイズします。

次の図は、このアーキテクチャ パターンの実装を示しています。

PUPI と VPC ネットワーク ピアリングを使用して IP アドレスを非表示にする実装を示すネットワーク図。

上の図は、VPC ネットワーク ピアリングを使用して IP アドレスを非表示にする方法を示しています。この図に示すように、すべての GKE クラスタは独自の VPC ネットワークを取得します。各ノードには個別のノード IP アドレス空間がありますが、組織の PUPI アドレス空間から定義されたものと同じ Pod IP アドレス空間を使用します。VPC ネットワークは相互に接続し、また VPC ネットワーク ピアリングを介して Google Cloud の Kubernetes 以外のアプリケーションに接続します。PUPI アドレス空間はピアリング間でアドバタイズされません。VPC ネットワークは、Cloud VPN トンネルを介して企業ネットワークに接続します。

互いに直接通信できるのは、クラスタ内の Pod だけです。ノードはクラスタ外から別のクラスタ、企業ネットワーク、または接続されたオンプレミス ネットワークとの通信持に、SNAT を使用して Pod IP アドレス空間をマスカレードします。他のクラスタや企業ネットワークから Pod に直接アクセスすることはできません。内部ロードバランサで公開されたサービスにのみ、VPC ネットワーク ピアリング接続を介してアクセスできます。

このアーキテクチャ パターンは、前述の Cloud VPN のアプローチに似ていますが、このパターンに比べて次のようなメリットがあります。

  • Cloud VPN アーキテクチャ パターンとは異なり、VPC ネットワーク ピアリングでは、Cloud VPN トンネルや環境間の帯域幅に追加料金はかかりません。
  • VPC ネットワーク ピアリングで帯域幅の制限がなく、Google のソフトウェア定義ネットワークに完全に統合されています。したがってピアリングでは Cloud VPN に必要なゲートウェイと処理が必要ないため、VPC ネットワーク ピアリングでは Cloud VPN よりもレイテンシが若干低くなる可能性があります。

ただし、VPC ネットワーク ピアリング モデルには、Cloud VPN モデルと比べて次のようなデメリットもあります。

  • 組織には、未使用であり、想定される最大の GKE クラスタに必要な Pod IP アドレス空間に十分な大きさのパブリック IP アドレス空間が必要です。
  • VPC ネットワーク ピアリングは推移的ではありません。したがって、VPC ネットワーク ピアリングを介してメインの VPC ネットワークに接続されている GKE クラスタは、相互に直接通信できません。また、メイン VPC とピアリングされている VPC ネットワーク内のアプリケーションとも直接通信できません。このような通信を有効にするには、VPC ネットワーク ピアリングを介してネットワークを直接接続するか、メイン VPC ネットワークでプロキシ VM を使用する必要があります。

マルチ NIC インスタンスを使用してクラスタ アドレスを非表示にする

このアーキテクチャ パターンは次のコンポーネントとテクノロジーで構成されており、アイランドモード ネットワーク モデルに似たモデルを作成します。

  • 複数のネットワーク インターフェース カード（マルチ NIC）を持つ Compute Engine インスタンスを使用して、GKE クラスタとメイン VPC ネットワークの間に分離レイヤを作成します。
  • これらの環境間で送信される IP アドレスに NAT を使用します。

このパターンは、GKE クラスタに出入りする特定のトラフィックを検査、変換、またはフィルタする必要がある場合に使用できます。このような検査、変換、フィルタリングを行う必要がある場合は、デプロイされた Compute Engine インスタンスを使用して行います。

マルチ NIC インスタンスを使用してクラスタ アドレスを非表示にすることには、次のようなメリットがあります。

  • GKE クラスタの IP アドレス空間は、ネットワークの他の部分からは非表示になります。使用する VPC ネットワークには、サービスごとに 1 つの IP アドレスのみが公開されます。
  • サービスへは、接続されたオンプレミス ネットワークとピアリングされたネットワークからグローバルにアクセスできます。

ただし、マルチ NIC インスタンスを使用してクラスタ アドレスを非表示にすることには、次のようなデメリットがあります。

  • このモデルは、モデルを実装するだけでなく、マルチ NIC インスタンスのモニタリングとロギングの設定も必要であるため、他のアプローチよりも実装が複雑です。
  • マルチ NIC インスタンスには帯域幅の制限があり、VM インスタンスの料金が適用されます。
  • マルチ NIC インスタンスの管理とアップグレードを行う必要があります。

次のステップ