GKE ネットワーキング アーキテクチャについて学習する

Autopilot Standard

Google Kubernetes Engine（GKE）ネットワーキングは、Virtual Private Cloud（VPC）が提供するソフトウェア定義ネットワーキング（SDN）インフラストラクチャを使用し、拡張します。GKE ネットワーキングを使用すると、コンポーネントは Kubernetes クラスタ内および外部のサービスやネットワークと通信できます。GKE ネットワーキング モデルは、すべての Pod に独自の IP アドレスが割り当てられるという Kubernetes ネットワーキングの原則に基づいて、IP アドレス指定、ロード バランシング、DNS 解決、ネットワーク ポリシーの適用を提供します。このドキュメントでは、GKE ネットワーキングのコンテキスト内で、ノード、Pod、Service などのコア コンポーネントがコントロール プレーンとどのように連携するかについて説明します。次の内容について説明します。

• VPC 内でのこれらのコンポーネントの相互作用
• IP アドレスの割り当てと管理の方法
• クラスタへのトラフィックの流入、クラスタ内のトラフィックのフロー、クラスタからのトラフィックの流出

GKE ネットワークのアーキテクチャ

GKE ネットワークは Google Cloudの Virtual Private Cloud（VPC）上に構築されます。この基盤は、すべてのコンテナ化されたアプリケーションに堅牢でスケーラブルな接続を提供します。

VPC 基盤と IP アドレス範囲

VPC 内で、リージョン IP アドレス範囲であるサブネットを定義します。GKE は、これらのサブネット内のさまざまな IP アドレス範囲をさまざまなクラスタ コンポーネントに戦略的に使用します。多くの場合、VPC エイリアス IP アドレス範囲を使用します。

• ノード IP アドレス範囲: クラスタノードがデプロイされるサブネットのプライマリ IP アドレス範囲です。Compute Engine VM であるすべての GKE ワーカーノードは、この範囲からメイン IP アドレスを取得します。これらの IP アドレスは、ノード間の通信と、ロードバランサからのヘルスチェックに使用されます。ノード IP アドレスは、ノード自体で発信されるトラフィックの送信元でもあります。VPC ネイティブ クラスタでは、Pod の IP アドレスが Cloud NAT などの機能によって変換されない限り、Pod からのトラフィックは Pod の IP アドレスを送信元アドレスとして使用します。
• Pod IP アドレス範囲: サブネット内の専用のセカンダリ IP アドレス範囲（多くの場合、より大きな CIDR ブロック）。各ノードは、この範囲から IP アドレスのプールを受け取ります。GKE は、これらの IP アドレスをそのノードで実行される Pod に割り当てます。クラスタ内のすべての Pod は、この範囲から一意の IP アドレスを取得します。これらの Pod IP アドレスは、Virtual Private Cloud 内でネイティブにルーティングできます。デフォルトでは、各ノードに /24 範囲が割り当てられ、256 個の IP アドレスが提供されます。ただし、GKE では、ノードあたりの Pod の最大数は 110 に制限されています。このバッファは、チャーンとも呼ばれる Pod の迅速な作成と削除の際に IP アドレスの可用性を確保するのに役立ちます。これらの IP アドレスにより、ネットワーク アドレス変換（NAT）を必要とせずに、異なるノードの Pod 間で直接通信できます。
• Service IP アドレス範囲（ClusterIP）: Kubernetes Service に割り当てられた仮想 IP アドレス（ClusterIP）のセカンダリ IP アドレス範囲。これらの安定した IP アドレスは、クラスタ内の通信にのみ使用されます。
• コントロール プレーンの IP アドレス: クラスタのタイプ、バージョン、作成日に応じて、各コントロール プレーンにパブリック IP アドレスまたは内部 IP アドレスが割り振られます。この IP アドレスは、ワーカーノードや kubectl などの外部クライアントが Kubernetes API サーバーと安全に通信するために使用されます。GKE Frontend（GKFE）は、各クラスタに DNS ベースのエンドポイントを提供し、IP アドレスを直接管理することなくコントロール プレーンに安全かつ確実にアクセスする方法を提供します。

GKE ネットワーキングの 3 つの柱

