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

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このページでは、Google Kubernetes Engine(GKE)でネットワーク ポリシーの適用を構成する方法を説明します。GKE ネットワーキングに関する一般的な情報については、ネットワークの概要をご覧ください。

概要

GKE のネットワーク ポリシーを適用することで、クラスタの Pod と Service 間の通信を制御できます。Kubernetes ネットワーク ポリシー API を使用して、Pod レベルのファイアウォール ルールを作成し、ネットワーク ポリシーを定義します。これらのファイアウォール ルールは、クラスタ内でどの Pod とサービスが相互にアクセスできるかを決定します。

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

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

準備

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

  • Google Kubernetes Engine API を有効にします。
  • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。

ネットワーク ポリシーの適用を使用する

ネットワーク ポリシーの適用は、GKE クラスタの作成時に有効にすることも、既存のクラスタに対して有効にすることもできます。また、既存のクラスタのネットワーク ポリシーを無効にすることもできます。

クラスタのネットワーク ポリシーを有効にした後は、Kubernetes ネットワーク ポリシー API を使用してネットワーク ポリシーを作成できます。

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

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

GKE Dataplane V2 を使用しない GKE クラスタでネットワーク ポリシーの適用を有効にすると、GKE はそのクラスタ内のネットワーク ポリシーを管理し、適用します。

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

gcloud

クラスタの作成時にネットワーク ポリシーの適用を有効にするには、次のコマンドを実行します。

gcloud container clusters create CLUSTER_NAME --enable-network-policy

CLUSTER_NAME は、新しいクラスタの名前に置き換えます。

既存のクラスタに対してネットワーク ポリシーの適用を有効にするには、次のタスクを実行します。

  1. 次のコマンドを実行して、アドオンを有効にします。

    gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
    

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

  2. 次のコマンドを実行してクラスタでネットワーク ポリシーの適用を有効にします。これにより、次に、ネットワーク ポリシーの適用が有効に設定されて、クラスタのノードプールが再作成されます。

    gcloud container clusters update CLUSTER_NAME --enable-network-policy
    

Console

新しいクラスタの作成時にネットワーク ポリシーの適用を有効にするには、次のようにします。

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

    Google Kubernetes Engine に移動

  2. [ 作成] をクリックします。

  3. 必要に応じてクラスタを構成します。

  4. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  5. [ネットワーク ポリシーを有効にする] チェックボックスを選択します。

  6. [作成] をクリックします。

既存のクラスタに対するネットワーク ポリシーの適用を有効にするには、次の手順を行います。

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

    Google Kubernetes Engine に移動

  2. クラスタのリストで、変更するクラスタの名前をクリックします。

  3. [ネットワーキング] の [ネットワーク ポリシー] フィールドで、 [ネットワーク ポリシーを編集] をクリックします。

  4. [マスターのネットワーク ポリシーの有効化] チェックボックスをオンにして、[変更を保存] をクリックします。

  5. 変更が適用されるのを待ってから、 [ネットワーク ポリシーを編集] を再度クリックします。

  6. [ノードのネットワーク ポリシーの有効化] チェックボックスをオンにします。

  7. [変更を保存] をクリックします。

API

ネットワーク ポリシーの適用を有効にするには、次のようにします。

  1. projects.zones.clusters.create または projects.zones.clusters.update に渡す cluster オブジェクト内に networkPolicy オブジェクトを指定します。

  2. networkPolicy オブジェクトには、使用するネットワーク ポリシー プロバイダを指定する列挙値と、ネットワーク ポリシーを有効にするかどうかを指定するブール値が必要です。ネットワーク ポリシーを有効にしてもプロバイダを設定しないと、create コマンドと update コマンドはエラーを返します。

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

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

gcloud

ネットワーク ポリシーの適用を無効にするには、次のタスクを行います。

  1. クラスタに対するネットワーク ポリシーの適用を無効にします。

    gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
    

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

    このコマンドを実行すると、GKE はネットワーク ポリシーの適用を無効にしたクラスタ ノードプールを再作成します。

  2. すべてのノードが再作成されたことを確認します。

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

    オペレーションが成功した場合、出力は次のようになります。

    No resources found
    

    出力が次のようになったら、GKE がノードプールの更新を完了するまで待つ必要があります。

    NAME                                             STATUS                     ROLES    AGE     VERSION
    gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
    gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
    

    ネットワーク ポリシーの適用を無効にすると、クラスタにメンテナンスの時間枠または除外が構成されている場合、GKE がノードをすぐに更新しないことがあります。詳しくは、クラスタの更新が遅いをご覧ください。

  3. すべてのノードが再作成されたら、アドオンを無効にします。

    gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
    

Console

