ネットワーク ポリシーを使用して Pod と Service 間の通信を制御する

このページでは、GKE のネットワーク ポリシーを適用して、クラスタの Pod と Service 間の通信を制御する方法について説明します。

完全修飾ドメイン名（FQDN）ネットワーク ポリシーを使用して、クラスタ外のエンドポイントまたはサービスに対する Pod の下り（外向き）トラフィックを制御することもできます。詳細については、FQDN を使用して Pod と Service 間の通信を制御するをご覧ください。

GKE ネットワーク ポリシーの適用について

ネットワーク ポリシーを適用すると、クラスタ内に Kubernetes ネットワーク ポリシーを作成できます。デフォルトでは、クラスタ内のすべての Pod は自由に通信できます。ネットワーク ポリシーは、クラスタ内で相互にアクセスできる Pod と Service を決定する Pod レベルのファイアウォール ルールを作成します。

ネットワーク ポリシーを定義すると、クラスタがマルチレベルのアプリケーションを処理するときに多層防御のような機能を有効にすることができます。たとえば、アプリケーション内の不正使用されたフロントエンド サービスが数レベル下の課金サービスや会計サービスと直接通信できないようにするネットワーク ポリシーを作成することができます。

ネットワーク ポリシーを使用して、複数のユーザーが生成したデータを同時にホストするアプリケーションをより簡単に作成することもできます。たとえば、テナント単位の名前空間モデルを定義して、セキュアなマルチテナンシーを提供できます。このようなモデルでは、ネットワーク ポリシー ルールにより、特定の Namespace 内の Pod や Service が異なる Namespace 内の他の Pod や Service にアクセスできないようにできます。

始める前に

作業を始める前に、次のことを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

要件と制限事項

• メタデータ サーバーへの下り（外向き）を許可する必要があります。
• GKE Dataplane V2 が有効になっているクラスタのネットワーク ポリシーで endPort フィールドを指定しても、GKE バージョン 1.22 以降では有効になりません。詳細については、ネットワーク ポリシーのポート範囲が有効にならないをご覧ください。Autopilot クラスタの場合、GKE Dataplane V2 は常に有効になります。

• GKE 用 Workload Identity 連携でネットワーク ポリシーを使用する場合は、メタデータ サーバーへの下り（外向き）を許可する必要があります。
• ネットワーク ポリシーの適用を有効にすると、kube-system プロセスのメモリ使用量が約 128 MB 増加し、約 300 ミリコアの CPU が必要になります。つまり、既存のクラスタに対してネットワーク ポリシーを有効にした場合、スケジュールされたワークロードの実行を継続するには、クラスタのサイズを大きくする必要があります。
• ネットワーク ポリシーの適用を有効にする場合、ノードの再作成が必要になります。クラスタのメンテナンスの時間枠が有効になっている場合、次のメンテナンスの時間枠でノードが自動的に再作成されます。必要に応じて、いつでも手動でクラスタをアップグレードできます。
• ネットワーク ポリシーの適用を行うために必要となるクラスタの最小サイズは、3 つの e2-medium インスタンス、または 1 つ以上の割り当て可能な vCPU を持つ 1 つのマシンタイプ インスタンスです。詳細については、GKE の既知の問題をご覧ください。
• ノードが f1-micro インスタンスまたは g1-small インスタンスであるクラスタでは、リソース要件が高すぎるため、ネットワーク ポリシーはサポートされません。

ノードのマシンタイプと割り当て可能なリソースについて詳しくは、標準クラスタ アーキテクチャ - ノードをご覧ください。

ネットワーク ポリシーの適用を有効にする

Autopilot クラスタでは、ネットワーク ポリシーの適用はデフォルトで有効になっているため、ネットワーク ポリシーの作成にスキップできます。

Standard クラスタでネットワーク ポリシーの適用を有効にするには、gcloud CLI ツール、Google Cloud コンソール、または GKE API を使用します。

ネットワーク ポリシーの適用は、GKE Dataplane V2 に組み込まれています。GKE Dataplane V2 を使用するクラスタでネットワーク ポリシーの適用を有効にする必要はありません。