GKE ネットワーキングは、相互接続された 3 つの柱で構成され、それぞれが通信の異なるレイヤを表しています。このフレームワークは、クラスタ内および外部ネットワークとのアプリケーションの通信方法を理解するのに役立ちます。

• Pod ネットワーキング: 基盤となるレイヤで、クラスタ内の個々のコンテナ（Pod）が互いに通信する方法を定義します。
• サービス ネットワーキング: Pod ネットワーキングに基づいて構築されたこのレイヤは、Kubernetes Service が内部クライアントまたは外部クライアント向けにアプリケーションを公開するための安定したエンドポイント（ロード バランシングやサービス検出など）をどのように提供するかを記述します。
• クラスタ ネットワーキング: 最外層。インターネットからの上り（内向き）トラフィック、外部サービスへの下り（外向き）トラフィック、 Google Cloud サービスとオンプレミス システムへの接続の管理など、GKE クラスタ全体がより広範なネットワーク エコシステムに接続する方法をカバーします。

これらのレイヤが連携して、内部接続と外部接続、セキュリティ、スケーラビリティをサポートする包括的な通信モデルを構築します。以降のセクションでは、各柱について詳しく説明します。

Pod ネットワーク

Pod ネットワーキングは、GKE クラスタ内のすべての通信の基盤です。Pod 内で実行されているアプリケーションが相互に検出してやり取りする方法を定義します。Kubernetes では、Pod は最も基本的なデプロイ可能な最小単位です。Pod は、アプリケーションの論理ホストとして機能します。ネットワーク リソースを共有する 1 つ以上のコンテナを実行します。Pod がノードでスケジュールされると、Kubernetes はノードの Linux カーネルに専用のネットワーク Namespace を作成します。これにより、そのネットワークは同じノード上の他の Pod から分離されます。

Pod ネットワーキングの仕組み

Pod ネットワーキングは、固有の IP アドレス、仮想ネットワーク デバイス、接続を管理する専用のプラグインの組み合わせによって確立されます。

Container Network Interface（CNI）: GKE は CNI プラグインを使用して、Pod ネットワーキングを実装および管理します。VPC ネイティブ クラスタの場合、デフォルトは Google CNI です。その他のオプションには、kubenet（VPC ネイティブ クラスタ以外の場合）、Calico、GKE Dataplane V2（Cilium ベース）などがあります。これらのプラグインは、Pod をネットワークに接続し、ネットワーク ポリシーを適用する役割を担います。

• IP アドレスの割り振り: 各ノードは、Pod IP アドレス範囲から IP アドレスのプールを受け取り、Pod に割り当てます。GKE は、これらのアドレスの一部を予約して、Pod の急激なチャーン（作成と破棄）中に IP アドレスの可用性を確保するバッファを作成します。この予約があるため、ノードあたりの割り当て可能な Pod IP アドレスの数は、常に範囲のサイズよりも小さくなります。

• ネットワーク名前空間と仮想イーサネット（veth）ペア: 通信を容易にするため、Kubernetes は Pod の分離されたネットワーク名前空間をノードのプライマリ（ルート）ネットワーク名前空間に接続します。Kubernetes は、仮想ネットワーク ケーブルのように機能する仮想イーサネット ペア（veth ペア）を使用してこの接続を行います。ペアの一方の端は Pod の Namespace 内に配置され、eth0 として表示されます。もう一方の端は、ネットワーク ブリッジまたはノードのルート Namespace 内のノードのネットワーク スタックに直接接続されます。これにより、Pod との間でパケットをやり取りできます。

  具体的な接続方法は、クラスタで使用する CNI プラグインによって異なります。

  • Google CNI: VPC ネイティブ クラスタのデフォルトの CNI です。Pod の veth ペアは、ノードのルート ネットワーク Namespace に接続されます。Pod IP アドレスは VPC ネットワークに認識されているエイリアス IP アドレスであるため、ノードの標準の Linux ルーティングによって Pod との間でトラフィックが転送されます。
  • GKE Dataplane V2: eBPF プログラムを使用して Pod ネットワーキングを処理します。多くの場合、従来の Linux ブリッジと veth ペアをバイパスして、カーネル内のパケット フローを直接管理し、パフォーマンスを向上させます。
  • Kubenet: VPC ネイティブ以外のクラスタで使用されます。veth ペアのもう一方の端は、ノードのルート名前空間にある cbr0 という Linux ブリッジ デバイスに接続されます。このブリッジは、同じノード上の Pod 間のトラフィックを管理し、ノードから送信されるトラフィックに NAT を使用します。
  • Calico: Calico でネットワーク ポリシーが有効になっている場合、veth ペアのもう一方の端はノードのルート Namespace に接続され、Calico はホストルートをプログラムしてトラフィックを正しい Pod に転送します。

