GKE のネットワーク モデルを比較する

Autopilot Standard

---

このドキュメントでは、Google Kubernetes Engine（GKE）で使用されるネットワーク モデルと、他の Kubernetes 環境のネットワーク モデルとの違いについて説明します。このドキュメントでは、次のコンセプトについて説明します。

• Kubernetes のさまざまな実装で使用される最も一般的なネットワーク モデル。
• 最も一般的なネットワーク モデルの IP アドレス指定メカニズム。
• 各ネットワーク モデルのメリットとデメリット。
• GKE が使用するデフォルトのネットワーク モデルの詳細な説明。

このドキュメントは、他の Kubernetes 実装に精通していて、GKE の使用を計画しているクラウド アーキテクト、オペレーション エンジニア、ネットワーク エンジニアを対象としています。このドキュメントは、Kubernetes とその基本的なネットワーキング モデルを理解していることを前提としています。また、IP アドレス指定、ネットワーク アドレス変換（NAT）、ファイアウォール、プロキシなどのネットワーキングのコンセプトにも精通している必要があります。

このドキュメントでは、さまざまな IP アドレスの制約を満たすためにデフォルトの GKE ネットワーキング モデルを変更する方法については説明しません。GKE への移行時に IP アドレスが不足している場合は、GKE への移行時の IP アドレス管理戦略をご覧ください。

注: このドキュメントでは、アマゾン ウェブ サービス、Microsoft Azure、Oracle® Cloud Infrastructure など、他のクラウド環境における Kubernetes ネットワーク モデルの実装について説明します。これらの実装は予告なく変更されることがあります。最新の実装情報については、ベンダーが提供するドキュメントをご覧ください。

一般的なネットワーク モデルの実装

Kubernetes ネットワーク モデルは、さまざまな方法で実装できます。ただし、実装は常に次の要件を満たす必要があります。

• Pod ごとに一意の IP アドレスが必要です。
• Pod は、NAT を使用せずにすべてのノード上の他の Pod と通信できます。
• ノード上のエージェント（kubelet など）は、対象ノード上のすべての Pod と通信できます。
• ノードのホスト ネットワーク上の Pod は、NAT を使用せずにすべてのノード上のすべての Pod と通信できます。

これらの要件を満たす Kubernetes ネットワーク モデルは、20 を超える実装が開発されています。

これらの実装は、3 種類のネットワーク モデルに分類できます。この 3 つのモデルには、次のような違いがあります。

• Pod が企業ネットワーク上の Kubernetes 以外のサービスと通信する方法。
• Pod が同じ組織内の他の Kubernetes クラスタと通信する方法。
• クラスタ外の通信に NAT が必要かどうか。
• Pod IP アドレスを他のクラスタまたは企業ネットワーク内の他の場所で再利用できるかどうか。

それぞれのクラウド プロバイダがこれらのモデルタイプを 1 つ以上実装しています。

次の表に、一般的に使用される 3 種類のモデルと、それらが使用される Kubernetes の実装を示します。

ネットワークのモデル名	使用されている実装
完全統合またはフラット	GKE Amazon Elastic Kubernetes Service（EKS） Azure CNI（advanced）ネットワーキングを使用する場合の Azure Kubernetes Service（AKS）
アイランド モードまたはブリッジ	デフォルトの Kubenet（Basic）ネットワーキングを使用する場合の Azure Kubernetes Service（AKS） Oracle Container Engine for Kubernetes（OKE） 多くのオンプレミス Kubernetes 実装
分離またはエアギャップあり	Kubernetes の実装では一般的に使用されませんが、クラスタが別のネットワークまたは Virtual Private Cloud（VPC）にデプロイされている場合の実装に使用できます。

このドキュメントでは、これらのネットワーク モデルについて説明する際に、接続されたオンプレミス ネットワークへの影響について言及しています。ただし、バーチャル プライベート ネットワーク（VPN）やプライベート相互接続を介して接続されたネットワーク（他のクラウド プロバイダへの接続を含む）にも、接続されたオンプレミス ネットワークについて説明するコンセプトを適用できます。GKE の場合、これらの接続には Cloud VPN または Cloud Interconnect を介したすべての接続が含まれます。

