このページでは、Google Kubernetes Engine（GKE）クラスタのネットワーク オプションを構成するためのベスト プラクティスの概要を説明します。このドキュメントは、ほとんどの GKE クラスタに適用できるクラスタ構成の推奨事項が記載された、クラウド アーキテクトとネットワーク エンジニア向けのアーキテクチャ プランニング ガイドです。GKE クラスタを作成する前に、このページのすべてのセクションを確認して、GKE でサポートされているネットワーキング オプションとその影響を理解することをおすすめします。
選択するネットワーキング オプションは、GKE クラスタのアーキテクチャに影響します。これらのオプションの一部は、クラスタを再作成しない限り構成後に変更することはできません。
このページを読む前に、Kubernetes ネットワーキングのコンセプトと用語、一般的なネットワーキングのコンセプト、Kubernetes ネットワーキングについて理解しておく必要があります。詳細については、GKE ネットワークの概要をご覧ください。
これらのベスト プラクティスを確認する際は、次の点を考慮してください。
- ワークロードを Virtual Private Cloud（VPC）ネットワーク、クラスタ内の他のワークロード、他の GKE クラスタ、またはインターネットに外部に公開する方法。
- ワークロードのスケーリングを計画する方法。
- 使用する Google サービスの種類。
すべてのベスト プラクティスをまとめたチェックリストについては、チェックリストの概要をご覧ください。
VPC 設計
VPC ネットワークを設計する場合は、VPC 設計のベスト プラクティスに従ってください。
次のセクションでは、VPC ネットワーク設計に関する GKE 固有の推奨事項について説明します。
VPC ネイティブ クラスタを使用する
VPC ネイティブ クラスタを使用することをおすすめします。VPC ネイティブ クラスタは、GKE ノードのエイリアス IP アドレス範囲を使用し、VPC ネットワーク ピアリングに基づくクラスタと共有 VPC のクラスタに必要です。また、この他にも多くのメリットがあります。Autopilot モードで作成されたクラスタでは、VPC ネイティブ モードが常にオンになっており、オフにできません。
VPC ネイティブ クラスタは、Google Cloud ルートを消費することなく、ルートベースのクラスタよりも簡単にスケールできるため、ルーティング上限に達する可能性が低くなります。
VPC ネイティブ クラスタを使用する利点は、エイリアス IP のサポートと密接に関連しています。たとえば、ネットワーク エンドポイント グループ（NEG）はセカンダリ IP アドレスのみで使用できるため、VPC ネイティブ クラスタでのみサポートされます。
共有 VPC ネットワークを使用する
GKE クラスタでは、IP アドレスを慎重に計画する必要があります。ほとんどの組織には、クラスタに IP アドレス空間を割り振ることができるネットワーク管理者チームと、クラスタを操作するプラットフォーム管理者がいる集中管理構造があります。この種の組織構造は、Google Cloud の共有 VPC ネットワーク アーキテクチャに適しています。共有 VPC ネットワーク アーキテクチャでは、ネットワーク管理者がサブネットを作成して VPC と共有できます。サービス プロジェクト内に GKE クラスタを作成し、ホスト プロジェクトで共有 VPC から共有されたサブネットを使用できます。IP アドレス コンポーネントはホスト プロジェクトに残り、他のクラスタ コンポーネントはサービス プロジェクト内に存在します。
一般的に、共有 VPC ネットワークは高頻度で使用されるアーキテクチャであり、一元化された管理チームを持つほとんどの組織に適しています。共有 VPC ネットワークを使用して GKE クラスタのサブネットを作成し、組織全体で IP アドレスの競合を回避することをおすすめします。運用機能のガバナンスに共有 VPC を使用することもできます。たとえば、ネットワーク コンポーネントと信頼性のみを担当するネットワーク チームと、GKE を担当する別のチームを配置できます。
IP アドレス管理の戦略
すべての Kubernetes クラスタ（GKE クラスタなど）では、各 Pod に一意の IP アドレスが必要です。
詳細については、GKE ネットワーキング モデルをご覧ください。GKE では、これらの IP アドレスをすべて VPC ネットワーク全体でルーティングできます。したがって、アドレスをオンプレミスまたは他の接続された環境で使用される内部 IP アドレス空間と重複できないため、IP アドレスの計画が必要です。次のセクションでは、GKE を使用した IP アドレス管理の戦略について説明します。
ベスト プラクティス:
必要な IP アドレスの割り振りを計画する。必要に応じて RFC 1918 以外の空間を使用する。
カスタム サブネット モードを使用する。
ノードあたりの Pod 密度を計画する。
他の環境で使用されている IP アドレスとの重複を回避する。
ロードバランサのサブネットを作成する。
クラスタ オートスケーラー用の十分な IP アドレス空間を予約する。
クラスタ間で IP アドレスを共有する。
内部 LoadBalancer Service の IP アドレスを共有する。
必要な IP アドレスの割り振りを計画する
Private Service Connect（PSC）で VPC ネイティブ クラスタを使用することをおすすめします。VPC ネットワーク ピアリングを使用するクラスタは、VPC ネイティブ クラスタである必要があります。
VPC ネイティブ クラスタには、次の IP アドレス範囲が必要です。
- コントロール プレーンの IP アドレス範囲: RFC 1918 に含まれる IP アドレスのプライベート範囲内の /28 サブネットを使用します。このサブネットが、VPC ネットワーク内の他のクラスレス ドメイン間ルーティング（CIDR）と重複しないようにする必要があります。
- ノードのサブネット: クラスタ内のすべてのノードに割り振るプライマリ IP 範囲を持つサブネット。
cloud.google.com/load-balancer-type: "Internal"アノテーションを使用するLoadBalancerタイプの Service も、デフォルトでこのサブネットを使用します。また、内部ロードバランサ専用のサブネットを使用することもできます。 - Pod の IP アドレス範囲: クラスタ内のすべての Pod に割り振る IP 範囲。GKE は、この範囲をサブネットのエイリアスとしてプロビジョニングします。詳細については、VPC ネイティブ クラスタの IP 範囲をご覧ください。
- Service IP アドレス範囲: クラスタ内のすべての Service に割り振る IP アドレス範囲。GKE は、この範囲をサブネットのエイリアスとしてプロビジョニングします。
クラスタ ネットワーキングを構成する場合は、ノードのサブネット、Pod の IP アドレス範囲、Service の IP アドレス範囲を定義する必要があります。
IP アドレス空間をより効率的に使用する場合は、GKE での内部 IP アドレスの使用量を減らすをご覧ください。コントロール プレーンの IP アドレス範囲は、VPC とピアリングされた Google が管理するテナント プロジェクトに存在する、GKE マネージド コントロール プレーン専用です。GKE はこのルートをプロジェクトにインポートするため、この IP アドレス範囲は VPC ピアリング グループ内の IP アドレスと重複しないようにしてください。つまり、プロジェクトに同じ CIDR へのルートがあると、ルーティングの問題が発生する可能性があります。
クラスタを作成する場合、サブネットにクラスタのノードのプライマリ範囲があり、これがクラスタの作成前に存在している必要があります。サブネットは、クラスタで想定される最大ノード数と、サブネットを使用するクラスタ全体の内部ロードバランサの IP アドレスを包含する必要があります。
クラスタ オートスケーラーを使用すると、ノードの最大数を制限できます。Pod と Service の IP アドレス範囲は、サブネットの個別のセカンダリ範囲として表され、VPC ネイティブ クラスタでエイリアス IP アドレスとして実装されます。
クラスタのすべてのノード、Pod、Service に対応できるように、十分な IP アドレス範囲を選択します。
次の制限事項を考慮してください。
- プライマリ IP アドレス範囲の拡張はできますが、縮小はできません。この IP アドレス範囲に不連続な範囲を指定することはできません。
- 追加の Pod 範囲をクラスタに追加するか、他のセカンダリ Pod 範囲を使用して新しいノードプールを作成することで、Pod の範囲を拡張できます。
- Service のセカンダリ IP アドレス範囲は、クラスタの存続期間中には拡張することも、変更することもできません。
- Pod と Service のセカンダリ IP アドレス範囲の制限事項を確認してください。
プライベート RFC 1918 より多くの IP アドレスを使用する
一部の環境では、大規模な連続した CIDR ブロック内の RFC 1918 空間が、組織内ですでに割り振られている場合があります。Google 所有のパブリック IP アドレスと重複しない場合は、GKE クラスタの追加 CIDR に RFC 1918 以外の空間を使用できます。クラス E アドレス空間では、オンプレミス ハードウェアとの相互運用性で問題が生じる可能性があるため、RFC アドレス空間の 100.64.0.0/10 部分を使用することをおすすめします。プライベートで再利用されるパブリック IP（PUPI）を使用できます。
プライベートに利用されたパブリック IP アドレスを使用する場合は注意が必要です。このオプションを選択する場合は、オンプレミス ネットワーク内のインターネットへのルート アドバタイズメントを制御することを検討してください。
Pod 間トラフィックと Pod と Service 間のトラフィックがあるクラスタでは、ソース ネットワーク アドレス変換（SNAT）を使用しないでください。これにより、Kubernetes ネットワーキング モデルが機能しなくなります。
Kubernetes は、RFC 1918 以外のすべての IP アドレスがプライベートで再利用されたパブリック IP アドレスであると想定し、これらのアドレスから発信されるすべてのトラフィックに SNAT を使用します。
Standard クラスタで、GKE クラスタに RFC 1918 以外の IP アドレスを使用している場合、SNAT を明示的に無効にするか、クラスタの Pod IP アドレスと Service のセカンダリ IP アドレス範囲を SNAT から除外するように、IP マスカレード エージェントを構成します。Autopilot クラスタの場合、追加の手順は必要ありません。
カスタム サブネット モードを使用する
ネットワークの設定時、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 を許可します。ただし、/23 範囲をすべてのノードで予約して、ノードあたり最大 256 個の Pod をサポートするように Standard クラスタを構成できます。ノードのサイズと Pod のアプリケーション プロファイルによっては、各ノードで実行できる Pod の数が大幅に制限される可能性があります。
ノードあたり 64 個を超える Pod を実行することを想定していない場合は、ノードあたりの最大 Pod 数を調整して、Pod サブネットの IP アドレス空間を維持することをおすすめします。
デフォルトの 1 ノードあたり 110 を超える Pod を実行する場合は、ノードあたりの最大 Pod 数を 256 まで増やすことができ、すべてのノード用に /23 が予約されます。このタイプの高 Pod 密度構成では、クラスタのスケーラビリティとパフォーマンスを確保するため、CPU コア数が 16 以上のインスタンスを使用することをおすすめします。
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 アドレスを割り振るには、ワークロードの種類を検討し、それぞれを個別のノードプールに割り当てる必要があります。
特に VPC ネイティブ クラスタを使用している場合は、クラスタ オートスケーラーでノードの自動プロビジョニングの使用を検討してください。詳細については、ノード制限範囲をご覧ください。
クラスタ間で IP アドレスを共有する
クラスタのインフラストラクチャを管理する一元化されたチームが存在する場合は、クラスタ間で IP アドレスを共有することが必要な場合があります。GKE クラスタ間で IP アドレスを共有するには、GKE クラスタ間での IP アドレス範囲の共有をご覧ください。特に共有 VPC モデルでは、Pod、Service、ノードの 3 つの範囲を作成し、それらを再利用または共有することで、IP の枯渇を低減できます。さらにこの設定では、ネットワーク管理者がクラスタごとに特定のサブネットを作成する必要がなく、ネットワーク管理者が IP アドレスを管理しやすくなります。
次の点を考慮してください。
- すべてのクラスタに個別のサブネットと IP アドレス範囲を使用することをおすすめします。
- セカンダリ Pod IP アドレス範囲を共有できますが、1 つのクラスタですべての IP アドレスが使用される可能性があるため、おすすめしません。
- セカンダリ Service IP アドレス範囲は共有できますが、この機能は GKE 用 VPC スコープ Cloud DNS では機能しません。
ただし、Pod の IP アドレスが不足している場合は、不連続マルチ Pod CIDR を使用して、Pod の IP アドレス範囲を追加作成できます。
内部 LoadBalancer Service の IP アドレスを共有する
単一の IP アドレスを、異なるポートを使用して最大 50 個のバックエンドと共有できます。これにより、内部 LoadBalancer Service に必要な IP アドレスの数を削減できます。
詳細については、共有 IP をご覧ください。
ネットワーク セキュリティ オプション
このセクションでは、クラスタの分離を目的とする、いくつかの重要な推奨事項について説明します。GKE クラスタのネットワーク セキュリティは、Google とお客様のクラスタ管理者との共有責任で管理されます。
ベスト プラクティス:
GKE Dataplane V2 を使用する。ノードの露出を最小限に抑える。
クラスタのコントロール プレーンの公開を最小化する。
コントロール プレーンへのアクセスを認可する。
コントロール プレーンへの接続を許可する。
ピアリング対象のネットワークからコントロール プレーンにアクセスするためのプロキシをデプロイする。
ネットワーク ポリシーを使用してクラスタのトラフィックを制限する。
Ingress の Google Cloud Armor セキュリティ ポリシーを有効にする。
Identity-Aware Proxy を使用して、IAM ユーザーを含むアプリケーションの認証を行う。
組織のポリシーによる制約を使用してセキュリティをさらに強化する。
GKE Dataplane V2 を使用する
GKE Dataplane V2 は eBPF に基づいており、統合されたネットワーク セキュリティと可視性のエクスペリエンスを提供します。GKE Dataplane V2 を使用してクラスタを作成する場合、GKE Dataplane V2 によってサービス ルーティング、ネットワーク ポリシーの適用、ロギングが管理されるため、ネットワーク ポリシーを明示的に有効にする必要はありません。クラスタの作成時に、Google Cloud CLI の --enable-dataplane-v2 オプションを使用して新しいデータプレーンを有効にします。ネットワーク ポリシーの構成後、デフォルトの NetworkLogging CRD オブジェクトを構成して、許可および拒否されたネットワーク接続をロギングできます。ネットワーク ポリシー ロギングなどの組み込み機能を最大限に活用するため、GKE Dataplane V2 を使用してクラスタを作成することをおすすめします。
ノードの露出を最小限に抑える
プライベート ノードのみを含むクラスタでは、Pod がインバウンド通信とアウトバウンド通信（クラスタ境界）から分離されます。このドキュメントのクラスタ接続セクションで説明されているように、ロード バランシングと Cloud NAT を使用して Service を公開することで、これらの指向性のあるフローを制御できます。次の図は、このような設定を示しています。
この図は、プライベート ノードを含むクラスタが通信を行う方法を示しています。オンプレミス クライアントは、kubectl クライアントを使用してクラスタに接続できます。Google サービスへのアクセスは限定公開の Google アクセスによって提供され、インターネットとの通信は Cloud NAT を使用する場合のみ可能です。
クラスタのコントロール プレーンの公開を最小化する
コントロール プレーンには、クラスタ アクセス用の 2 種類のエンドポイントがあります。
- DNS ベースのエンドポイント
- IP ベースのエンドポイント
DNS ベースのエンドポイントのみを使用してコントロール プレーンにアクセスすることで、構成を簡素化し、柔軟なポリシーベースのセキュリティ レイヤを実現します。
DNS エンドポイントには、オンプレミス ネットワークや他のクラウド ネットワークなど、Google Cloud APIs からアクセスできる任意のネットワークからアクセスできます。DNS ベースのエンドポイントを有効にするには、--enable-dns-access フラグを使用します。
GKE API サーバーは、パブリック IP ベースまたはプライベート IP ベースのエンドポイントとして公開することもできます。使用するエンドポイントは、クラスタの作成時に指定できます。承認済みネットワークを使用してアクセスを制御できます。この場合、パブリック エンドポイントとプライベート エンドポイントの両方で、デフォルトで Pod とクラスタ内のノード IP アドレス間のすべての通信が許可されます。クラスタの作成時にプライベート エンドポイントを有効にするには、--enable-private-endpoint フラグを使用します。
コントロール プレーンへのアクセスを認可する
承認済みネットワークを使用すると、GKE コントロール プレーンのノードにアクセスできる IP アドレスのサブネットを指定できます。これらのネットワークを有効にした後、特定のソース IP アドレス範囲へのアクセスを制限できます。パブリック エンドポイントが無効になっている場合、これらのソース IP アドレス範囲はプライベートになります。パブリック エンドポイントが有効になっている場合、内部 IP アドレス範囲またはプライベート IP アドレス範囲を許可できます。カスタムルート アドバタイズを構成して、クラスタ コントロール プレーンのプライベート エンドポイントに、オンプレミス環境から到達できるようにします。クラスタの作成時に --enable-master-global-access オプションを使用すると、プライベート GKE API エンドポイントにグローバルに到達できるようにすることができます。
次の図は、承認済みネットワークを使用した一般的なコントロール プレーン接続を示しています。
この図は、信頼されたユーザーが承認済みネットワークの一部であるため、パブリック エンドポイントを介して GKE コントロール プレーンと通信できる一方で、信頼できないユーザーからのアクセスがブロックされることを示しています。GKE クラスタとの間の通信は、コントロール プレーンのプライベート エンドポイントを介して行われます。
コントロール プレーンへの接続を許可する
すべてのワーカーノードの特定のシステム Pod は、Kubernetes API サーバー（kube-apiserver）、Google API、メタデータ サーバーなどのサービスに到達する必要があります。また、kube-apiserver は、event-exporter などの特定のシステム Pod と通信する必要があります。この通信はデフォルトで許可されます。プロジェクト内に VPC ファイアウォール ルールをデプロイする場合（詳細については、クラスタのトラフィックを制限するのセクションを参照）、それらの Pod が Google API だけでなく kube-apiserver とも通信を継続できるようにします。
ピアリング対象のネットワークからコントロール プレーンにアクセスするためのプロキシをデプロイする
クラスタで VPC ネットワーク ピアリングを使用している場合、別のピアリング ネットワークからクラスタのコントロール プレーンにアクセスすることはできません。
ハブ アンド スポーク アーキテクチャを使用するときに、ピアリングされた別のネットワークやオンプレミスから直接アクセスする必要がある場合は、コントロール プレーン トラフィック用のプロキシをデプロイします。
ネットワーク ポリシーを使用してクラスタのトラフィックを制限する
組み合わせ可能なクラスタ ワークロードには、VPC ファイアウォール ルール、階層的ファイアウォール ポリシー、Kubernetes ネットワーク ポリシーなど、複数のレベルのネットワーク セキュリティを設定できます。VPC ファイアウォール ルールと階層的ファイアウォール ポリシーは、仮想マシン（VM）レベル、つまり GKE クラスタの Pod が存在するワーカーノードに適用されます。Kubernetes ネットワーク ポリシーは Pod レベルで適用され、Pod 間のトラフィック パスを適用します。
VPC ファイアウォールを実装すると、デフォルトの必須コントロール プレーン通信（コントロール プレーンとの kubelet 通信など）が機能しなくなる可能性があります。GKE はデフォルトで必要なファイアウォール ルールを作成しますが、上書きすることができます。一部のデプロイでは、Service のクラスタに到達するためにコントロール プレーンが必要になる場合があります。VPC ファイアウォールを使用して、Service のアクセスを可能にする Ingress ポリシーを構成できます。
GKE ネットワーク ポリシーは、Kubernetes Network Policy API を介して構成され、クラスタの Pod の通信を実施します。クラスタの作成時にネットワーク ポリシーを有効にするには、gcloud container
clusters create オプション --enable-network-policy を使用します。ネットワーク ポリシーを使用してトラフィックを制限するには、Anthos トラフィック制限ブループリント実装ガイドに沿ってください。
Ingress の Google Cloud Armor セキュリティ ポリシーを有効にする
Google Cloud Armor セキュリティ ポリシーを使用すると、ネットワークエッジでトラフィックをブロックすることにより、DDoS 攻撃やその他のウェブベースの攻撃から外部アプリケーション ロードバランサを使用しているアプリケーションを保護できます。GKE で、外部アプリケーション ロードバランサの Ingress を使用し、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 と組み合わせることができます。
組織のポリシーの制約を使用してセキュリティをさらに強化する
組織のポリシーの制約を使用して、ポリシーを設定することでセキュリティ ポスチャーをさらに強化できます。たとえば、制約を使用すると、ロードバランサの作成を特定のタイプに制限（内部ロードバランサのみなど）できます。
クラスタ接続のスケーリング
このセクションでは、DNS のスケーラブルなオプションと、クラスタからインターネットおよび Google サービスへの外向き接続について説明します。
ベスト プラクティス:
GKE 向け Cloud DNS を使用する。NodeLocal DNSCache を有効にする。
クラスタからのインターネット アクセスに Cloud NAT を使用する。
限定公開の Google アクセスを使用して Google サービスにアクセスする。
GKE 向け Cloud DNS を使用する
GKE 向け Cloud DNS を使用すると、クラスタでホストされる DNS プロバイダなしで、マネージド DNS で Pod と Service の DNS 解決を行うことができます。Cloud DNS は Google のホスト型サービスであるため、クラスタでホストされる DNS サーバーを管理するオーバーヘッドがなくなります。また、DNS インスタンスのスケーリング、モニタリング、管理は必要ありません。
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 はデフォルトで有効になっており、オーバーライドできません。
Google Cloud CLI の --addons NodeLocalDNS. オプションを使用すると、クラスタの作成時に NodeLocal DNSCache が有効に設定されます。
アプリケーションが解決しようとしている名前を制御できる場合は、DNS スケーリングを改善できます。たとえば、FQDN を使用する（ホスト名をピリオドで終了する）か、Pod.dnsConfig マニフェスト オプションを使用して検索パスの拡張を無効にします。
クラスタからのインターネット アクセスに Cloud NAT を使用する
デフォルトでは、プライベート ノードが有効になっているクラスタはインターネットにアクセスできません。Pod がインターネットに到達できるようにするには、各リージョンで Cloud NAT を有効にします。少なくとも、GKE サブネットのプライマリ範囲とセカンダリ範囲に対して Cloud NAT を有効にします。Cloud NAT と VM ごとのポートに十分な IP アドレスを割り振るようにしてください。
クラスタで Cloud NAT を使用する場合は、次の Cloud NAT ゲートウェイ構成のベスト プラクティスを使用します。
- Cloud NAT ゲートウェイを作成する際は、クラスタで使用されるサブネット範囲に対してのみ有効にします。すべてのクラスタ内のすべてのノードをカウントすることで、プロジェクト内の NAT コンシューマー VM の数を判断できます。
動的ポートの割り当てを使用すると、VM の使用量に基づいて、VM ごとに異なるポート数を割り当てることができます。最小ポート数は 64、最大ポート数は 2,048 から開始します。
同じ宛先 3 タプルへの多数の同時接続を管理する必要がある場合は、TCP
TIME_WAITタイムアウトをデフォルト値の120sから5sに引き下げます。詳細については、NAT に別のタイムアウトを指定するをご覧ください。Cloud NAT エラーロギングを有効にして、関連するログを確認します。
ゲートウェイの構成後に Cloud NAT ゲートウェイのログを確認します。割り当てステータスのドロップの問題を低減するには、VM あたりの最大ポート数を引き上げることが必要な場合があります。
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 サービスにアクセスできるようになります。
プライベート ノードのあるクラスタでは、共有 VPC クラスタを除き、デフォルトで限定公開の Google アクセスが有効になっています。
アプリケーションの処理
組織の外部または内部からアクセス可能なアプリケーションを作成するときは、必ず適切なロードバランサの種類とオプションを使用してください。このセクションでは、Cloud Load Balancing を使用してアプリケーションを公開し、スケーリングする際の推奨事項をいくつか紹介します。
ベスト プラクティス:
コンテナ ネイティブの負荷分散を使用する。アプリケーション公開するための正しい GKE リソースを選択する。
BackendConfig に基づいてヘルスチェックを作成する。
ローカル トラフィック ポリシーを使用して元の IP アドレスを維持する。
Private Service Connect を使用する。
コンテナネイティブのロード バランシングを使用する
HTTP(S) を外部で使用して Service を公開する場合は、コンテナネイティブのロード バランシングを使用します。コンテナネイティブのロード バランシングにより、ネットワーク ホップ数が少なくなり、レイテンシが小さくなり、より正確なトラフィック分散が可能になります。また、ラウンド トリップ時間の可視性が向上し、Google Cloud Armor などのロード バランシング機能を使用できるようになります。
アプリケーションを公開するための正しい GKE リソースを選択する
クライアントのスコープ（内部、外部、クラスタ内部）、アプリケーションの地域性、使用するプロトコルに応じて、アプリケーションの公開で使用できるさまざまな GKE リソースがあります。Service ネットワーキングの概要では、これらのオプションについて説明しており、Google Cloud のロード バランシング オプションを使用して、アプリケーションの各部分を公開するための最適なリソースを選択できます。
BackendConfig に基づいてヘルスチェックを作成する
Ingress を使用して Service を公開する場合は、BackendConfig CRD のヘルスチェック構成を使用して外部アプリケーション ロードバランサのヘルスチェック機能を使用します。ヘルスチェックを適切なエンドポイントに転送し、独自のしきい値を設定できます。BackendConfig CRD がない場合、ヘルスチェックは readinessProbe パラメータから推定されるか、デフォルトのパラメータが使用されます。
ローカル トラフィック ポリシーを使用して元の IP アドレスを維持する
GKE で内部パススルー ネットワーク ロードバランサを使用する場合は、externalTrafficPolicy オプションを Local に設定して、リクエストの送信元 IP アドレスを保持します。アプリケーションで元の送信元 IP アドレスが必要な場合は、このオプションを使用します。ただし、externalTrafficPolicy local オプションを使用すると最適な負荷分散が得られない場合があるため、この機能は必要な場合にのみ使用してください。HTTP(S) サービスの場合、HTTP リクエスト内の X-Forwarded-For ヘッダーを読み取ることで、Ingress コントローラを使用して元の IP アドレスを取得できます。
Private Service Connect を使用する
Private Service Connect を使用して、内部パススルー ネットワーク ロードバランサ サービスを他の VPC ネットワーク間で共有できます。これは、GKE クラスタでホストされているものの、別のプロジェクトや VPC で実行されているお客様にサービスを提供している Service に対して有効です。
Private Service Connect を使用して、重複する IP アドレスを持つ VPC 間の接続を提供することで、IP アドレスの消費量を削減できます。
運用と管理
ベスト プラクティス:
GKE 用 IAM 権限を使用して共有 VPC ネットワーク内のポリシーを制御する。リージョン クラスタを使用し、ワークロードを分散して高可用性を実現する。
Cloud Logging と Cloud Monitoring を使用してネットワーク ポリシー ロギングを有効にする。
以下のセクションでは、ワークロードのきめ細かい承認オプションの実現に役立つ、運用上のベスト プラクティスについて説明します。手動のファイアウォール ルールが作成されないようにするには、このセクションの運用上のベスト プラクティスをご覧ください。ワークロードの分散や、GKE でのモニタリングとロギングに関する推奨事項も記載されています。
GKE 用 IAM 権限を使用して共有 VPC ネットワーク内のポリシーを制御する
共有 VPC ネットワークを使用する場合、ロードバランサのファイアウォール ルールはホスト プロジェクトで自動的に作成されます。
手動でファイアウォール ルールを作成する必要がないようにするには、service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com という名前のホスト プロジェクトの GKE サービス アカウントに最小権限のカスタムロールを割り当てます。
HOST_PROJECT_NUMBER は、共有 VPC のホスト プロジェクトのプロジェクト番号に置き換えます。
作成するカスタムロールには、次の権限が付与されている必要があります。
compute.firewalls.createcompute.firewalls.getcompute.firewalls.listcompute.firewalls.delete
また、GKE によって作成されたファイアウォール ルールの優先度はデフォルトで 1,000 であるため、優先度の高いファイアウォール ルールを作成することで、特定のトラフィック フローを禁止できます。
特定のロードバランサ タイプの作成を制限する場合は、ロードバランサの作成を制限する組織のポリシーを使用します。
リージョン クラスタを使用しワークロードを分散して高可用性を実現する
リージョン クラスタでは、クラスタのコントロール プレーンとノードが複数のゾーンに分散されるため、クラスタ内のアプリケーションの可用性を向上させることができます。
ただし、ゾーン障害が発生した場合でも可能な限り最適なユーザー エクスペリエンスを提供するには、クラスタ オートスケーラーを使用して、クラスタが必要な負荷をいつでも処理できるようにします。また、Pod のアンチアフィニティを使用して、特定の Service の Pod が複数のゾーンでスケジュールされるようにすることも可能です。
高可用性とコスト最適化のためにこれらの設定を構成する方法については、高可用性 GKE クラスタのベスト プラクティスをご覧ください。
Cloud Logging と Cloud Monitoring を使用してネットワーク ポリシー ロギングを有効にする
可視性と監査の要件は組織によって異なりますが、ネットワーク ポリシー ロギングを有効にすることをおすすめします。この機能は GKE Dataplane V2 でのみ使用できます。ネットワーク ポリシー ロギングは、ポリシーの適用と Pod のトラフィック パターンを可視化します。ネットワーク ポリシー ロギングには費用がかかります。
バージョン 1.14 以降を使用する GKE クラスタの場合、Logging と Monitoring はどちらもデフォルトで有効になっています。Monitoring は、GKE クラスタ用のダッシュボードを提供します。また、VPC Flow Logs の GKE アノテーションも有効になります。デフォルトでは、Logging はクラスタにデプロイされたすべてのワークロードのログを収集しますが、システムのみのログオプションもあります。GKE ダッシュボードを使用して、アラートの監視と設定を行います。Autopilot モードで作成されたクラスタの場合、モニタリングとロギングは自動的に有効になり、構成はできません。
Google Cloud Observability では費用が発生します。