最大伝送単位（MTU）: 断片化せずにネットワーク経由で送信できる最大パケットサイズを決定します。GKE では、Pod のインターフェースの MTU は、クラスタで使用される GKE CNI プラグインと、基盤となる VPC ネットワークの MTU 設定に依存する重要な設定です。MTU 値が一致しないと、パケットロスやパフォーマンスの低下が発生する可能性があります。Pod インターフェースの MTU 値は、次の表に示すように、固定の 1, 460 バイトであるか、ノードのプライマリ ネットワーク インターフェースから継承されます。

CNI	MTU	用途
Google CNI	1460	1.26.1 より前の GKE バージョンを使用する VPC ネイティブ クラスタのデフォルト。
Google CNI	継承	GKE バージョン 1.26.1 以降を使用する VPC ネイティブ クラスタのデフォルト。
Calico	1460	ネットワーク ポリシーが有効（--enable-network-policy）の場合に使用されます。
GKE Dataplane V2	継承	GKE Dataplane V2 が有効（--enable-dataplane-v2）の場合に使用されます。
netd	継承	`Intranode` 可視性、GKE 用 Workload Identity Federation for GKE、IPv4/IPv6 デュアルスタック ネットワーキングなどの機能が有効になっている場合に使用されます。

バージョン 1.26.1 より前のバージョンを実行するクラスタで、`Intranode visibility`、Workload Identity Federation for GKE、IPv4/IPv6 デュアルスタック ネットワーキングなどの機能を有効にすると、Pod の MTU はノードのプライマリ インターフェースから継承されます。

Pod 間の通信フロー

Kubernetes は、すべての Pod に一意のルーティング可能な IP アドレスがあるフラット ネットワーキング モデルを使用します。このモデルは、Pod 間のシームレスな接続を保証するのに役立ちます。

同じノード内の通信

Pod が同じノード上の別の Pod にトラフィックを送信すると、リクエストは最初の Pod のネットワーク Namespace から veth ペアを介してノードのルート ネットワーク Namespace に流れます。このトラフィックはノード内に留まります。使用する CNI プラグインに応じて、CNI プラグインはトラフィックを 2 番目の Pod の veth ペアに転送します。たとえば、kubenet を使用すると、ブリッジ デバイスがトラフィックを転送します。GKE Dataplane V2 では、eBPF プログラムがパケット フローを直接管理します。

異なるノード間の通信

あるノードの Pod が別のノードの Pod にトラフィックを送信すると、トラフィックは最初のノードのルート ネットワーク Namespace に流れます。トラフィックは、最初のノードのプライマリ ネットワーク インターフェースから VPC ネットワークに入ります。Pod IP アドレスは VPC ネイティブ GKE クラスタでネイティブにルーティング可能であるため、VPC ネットワークはトラフィックを 2 番目のノードに直接ルーティングします。2 番目のノードは、トラフィックを宛先 Pod に転送します。

ホスト ネットワーク Pod

