GKE ネットワーキングのベスト プラクティス

このドキュメントでは、Google Kubernetes Engine(GKE)クラスタのネットワーク オプションを構成するためのベスト プラクティスの概要を説明します。このドキュメントは、ほとんどの GKE クラスタに適用できる推奨事項が記載された、クラウド アーキテクトとネットワーク エンジニア向けのアーキテクチャ プランニング ガイドです。クラスタを作成する前に、すべてのセクションを確認してネットワーキング オプションと影響を確認することをおすすめします。このドキュメントは、Kubernetes ネットワーキングのコンセプトや用語を紹介するものではなく、読者にある程度の Kubernetes ネットワーキングの知識があることを前提としています。詳細については、GKE ネットワークの概要をご覧ください。

このドキュメントをご確認いただきながら、クラスタとクラスタタイプの公開レベル、ワークロードを内部で Virtual Private Cloud(VPC)ネットワークに対して、または外部のインターネットに公開する方法についての計画、ワークロードのスケーリング方法についての計画、使用する Google サービスの種類について検討してください。

VPC 設計

VPC ネットワークを設計する場合は、VPC 設計のベスト プラクティスに沿ってください。次のセクションでは、VPC ネットワーク設計に関する GKE 固有の推奨事項について説明します。

VPC ネイティブ クラスタを使用する

クラスタを作成する前に、ルートベースまたは VPC ネイティブ クラスタのいずれかを選択する必要があります。GKE ノードでエイリアス IP アドレス範囲を使用し、ルートベースのクラスタよりも簡単にスケーリングできる VPC ネイティブ クラスタを選択することをおすすめします。VPC ネイティブ クラスタは、限定公開 GKE クラスタ、および共有 VPC でクラスタを作成するために必要です。Autopilot モードで作成されたクラスタでは、VPC ネイティブ モードが常にオンになっており、オフにできません。

VPC ネイティブ クラスタは、Google Cloud ルートを消費することなく、ルートベースのクラスタよりも簡単にスケールできるため、ルーティング上限に達する可能性が低くなります。VPC ネイティブ クラスタを使用する利点は、エイリアス IP のサポートと密接に関連しています。たとえば、ネットワーク エンドポイント グループ(NEG)はセカンダリ IP アドレスのみで使用できるため、VPC ネイティブ クラスタでのみサポートされます。

共有 VPC ネットワークを使用する

GKE クラスタでは、IP アドレスを慎重に計画する必要があります。ほとんどの組織の場合で、クラスタに IP アドレス空間を割り振ることができるネットワーク管理者と、クラスタを操作するプラットフォーム管理者がいる集中管理構造になります。この種の組織構造は、Google Cloud の共有 VPC ネットワーク アーキテクチャに適しています。共有 VPC ネットワーク アーキテクチャでは、ネットワーク管理者がサブネットを作成し、それを特定のメンバーやロールと共有できます。その後、これらのサブネットのサービス プロジェクトに GKE クラスタを作成できます。

一般的に、共有 VPC ネットワークは高頻度で使用されるアーキテクチャであり、一元化された管理チームを持つほとんどの組織に適しています。共有 VPC ネットワークを使用して GKE クラスタのサブネットを作成し、組織全体で IP アドレスの競合を回避することをおすすめします。

IP アドレス管理の戦略

Kubernetes クラスタでは、Pod ごとに一意の IP アドレスが必要です。GKE では、これらのアドレスをすべて VPC ネットワーク全体でルーティングできます。したがって、アドレスをオンプレミスまたは他の接続された環境で使用されるプライベート IP アドレス空間と重複できないため、IP アドレスの計画が必要です。次のセクションでは、GKE を使用した IP アドレス管理の戦略について説明します。

必要な IP アドレスの割り振りを計画する