この変更を行うにはノードを再作成する必要があります。これにより、実行中のワークロードが中断する可能性があります。この特定の変更について詳しくは、ノードのアップグレード戦略を使用してノードを再作成し、メンテナンス ポリシーに準拠する手動変更の表で対応する行を確認してください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。

Standard クラスタでネットワーク ポリシーの適用を無効にする

ネットワーク ポリシーの適用は、gcloud CLI、Google Cloud コンソール、または GKE API を使用して無効にできます。Autopilot クラスタまたは GKE Dataplane V2 を使用するクラスタでネットワーク ポリシーの適用を無効にすることはできません。

この変更を行うにはノードを再作成する必要があります。これにより、実行中のワークロードが中断する可能性があります。この特定の変更について詳しくは、ノードのアップグレード戦略を使用してノードを再作成し、メンテナンス ポリシーに準拠する手動変更の表で対応する行を確認してください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。

ネットワーク ポリシーを作成する

ネットワーク ポリシーは、Kubernetes Network Policy API を使用して作成できます。

ネットワーク ポリシーの作成について詳しくは、Kubernetes ドキュメントの次のトピックをご覧ください。

• ネットワーク ポリシーの概要
• ネットワーク ポリシーを宣言する

ネットワーク ポリシーと GKE 用 Workload Identity 連携

GKE 用 Workload Identity 連携でネットワーク ポリシーを使用する場合は、Pod が GKE メタデータ サーバーと通信できるように、次の IP アドレスへの下り（外向き）を許可する必要があります。

• GKE バージョン 1.21.0-gke.1000 以降を実行しているクラスタでは、ポート 988 で 169.254.169.252/32 への下り（外向き）を許可します。
• 1.21.0-gke.1000 より前の GKE バージョンを実行しているクラスタでは、ポート 988 で 127.0.0.1/32 への下り（外向き）を許可します。
• GKE Dataplane V2 を実行しているクラスタでは、ポート 80 で 169.254.169.254/32 への下り（外向き）を許可します。

これらの IP アドレスとポートへの下り（外向き）を許可しない場合は、自動アップグレード中にサービスの中断が発生する可能性があります。

Calico から GKE Dataplane V2 への移行

ネットワーク ポリシーを Calico から GKE Dataplane V2 に移行する場合は、次の制限事項を考慮してください。

• NetworkPolicy マニフェストの ipBlock.cidr フィールドに Pod または Service の IP アドレスを使用することはできません。ワークロードはラベルを使用して参照する必要があります。たとえば、次の構成は無効です。

  - ipBlock:
      cidr: 10.8.0.6/32
  

• NetworkPolicy マニフェストで空の ports.port フィールドを指定することはできません。プロトコルを指定する場合は、ポートも指定する必要があります。たとえば、次の構成は無効です。

  ingress:
  - ports:
    - protocol: TCP
  

アプリケーション ロードバランサの操作

Ingress を Service に適用してアプリケーション ロードバランサを構築する場合は、Service の背後にある Pod に適用されるネットワーク ポリシーを構成して、適切なアプリケーション ロードバランサのヘルスチェック IP 範囲を許可する必要があります。内部アプリケーション ロードバランサを使用する場合は、プロキシ専用サブネットを許可するようにネットワーク ポリシーを構成する必要もあります。

ネットワーク エンドポイント グループでコンテナネイティブのロード バランシングを使用しない場合は、Service のノードポートが他のノードの Pod に接続を転送する可能性があります。これを回避するには、Service の定義で externalTrafficPolicy を Local に設定します。externalTrafficPolicy を Local に設定しない場合は、ネットワーク ポリシーでクラスタ内の他のノード IP からの接続も許可する必要があります。

ipBlock ルールへの Pod IP 範囲の追加