特定のユースケースでは、hostNetwork: true 設定で Pod を構成できます。この設定により、分離された Pod ネットワークがバイパスされ、Pod がノードのネットワーク Namespace を直接共有できるようになります。この直接アクセスにより、Pod はノードの IP アドレスを使用し、NAT を必要とせずに他のすべての Pod と通信できます。kubenet CNI プラグインを使用するクラスタでは、この動作は通常の Pod とは異なります。通常の Pod の IP アドレスは VPC ネットワークで直接ルーティングできないため、アウトバウンド トラフィックには NAT が必要です。一方、GKE の VPC ネイティブ ネットワーキングでは、すべての Pod でこの変換が不要になります。ただし、hostNetwork: true 設定で Pod を構成する場合は、同じノードで実行されている他のプロセスや Pod とのポートの競合を避けるように注意してください。kubenet CNI を使用するクラスタでは、ノードに hostNetwork: false 設定を持つ Pod がある場合にのみ、cbr0 仮想ネットワーク ブリッジが作成されます。

サービス ネットワーキング

Pod ネットワーキングは個々の Pod 間の基本的な接続を提供しますが、堅牢でスケーラブルなアプリケーションを構築するには十分ではありません。Pod はエフェメラルです。いつでも作成、破棄、再スケジュールできます。この状況により、IP アドレスが変更されます。サービス ネットワーキングは、アプリケーションを公開し、クラスタ内と外部の両方でアプリケーションの通信方法を管理するための安定した信頼性の高い方法を提供することで、この問題を解決します。

Kubernetes Service は、Pod の論理セットと、Pod へのアクセスに適用するポリシーを定義する抽象化機能です。Service はラベルを使用して、関連する複数の Pod を 1 つの論理単位にグループ化します。Service を作成すると、Kubernetes は Service 用に予約されているアドレスのプールから、ClusterIP と呼ばれる安定した仮想 IP アドレスを割り当てます。この ClusterIP は、関連付けられた DNS 名とともに、Service のライフサイクル全体で一定のままです。これにより、他のアプリケーションが Pod への接続に使用できる一貫したエンドポイントが提供されます。

サービス ネットワーキングの仕組み

サービス ネットワーキングは、サービス ディスカバリとロード バランシングという 2 つの主要なメカニズムを使用して、サービスの安定したエンドポイントから動的バックエンド Pod にトラフィックをルーティングします。

サービス ディスカバリ: アプリケーションが相互に検索して通信できるように、GKE は内部 DNS サービス（kube-dns または Cloud DNS）を提供します。Service を作成すると、DNS サービスによって対応する DNS レコードが自動的に作成されます。このレコードを使用すると、アプリケーションは ClusterIP を知らなくても、DNS 名（my-app-service など）を使用して Service に接続できます。kube-dns は Standard クラスタのデフォルトですが、ほとんどの本番環境では Cloud DNS for GKE が推奨ソリューションです。また、GKE Autopilot クラスタでサポートされている唯一のソリューションでもあります。このサービスは、フルマネージドでスケーラブルであり、可用性が高いサービスです。VPC ネットワーキングと Cloud Logging と統合されており、kube-dns Pod を管理しなくても、パフォーマンスとオブザーバビリティが向上します。

ロード バランシング メカニズム: Service ロード バランシングの実装は、GKE クラスタのネットワーキング モードによって異なります。

• GKE Dataplane V2: GKE Dataplane V2（Cilium ベース）を使用するクラスタは、Service ロード バランシングに kube-proxy を使用しません。代わりに、GKE Dataplane V2 は Linux カーネルで実行される eBPF プログラムを使用します。これらの eBPF プログラムは、Service ClusterIP へのトラフィックをインターセプトし、トラフィックを適切なバックエンド Pod に直接ロードバランスするのに非常に効率的です。このアプローチにより、パフォーマンスが向上し、GKE Dataplane V2 のネットワーク ポリシー適用機能と緊密に統合されます。

• kube-proxy（GKE Dataplane V2 を使用しないクラスタの場合）: GKE Dataplane V2 を使用しない GKE クラスタのすべてのノードで、kube-proxy というコンポーネントが Service の仮想 IP アドレス メカニズムを実装します。kube-proxy は、Kubernetes API サーバーで Service と Endpoint の変更を監視し、ノードでネットワーク ルールをプログラムして、Service の ClusterIP 宛てのトラフィックをインターセプトします。

  kube-proxy は、次のようなさまざまなモードで動作できます。

  • iptables モード: デフォルトのモードです。kube-proxy は、ノードの iptables サブシステムで宛先 NAT（DNAT）ルールを追加および削除します。Service の ClusterIP にトラフィックが到着すると、これらのルールは NAT 変換を実行し、宛先 IP アドレスを正常なバックエンド Pod のいずれかに変更します。バックエンド Pod 間のロード バランシングは、通常はランダムまたはラウンド ロビンです。
  • ipvs モード: このモードでは、高パフォーマンスのロード バランシングに Linux IP Virtual Server（IPVS）を使用します。kube-proxy は IPVS ルールを構成します。このルールは、多数のサービスを処理し、より高度なロード バランシング アルゴリズムを提供できます。