限定公開クラスタは推奨されており、詳細については、ネットワーク セキュリティのセクションをご覧ください。限定公開クラスタのコンテキストでは、VPC ネイティブ クラスタのみがサポートされているため、次の IP 範囲を定義する必要があります。

  • コントロール プレーンの IP アドレス範囲: VPC ネットワーク内の他のクラスレス ドメイン間ルーティング(CIDR)と重複しない RFC 1918 /28 サブネット。
  • ノードのサブネット: クラスタ内のすべてのノードに割り振るプライマリ IP 範囲を持つサブネット。cloud.google.com/load-balancer-type: "Internal" アノテーションを使用する LoadBalancer タイプの Service でも、このサブネットが使用されます。
  • Pod の IP アドレス範囲: クラスタ内のすべての Pod に割り振る IP 範囲。クラスタ CIDR とも呼ばれます。
  • Service の IP アドレス範囲: クラスタ内のすべての Service に割り振る IP アドレス範囲。Service CIDR とも呼ばれます。

コントロール プレーンの IP アドレス範囲は、VPC とピアリングされた Google が管理するテナント プロジェクトに存在する、GKE マネージド コントロール プレーン専用です。この IP アドレス範囲は、VPC ピアリング グループ内のどの IP アドレスと重複してはなりません。

クラスタを作成する場合、サブネットにクラスタのノードのプライマリ範囲があり、これがクラスタの作成前に存在している必要があります。サブネットは、クラスタで予想されるノードの最大数に対応できるようにする必要があります。クラスタ オートスケーラーを使用すると、ノードの最大数を制限できます。

Pod と Service の IP アドレス範囲は、サブネットの個別のセカンダリ範囲として表され、VPC ネイティブ クラスタでエイリアス IP アドレスとして実装されます。

クラスタのすべてのノード、Pod、Service に対応できるように、十分なアドレス範囲を選択します。

必要に応じて RFC 1918 以外の空間を使用する

一部の環境では、大規模な連続した CIDR ブロック内の RFC 1918 空間が、組織内ですでに割り振られている場合があります。Google 所有のパブリック IP アドレスと重複しない場合は、GKE クラスタの追加 CIDR に RFC 1918 以外の空間を使用できます。クラス E アドレス空間はオンプレミス ハードウェアとの相互運用性の問題をもたらす可能性があるため、RFC 6598 アドレス空間の一部(100.64.0.0/10)を使用することをおすすめします。また、プライベートに再利用されたパブリック IP を使用する場合は、注意が必要です。このオプションを選択する場合は、オンプレミス ネットワーク内のインターネットへのルート アドバタイズメントを制御することを検討してください。

クラスタ Pod と Pod 間、および Pod と Service 間のトラフィックでの SNAT の使用は避けてください。限定公開クラスタでプライベートに再利用されたパブリック IP を使用する場合、デフォルトの動作で、RFC 1918 以外のすべてのアドレス空間に対して SNAT が想定されます。これを修正するには、IP マスカレード エージェントを適切に構成します。nonMasqueradeCIDRs には、少なくともクラスタ CIDR と Service CIDR が含まれている必要があります。

カスタム サブネット モードを使用する

ネットワークの設定時、auto(デフォルト)または custom(推奨)からサブネット モードも選択します。auto モードでは、サブネットの割り振りが Google に任されるため、IP アドレスを計画しなくても使用を開始できます。ですが、環境内の他の範囲と重複しない IP アドレス範囲を選択できる custom モードを選択することをおすすめします。共有 VPC を使用している場合は、組織管理者またはネットワーク管理者のいずれかがこのモードを選択できます。

次の例では、カスタム サブネット モードが設定された my-net-1 という名前のネットワークを作成しています。

gcloud compute networks create my-net-1 --subnet-mode custom

ノードあたりの Pod 密度を計画する

デフォルトでは、Standard クラスタは、サブネット内の Pod アドレス空間から全ノードに /24 の範囲を予約し、ノードあたり最大 110 個の Pod を許可します。ノードのサイズと Pod のアプリケーション プロファイルによっては、各ノードで実行できる Pod の数が大幅に制限される可能性があります。

ノードあたり 64 個を超える Pod を実行することを想定していない場合は、ノードあたりの最大 Pod 数を調整して、Pod サブネットの IP アドレス空間を維持することをおすすめします。

Autopilot クラスタの場合、ノードあたりの最大 Pod 数は 32 に設定され、すべてのノードに /26 範囲を予約します。この設定は、Autopilot クラスタでは構成できません。