完全統合ネットワーク モデル

完全統合ネットワーク（またはフラット）モデルでは、Kubernetes 外部のアプリケーションやその他の Kubernetes クラスタのアプリケーションと簡単に通信できます。主要なクラウド サービス プロバイダは通常、このモデルを実装しています。これは、そのようなプロバイダが Kubernetes の実装をソフトウェア定義ネットワーク（SDN）と緊密に統合しているためです。

完全統合モデルを使用する場合、Pod に使用する IP アドレスは、Kubernetes クラスタが存在するネットワーク内にルーティングされます。また、基盤となるネットワークは、Pod の IP アドレスがどのノードにあるかを認識します。多くの実装では、同じノード上の Pod IP アドレスは、事前に割り当てられた特定の Pod IP アドレス範囲からのものです。ただし、この事前に割り当てられたアドレス範囲は要件ではありません。

次の図は、完全統合ネットワーク モデルの Pod 通信オプションを示しています。

上記の完全な統合ネットワーク モデルの図は、次の通信パターンを示しています。

• Kubernetes クラスタ内の Pod は、相互に直接通信できます。
• Pod は、それらのクラスタが同じネットワーク内にある限り、他のクラスタの他の Pod と通信できます。
• Pod は、アプリケーションが同じネットワークまたは相互接続されたネットワークにあるかどうかにかかわらず、クラスタの外部にある他のアプリケーションと通信するために NAT を必要としません。

この図は、Pod の IP アドレス範囲が異なるクラスタ間で区別されていることも示しています。

完全統合ネットワーク モデルは、次の実装で利用可能です。

• デフォルトでは、GKE はこのモデルを実装します。この実装の詳細については、このドキュメントで後述する GKE ネットワーキング モデルをご覧ください。
• デフォルトでは、Amazon EKS はこのモデルを実装します。この実装では、Amazon EKS は Kubernetes 用の Amazon VPC Container Networking インターフェース（CNI）プラグインを使用して、VPC アドレス空間から直接 Pod IP アドレスを割り当てます。CNI プラグインは、ノードが存在するデフォルトのサブネットまたはカスタム サブネットの IP アドレスを割り当てます。Pod IP アドレスは、ノードあたりの専用の Pod IP アドレス範囲から取得されません。
• Azure では、Azure CNI（高度なネットワーキング）を使用する場合に AKS がこのモデルを実装します。この実装は、デフォルトの構成ではありません。この実装では、各 Pod はサブネットから IP アドレスを取得します。ノードあたりの最大 Pod 数を構成することもできます。したがって、対象ノードの Pod 用に事前に予約された IP アドレスの数は、ノードあたりの Pod の最大数と同じです。

完全統合ネットワーク モデルの使用には、次のようなメリットがあります。

• より優れたテレメトリー データ。Pod IP アドレスはネットワーク全体で表示されます。表示されることによって、クラスタの外部で収集されたテレメトリー データからも Pod を特定できるため、他のモデルよりもテレメトリー データの有用性が高くなります。
• ファイアウォール構成の簡易化。完全に統合されたネットワーク モデルでは、他のモデルよりもファイアウォール ルールを設定するときにノードと Pod のトラフィックを簡単に識別できます。
• 互換性の向上。Pod は、NAT をサポートしていないプロトコルを使用して通信できます。
• デバッグの向上。ファイアウォールで許可されている場合は、デバッグ プロセス中にクラスタ外のリソースが Pod に直接アクセスできます。
• サービス メッシュとの互換性。Istio や Cloud Service Mesh などのサービス メッシュは、Pod が相互に直接通信できるため、クラスタ間で簡単に通信できます。一部のサービス メッシュ実装は、マルチクラスタ サービス メッシュの Pod 間接続のみをサポートしています。

完全統合ネットワーク モデルの使用には、次のようなデメリットがあります。