内部コミュニケーション フローの例

次のリストは、GKE Dataplane V2 を使用しないクラスタの Service を使用して、クライアント Pod からサーバー Pod にリクエストがどのように流れるかを示しています。

1. クライアント アプリケーションが my-server-service の DNS クエリを行います。
2. クラスタの内部 DNS サービスは、この名前を Service の安定した ClusterIP（10.0.32.8 など）に解決します。
3. クライアント Pod が Service の ClusterIP にリクエストを送信します。
4. kube-proxy によって管理されるクライアント ノードの iptables ルールが、このリクエストをインターセプトします。
5. これらの iptables ルールは DNAT を実行し、正常なバックエンド Pod の 1 つを my-server-service に選択します（IP アドレス 10.4.0.3 の Pod 2 など）。ルールは、パケットの宛先 IP アドレスを Pod の IP アドレスに書き換えます。
6. パケットはフラット Pod ネットワークを介して Pod 2 に転送され、リクエストが処理されます。

GKE Dataplane V2 を使用するクラスタでは、eBPF プログラムが Service ClusterIP へのトラフィックのインターセプトとロード バランシングを処理し、kube-proxy と iptables をバイパスします。

Service マニフェストの例

次の例は、Service マニフェストを示しています。selector フィールドには、ラベルに基づいてトラフィックを受信する Pod を指定します。

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

サービス ネットワーキングの機能

GKE サービス ネットワーキングには、トラフィック フローを管理し、アプリケーションを内部と外部の両方に公開するための機能がいくつか用意されています。

• クラスタ内からのみアクセスする必要がある Service の場合、内部ロード バランシングと外部ロード バランシング。kube-proxy（または GKE Dataplane V2）はロード バランシングを内部で処理します。インターネットに公開する必要がある Service の場合、GKE はクラスタ内のノードに外部トラフィックを分散するクラウド ロードバランサを自動的にプロビジョニングします。
• HTTP(S) ルーティング用のアプリケーション ロードバランサ。HTTP(S) トラフィックの場合、GKE は専用のレイヤ 7 ロードバランサであるアプリケーション ロードバランサを使用します。このロードバランサは、すべての新しいアプリケーションに推奨されるアプローチである Kubernetes Gateway API を使用して構成します。GKE Gateway Controller は、Google が実装した Gateway API であり、Ingress リソースの後継として、より表現力、柔軟性、拡張性を高めるように設計されています。Gateway API は、次のリソースを使用してロードバランサを構成します。
  • Gateway: ポート、プロトコル、ホスト名などのリスナー構成を定義します。トラフィックのエントリ ポイントとして機能します。
  • HTTPRoute: Gateway が受信したトラフィックを Service にルーティングする方法を指定します。パスベースのルーティング、ヘッダー マッチング、トラフィック分割などの高度な機能をサポートしています。
  • Policy: Gateway、Route、Service に接続することで、基盤となる Google Cloud インフラストラクチャの動作を定義します。
• 複雑なマイクロサービス アーキテクチャ向けのサービス メッシュ統合。GKE はサービス メッシュ テクノロジーをサポートしています。サービス メッシュは、トラフィック管理、オブザーバビリティ、セキュリティの高度な機能を提供するオプションのインフラストラクチャ レイヤです。フルマネージドでサポートされているエクスペリエンスを実現するために、GKE は Istio をベースにした Cloud Service Mesh を提供しています。

クラスタ ネットワーク