他の環境で使用されている IP アドレスとの重複を回避する

Cloud VPN または Cloud Interconnect を介して、VPC ネットワークをオンプレミス環境または他のクラウド サービス プロバイダに接続できます。これらの環境はルートを共有できるので、オンプレミスの IP アドレス管理方式が GKE の IP アドレスの計画において重要となります。IP アドレスが他の環境で使用されている IP アドレスと重複しないようにすることをおすすめします。

ロードバランサのサブネットを作成する

別のロードバランサのサブネットを作成して、内部 TCP / UDP 負荷分散を使用して Service を公開します。別のロードバランサのサブネットが使用されない場合、これらの Service はノードのサブネットの IP アドレスを使用して公開されます。そのため、そのサブネットに割り振られたすべての空間が想定よりも早く使用される可能性があり、GKE クラスタが想定されるノード数にスケーリングされなくなる可能性があります。

また、個別のロードバランサのサブネットを使用すると、内部 TCP / UDP 負荷分散によって公開される Service に、GKE ノードとの間でトラフィックをフィルタリングできます。これにより、より厳密なセキュリティ境界を設定できます。

クラスタ オートスケーラー用の十分な IP アドレス空間を予約する

クラスタ オートスケーラーを使用すると、クラスタ内のノードを動的に起動および停止して、費用を管理し、使用率を改善できます。ただし、クラスタ オートスケーラーを使用する場合は、IP アドレスを計画する際にすべてのノードプールの最大サイズを考慮するようにします。新しいノードには、ノードごとに構成された Pod に基づいた独自のノード IP アドレスと独自の割り振り可能な Pod IP アドレスのセットが必要です。ノードあたりの Pod の数は、クラスタレベルでの構成とは異なる数に構成できます。クラスタまたはノードプールを作成した後に、ノードあたりの Pod の数を変更することはできません。最適な IP アドレスを割り振るには、ワークロードの種類を検討し、それぞれを個別のノードプールに割り当てる必要があります。

ネットワーク セキュリティ オプション

このセクションでは、クラスタの分離を目的とする、いくつかの重要な推奨事項について説明します。GKE クラスタのネットワーク セキュリティは、Google とお客様のクラスタ管理者との共有責任で管理されます。

限定公開クラスタのタイプを選択する

クラスタには、パブリックと限定公開の 2 つのネットワーク分離タイプがあります。パブリック クラスタの場合、ノード上にプライベート IP アドレスとパブリック IP アドレスの両方があり、コントロール プレーン ノード用のパブリック エンドポイントのみがあります。限定公開クラスタの場合、ノード上にプライベート IP アドレスのみがあり、コントロール プレーン ノード用のプライベート エンドポイントとパブリック エンドポイントがあるため、より高度な分離を実現できます(これをさらに分離することも可能であり、クラスタのコントロール プレーンの公開を最小化するのセクションで説明されています)。限定公開クラスタでは、限定公開の Google アクセスを使用して Google API にアクセスできます。ネットワークの分離には限定公開クラスタを選択することをおすすめします。

限定公開クラスタでは、Pod が受信通信と送信通信から分離されます(クラスタ境界)。このドキュメントのクラスタ接続セクションで説明されているように、負荷分散と Cloud NAT を使用して Service を公開することで、これらの指向性のあるフローを制御できます。次の図は、このような設定を示しています。

限定公開クラスタの通信
図 1: 限定公開クラスタの通信

上の図は、限定公開クラスタが通信を行う方法を示しています。オンプレミス クライアントは、kubectl クライアントを使用してクラスタに接続できます。Google サービスへのアクセスは限定公開の Google アクセスによって提供され、インターネットとの通信は Cloud NAT を使用する場合のみ可能です。

詳細については、限定公開クラスタの要件、制約、制限事項をご覧ください。

クラスタのコントロール プレーンの公開を最小化する