• IP アドレスの使用状況。ネットワーク内で Pod IP アドレスを再利用することはできません。各 IP アドレスは一意である必要があります。これらの要件により、Pod 用に予約する必要がある IP アドレスが大量に発生する可能性があります。
• SDN の要件。完全に統合されたネットワーク モデルでは、基盤となるネットワークとの緊密な統合が必要になります。これは、Kubernetes の実装で SDN を直接プログラムする必要があるためです。SDN のプログラミングはユーザーにとって透過的であり、ユーザーにとっての欠点はありません。しかし、このような緊密に統合されたネットワーク モデルは、セルフマネージド型のオンプレミス環境に簡単に実装することはできません。

アイランド モード ネットワーク モデル

アイランド モードのネットワーク モデル（ブリッジ）は、基盤となるネットワークとの緊密な統合が不可能なオンプレミス Kubernetes 実装に頻繁に使用されます。アイランド モード ネットワーク モデルを使用する場合、Kubernetes クラスタ内の Pod は、なんらかのゲートウェイやプロキシを介してクラスタ外のリソースと通信できます。

次の図は、アイランド モードのネットワーク モデルの Pod 通信オプションを示しています。

アイランド モード ネットワーク モデルの上の図は、Kubernetes クラスタ内の Pod が互いに直接通信する方法を示しています。この図はまた、クラスタ内の Pod がクラスタ外のアプリケーションや他のクラスタの Pod と通信するときに、ゲートウェイまたはプロキシを使用する必要があることを示しています。クラスタと外部アプリケーション間の通信には単一のゲートウェイが必要ですが、クラスタ間の通信には 2 つのゲートウェイが必要です。2 つのクラスタ間のトラフィックは、最初のクラスタから離れるときにゲートウェイを通過し、もう一方のクラスタに入るときに別のゲートウェイを通過します。

分離ネットワーク モデルでゲートウェイやプロキシを実装するには、さまざまな方法があります。次の実装は、最も一般的な 2 つのゲートウェイまたはプロキシです。

• ノードをゲートウェイとして使用する。この実装は、クラスタ内のノードが既存のネットワークの一部であり、それらの IP アドレスがこのネットワーク内でネイティブにルーティングできる場合に使用します。この場合、ノード自体は、クラスタ内から大規模なネットワークへの接続を提供するゲートウェイになります。Pod からクラスタ外部への下り（外向き）トラフィックは、他のクラスタや Kubernetes 以外のアプリケーションに転送できます。たとえば、企業ネットワーク上のオンプレミス API を呼び出す場合などです。この下り（外向き）トラフィックの場合、Pod を含むノードは送信元 NAT（SNAT）を使用して Pod の IP アドレスをノード IP アドレスにマッピングします。クラスタ外のアプリケーションがクラスタ内の Service と通信できるようにするには、ほとんどの実装で NodePort サービスタイプを使用します。一部の実装では、LoadBalancer サービスタイプを使用して Service を公開できます。LoadBalancer タイプの Service を使用する場合は、それらの Service に、ノード間でロードバランスされ Service の一部である Pod にルーティングされる仮想 IP アドレスを付与します。

  次の図に、ノードをゲートウェイとして使用する場合の実装パターンを示します。

  

  上の図は、ゲートウェイをノードとして使用しても、クラスタ内の Pod 間通信には影響しないことを示しています。クラスタ内の Pod 同士は、直接通信を行います。ただし、この図にはクラスタの外部にある次の通信パターンも示されています。

  • ノードから離れるときに SNAT を使用して、Pod が他のクラスタまたは Kubernetes 以外のアプリケーションと通信する方法。
  • 他のクラスタまたは Kubernetes 以外のアプリケーションの外部 Service からのトラフィックが、クラスタ内の適切な Pod に転送される前に、NodePort Service を介してクラスタに入る方法。