特定の Pod のトラフィックを制御するには、NetworkPolicy の上り（内向き）ルールまたは下り（外向き）ルールで namespaceSelector フィールドと podSelector フィールドを使用して、Namespace または Pod ラベルごとに Pod を選択します。Pod の IP アドレス範囲を意図的に選択するために ipBlock.cidr フィールドを使用することは避けてください。これは本質的にエフェメラルです。Kubernetes プロジェクトで、Pod の IP アドレス範囲が含まれている場合の ipBlock.cidr フィールドの動作は明確に定義されていません。Pod の IP アドレス範囲を含めて、このフィールドに広い CIDR 範囲（0.0.0.0/0 など）を指定すると、NetworkPolicy のさまざまな実装で予期しない結果が生じる可能性があります。

GKE Dataplane V2 での ipBlock の動作

NetworkPolicy の GKE Dataplane V2 実装では、Pod のトラフィックは ipBlock ルールの対象外です。したがって、cidr: '0.0.0.0/0' などの広範なルールを定義しても、Pod トラフィックは含まれません。たとえば、これは、Pod からのトラフィックを許可せずに、Namespace 内の Pod がインターネットからのトラフィックを受信することを許可する場合に便利です。Pod トラフィックも含めるには、NetworkPolicy の上り（内向き）ルールまたは下り（外向き）ルールの定義で、追加の Pod または Namespace セレクタを使用して、Pod を明示的に選択します。

Calico での ipBlock の動作

NetworkPolicy の Calico 実装では、Pod トラフィックが ipBlock ルールの対象となります。この実装で、Pod トラフィックを許可せずに広範な CIDR 範囲を構成するには、次の例のように、クラスタの Pod CIDR 範囲を明示的に除外します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-non-pod-traffic
spec:
  ingress:
  - from:
    - ipBlock:
      cidr: '0.0.0.0/0'
      except: ['POD_IP_RANGE']

この例の POD_IP_RANGE は、クラスタの Pod の IPv4 アドレス範囲です（例: 10.95.0.0/17）。複数の IP 範囲がある場合は、配列に個別に含めることができます（例: ['10.95.0.0/17', '10.108.128.0/17']）。

トラブルシューティング

Pod が Private Service Connect を使用するクラスタ上のコントロール プレーンと通信できない

コントロール プレーンの内部 IP アドレスへの Pod の下り（外向き）が下り（外向き）ネットワークで制限されている場合、Private Service Connect を使用する GKE クラスタの Pod でコントロール プレーンとの通信に問題が発生する可能性があります。

この問題には次のように対処してください。

1. クラスタで Private Service Connect を使用していることを確認します。Private Service Connect を使用するクラスタで、サブネットの作成時に master-ipv4-cidr フラグを使用すると、GKE は master-ipv4-cidr で定義した値から各コントロール プレーンに内部 IP アドレスを割り当てます。それ以外の場合は、GKE はクラスタノード サブネットを使用して、各コントロール プレーンに内部 IP アドレスを割り当てます。

2. コントロール プレーンの内部 IP アドレスへのトラフィックを許可するように、クラスタの下り（外向き）ポリシーを構成します。

   コントロール プレーンの内部 IP アドレスを確認するには:

   gcloud

   privateEndpoint を探すには、次のコマンドを実行します。

   gcloud container clusters describe CLUSTER_NAME
   

   CLUSTER_NAME はクラスタの名前で置き換えます。

   このコマンドは、指定したクラスタの privateEndpoint を取得します。

   コンソール

   1. Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。

      Google Kubernetes Engine に移動

   2. ナビゲーション パネルの [クラスタ] で、内部 IP アドレスを確認するクラスタをクリックします。

   3. [クラスタの基本] で、内部 IP アドレスが表示されている Internal endpoint に移動します。

   privateEndpoint または Internal endpoint が見つかったら、コントロール プレーンの内部 IP アドレスへのトラフィックを許可するようにクラスタの下り（外向き）ポリシーを構成します。詳細については、ネットワーク ポリシーを作成するをご覧ください。

クラスタの更新が遅い

既存のクラスタでネットワーク ポリシーの適用を有効または無効にすると、クラスタにメンテナンスの時間枠または除外が構成されている場合、GKE によってノードが直ちに更新されない場合があります。

手動でデプロイした Pod のスケジューリングが解除される

既存のクラスタのコントロール プレーンでネットワーク ポリシーの適用を有効にすると、GKE は、手動でデプロイされた ip-masquerade-agent や calico ノードの Pod のスケジュールを解除します。