限定公開クラスタでは、GKE API サーバーはパブリック エンドポイントまたはプライベート エンドポイントとして公開できます。使用するエンドポイントは、クラスタの作成時に指定できます。承認済みネットワークを使用してアクセスを制御できます。この場合、パブリック エンドポイントとプライベート エンドポイントの両方で、デフォルトで Pod とクラスタ内のノード IP アドレス間のすべての通信が許可されます。クラスタの作成時にプライベート エンドポイントを有効にするには、--enable-private-endpoint フラグを使用します。

コントロール プレーンへのアクセスを認可する

承認済みネットワークを使用すると、GKE コントロール プレーンのノードにアクセスできる IP アドレスのサブネットを指定できます。これらのネットワークを有効にした後、特定のソース IP アドレス範囲へのアクセスを制限できます。パブリック エンドポイントが無効になっている場合、これらのソース IP アドレス範囲はプライベートになります。パブリック エンドポイントが有効になっている場合、パブリック IP アドレス範囲またはプライベート IP アドレス範囲を許可できます。カスタムルート アドバタイズを構成して、クラスタ コントロール プレーンのプライベート エンドポイントに、オンプレミス環境から到達できるようにします。クラスタの作成時に --enable-master-global-access オプションを使用すると、プライベート GKE API エンドポイントにグローバルに到達できるようにすることができます。

次の図は、承認済みネットワークを使用した一般的なコントロール プレーン接続を示しています。

承認済みネットワークを使用したコントロール プレーン接続
図 2: 承認済みネットワークを使用したコントロール プレーン接続

上の図は、信頼されたユーザーが承認済みネットワークの一部であるため、パブリック エンドポイントを介して GKE コントロール プレーンと通信できる一方で、信頼できないユーザーからのアクセスがブロックされることを示しています。GKE クラスタとの間の通信は、コントロール プレーンのプライベート エンドポイントを介して行われます。

コントロール プレーンへの接続を許可する

すべてのワーカーノードの特定のシステム Pod は、Kubernetes API サーバー(kube-apiserver)、Google API、メタデータ サーバーなどのサービスに到達する必要があります。また、kube-apiserver は、event-exporter などの特定のシステム Pod と通信する必要があります。この通信はデフォルトで許可されます。プロジェクト内に VPC ファイアウォール ルールをデプロイする場合(詳細については、クラスタのトラフィックを制限するのセクションをご覧ください)、それらの Pod が Google API だけでなく kube-apiserver とも通信し続けることができることを確認します。

ピアリング対象のネットワークからコントロール プレーンにアクセスするためのプロキシをデプロイする

プライベート GKE クラスタのコントロール プレーンへのアクセスは、VPC ネットワーク ピアリングを介して行われます。VPC ネットワーク ピアリングは推移的ではないため、別のピアリング ネットワークからクラスタのコントロール プレーンにアクセスすることはできません。

ハブアンドスポーク アーキテクチャを使用するときに、ピアリングされた別のネットワークやオンプレミスから直接アクセスする必要がある場合は、コントロール プレーン トラフィック用のプロキシをデプロイします。詳細については、コントロール プレーン アクセス用のネットワーク プロキシを使用した Kubernetes 限定公開クラスタの作成をご覧ください。

ネットワーク ポリシーを使用してクラスタのトラフィックを制限する

組み合わせ可能なクラスタ ワークロードには、VPC ファイアウォール ルール、階層的ファイアウォール ポリシー、GKE ネットワーク ポリシーなど、複数のレベルのネットワーク セキュリティを設定できます。VPC ファイアウォール ルールと階層的ファイアウォール ポリシーは、仮想マシン(VM)レベル、つまり GKE クラスタの Pod が存在するワーカーノードに適用されます。GKE ネットワーク ポリシーは Pod レベルで適用され、Pod のトラフィック パスを適用します。詳細については、Anthos セキュリティのブループリント: トラフィックの制限をご覧ください。

VPC ファイアウォールを実装すると、デフォルトの必須コントロール プレーン通信(コントロール プレーンとの kubelet 通信など)が機能しなくなる可能性があります。GKE はデフォルトで必要なファイアウォール ルールを作成しますが、上書きすることができます。一部のデプロイでは、Service のクラスタに到達するためにコントロール プレーンが必要になる場合があります。VPC ファイアウォールを使用して、Service のアクセスを可能にする Ingress ポリシーを構成できます。