• 複数のネットワーク インターフェースを持つプロキシ仮想マシン（VM）を使用する。この実装パターンでは、プロキシを使用して Kubernetes クラスタを含むネットワークにアクセスします。プロキシは、Pod とノードの IP アドレス空間にアクセスする必要があります。このパターンでは、各プロキシ VM に 2 つのネットワーク インターフェースがあります。1 つは大規模なエンタープライズ ネットワーク用で、もう 1 つは Kubernetes クラスタを含むネットワーク用です。

  次の図は、プロキシ VM を使用する場合の実装パターンを示しています。

  

  上の図は、アイランド モードでプロキシを使用してもクラスタ内の通信に影響を及ぼさないことを示しています。クラスタ内の Pod は、互いに直接通信できます。ただし、この図は Pod から他のクラスタまたは Kubernetes 以外のアプリケーションへの通信が、クラスタのネットワークと宛先ネットワークの両方にアクセスできるプロキシを通過する方法も示しています。さらに、外部からクラスタに入る通信も、同じ種類のプロキシを通過します。

アイランド モード ネットワーク モデルは、次の実装で使用できます。

• デフォルトでは、Azure Kubernetes Service（AKS）は Kubenet（基本）ネットワーキングを使用するときにアイランド モード ネットワーキングを使用します。AKS でアイランド モード ネットワーキングを使用する場合、クラスタを含む仮想ネットワークにはノード IP アドレスのみが含まれます。Pod IP アドレスは仮想ネットワークの一部ではありません。代わりに、Pod は別の論理空間から IP アドレスを受け取ります。AKS で使用されるアイランド モード モデルは、ノード インターフェース上で IP 転送が有効化されているユーザー定義ルートを使用して、ノード間の Pod 間トラフィックをルーティングします。クラスタ外のリソースへの Pod 通信の場合、ノードは下り（外向き）トラフィックがノードから出る前に、SNAT を使用して Pod IP アドレスをノード IP アドレスにマッピングします。
• Oracle Container Engine for Kubernetes（OKE）では、Pod 間通信には VXLAN オーバーレイ ネットワークを使用します。また、Pod からクラスタ外のアプリケーションへのトラフィックは SNAT を使用して、Pod IP アドレスをノード IP アドレスにマッピングします。

アイランド モード ネットワーク モデルの使用には、次のようなメリットがあります。

• IP アドレスの使用状況。クラスタ内の Pod IP アドレスは、他のクラスタで再利用できます。ただし、Pod とそれらのサービス間で通信する必要がある場合、エンタープライズ ネットワーク内の外部サービスによってすでに使用されている IP アドレスは使用できません。したがって、アイランド モード ネットワーキングのベスト プラクティスは、ネットワーク内で一意の Pod IP アドレス空間を予約し、この IP アドレスをすべてのクラスタに使用することです。
• 簡単なセキュリティ設定。Pod はエンタープライズ ネットワークの他の部分に直接公開されないため、エンタープライズ ネットワークの他の部分からの上り（内向き）トラフィックから Pod を保護する必要はありません。

アイランド モード ネットワーク モデルの使用には、次のようなデメリットがあります。

• 不正確なテレメトリークラスタ外部で収集されたテレメトリー データには、Pod の IP アドレスではなく、ノードの IP アドレスのみが含まれます。Pod IP アドレスがないため、トラフィックの送信元と宛先を特定するのが難しくなります。
• デバッグの実施が困難である。デバッグ時に、クラスタの外部から Pod に直接接続することはできません。
• ファイアウォールの構成が困難である。ノード IP アドレスは、ファイアウォールを構成する場合にのみ使用できます。したがって、ファイアウォールの設定で、ノードとノード自体のすべての Pod が外部サービスに到達することを許可するか、いずれの Pod も外部サービスに到達できないようにします。

• サービス メッシュとの互換性。アイランド モードを使用すると、Istio または Cloud Service Mesh などのサービス メッシュ内のクラスタ間で Pod 間通信を直接行うことはできません。

  一部のサービス メッシュ実装には、他にも制限があります。Google Cloud 上の GKE クラスタに対する Cloud Service Mesh マルチクラスタのサポートでは、同じネットワーク上のクラスタのみがサポートされます。マルチネットワーク モデルをサポートする Istio の実装では、Istio ゲートウェイを介して通信を行う必要があります。これにより、マルチクラスタのサービス メッシュのデプロイがより複雑になります。

