Google Kubernetes Engine（GKE）のネットワーキングは、Pod、サービス、DNS、ロード バランシング、セキュリティ、IP アドレス管理など、幅広いコンセプトを対象としています。ドキュメントには各機能の詳細が説明されていますが、実際の問題に直面したときに、どこから始めればよいかわからないことがあります。
このドキュメントでは、一般的な課題を解決する機能とセクションにリンクすることで、GKE ネットワーキングのドキュメントをナビゲートできるようにします。各ユースケースでは、シナリオが提示され、課題が特定され、関連するドキュメントが示されます。このドキュメントは、GKE の一般的なネットワーキングの課題を理解して解決する必要があるクラウド アーキテクト、デベロッパー、運用チームを対象としています。
一般的なネットワーキングの課題をすでに理解しており、技術的な詳細をすぐに確認したい場合は、次のリソースで GKE ネットワーキングの基礎知識を習得してください。
- GKE ネットワーキングの基礎を学習する。
- GKE ネットワーキング アーキテクチャについて学習する。
- GKE ネットワーキング用語集（不明な用語を簡単に確認できます）。
ユースケース: GKE のネットワーク基盤を設計する
このユースケースでは、新しい GKE プラットフォーム用にスケーラブルで安全かつ信頼性の高いネットワーク基盤を設計する必要があるクラウド アーキテクトを対象としています。
課題: IP アドレスの枯渇を防ぐ
シナリオ: アプリケーションの複雑さと使用量が増加することが予想されるため、トラフィックの増加に対応し、Pod、サービス、ノードの増加をサポートできるネットワークを設計する必要があります。また、IP アドレスの割り当てを計画して、枯渇を回避する必要があります。
解決策: 必要なノード、Pod、Service の数を考慮して、IP アドレス指定スキームを計画します。このプランには、各 Pod に適切な IP アドレス範囲を選択し、Pod の密度を考慮して、他のネットワークとの重複を回避することが含まれます。詳細については、GKE での IP アドレスの移行を管理するをご覧ください。
課題: 多層防御セキュリティを適用する
シナリオ: クラスタ境界を保護し、ゼロトラストの Pod 間ルールを適用する必要があります。
解決策: クラスタ境界にファイアウォール ポリシーを使用します。詳細については、ネットワーク ポリシーを使用して Pod と Service 間の通信を制御するをご覧ください。
課題: さまざまなタイプのアプリケーションにトラフィックをルーティングする
シナリオ: 他のサービスやユーザーが、プライベート バックエンドやパブリック HTTP(S) アプリケーションなど、さまざまな種類のアプリケーションにアクセスできるようにする必要があります。
解決策: プライベート バックエンドに内部ロードバランサを使用します。パブリック HTTP(S) アプリケーションの場合は、Ingress または Gateway API を使用します。詳細については、GKE のロード バランシングについてをご覧ください。
チャレンジ: 可観測性ツールを使用してワークロードの問題をモニタリングし、トラブルシューティングする
シナリオ: ネットワーク トラフィックの問題を修正し、GKE トラフィック フローを理解してモニタリングし、問題を効果的に診断する必要があります。
解決策: オブザーバビリティ ツールを実装して、ネットワーク トラフィックをモニタリングし、トラブルシューティングします。詳細については、GKE Dataplane V2 のオブザーバビリティを使用してトラフィックを監視するをご覧ください。
ユースケース: 新しいマイクロサービスを公開する
このユースケースでは、GKE に新しいマイクロサービスをデプロイするデベロッパーを想定しています。マイクロサービスをクラスタ内の他のサービスからアクセスできるようにし、後で外部クライアントからアクセスできるようにする必要があります。
課題: Pod 間の通信に安定したエンドポイントを提供する
シナリオ: アプリケーションで Pod が他の Pod と通信する必要があるが、Pod で使用される動的 IP アドレスにより、この通信の信頼性が低下する。
解決策: Kubernetes Service を作成します。ClusterIP サービスは、Pod 間でロード バランシングされた安定した仮想 IP アドレスと DNS 名を提供します。詳細については、Kubernetes Service についてをご覧ください。
課題: 外部アクセス用にサービスを公開する
シナリオ: デモ用にマイクロサービスにインターネットからアクセスできるようにする必要があります。
解決策: LoadBalancer サービスを作成します。GKE は、パブリック IP アドレスを持つリージョン外部パススルー ネットワーク ロードバランサをプロビジョニングします。HTTP(S) トラフィックの場合は、レイヤ 7 機能を提供する Ingress または Gateway の使用を検討してください。詳細については、LoadBalancer Service についてをご覧ください。
課題: 永続的でユーザー フレンドリーな URL を割り当てる
シナリオ: サービスにはクライアント用の安定したドメイン名が必要です。
解決策: 静的 IP アドレスを予約し、カスタム ドメインの DNS を構成します。詳細については、静的 IP アドレスでドメイン名を構成するをご覧ください。
チャレンジ: 高度なトラフィック ルーティングを管理する
シナリオ: アプリケーションが拡大するにつれて、トラフィックのルーティング方法をより高度に制御する必要があります。たとえば、次の操作を行う必要があります。
- 複数のウェブサイト（api.example.com や shop.example.com など）を単一のロードバランサでホストして、費用を節約します。
- URL パスに基づいてリクエストをさまざまなサービスに転送します（たとえば、
/をフロントエンド ワークロードに送信し、/api/v1をバックエンド ワークロードに送信します）。 - TLS 証明書を管理して、HTTPS でアプリケーションを保護します。
- カナリア リリースを使用して、新機能を段階的に安全にデプロイします。カナリア リリースでは、完全なロールアウトの前に、トラフィックの一部を新しいバージョンに送信します。
解決策: Gateway API を使用します。GKE の Gateway API の実装は、この種の north-south トラフィックを管理するための強力で標準化された方法を提供し、パスベースのルーティング、ヘッダー マッチング、トラフィック分割などの高度な機能をサポートします。詳細については、Gateway API についてをご覧ください。
ユースケース: 成長するアプリケーションのサービス ディスカバリをスケーリングする
マイクロサービス ベースのアプリケーションのトラフィックと複雑さが増すにつれて、サービス間の DNS クエリが大幅に増加します。デベロッパーは、この環境で復元力のあるアプリケーションを構築する方法を理解する必要がありますが、スケーラブルなネットワーキング ソリューションの実装は、プラットフォーム チームと運用チームが担当することがよくあります。
課題: サービス間の通信を有効にする
シナリオ: Pod が他のサービスを確実に検出する方法を必要としている。
解決策: GKE は、Service の安定した DNS 名を解決するクラスタ内 DNS サービス（kube-dns や Cloud DNS など）を提供し、Pod 間の信頼性の高い通信を可能にします。詳細については、サービス ディスカバリと DNS をご覧ください。
課題: 大規模な DNS パフォーマンスを改善する
シナリオ: クエリ量が多く、ルックアップの遅延が発生する。
解決策: NodeLocal DNSCache を有効にします。各ノードは DNS クエリをローカルにキャッシュに保存し、レイテンシを短縮します。詳細については、NodeLocal DNSCache の設定の概要をご覧ください。
課題: VPC 全体でサービス検出を提供する
シナリオ: Compute Engine VM がクラスタ内のサービスにアクセスする必要がある。
解決策: Cloud DNS と統合して、サービス DNS レコードが VPC 全体で解決されるようにします。詳細については、GKE 向け Cloud DNS を使用するをご覧ください。
ユースケース: 多層アプリケーションを保護する
このユースケースでは、3 階層アプリケーション（フロントエンド、課金、データベース）をデプロイするプラットフォーム エンジニアリング チームに所属しており、ゼロトラスト通信を適用する必要があります。
課題: 厳格なトラフィック ルールを適用する
シナリオ: 特定のサービスのみが相互に通信できるようにします。
解決策: ネットワーク ポリシーの適用を有効にして default deny ポリシーを適用し、明示的な許可ルール（フロントエンドから課金へのトラフィックを許可する、課金からデータベースへのトラフィックを許可するなど）を定義します。詳細については、アプリケーションのネットワーク ポリシーを構成するをご覧ください。
課題: ネットワーク ポリシーの監査と検証
シナリオ: セキュリティには、実施の証明と可視性が必要です。
解決策: ネットワーク ポリシー ロギングを有効にして、許可された接続と拒否された接続を記録します。詳細については、ネットワーク ポリシーのロギングを使用するをご覧ください。
課題: サービスをコンシューマーに非公開で公開する
シナリオ: データベースや API などのバックエンド サービスを、パブリック インターネットに公開したり、VPC ピアリングの複雑さを処理したりすることなく、他の VPC ネットワークのコンシューマーからアクセスできるようにする必要があります。
解決策: Private Service Connect を使用してサービスを公開します。コンシューマーは、独自の VPC に PSC エンドポイントを作成して、サービスに限定公開で安全にアクセスできます。詳細については、Private Service Connect を使用してサービスを公開するをご覧ください。
ユースケース: 複数のクラスタで高可用性を実現する
このユースケースでは、信頼性を向上させるために、異なるリージョンにまたがる複数の GKE クラスタで e コマース企業のワークロードを実行する SRE を想定しています。
課題: クラスタ間通信を有効にする
シナリオ: 1 つのクラスタ内のサービスが、別のクラスタ内のサービスを検出して呼び出す必要があります。
解決策: GKE マルチクラスタ サービス（MCS）を使用してグローバル DNS 名を作成し、トラフィックを正常なバックエンドに自動的に転送します。詳細については、マルチクラスタ サービスをご覧ください。
課題: レジリエントなフェイルオーバーを確保する
シナリオ: 1 つのリージョン サービスが使用できなくなった場合、トラフィックを自動的に再ルーティングする必要があります。
解決策: MCS は、健全性を認識したサービス ディスカバリを提供します。これにより、クライアントは単一の DNS 名を最も近い使用可能なクラスタ内の健全なバックエンドに解決できます。このアプローチにより、復元力のあるフェイルオーバーが可能になります。詳細については、マルチクラスタ サービスをご覧ください。
ユースケース: 安全で効率的なマルチテナント GKE 環境を構築する
プラットフォーム エンジニアリング チームの一員として、複数のアプリケーション チームに GKE クラスタを提供します。ネットワーク制御の一元化、IP アドレスの節約、厳格なセキュリティの適用が必要です。
課題: ネットワーク制御を一元管理する
シナリオ: 複数のアプリチームが独自のクラスタを必要としているが、ネットワーキングは一元管理する必要がある。
解決策: 共有 VPC を使用します。ネットワーキング リソースはホスト プロジェクトに存在しますが、アプリ クラスタはサービス プロジェクトで実行されます。詳細については、共有 VPC を使用してクラスタを構成するをご覧ください。
課題: 制限のある IP アドレスを効率的に管理する
シナリオ: IP アドレス空間が限られているため、効率的に使用する必要があります。
解決策: ノードあたりの最大 Pod 数を調整し、必要に応じて Pod の IP アドレスに非 RFC 1918 範囲を使用します。詳細については、GKE での IP アドレスの移行を管理するをご覧ください。
課題: 最新の安全なデータプレーンを使用し、新しいデータプレーンでクラスタをプロビジョニングする
シナリオ:
- 企業は、要求の厳しいワークロードとゼロトラスト セキュリティ体制をサポートするために、高性能と組み込みのポリシー適用を必要としています。たとえば、ネットワーク レイテンシに敏感な大規模なマイクロサービスを実行している場合や、規制コンプライアンス要件を満たすためにマルチテナント クラスタ内のアプリケーション間に厳格なセキュリティ境界を適用する必要がある場合があります。
- クラスタは、高いパフォーマンスとセキュリティを実現するために最新のネットワーキング データプレーンを使用するように構成し、組織の一元管理されたネットワーク構造内にデプロイする必要があります。
解決策: eBPF ベースで、高性能とネットワーク ポリシーの適用が組み込まれている GKE Dataplane V2 を使用します。詳細については、GKE Dataplane V2 をご覧ください。
ユースケース: トラフィックのモニタリングとトラブルシューティング
SRE として、チェックアウト サービスが決済サービスに接続できない理由を調査しています。
チャレンジ: 接続に関する問題を解決する
シナリオ: パケットがドロップされるが、原因が不明である。
解決策: GKE Dataplane V2 のオブザーバビリティを有効にします。hubble_drop_total などの指標で、パケットが拒否されたことを確認します。詳細については、Hubble を使用したトラブルシューティングをご覧ください。
課題: ドロップされたパケットの根本原因を特定する
シナリオ: ネットワーク パケットがドロップされていることを確認したら（hubble_drop_total を使用するなど）、サービス間のトラフィックをブロックしている特定のネットワーク ポリシーを特定します。
解決策: Hubble コマンドライン インターフェースまたは UI を使用してフローをトレースします。Hubble UI には、トラフィックが視覚的に表示され、接続を拒否している構成ミスのあるポリシーがハイライト表示されます。この可視化により、チームは問題の根本原因を迅速に特定し、ポリシーを修正できます。詳細については、GKE Dataplane V2 のオブザーバビリティを使用してトラフィックを監視するをご覧ください。
エンドツーエンドのユースケース: 安全な小売アプリケーションをデプロイしてスケーリングする
このエンドツーエンドのシナリオでは、プラットフォーム エンジニアリング チームが複数のアプリケーション チーム向けに標準化された GKE プラットフォームを構築します。チームは、3 階層の小売アプリケーション（フロントエンド、請求、データベース）をデプロイして最適化します。このプロセスには、ML ワークロードのセキュリティ保護、スケーリング、パフォーマンスの向上、高度なセキュリティ アプライアンスの統合が含まれます。
次の図は、GKE にデプロイされた安全な多層小売アプリケーションのエンドツーエンド アーキテクチャを示しています。アーキテクチャは複数のフェーズを経て進化します。
- フェーズ 1: 共有 VPC と GKE Dataplane V2 を使用して基盤となる設定を構築します。
- フェーズ 2: 高可用性を実現するために、Gateway API とマルチクラスタ サービスを使用してアプリケーションを公開します。
- フェーズ 3: gVNIC と Tier 1 ネットワーキングを使用して ML タスクを高速化します。
- フェーズ 4: マルチネットワーク サポートを使用して、高度なセキュリティ アプライアンスをデプロイします。
フェーズ 1: プラットフォームの基盤を構築する
課題: 複数のアプリケーション チームのネットワーキングを一元化し、スケーリングに対応するのに十分な IP アドレスを割り当てます。
ソリューション:
- 一元管理には共有 VPC を使用します。
- スケーラビリティを確保するために、IP アドレス指定を計画します。
- 高パフォーマンスで安全なデータプレーンを実現するには、GKE Dataplane V2 を有効にします。
- Private Service Connect を使用して、GKE コントロール プレーンに安全に接続します。
フェーズ 2: アプリケーションをデプロイして保護する
課題: サービス間の信頼性の高い通信を確保し、ゼロトラスト セキュリティを適用します。
ソリューション:
- 安定した内部エンドポイント用に ClusterIP サービスを作成します。
- デフォルト拒否ベースラインと明示的な許可ルールを使用して、ネットワーク ポリシーを適用します。
フェーズ 3: アプリケーションを公開し、成長に合わせてスケーリングする
課題: トラフィックの増加に伴い、外部アクセスを提供し、DNS ルックアップのレイテンシを短縮します。
ソリューション:
- 高度なトラフィック管理のために、Gateway API を使用してフロントエンドを公開します。
- DNS を使用して静的 IP アドレスを割り当てます。
- ルックアップを高速化するために、NodeLocal DNSCache を有効にします。
フェーズ 4: 高可用性を実現し、問題をトラブルシューティングする
課題: リージョン フェイルオーバーを確保し、ドロップされたトラフィックをデバッグします。
ソリューション:
- クロスリージョン フェイルオーバーには、マルチクラスタ サービスを使用します。
- Hubble で GKE Dataplane V2 オブザーバビリティを有効にして、構成が誤っているネットワーク ポリシーを診断して修正します。
フェーズ 5: ML ワークロードを高速化する
課題: GPU ベースのモデル トレーニングのネットワーク ボトルネックを解消します。
ソリューション:
- 帯域幅を増やすには、gVNIC を有効にします。
- 最大スループットを実現するために、重要なノードで Tier 1 ネットワーキングを構成します。
フェーズ 6: 高度なセキュリティ アプライアンスをデプロイする
課題: 超低レイテンシで、管理プレーンとデータプレーンのトラフィックを分離してサードパーティのファイアウォールと IDS をデプロイします。
ソリューション:
- マルチネットワーク サポートを有効にして、複数のインターフェースを Pod に接続します。
- デバイスモード ネットワーキング（DPDK）を構成します。