GKE ネットワーク ポリシーは、Kubernetes Network Policy API を介して構成され、クラスタの Pod と Service の通信を実施します。クラスタの作成時にネットワーク ポリシーを有効にするには、gcloud container clusters create オプション --enable-network-policy を使用します。ネットワーク ポリシーを使用してトラフィックを制限するには、Anthos トラフィック制限ブループリント実装ガイドに沿ってください。

GKE Dataplane V2eBPF に基づいており、統合されたネットワーク セキュリティと可視性のエクスペリエンスを提供します。GKE Dataplane V2 を使用してクラスタを作成する場合、GKE Dataplane V2 がサービス ルーティング、ネットワーク ポリシーの適用、ロギングを管理するため、ネットワーク ポリシーを明示的に有効にする必要はありません。クラスタの作成時に gcloud --enable-dataplane-v2 オプションを使用して新しいデータプレーンを有効にします。ネットワーク ポリシーの構成後、デフォルトの NetworkLogging CRD オブジェクトを構成して、許可および拒否されたネットワーク接続をロギングできます。

Ingress の Google Cloud Armor セキュリティ ポリシーを有効にする

Google Cloud Armor セキュリティ ポリシーを使用すると、ネットワークエッジでトラフィックをブロックすることにより、DDoS 攻撃やその他のウェブベースの攻撃から外部 HTTP(S) 負荷分散を使用しているアプリケーションを保護できます。GKE で、Ingress for External HTTP(S) Load Balancing を使用し、Ingress オブジェクトに接続された BackendConfig にセキュリティ ポリシーを追加して、アプリケーションの Google Cloud Armor セキュリティ ポリシーを有効にします。

Identity-Aware Proxy を使用して、IAM ユーザーを含むアプリケーションの認証を行う

組織内のユーザーのみがアクセスできるように Service をデプロイしたいが、企業ネットワーク上に存在する必要がない場合、Identity-Aware Proxy を使用してアプリケーションに認証レイヤを作成できます。GKE で Identity-Aware Proxy を有効にするには、構成手順に沿って Identity-Aware Proxy を Service の Ingress 用の BackendConfig の一部として追加します。Identity-Aware Proxy は Google Cloud Armor と組み合わせることができます。

組織のポリシーの制約を使用してセキュリティをさらに強化する

組織のポリシーの制約を使用して、ポリシーを設定することでセキュリティ体制をさらに強化できます。たとえば、制約を使用してロードバランサの作成を特定のタイプ(内部ロードバランサのみなど)に制限することも、外部 IP アドレスの使用を制限することもできます。

クラスタ接続のスケーリング

このセクションでは、DNS のスケーラブルなオプションと、クラスタからインターネットおよび Google サービスへの外向き接続について説明します。

NodeLocal DNSCache を有効にする

GKE は、デフォルトのクラスタ アドオンとしてクラスタのローカル DNS サービスを提供するために kube-dns を使用します。kube-dns は、クラスタ内のコアとノードの総数の関数として、クラスタ間で複製されます。

DNS パフォーマンスは、NodeLocal DNSCache によって改善できます。NodeLocal DNSCache は、DaemonSet としてデプロイされるアドオンで、Pod の構成を変更する必要はありません。ローカル Pod Service への DNS ルックアップは、ノード上で追跡する必要のあるオープン接続を作成しないため、より大きなスケールが可能になります。外部ホスト名ルックアップは Cloud DNS に転送され、他のすべての DNS クエリは kube-dns に転送されます。

NodeLocal DNSCache を有効にすることで、DNS クエリのルックアップ時間の一貫性が向上し、クラスタ規模が改善されます。Autopilot クラスタの場合、NodeLocal DNSCache はデフォルトで有効になっており、オーバーライドできません。

次の gcloud コマンドライン ツール オプションは、クラスタの作成時に NodeLocal DNSCache を有効にします。--addons NodeLocalDNS.

アプリケーションが解決しようとしている名前を制御できる場合は、DNS スケーリングを改善できます。たとえば、FQDN を使用する(ホスト名をピリオドで終了する)か、Pod.dnsConfig マニフェスト オプションを使用して検索パスの拡張を無効にします。