クラスタ ネットワーキングは、GKE ネットワーキングの最も外側のレイヤです。インターネット クライアントがアプリケーションにアクセスする方法、Pod が外部 API にアクセスする方法、クラスタがオンプレミス データセンターに接続する方法など、Kubernetes クラスタ全体が外部リソースやネットワークとどのようにやり取りするかに重点を置いています。クラスタ ネットワーキングは、 Google Cloudの VPC インフラストラクチャ上に構築されています。

インバウンド トラフィックを管理する

上り（内向き）は、外部からクラスタに入るトラフィックです。GKE は、複数の統合機能を使用して、このトラフィックを管理し、保護します。 Google Cloud

外部アクセス データフロー: インターネットのクライアントがアプリケーションにリクエストを送信すると（通常は LoadBalancer タイプの Service、Ingress、Gateway リソースを介して公開されます）、最初に Google Cloud ロードバランサに到達します。ロードバランサは、クラスタ内の正常なノードにリクエストを転送します。ノードは、トラフィックを適切な Pod に転送します。kube-proxy は、GKE Dataplane V2 を使用しないクラスタでこの転送を処理します。GKE Dataplane V2 を使用するクラスタでは、eBPF プログラムが処理します。宛先 Pod は、同じノードまたは別のノードに存在する可能性があります。

ファイアウォール ルール: GKE クラスタは VPC ファイアウォール ルールを使用して上り（内向き）トラフィックを制御します。GKE は、コントロール プレーンがノードに到達できるようにするなど、クラスタの重要なオペレーション用にデフォルトのファイアウォール ルールを自動的に作成しますが、特定のセキュリティ要件を満たすようにカスタムルールを定義することもできます。これらの VPC ファイアウォール ルールは、Kubernetes ネットワーク ポリシーと連携して、ノードレベルと Pod レベルの両方でトラフィックを制御することで多層防御を提供します。

外部トラフィック フローの最適化: ロードバランサがトラフィックをノードに送信するとき、ノードはそのトラフィックを別のノード上の Pod に転送する必要がある場合があります。この場合、ネットワーク ホップが余計に必要になります。このような状況を回避するには、Service マニフェストで externalTrafficPolicy フィールドを Local に設定します。このポリシーが有効になっている場合、ロードバランサはヘルスチェックを使用して、ターゲット Service の正常な Pod があるノードを特定します。ロードバランサは正常な Pod にのみトラフィックを送信するため、追加のネットワーク ホップを防ぐことができます。このポリシーでは、バックエンド Pod がクラスタ内のノードに均等に分散されていない場合、トラフィックの分散が不均一になる可能性があります。

送信トラフィックを管理する

下り（外向き）は、クラスタから送信されるトラフィックです。GKE クラスタが機能し、アプリケーションが外部サービスにアクセスできるようにするには、複数の接続パスを管理する必要があります。

基本的な接続要件: すべての GKE クラスタで、*.googleapis.com、*.gcr.io、*.pkg.dev ドメインへのアウトバウンド接続が必要です。コントロール プレーンの IP アドレスへのアウトバウンド接続も正しく機能している必要があります。Cloud NAT を使用した Pod のインターネット アクセス: Pod にパブリック IP アドレスがない限定公開クラスタで、Cloud NAT を使用してアウトバウンドのインターネット アクセスを有効にします。Cloud NAT は、Pod がインターネットに接続して更新のダウンロードや外部 API へのアクセスなどのタスクを実行できるようにするマネージド サービスです。このサービスを使用すると、Pod をインバウンド接続に公開することなく、これらのタスクを実行できます。

Google Cloud サービスへの接続: クラスタが公共のインターネットを経由せずに Cloud Storage や Cloud SQL などの他の Google Cloud サービスと安全に通信できるようにする必要がある場合は、限定公開の Google アクセスを使用します。これは、Google API とやり取りするプライベート クラスタにとって重要な下り（外向き）メカニズムです。

ハイブリッド クラウドとマルチクラスタの接続

GKE クラスタをオンプレミス インフラストラクチャに接続するには、暗号化されたトンネルに Cloud VPN を使用するか、専用の高帯域幅接続に Cloud Interconnect を使用します。複数の GKE クラスタ間の通信を有効にするには、マルチクラスタ サービスを使用します。これにより、異なるクラスタ、リージョン、プロジェクト間のサービス ディスカバリとトラフィック フローが容易になります。

