このページでは、Google Kubernetes Engine（GKE）ネットワーキングの主な特性について説明します。この情報は、Kubernetes を使い始めたばかりのユーザーだけでなく、アプリケーションの設計の向上や、Kubernetes ワークロードの構成の強化のために Kubernetes ネットワークに関する知識の充実が求められる経験豊富なクラスタ オペレーターやアプリケーション開発者にも役立ちます。
このページは、組織のネットワークを設計するクラウド アーキテクトとネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
Kubernetes を使用すると、アプリケーションのデプロイ方法、アプリケーションの相互通信方法、アプリケーションと Kubernetes コントロール プレーンの通信方法、クライアントがアプリケーションにアクセスする方法を宣言型の方法で定義できます。また、このページでは、GKE が Google Cloud サービスをどのように構成するかについても説明し、これはネットワーキングとも関連します。
Kubernetes を使用してアプリケーションをオーケストレートする際は、アプリケーションとそのホストのネットワーク設計について考え方を変えることが重要です。Kubernetes では、ホストや仮想マシン（VM）がどのように接続されているかを考えるのではなく、ポッド、サービス、外部クライアントがどのように通信するかを考えます。
Kubernetes の高度なソフトウェア定義ネットワーキング（SDN）により、同じリージョン クラスタ内の複数のゾーン間でのポッド、サービス、ノードのパケットのルーティングや転送が可能になります。Kubernetes と Google Cloud は、Kubernetes デプロイの宣言モデルと Google Cloud 上のクラスタ構成に応じて、各ノードの IP フィルタリング ルール、ルーティング テーブル、ファイアウォール ルールの動的な構成も行います。
前提条件
このページを読む前に、Linux ネットワーク管理のコンセプトとユーティリティ（iptables ルールやルーティングなど）を理解しておいてください。
また、次のトピックの基本用語も理解しておく必要があります。
Kubernetes の IP アドレスに関連する用語
Kubernetes ネットワーク モデルは、IP アドレスに大きく依存しています。サービス、ポッド、コンテナ、ノードは、IP アドレスとポートを使用して通信します。Kubernetes は各種のロード バランシング機能を提供しており、トラフィックを適切な Pod に振り分けます。これらのメカニズムについては、後で詳しく説明します。次の用語に注意しながら読み進めてください。
- ClusterIP: サービスに割り当てられた IP アドレス。他のドキュメントでは、「クラスタ IP」と呼ばれることもあります。Service で説明しているように、このアドレスは Service の存続期間中は不変です。
- Pod IP アドレス: 特定の Pod に割り当てられた IP アドレス。Pod で説明したように、これは一時的なものです。
- ノード IP アドレス: 特定のノードに割り振られた IP アドレス。
クラスタ ネットワーキングの要件
一般公開クラスタと限定公開クラスタのどちらでも、*.googleapis.com、*.gcr.io、およびコントロール プレーン IP アドレスへの接続が必要です。この要件は、暗黙の下り（外向き）許可ルールと、GKE が作成する自動作成されるファイアウォール ルールによって満たされます。
一般公開クラスタで、より高い優先度で下り（外向き）を拒否するファイアウォール ルールを追加する場合は、*.googleapis.com、*.gcr.io、およびコントロール プレーン IP アドレスを許可するファイアウォール ルールを作成する必要があります。
限定公開クラスタの要件の詳細については、要件、制約、制限をご覧ください。
クラスタ内のネットワーク
このセクションでは、Kubernetes クラスタ内のネットワーキングを、IP 割り振り、Pod、Service、DNS、コントロール プレーンとの関連を考慮して説明します。
IP 割り振り
Kubernetes はさまざまな IP 範囲を使用して、ノード、ポッド、サービスに IP アドレスを割り当てます。
- 各ノードには、クラスタの Virtual Private Cloud（VPC）ネットワークから割り当てられた IP アドレスがあります。このノード IP によって、
kube-proxyやkubeletなどの制御コンポーネントから Kubernetes API サーバーに接続できるようになります。この IP アドレスにより、クラスタの残りの部分とノードが接続されます。 - 各ノードには、IP アドレスのプールがあり、GKE がそのノードで実行中の Pod をこれらのアドレスに割り振ります（デフォルトは /24 CIDR ブロック）。必要に応じて、クラスタの作成時に IP の範囲を指定できます。 フレキシブル Pod CIDR 範囲機能を使用すると、ノードプール内のノードの Pod IP アドレス範囲のサイズを小さくできます。
- 各 Pod には、そのノードの Pod CIDR 範囲から IP アドレスが 1 つだけ割り当てられます。この IP アドレスはポッド内で実行中のすべてのコンテナで共有され、クラスタ内で実行中の他のポッドにコンテナを接続します。
- 各サービスには、クラスタの VPC ネットワークから割り当てられた、ClusterIP という IP アドレスがあります。オプションで、クラスタの作成時に VPC ネットワークをカスタマイズできます。
- 各コントロール プレーンには、クラスタのタイプ、バージョン、作成日に基づいて、パブリック IP アドレスまたは内部 IP アドレスが割り振られます。詳細については、コントロール プレーンの説明をご覧ください。
GKE ネットワーキング モデルでは、ネットワーク全体で IP アドレスを再利用できません。GKE に移行する際は、GKE での内部 IP アドレスの使用量を減らすように IP アドレスの割り振りを計画する必要があります。
MTU
Pod インターフェースに選択される MTU は、クラスタノードで使用される Container Network Interface（CNI）と、基盤となる VPC MTU の設定によって異なります。詳細については、Pod をご覧ください。
Pod インターフェースの MTU 値は 1460 か、ノードのプライマリ インターフェースから継承されます。
| CNI | MTU | GKE Standard |
|---|---|---|
| kubenet | 1460 | デフォルト |
|
kubenet （GKE バージョン 1.26.1 以降） |
継承 | デフォルト |
| Calico | 1460 |
詳細については、ネットワーク ポリシーを使用して Pod と Service 間の通信を制御するをご覧ください。 |
| netd | 継承 | 次のいずれかを使用して有効にします。 |
| GKE Dataplane V2 | 継承 |
詳細については、GKE Dataplane V2 の使用をご覧ください。 |
詳細については、VPC ネイティブ クラスタをご覧ください。
サポートされているネットワーク プラグイン
- 使用するネットワーク プラグインを自身でインストールする必要があります。GKE には、ネイティブにサポートされている次のネットワーク プラグインがあります。
- Calico（Dataplane V1）
- Cilium（Dataplane V2）
- Istio-CNI（GKE Enterprise のマネージド データプレーン コントローラ）
Pod
Kubernetes において、Pod は Kubernetes クラスタ内にデプロイできる最も基本的な単位です。1 つの Pod は 1 つ以上のコンテナを実行します。0 個以上の Pod がノードで実行されます。 クラスタ内の各ノードはノードプールに属します。
GKE では、これらのノードは仮想マシンであり、それぞれ Compute Engine でインスタンスとして実行されます。
Pod は、外部ストレージ ボリュームやその他のカスタム リソースに接続することもできます。次の図では、1 つのノードが 2 つの Pod を実行し、各 Pod に 2 つのボリュームがアタッチされています。
Kubernetes が Pod をあるノードで実行するようにスケジュールすると、そのノードの Linux カーネルで Pod のネットワーク Namespace が作成されます。このネットワーク Namespace により、仮想ネットワーク インターフェースを使用して、ノードの物理ネットワーク インターフェース（eth0 など）と Pod が接続され、Pod との間でパケットをやり取りできるようになります。ノードのルート ネットワーク名前空間内の関連する仮想ネットワーク インターフェースは、同じノード上のポッド間の通信を可能にする Linux ブリッジに接続されます。Pod は、同じ仮想インターフェースを使用して、ノード外にパケットを送信することもできます。
Kubernetes は、ノード上の Pod 用に予約されたアドレスの範囲から、Pod のネットワーク名前空間内の仮想ネットワーク インターフェースに IP アドレス（Pod IP アドレス）を割り当てます。このアドレス範囲は、Pod のクラスタに割り当てられる IP アドレス範囲のサブセットで、これはクラスタ作成時にも構成できます。
Pod で動作しているコンテナは、Pod のネットワーク名前空間を使用します。コンテナの視点からは、Pod はネットワーク インターフェースを 1 つ備えた物理マシンのように見えます。ポッド内のすべてのコンテナは、この同じネットワーク インターフェースを参照します。各コンテナの localhost は、Pod を介して、ノードの物理ネットワーク インターフェース（eth0 など）に接続されます。
この接続は、GKE の Container Network Interface（CNI）を使用するか、クラスタ作成時にネットワーク ポリシーを有効にして Calico の実装を使用するかによって、大きく異なります。
GKE の CNI を使用する場合、Virtual Ethernet Device（veth）ペアの一方の端が名前空間内の Pod に接続され、もう一方の端が Linux ブリッジ デバイス
cbr0に接続されます。1 この場合、次のコマンドは、cbr0に接続されているさまざまな Pod の MAC アドレスを表示します。arp -nツールボックス コンテナで次のコマンドを実行すると、
cbr0に接続している各 veth ペアの端のルート名前空間が表示されます。brctl show cbr0ネットワーク ポリシーが有効になっている場合、veth ペアの一方の端はポッドに接続され、もう一方の端は
eth0に接続されています。この場合、次のコマンドは異なる veth デバイスに接続されているさまざまなポッドの MAC アドレスを表示します。arp -nツールボックス コンテナで次のコマンドを実行すると、
cbr0という名前の Linux ブリッジ デバイスがないことが示されます。brctl show
クラスタ内での転送を容易にする iptables ルールは、シナリオごとに異なります。接続の問題の詳細なトラブルシューティングを行う際には、この違いを考慮することが重要です。
デフォルトでは、各 Pod はクラスタのすべてのノードで実行されている他の Pod に無制限にアクセスできます。しかし、Pod 間のアクセスを制限することは可能です。Kubernetes は定期的にポッドを破棄し、再作成します。この動作は、ノードプールがアップグレードされたとき、Pod の宣言型の構成を変更したとき、コンテナのイメージを変更したとき、ノードが使用不可になったときに行われます。したがって、Pod の IP アドレスは実装の詳細であるため、それらに依存しないようにしてください。Kubernetes は、Service を使用して安定した IP アドレスを提供します。
-
hostNetwork: falseを設定する Pod がある場合にのみ、仮想ネットワーク ブリッジcbr0が作成されます。↩
Service
Kubernetes では、任意の Kubernetes リソースにラベルと呼ばれる任意の Key-Value ペアを割り当てることができます。Kubernetes はラベルを使用し、関連する複数のポッドをサービスと呼ばれる論理単位にグループ化します。サービスは不変の IP アドレスとポートを持ち、サービス作成時にラベルセレクタで定義したすべてのラベルと一致するラベルを持つ一連のポッド間で負荷分散を行います。
次の図は、2 つの個別サービスを示しています。各サービスは複数のポッドで構成されています。図の各ポッドには app=demo というラベルが存在しますが、それぞれにそれ以外のラベルも存在します。サービス「frontend」は、app=demo と component=frontend の両方を持つすべてのポッドと対応しますが、サービス「users」は、app=demo と component=users を持つすべてのポッドと対応します。Client Pod はいずれのサービス セレクタとも正確には一致しないため、いずれのサービスにも含まれません。ただし、Client Pod も同じクラスタ内で実行されるため、いずれのサービスとも通信できます。
Kubernetes は新しく作成された各 Service（ClusterIP）に、クラスタの使用可能な Service の IP アドレスのプールから、安定した、信頼できる IP アドレスを割り振ります。また、Kubernetes は DNS エントリを追加することによって、ClusterIP にホスト名を割り当てます。ClusterIP とホスト名はクラスタ内で一意であり、Service のライフサイクル全体で変更されません。Kubernetes は、クラスタの構成から Service が削除された場合にのみ、ClusterIP とホスト名を解放します。ClusterIP または Service のホスト名のどちらを使用しても、アプリケーションを実行している正常な Pod にアクセスできます。
一見すると、サービスはアプリケーションにとって単一の障害点のように見えます。ただし、Kubernetes は、多数のノードで実行されているすべての Pod にできるだけ均等にトラフィックを分散させます。このため、クラスタは、1 つ以上のノード（すべてではない）に影響する停止に耐えることができます。
Kube-Proxy
Kubernetes は、従来、各ノード上で静的 Pod として実行される kube-proxy コンポーネントを使用して Pod と Service 間の接続を管理しています。
kube-proxy は、インライン プロキシではなく、下り（外向き）ベースのロード バランシング コントローラです。これは、Kubernetes API サーバーを監視し、ノードの iptables サブシステムに対して宛先 NAT（DNAT）ルールを追加および削除することで、絶えず ClusterIP の正常な Pod へのマッピングを行います。Pod で動作しているコンテナが Service の ClusterIP にトラフィックを送信すると、ノードはランダムに Pod を選択し、トラフィックをその Pod にルーティングします。
サービスを構成する場合、オプションで port と targetPort の値を定義することで、サービスのリスニング ポートを再マップできます。
portは、クライアントがアプリケーションにアクセスする場所です。targetPortは、アプリケーションがポッド内のトラフィックを実際にリッスンするポートです。
kube-proxy は、ノードに対して iptables ルールを追加および削除することで、このポートの再マッピングを管理します。
次の図は、クライアント Pod から別のノード上のサーバー Pod へのトラフィックの流れを示しています。クライアントは 172.16.12.100:80 でサービスに接続します。Kubernetes API サーバーは、アプリケーションを実行するポッドのリストを保持しています。各ノードの kube-proxy プロセスはこのリストを使用して iptables ルールを作成し、該当する Pod（10.255.255.202:8080など）にトラフィックを送信します。Client Pod は、クラスタのトポロジや、個々の Pod またはそれらに含まれているコンテナに関する詳細を認識する必要はありません。
kube-proxy のデプロイ形態は、クラスタの GKE バージョンによって変わります。
- GKE バージョン 1.16.0 と 1.16.8-gke.13 では、
kube-proxyが DaemonSet としてデプロイされます。 - GKE バージョンが 1.16.8-gke.13 より新しい場合は、
kube-proxyがノードの静的 Pod としてデプロイされます。
DNS
GKE には、サービス名と外部名を解決するための次のマネージド クラスタ DNS オプションが用意されています。
kube-dns: デフォルトですべての GKE クラスタにデプロイされるクラスタ アドオン。 詳細については、kube-dns の使用をご覧ください。
Cloud DNS: クラスタ内の kube-dns を置き換えるクラウドマネージド クラスタ DNS インフラストラクチャ。詳細については、GKE 向け Cloud DNS を使用するをご覧ください。
また、GKE は NodeLocal DNSCache を kube-dns または Cloud DNS のオプションのアドオンとして提供し、クラスタ DNS のパフォーマンスを向上させます。
GKE が DNS を提供する方法の詳細については、サービス ディスカバリと DNS をご覧ください。
コントロール プレーン
Kubernetes では、コントロール プレーンがコントロール プレーン プロセス（Kubernetes API サーバーを含む）を管理します。コントロール プレーンへのアクセス方法は、GKE Autopilot または Standard クラスタのバージョンによって異なります。
Private Service Connect を使用したクラスタ
次のいずれかの条件を満たす限定公開クラスタまたは一般公開クラスタでは、Private Service Connect を使用してノードとコントロール プレーンを非公開接続します。
- 2022 年 3 月 15 日またはそれ以降のバージョン 1.23 の新しい一般公開クラスタ。
- 2024 年 1 月 28 日以降のバージョン 1.29 の新しい限定公開クラスタ。
上記の条件を満たさない既存の一般公開クラスタは、Private Service Connect に移行中です。そのため、これらのクラスタではすでに Private Service Connect が使用されている可能性があります。クラスタが Private Service Connect を使用しているかどうかを確認するには、gcloud container clusters describe コマンドを実行します。一般公開クラスタで Private Service Connect を使用している場合、privateClusterConfig リソースには次の値が設定されています。
peeringNameフィールド: 空、または存在しません。privateEndpointフィールド: 値が割り当てられています。
ただし、上記の条件を満たさない既存の限定公開クラスタはまだ移行されません。
Private Service Connect を使用するクラスタを作成し、クラスタ分離を変更できます。承認済みネットワークを使用して、コントロール プレーンに到達できる送信元を定義し、クラスタのコントロール プレーンへのアクセスを制限します。
GKE クラスタに使用される Private Service Connect リソースは非表示になります。
Private Service Connect を使用する限定公開クラスタの場合、サブネットの作成時に --master-ipv4-cidr フラグは省略可能です。このフラグを使用すると、GKE は --master-ipv4-cidr で定義した値を使用する新しいサブネットを作成し、新しいサブネットを使用してコントロール プレーンの内部 IP アドレスをプロビジョニングします。
クラスタ外のネットワーキング
このセクションでは、クラスタ外からのトラフィックが Kubernetes クラスタ内で実行されているアプリケーションにどのように到達するかについて説明します。この情報は、クラスタのアプリケーションとワークロードを設計する際に重要です。
Kubernetes がどのように Service を使用して、Pod 内で実行されるアプリケーションに安定した IP アドレスを提供するかについては、すでにご紹介しました。デフォルトでは、各ノードのすべてのトラフィックが kube-proxy によって管理されるため、Pod は外部 IP アドレスを公開しません。Pod とそのコンテナは自由に通信できますが、クラスタ外の接続は Service にアクセスできません。たとえば、前の図では、クラスタ外のクライアントは ClusterIP を使用してフロントエンド サービスにアクセスできません。
GKE には、アクセスを制御し、クラスタ全体に着信トラフィックをできるだけ均等に分散させるための 3 種類のロードバランサが用意されています。複数のタイプのロードバランサを同時に使用するように 1 つの Service を構成できます。
- 外部ロードバランサは、クラスタ外と Google Cloud VPC ネットワーク外から着信するトラフィックを管理します。Google Cloud ネットワークに関連付けられた転送ルールを使用して、Kubernetes ノードにトラフィックをルーティングします。
- 内部ロードバランサは、同じ VPC ネットワーク内から着信するトラフィックを管理します。外部ロードバランサの場合と同様に、Google Cloud ネットワークに関連付けられた転送ルールを使用して、Kubernetes ノードにトラフィックをルーティングします。
- アプリケーション ロードバランサは、HTTP(S) トラフィックに使用される専用の外部ロードバランサです。このロードバランサは、転送ルールではなく Ingress リソースを使用して、Kubernetes ノードにトラフィックをルーティングします。
トラフィックが Kubernetes ノードに到達すると、ロードバランサのタイプに関係なく、同じ方法で処理されます。ロードバランサは、クラスタ内のどのノードがそのサービス用のポッドを実行しているか認識しません。代わりに、ノードが関連する Pod を実行していない場合でも、クラスタ内のすべてのノード間でトラフィックのバランスをとります。リージョン クラスタでは、クラスタのリージョンのすべてのゾーン内のすべてのノードに対して負荷が分散されます。トラフィックがノードにルーティングされると、ノードはそのトラフィックを同じノードまたは別のノードで実行されている Pod にルーティングします。ノードは、kube-proxy によってノード上で管理される iptables ルールを使用して、ランダムに選択された Pod にトラフィックを転送します。
次の図では、外部パススルー ネットワーク ロードバランサが、トラフィックを中央のノードに転送し、そのトラフィックは左側のノードの Pod にリダイレクトされています。
ロードバランサがトラフィックをノードに送信した後、そのトラフィックは別のノード上の Pod に転送される可能性があります。その場合、ネットワーク ホップが余計に必要となります。この追加のホップを避けたい場合は、最初にトラフィックを受信したノードと同じノード上の Pod にトラフィックを送信するように指定できます。
同じノード上の Pod にトラフィックが送信されるように指定するには、Service マニフェストで externalTrafficPolicy を Local に設定します。
apiVersion: v1
kind: Service
metadata:
name: my-lb-service
spec:
type: LoadBalancer
externalTrafficPolicy: Local
selector:
app: demo
component: users
ports:
- protocol: TCP
port: 80
targetPort: 8080
externalTrafficPolicy を Local に設定すると、ロードバランサは、サービスに属し、正常な Pod があるノードにのみトラフィックを送信します。ロードバランサは、ヘルスチェックを使用して、どのノードに適切な Pod があるかを判断します。
外部ロードバランサ
クラスタ外および VPC ネットワーク外から Service に到達できるようにする必要がある場合、Service の定義時に、Service の type フィールドを Loadbalancer に設定することで、Service を LoadBalancer として構成できます。すると GKE は、Service の前に外部パススルー ネットワーク ロードバランサをプロビジョニングします。外部パススルー ネットワーク ロードバランサは、クラスタ内のすべてのノードを認識し、VPC ネットワーク外から Service へ Service の外部 IP アドレスを使って接続できるように、VPC ネットワークのファイアウォール ルールを構成します。静的な外部 IP アドレスを Service に割り振ることができます。
ファイアウォール ルールの詳細については、自動的に作成されるファイアウォール ルールをご覧ください。
詳細な技術情報
外部ロードバランサを使用する場合、到着するトラフィックは最初に、Google Cloud ネットワークに関連付けられた転送ルールを使用してノードに転送されます。トラフィックがノードに到達すると、ノードはその iptables NAT テーブルを使用して、ポッドを選択します。ノードの iptables ルールは、kube-proxy によって管理されます。
内部ロードバランサ
同じ VPC ネットワーク内からクラスタに到達する必要のあるトラフィックについては、Service を構成して内部パススルー ネットワーク ロードバランサをプロビジョニングできます。内部パススルー ネットワーク ロードバランサは、外部 IP アドレスではなく、クラスタの VPC サブネットから IP アドレスを選択します。VPC ネットワーク内のアプリケーションまたはサービスは、この IP アドレスを使用してクラスタ内の Service と通信できます。
詳細な技術情報
内部ロード バランシング機能は、Google Cloud によって提供されます。トラフィックが所定のノードに到達すると、ノードはその iptables NAT テーブルを使用して Pod を選択します。Pod が別のノードにある場合でも、該当する Pod が選択されます。ノードの iptables ルールは、kube-proxy によって管理されます。
内部ロードバランサの詳細については、内部パススルー ネットワーク ロードバランサの使用をご覧ください。
アプリケーション ロードバランサ
RESTful ウェブサービス API などの多くのアプリケーションは、HTTP(S) を使用して通信します。Kubernetes Ingress を使用することで、VPC ネットワークの外部のクライアントからこの種類のアプリケーションへのアクセスを可能にできます。
Ingress を使用すると、ホスト名と URL パスをクラスタ内の Service にマッピングできます。アプリケーション ロードバランサを使用する場合は、NodePort と ClusterIP を使用するように Service を構成する必要があります。トラフィックが NodePort でノードの IP の Service にアクセスすると、GKE はそのトラフィックを Service の正常な Pod にルーティングします。NodePort を指定することも、GKE による未使用ポートのランダムな割り当てを許可することもできます。
Ingress リソースを作成すると、GKE によって Google Cloud プロジェクトに外部アプリケーション ロードバランサがプロビジョニングされます。ロードバランサは、NodePort でノードの IP アドレスにリクエストを送信します。リクエストがノードに到達すると、ノードはその iptables NAT テーブルを使用して、Pod を選択します。ノードの iptables ルールは、kube-proxy によって管理されます。
この Ingress 定義では、demo.example.com へのトラフィックはポート 80 の frontend という名前の Service にルーティングされ、demo-backend.example.com へのトラフィックはポート 8080 の users という名前の Service にルーティングされます。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
rules:
- host: demo.example.com
http:
paths:
- backend:
service:
name: frontend
port:
number: 80
- host: demo-backend.example.com
http:
paths:
- backend:
service:
name: users
port:
number: 8080
詳細については、アプリケーション ロードバランサ用の GKE Ingress をご覧ください。
詳細な技術情報
Ingress オブジェクトを作成すると、Ingress マニフェストと関連する Service マニフェストのルールに従って、GKE Ingress コントローラによってアプリケーション ロードバランサが構成されます。クライアントがアプリケーション ロードバランサにリクエストを送信します。ロードバランサは実際のプロキシです。つまり、ノードを選択して、そのノードの NodeIP:NodePort の組み合わせにリクエストを転送します。ノードはその iptables NAT テーブルを使用して Pod を選択します。ノードの iptables ルールは、kube-proxy によって管理されます。
ノード間の接続を制限する
クラスタ内のノードをターゲットとする上り（内向き）または下り（外向き）のファイアウォール ルールを作成すると、悪影響が生じる可能性があります。たとえば、クラスタ内のノードに下り（外向き）拒否ルールを適用すると、NodePort や kubectl exec などが機能しなくなる恐れがあります。
Pod と Service への接続を制限する
デフォルトでは、同じクラスタ内で実行されているすべての Pod は自由に通信できます。ただし、必要に応じて、クラスタ内の接続をさまざまな方法で制限できます。
Pod 間のアクセスを制限する
ネットワーク ポリシーを使用して、ポッド間のアクセスを制限できます。ネットワーク ポリシー定義を使用すると、ラベル、IP 範囲、ポート番号の任意の組み合わせに基づいて、Pod の上りと下りを制限できます。
デフォルトではネットワーク ポリシーはないため、クラスタ内の Pod 間のすべてのトラフィックが許可されます。名前空間に最初のネットワーク ポリシーを作成すると、他のトラフィックはすべて拒否されます。
ネットワーク ポリシーを作成した後、クラスタに対してそのポリシーを明示的に有効にする必要があります。詳細については、アプリケーションのネットワーク ポリシーの構成をご覧ください。
外部ロードバランサへのアクセスを制限する
Service で外部ロードバランサが使用されている場合、外部 IP アドレスからのトラフィックはデフォルトで Service にアクセスできます。Service 構成時に loadBalancerSourceRanges オプションを構成することで、クラスタ内のエンドポイントにアクセスできる IP アドレスの範囲を制限できます。複数の範囲を指定でき、またいつでも実行中のサービスの構成を更新できます。各ノードで動作している kube-proxy インスタンスは、指定された loadBalancerSourceRanges に一致しないトラフィックはすべて拒否するように、そのノードの iptables ルールを構成します。また、LoadBalancer Service を作成すると、GKE は対応する VPC ファイアウォール ルールを作成し、ネットワーク レベルでこれらの制限を適用します。
アプリケーション ロードバランサへのアクセスを制限する
サービスがアプリケーション ロードバランサを使用している場合は、Google Cloud Armor セキュリティ ポリシーを使用して、Service にアクセス可能な外部 IP アドレスと、セキュリティ ポリシーによってアクセスが拒否されたときに返されるレスポンスを制限できます。Cloud Logging を構成することで、これらの操作に関する情報をログに記録できます。
Google Cloud Armor セキュリティ ポリシーの詳細度が十分に高くない場合は、エンドポイントで Identity-Aware Proxy を有効にして、ユーザー単位の認証と認可をアプリケーションに実装できます。詳細については、IAP の構成に関する詳細なチュートリアルをご覧ください。
既知の問題
このセクションでは、既知の問題について説明します。
containerd が有効なノードで 172.17/16 範囲に接続できない
containerd が有効なノード VM は、172.17/16 内の IP を持つホストに接続できません。詳細については、172.17/16 の IP アドレス範囲と競合するをご覧ください。
Private Service Connect で削除済みの GKE クラスタのリソースが残る
2024 年 5 月 7 日より前に Private Service Connect を使用して GKE クラスタを作成して削除していて、クラスタよりも前にそのクラスタを含むプロジェクトを削除した場合、関連する Private Service Connect リソースがリークする可能性があります。これらのリソースは非表示のままになり、関連付けられたサブネットを削除することはできません。この問題が発生した場合は、Google Cloud サポートにお問い合わせください。