限定公開クラスタからのインターネット アクセスに Cloud NAT を使用する

デフォルトでは、限定公開クラスタはインターネットにアクセスできません。Pod がインターネットに到達できるようにするには、各リージョンで Cloud NAT を有効にします。少なくとも、GKE サブネットのプライマリ範囲とセカンダリ範囲に対して Cloud NAT を有効にします。Cloud NAT と VM ごとのポートに十分な IP アドレスを割り振るようにしてください。

Pod トラフィックでは、二重 SNAT を避ける必要があります(最初に GKE ノードで SNAT、次に Cloud NAT)。SNAT が Cloud VPN または Cloud Interconnect によって接続されたオンプレミス ネットワークに対して Pod IP を非表示にする必要がない限り、disable-default-snat して、スケーラビリティのために SNAT 追跡を Cloud NAT にオフロードします。このソリューションは、すべてのプライマリおよびセカンダリ サブネット IP 範囲で機能します。Cloud NAT を有効にした後、ネットワーク ポリシーを使用して外部トラフィックを制限します。Cloud NAT は、Google サービスへのアクセスには必要ありません。

限定公開の Google アクセスを使用して Google サービスにアクセスする

限定公開クラスタでは、Google API やサービスなどの公開サービスにアクセスするためのパブリック IP アドレスが Pod に付与されません。限定公開の Google アクセスを使用すると、限定公開の Google Cloud リソースが Google サービスにアクセスできるようになります。限定公開の Google アクセスでサポートされる Google サービスには、BigQuery、Binary Authorization、Container Registry などがあります。

このオプションはデフォルトではオフになっています。サブネットの作成時にクラスタに関連付けられたサブネットで有効にする必要があります。

--enable-private-ip-google-access gcloud コマンドライン ツール オプションを使用すると、サブネットの作成時に限定公開の Google アクセスを有効にできます。

アプリケーションの処理

組織の外部または内部からアクセス可能なアプリケーションを作成するときは、必ず適切なロードバランサの種類とオプションを使用してください。このセクションでは、Cloud Load Balancing を使用してアプリケーションを公開し、スケーリングする際の推奨事項をいくつか紹介します。

コンテナ ネイティブの負荷分散を使用する

HTTP(S) を外部で使用して Service を公開する場合は、コンテナ ネイティブの負荷分散を使用します。コンテナ ネイティブの負荷分散により、ネットワーク ホップ数が少なくなり、レイテンシが小さくなり、より正確なトラフィック分散が可能になります。また、ラウンド トリップ時間の可視性が向上し、Cloud CDN や Google Cloud Armor などの負荷分散機能を使用できるようになります。

アプリケーションを公開するための正しい GKE リソースを選択する

クライアントのスコープ(内部、外部、クラスタ内部)、アプリケーションの地域性、使用するプロトコルに応じて、アプリケーションの公開で使用できるさまざまな GKE リソースがあります。Service ネットワーキングの概要では、これらのオプションについて説明しており、Google Cloud の負荷分散オプションを使用して、アプリケーションの各部分を公開するための最適なリソースを選択できます。

BackendConfig に基づいてヘルスチェックを作成する

Ingress を使用して Service を公開する場合は、BackendConfig CRD のヘルスチェック構成を使用して HTTP(S) 負荷分散のヘルスチェック機能を使用します。ヘルスチェックを適切なエンドポイントに転送し、独自のしきい値を設定できます。BackendConfig CRD がない場合、ヘルスチェックは readiness Probe パラメータから推定されるか、デフォルトのパラメータが使用されます。

ローカル トラフィック ポリシーを使用して元の IP アドレスを維持する

GKE で内部 TCP / UDP ロードバランサを使用する場合は、externalTrafficPolicy オプションを Local に設定して、リクエストのソース IP アドレスを保持します。アプリケーションで元のソース IP アドレスが必要な場合は、このオプションを使用します。ただし、externalTrafficPolicy local オプションを使用すると最適な負荷分散が得られない場合があるため、この機能は必要な場合にのみ使用してください。HTTP(S) サービスの場合、HTTP リクエスト内の X-Forwarded-For ヘッダーを読み取ることで、Ingress コントローラを使用して元の IP アドレスを取得できます。