分離ネットワーク モデル

分離（またはエアギャップ）ネットワーク モデルは、公開されている API を使用する場合を除き、大規模な企業ネットワークにアクセスする必要がないクラスタで最も一般的に使用されます。分離ネットワーク モデルを使用すると、各 Kubernetes クラスタが分離され、内部 IP アドレスを使用してネットワークの残りの部分と通信できなくなります。クラスタは独自のプライベート ネットワーク上に配置されます。クラスタ内の Pod がクラスタ外の Service と通信する必要がある場合、この通信では、上り（内向き）と下り（外向き）の両方にパブリック IP アドレスを使用する必要があります。

次の図は、分離ネットワーク モデルの Pod 通信オプションを示しています。

上の分離ネットワーク モデルの図は、Kubernetes クラスタ内の Pod が互いに直接通信できることを示しています。この図は、Pod が内部 IP アドレスを使用して他のクラスタの Pod と通信できないことも示しています。また、Pod は、次の条件を満たしている場合にのみ、クラスタ外のアプリケーションと通信できます。

• クラスタを外部に接続するインターネット ゲートウェイがあります。
• 外部アプリケーションは、通信に外部 IP アドレスを使用します。

最後に、この図は、異なる環境間で Pod とノードに同じ IP アドレス空間を再利用する方法を示しています。

分離ネットワーク モデルは、Kubernetes 実装では一般に使用されません。ただし、どのような実装でも分離ネットワーク モデルを実現できます。他のサービスやエンタープライズ ネットワークに接続せずに、別のネットワークまたは VPC に Kubernetes クラスタをデプロイするだけです。結果として得られる実装には、分離ネットワーク モデルと同じメリットとデメリットがあります。

分離ネットワーク モードを使用すると、次のようなメリットがあります。

• IP アドレスの使用状況。クラスタ内のすべての内部 IP アドレス（ノード IP アドレス、Service IP アドレス、Pod IP アドレス）は再利用できます。各クラスタには独自のプライベート ネットワークがあり、クラスタ外のリソースとの通信はパブリック IP アドレスを介してのみ行われるため、内部 IP アドレスの再利用が可能です。
• コントロール。クラスタ管理者は、クラスタ内の IP アドレスを完全に制御できます。IP アドレスの管理タスクを行う必要はありません。たとえば、これらのアドレスがすでに組織内で使用されている場合でも、管理者はクラスタ内の完全な Pod と Service に 10.0.0.0/8 アドレス空間を割り当てることができます。
• セキュリティ。クラスタ外の通信は厳密に制御され、可能であれば、明確に定義された外部インターフェースと NAT を使用します。

分離ネットワーク モデルの使用には、次のようなデメリットがあります。

• プライベート通信なし。内部 IP アドレスを使用した通信は、ネットワーク内の他のクラスタやサービスでは使用できません。

GKE ネットワーキング モデル

GKE は、完全統合ネットワーク モデルを使用して、他のアプリケーションを配置できる Virtual Private Cloud（VPC）ネットワークにクラスタをデプロイします。

GKE 環境には、VPC ネイティブ クラスタを使用することをおすすめします。Standard または Autopilot のいずれかで VPC ネイティブ クラスタを作成できます。Autopilot モードを選択した場合、VPC ネイティブ モードは常にオンになり、オフにできません。以下では、Autopilot の相違点に関する注意事項とともに、Standard の GKE ネットワーク モデルについて説明します。

VPC ネイティブ クラスタでの IP アドレス管理

VPC ネイティブ クラスタを使用する場合、Pod の IP アドレスは各ノードのセカンダリ IP アドレスです。各ノードには、クラスタの作成時に内部 IP アドレス空間から選択した Pod IP アドレス範囲の特定のサブネットが割り当てられます。デフォルトでは、VPC ネイティブ クラスタは各ノードに /24 サブネットを割り当てて、Pod の IP アドレスとして使用します。/24 サブネットは 256 個の IP アドレスに対応しています。Autopilot では、クラスタは 64 個のアドレスに対応する /26 サブネットを使用します。このサブネットの設定は変更できません。