クラスタノードでネットワーク ポリシーの適用が有効になり、ノードが再作成されるまで、GKE はこれらの Pod の再スケジュールを行いません。

メンテナンスの時間枠または除外を構成している場合は、これによって中断が延長される可能性があります。

この中断期間を最小限に抑えるために、次のラベルをクラスタノードに手動で割り当てできます。

• node.kubernetes.io/masq-agent-ds-ready=true
• projectcalico.org/ds-ready=true

ネットワーク ポリシーが機能しない

NetworkPolicy が有効でない場合は、次の手順でトラブルシューティングを行います。

1. ネットワーク ポリシーの適用が有効になっていることを確認します。使用するコマンドは、クラスタで GKE Dataplane V2 が有効かどうかによって異なります。

   クラスタで GKE Dataplane V2 が有効になっている場合は、次のコマンドを実行します。

   kubectl -n kube-system get pods -l k8s-app=cilium
   

   出力が空の場合、ネットワーク ポリシーの適用は有効になっていません。

   クラスタで GKE Dataplane V2 が有効になっていない場合は、次のコマンドを実行します。

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   出力が空の場合、ネットワーク ポリシーの適用は有効になっていません。

2. Pod のラベルを確認します。

   kubectl describe pod POD_NAME
   

   POD_NAME は、Pod の名前で置き換えます。

   出力は次のようになります。

   Labels:        app=store
                  pod-template-hash=64d9d4f554
                  version=v1
   

3. ポリシーのラベルが Pod のラベルと一致することを確認します。

   kubectl describe networkpolicy
   

   出力は次のようになります。

   PodSelector: app=store
   

   この出力では、app=store ラベルは前の手順の app=store ラベルと一致します。

4. ワークロードを選択するネットワーク ポリシーがあるかどうかを確認します。

   kubectl get networkpolicy
   

   出力が空の場合、Namespace に NetworkPolicy が作成されておらず、何もワークロードを選択していません。出力が空でない場合は、ポリシーでワークロードが選択されていることを確認します。

   kubectl describe networkpolicy
   

   出力は次のようになります。

   ...
   PodSelector:     app=nginx
   Allowing ingress traffic:
      To Port: <any> (traffic allowed to all ports)
      From:
         PodSelector: app=store
   Not affecting egress traffic
   Policy Types: Ingress
   

既知の問題

Calico を使用した StatefulSet Pod の終了

Calico ネットワーク ポリシーが有効になっている GKE クラスタでは、Pod の削除時に StatefulSet Pod が既存の接続を切断するという問題が発生する場合があります。Pod が Terminating 状態になると、Pod 仕様の terminationGracePeriodSeconds 構成が優先されて、StatefulSet Pod との接続がすでに存在する他のアプリケーションが中断します。この問題の詳細については、Calico 問題 #4710 をご覧ください。

この問題は、次の GKE バージョンに影響します。

• 1.18
• 1.19～1.19.16-gke.99
• 1.20～1.20.11-gke.1299
• 1.21～1.21.4-gke.1499

この問題を軽減するには、GKE コントロール プレーンを次のいずれかのバージョンにアップグレードします。

• 1.19.16-gke.100 以降
• 1.20.11-gke.1300 以降
• 1.21.4-gke.1500 以降

Pod が containerCreating 状態で停止する

Calico ネットワーク ポリシーが有効になっている GKE クラスタで、Pod が containerCreating 状態のままになる可能性があります。

Pod の [イベント] タブに、次のようなメッセージが表示されます。

plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local

この問題を軽減するには、GKE クラスタの calico-ipam を使用するのではなく Calico のホストローカル ipam を使用します。

次のステップ

• ネットワーク ポリシー チュートリアルを実行する。

• Kubernetes ドキュメントのネットワーク ポリシーの説明を読む。

• ネットワーク ポリシーでトラフィックを制限する一般的な方法を実装する。

• ネットワーク ポリシー ロギングを使用する。

• セキュリティ分析情報を使用してインフラストラクチャを強化するほかの方法を確認する。