ネットワーク セキュリティ管理

クラスタとクラスタで実行されているアプリケーションを保護するために、GKE は内部（East-West）トラフィックと外部（North-South）トラフィックの両方に対して、複数のレイヤのセキュリティ制御を提供します。

ネットワーク ポリシーによる内部トラフィック（East-West）の保護

デフォルトでは、GKE クラスタ内のすべての Pod は自由に通信できます。内部トラフィックを保護し、最小権限の原則を適用するには、NetworkPolicy を使用します。NetworkPolicy は、Pod 間のネットワーク トラフィックを制御することで Pod のファイアウォールとして機能する Kubernetes リソースです。NetworkPolicy リソースを使用すると、ラベル、IP アドレス範囲、ポート番号の組み合わせに基づいて、選択した Pod グループの上り（内向き）トラフィックと下り（外向き）トラフィックを制限するルールを定義できます。Namespace に最初の NetworkPolicy を作成すると、そのポリシーで明示的に許可されていないすべてのトラフィックが拒否されます。これらのポリシーの適用は、GKE Dataplane V2 に直接組み込まれているか、Calico などのクラスタの CNI プラグインによって処理されます。

NetworkPolicy マニフェストの例

次の例は、NetworkPolicy マニフェストを示しています。このポリシーは、app: backend ラベルを持つ Pod に適用され、TCP ポート 6379 で app: frontend ラベルを持つ Pod からの上り（内向き）トラフィックのみを許可します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

クラスタへの外部アクセスを保護する

クラスタに出入りするトラフィックを制御することは、外部の脅威からアプリケーションを保護するために不可欠です。

VPC ファイアウォール ルール

GKE クラスタは Google Cloud VPC ネットワーク内に存在し、クラスタノードとの間のトラフィックを制御する VPC ファイアウォール ルールによって保護されます。VPC ファイアウォール ルールとネットワーク ポリシーは連携して、多層防御を提供します。VPC ファイアウォールはノード（レイヤ 3 またはレイヤ 4）レベルで動作し、VM 自体へのトラフィックを制御します。ネットワーク ポリシーは Pod（レイヤ 3 またはレイヤ 4）レベルで動作し、クラスタ内のアプリケーション間のトラフィックをより細かく制御できます。

クラスタ内のノードをターゲットとする上り（内向き）または下り（外向き）のファイアウォール ルールを作成すると、悪影響が生じる可能性があります。たとえば、クラスタ内のノードに下り（外向き）拒否ルールを適用すると、NodePort や kubectl exec などの機能が機能しなくなる恐れがあります。

ロードバランサへのアクセスを制限する

Kubernetes Service または Ingress を使用してアプリケーションを公開する場合は、ロードバランサ レベルで追加のセキュリティ制御を適用できます。外部ロードバランサの場合は、次のオプションを検討してください。

• type: LoadBalancer フィールドを使用して Service を公開する場合は、Service マニフェストで loadBalancerSourceRanges フィールドを指定できます。このフィールドでは、Service へのアクセスを定義した IP アドレス範囲のみに制限します。

• アプリケーション ロードバランサ（Ingress）では、HTTP(S) アプリケーションを公開するときに、より高度なセキュリティ サービスを使用できます。

  • Google Cloud Armor: このサービスは、DDoS 攻撃やその他のウェブベースの脅威からアプリケーションを保護するウェブ アプリケーション ファイアウォール（WAF）です。
  • Identity-Aware Proxy（IAP）: きめ細かいアクセス制御を行うには、エンドポイントで IAP を有効にします。IAP は、ユーザーの ID を検証し、それを使用して、ユーザーにアプリケーションへのアクセスを許可するかどうかを判断します。

次のステップ

• VPC ネイティブ クラスタを作成する方法を学習する。
• GKE Dataplane V2 の詳細を確認する。
• ネットワーク ポリシーを実装して、Pod 間の通信を保護します。
• サービスを使用してアプリケーションを公開するさまざまな方法と、Gateway API を使用して Ingress を構成する方法について説明します。