既存のクラスタに対するネットワーク ポリシーの適用を無効にするには、次のようにします。

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

    Google Kubernetes Engine に移動

  2. クラスタのリストで、変更するクラスタの名前をクリックします。

  3. [ネットワーキング] の [ネットワーク ポリシー] フィールドで、 [ネットワーク ポリシーを編集] をクリックします。

  4. [ノードのネットワーク ポリシーの有効化] チェックボックスをオフにして、[変更を保存] をクリックします。

  5. 変更が適用されるのを待ってから、 [ネットワーク ポリシーを編集] を再度クリックします。

  6. [マスターのネットワーク ポリシーの有効化] チェックボックスをオフにします。

  7. [変更を保存] をクリックします。

API

既存のクラスタに対するネットワーク ポリシーの適用を無効にするには、次のようにします。

  1. setNetworkPolicy API を使用して、networkPolicy.enabled: false を使用するようにクラスタを更新します。

  2. gcloud CLI を使用して、すべてのノードが再作成されたことを確認します。

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

    オペレーションが成功した場合、出力は次のようになります。

    No resources found
    

    出力が次のようになったら、GKE がノードプールの更新を完了するまで待つ必要があります。

    NAME                                             STATUS                     ROLES    AGE     VERSION
    gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
    gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
    

    ネットワーク ポリシーの適用を無効にすると、クラスタにメンテナンスの時間枠または除外が構成されている場合、GKE がノードをすぐに更新しないことがあります。詳しくは、クラスタの更新が遅いをご覧ください。

  3. updateCluster API を使用して、update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true を使用するようにクラスタを更新します。

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

クラスタに対するネットワーク ポリシーの適用を有効にした後は、実際のネットワーク ポリシーを定義する必要があります。ネットワーク ポリシーは、Kubernetes ネットワーク ポリシー API を使用して定義します。

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

PodSecurityPolicy の操作

NetworkPolicy を使用していて、PodSecurityPolicy の対象となる Pod がある場合は、PodSecurityPolicy を使用する権限を持つ RBAC Role または ClusterRole を作成します。その後、ロールまたは ClusterRole を Pod のサービス アカウントにバインドします。NetworkPolicy と PodSecurityPolicy を一緒に使用する場合、ユーザー アカウントに権限を付与するだけでは不十分です。サービス アカウントに役割をバインドする必要があります。詳細については、ポリシーの承認をご覧ください。

オーバーヘッド、制限事項、および注意事項

  • ネットワーク ポリシーの適用を有効にすると、ノードで追加のリソースが消費されます。具体的には、kube-system プロセスのメモリ フットプリントが約 128 MB 増加し、約 300 ミリコアの CPU が必要になります。

  • ネットワーク ポリシーの適用を有効にする場合、ノードの再作成が必要になります。クラスタにアクティブなメンテナンスの時間枠がある場合、次のメンテナンスの時間枠までにはノードは自動的に再作成されません。必要に応じて、いつでも手動でクラスタをアップグレードできます。

制限事項と要件

  • ネットワーク ポリシーの適用を行うために推奨されるクラスタの最小サイズは、3 つの e2-medium インスタンスです。
  • ノードが f1-micro または g1-small インスタンスであるクラスタでは、そのサイズに対してリソース要件が高すぎるため、ネットワーク ポリシーはサポートされません。
  • GKE Workload Identity によるネットワーク ポリシーを使用する場合は、Pod が GKE メタデータ サーバーと通信できるように、次の IP アドレスとポート番号への下り(外向き)通信を許可する必要があります。GKE バージョン 1.21.0-gke.1000 以降を実行しているクラスタでは、ポート 988169.254.169.252/32 への下り(外向き)を許可します。1.21.0-gke.1000 より前のバージョンの GKE を実行しているクラスタの場合は、ポート 988127.0.0.1/32 への下り(外向き)を許可します。 GKE Dataplane V2 を実行しているクラスタの場合、ポート 80169.254.169.254/32 への下り(外向き)が許可されていることを確認します。自動アップグレード中の中断を回避するには、これらの IP アドレスとポートへの下り(外向き)を許可します。
  • GKE Dataplane V2 が有効になっているクラスタのネットワーク ポリシーで endPort フィールドを指定すると、GKE バージョン 1.22 以降では有効になりません。詳細については、ネットワーク ポリシーのポート範囲が有効にならないをご覧ください。

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

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
    

HTTP(S) ロード バランシングの操作

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

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

トラブルシューティング

クラスタの更新が遅い

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

ノードプールを手動でアップグレードするには、--cluster-version フラグを、コントロール プレーンが実行中のものと同じ GKE バージョンに設定します。このオペレーションを行うには、Google Cloud CLI を使用する必要があります。詳細については、メンテナンス時間枠の注意点をご覧ください。

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

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

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

メンテナンスの時間枠または除外を構成した場合、中断が長引く可能性があります。

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

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

既知の問題

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 以降

次のステップ