運用と管理

以下のセクションでは、ワークロードのきめ細かい承認オプションの実現に役立つ、運用上のベスト プラクティスについて説明します。手動のファイアウォール ルールが作成されないようにするには、このセクションの運用上のベスト プラクティスをご覧ください。ワークロードの分散や、GKE でのモニタリングとロギングに関する推奨事項も記載されています。

Workload Identity を使用して、Google API に対してワークロードを認証する

GKE クラスタ内から他の Google Cloud サービスにアクセスするには、Workload Identity を使用します。Workload Identity を使用して、Kubernetes サービス アカウントGoogle サービス アカウントにリンクすることで、最小権限の原則を維持できます。Kubernetes サービス アカウントは Pod に割り当てることができます。これにより、Google API にアクセスするためのきめ細かい権限をワークロードごとに取得できます。Autopilot クラスタでは、Workload identity はデフォルトで有効になります。

GKE 用 IAM 権限を使用して共有 VPC ネットワーク内のポリシーを制御する

共有 VPC ネットワークを使用する場合、ロードバランサのファイアウォール ルールはホスト プロジェクトで自動的に作成されます。ファイアウォール ルールを手動で作成する必要がないようにするには、service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com という名前のホスト プロジェクトの GKE サービス アカウントに Compute セキュリティ管理者のロールを付与しますHOST_PROJECT_NUMBER は、共有 VPC のホスト プロジェクトのプロジェクト番号に置き換えます。

また、GKE によって作成されたファイアウォール ルールの優先度はデフォルトで 1,000 であるため、優先度の高いファイアウォール ルールを作成することで、特定のトラフィック フローを禁止できます。

特定のロードバランサ タイプの作成を制限する場合は、ロードバランサの作成を制限する組織のポリシーを使用します。

リージョン クラスタを使用しワークロードを分散して高可用性を実現する

リージョン クラスタでは、クラスタのコントロール プレーンとノードが複数のゾーンに分散されるため、クラスタ内のアプリケーションの可用性を向上させることができます。

ただし、ゾーン障害が発生した場合でもユーザーに可能な限り最適なエクスペリエンスを提供するには、クラスタ オートスケーラーを使用して、クラスタが必要な負荷をいつでも処理できるようにします。また、Pod の反アフィニティを使用して、特定の Service の Pod が複数のゾーンでスケジュールされるようにします。高可用性とコスト最適化のためにこれらの設定を構成する方法の詳細については、高可用性 GKE クラスタのベスト プラクティスをご覧ください。

Cloud Operations for GKE とネットワーク ポリシー ロギングを使用する

可視性と監査の要件は組織によって異なりますが、ネットワーク ポリシー ロギングベータ版)を有効にすることをおすすめします。この機能は、GKE Dataplane v2ベータ版)でのみ利用できます。ネットワーク ポリシー ロギングは、ポリシーの適用と Pod のトラフィック パターンを可視化します。なお、ネットワーク ポリシー ロギングには費用がかかります。

バージョン 1.14 以降を使用する GKE クラスタの場合、Cloud Operations for GKE はデフォルトでモニタリングとロギングの両方を有効にし、GKE クラスタ用のダッシュボードを提供します。また、VPC フローログの GKE アノテーションも有効になります。Cloud Operations for GKE はデフォルトで、クラスタにデプロイされたすべてのワークロードのログを収集しますが、システムのみのログオプションもあります。Cloud Operations for GKE ダッシュボードを使用して、アラートをモニタリングして設定します。Google Cloud のオペレーション スイートには費用が発生します。Autopilot モードで作成されたクラスタの場合、Cloud Operations for GKE は自動的に有効になり、構成できません。

チェックリストの概要

次の表は、GKE クラスタのネットワーク オプションを構成するためのベスト プラクティスをまとめたものです。

領域 プラクティス
VPC 設計
IP アドレス管理の戦略
セキュリティ
スケーリング
アプリケーションの処理
運用と管理

次のステップ