GKE ネットワーキング モデルでは、ネットワーク全体で IP アドレスを再利用することはできません。GKE に移行する際は、GKE での内部 IP アドレスの使用量を減らすように IP アドレスの割り振りを計画する必要があります。

Pod IP アドレスは VPC ネットワーク内でルーティング可能であるため、Pod はデフォルトで次のリソースからトラフィックを受信できます。

• VPC ネットワーク内の他の Service から。
• VPC ネットワーク ピアリングで接続された VPC ネットワークから。
• Cloud VPN または Cloud Interconnect を介して接続されたオンプレミス ネットワークから。

IP マスカレード エージェントを使用して外部トラフィック通信を管理する

Pod からクラスタ外の Service と通信する場合、IP マスカレード エージェントがこれらの Service へのトラフィックをどのように制御するかを管理します。IP マスカレード エージェントは、次の箇条書きで説明するように、プライベート IP アドレスと外部 IP アドレスを異なる方法で処理します。

• デフォルトでは、IP マスカレード エージェントは RFC 1918 IP アドレスや一般に使用されている RFC 1918 以外の IP アドレスなどの内部 IP アドレスへのトラフィックをマスカレードしません（詳細については、デフォルトのマスカレード以外の宛先のリストをご覧ください）。内部 IP アドレスはマスカレードされないため、ノードはこれらのアドレスで NAT を使用しません。
• 外部 IP アドレスの場合、IP マスカレード エージェントがノード IP アドレスにこれらのアドレスをマスカレードします。したがって、マスカレードで指定されたアドレスは Cloud NAT によって外部 IP アドレスに変換されるか、仮想マシン（VM）インスタンスの外部 IP アドレスに変換されます。

VPC ネットワークまたは接続されたネットワーク内でプライベートで使用されるパブリック IP（PUPI）アドレスを使用することもできます。PUPI アドレスを使用している場合でも、完全に統合されたネットワーク モデルのメリットを得ることができ、Pod として IP アドレスを直接送信元として確認できます。この両方の目標を達成するには、nonMasqueradeCIDRs リストに PUPI アドレスを含める必要があります。

GKE ネットワークでの Pod トラフィック フローの理解

次の図は、GKE ネットワーキング モデル内の Pod の通信方法を示しています。

上の図は、GKE 環境の Pod が内部 IP アドレスを使用して次のリソースと直接通信する方法を示しています。

• 同じクラスタ内の他の Pod。
• 同じ VPC ネットワーク内の他の GKE クラスタの Pod。
• 同じ VPC ネットワーク内の他の Google Cloud アプリケーション。
• Cloud VPN 経由で接続されたオンプレミス アプリケーション

この図は、Pod がアプリケーションと通信するために外部 IP アドレスを使用する必要がある場合の動作も示しています。トラフィックがノードから離れると、Pod が存在するノードは SNAT を使用して Pod の IP アドレスをノードの IP アドレスにマッピングします。トラフィックがノードから離れると、Cloud NAT はノードの IP アドレスを外部 IP アドレスに変換します。

このドキュメントで前述したメリット、特に Pod IP アドレスがすべてのテレメトリー データに表示されるというメリットのために、Google は完全統合ネットワーク モデルを選択しています。GKE では、Pod IP アドレスは VPC フローログ（メタデータ内の Pod 名を含む）、Packet Mirroring、ファイアウォール ルールのロギングと、マスカレード以外の宛先に対する独自のアプリケーション ログで公開されています。

次のステップ

• GKE への移行時の IP アドレス管理戦略を確認する。
• GKE ネットワーキングのベスト プラクティスについて学習する。
• AWS サービスや Azure サービスと Google Cloud を比較する
• Google Cloud へのコンテナの移行: Kubernetes から GKE への移行