Google PCNE: GKE、コンテナ、アプリケーション ネットワーキング — 学習ガイド

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Network Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Kubernetes Engine (GKE) は、Google Cloudのネットワーキングと密接に統合されています。信頼性とセキュリティを考慮した設計には、VPCネイティブのIPアドレッシング、プライベートコントロールプレーン、エグレス、north-southおよびeast-westトラフィック、ポリシー適用、マルチクラスタ構成の理解が必要です。このセクションでは、Google Cloud上のコンテナとアプリケーションネットワーキングに関する設計ガイダンス、運用上の考慮事項、および一般的な障害モードについて説明します。

GKEのIPアーキテクチャとプライベートクラスタ

VPCネイティブクラスタ

• VPCサブネット内の2つのセカンダリ範囲を持つエイリアスIPを使用します。1つはPod用（PodCIDR）、もう1つはService用（ServiceCIDR）です。これにより、ノードでのiptablesベースのSNATが回避され、NEGによるコンテナネイティブのロードバランシングが可能になり、ルートベースのクラスタよりも優れたスケーラビリティが得られます。
• サイズ設定のガイドライン:
  • Pods: ノードあたりのPod数 × 最大ノード数に、ヘッドルーム（20～30%）を加えた数を割り当てます。例えば、現在の10ノード × 20 Podで、100 × 200への増加を見込む場合、/17のPod範囲が推奨されます。Serviceは、2000以上のサービスに対して/21で収まることが多いです。
  • Services: 各ClusterIPは1つのIPを消費します。ヘッドレスからClusterIPへの移行やアドオンのためのヘッドルームを考慮に入れます。
• 障害モード:
  • Pod IPの枯渇: PodがPending状態のままになるか、CNI/IPAMエラーが表示されます。セカンダリPod範囲をスケールするか、ノードあたりの最大Pod数を減らしてから、ノードを再作成します。
  • Service IPの枯渇: 新しいServiceでClusterIPの割り当てに失敗します。Serviceのセカリ範囲を拡張します。
  • エイリアス範囲の重複: クラスタの作成が失敗するか、ルーティングのブラックホールが発生します。他のサブネットやピアリングされたVPCと重複がないことを確認します。

プライベートクラスタ、コントロールプレーンアクセス、ノードのエグレス

• プライベートクラスタは、コントロールプレーンのエンドポイントを、プロデューサーピアリングを介してVPCからのみ到達可能なプライベートなRFC1918アドレスに制限します。ノードは外部IPを必要としません。
• 運用担当者は、以下から選択します:
  • プライベートエンドポイントのみ: コントロールプレーンはVPCサブネットおよび接続されたネットワークから到達可能です。到達するには、踏み台サーバーまたはPrivate Service Connectを使用したCloud Shellを使用します。
  • 承認済みネットワークを持つパブリックエンドポイント: 特定の送信元CIDRによって制限されたパブリックIPでコントロールプレーンを公開します。これは便利ですが、公開範囲が広がるため、厳格なCIDRスコープと強力な管理者ID制御と組み合わせてのみ使用してください。
• ノードのエグレス:
  • 外部IPを持たないノードには、Cloud NATを介してインターネット向けのエグレスを提供します。これにより、ノードをプライベートに保ちながら、OSの更新、外部レジストリからのコンテナイメージのプル、パートナーAPIへのアクセスが可能になります。
  • 外部IPなしでGoogle APIやArtifact/Container Registryにアクセスするには、ノードのサブネットでPrivate Google Access (PGA) を有効にします。PGAは、Google API/レジストリへのトラフィックを、パブリックな送信元IPなしでGoogleのエッジに解決し、ルーティングします。イメージのプルにはPGAが推奨されます。Google以外へのエグレスも必要な場合は、Cloud NATと組み合わせます。
  • サードパーティのファイアウォール経由で0.0.0.0/0を送信する場合でも、PGAを有効にし、Google APIのVIP範囲への静的ルートをデフォルトのインターネットゲートウェイに追加して、Googleサービスがファイアウォールをバイパスするようにします。

スケーリングとIPのトラブルシューティング

• サブネットのセカンダリ範囲レベルでエイリアスIPの消費量を監視します。IPアドレスの逼迫が高まった場合:
  • セカンダリ範囲のサイズを増やします（より大きな範囲を追加し、必要に応じてクラスタを再作成するか、ワークロードを移行します）。
  • ノードあたりのIP使用量とスケジューリングの断片化のバランスを取るために、ノードあたりの最大Pod数を調整します。
  • 放置されたServiceを整理します。ヘッドレスServiceはClusterIPを割り当てませんが、ClusterIPに変換するとIPを消費します。
• 共有VPC、VPCピアリング、またはマルチクラスタサービスを使用する際に再IP化を避けるため、重複しないセカンダリ範囲で複数リージョンへの拡張を計画します。

Ingress、Gateway API、Service、およびポリシー

Serviceとロードバランサー

• Serviceタイプ:
  • ClusterIP: クラスター内アクセスのみ。東西トラフィックはkube-proxyまたはdataplane v2を使用します。
  • NodePort: 各ノードにポートを割り当てます。多くのLBでバックエンドとして使用されますが、インターネットに直接公開することは避けてください。
  • LoadBalancer: クラウドロードバランサーをプロビジョニングします。外部または内部のL4ロードバランサーはTCP/UDPをサポートし、必要に応じてセッションアフィニティのClientIPが複数のプロトコルにまたがるスティッキネスを提供します。
• コンテナネイティブのロードバランシングではNetwork Endpoint Groups (NEGs) を使用し、ロードバランサーがPodのIP:ポートを直接ターゲットにします。これにより、ヘルスシグナリングが改善され、ノードホップが削減されます。GKEでは、GKE Pod NEGs (GCE_POD) を使用します。他のNEGタイプには、VM_IP_PORT、Internet FQDN、PSCなどがあります。
• GKE IngressとGateway API:
  • Ingressは、Googleのグローバル外部HTTP(S)ロードバランサーまたはリージョン内部HTTP(S)ロードバランサーを使用したHTTP(S)の南北トラフィックに対して安定しています。コントローラーは、標準的なパターンに対してヘルスチェックとファイアウォールルールを自動的にプログラムします。
  • Gateway APIは、GatewaysとHTTPRoutes/TCPRoutesを使用して、より表現力豊かなモデルを提供します。マルチテナント構成、高度なルーティング、環境間での一貫した仕様をサポートします。将来性を確保するためにはGateway APIを選択し、シンプルさと互換性が重要な場合はIngressを使用します。

クライアント制限とヘルスチェック

• 特定のソースレンジにクライアントを制限するには、L4ではバックエンドインスタンスをターゲットとするVPCファイアウォールルールを使用するか、L7ではHTTP(S)ロードバランサー上のCloud Armorポリシーを使用します。
• ヘルスチェックが成功するように、GoogleヘルスチェッカーのソースレンジからバックエンドターゲットまたはPodへのアクセスを常に許可してください。一部のデプロイメントでは、GKEがk8s-fwルールを自動作成します。制限的なルールを追加する場合は、ヘルスチェッカーのレンジに対する明示的な許可を維持してください。
• L4バックエンドのアプローチ例: ノードに「application」タグを付け、許可されたクライアントCIDRとGoogleヘルスチェックレンジからtcp:NodePortへの許可ファイアウォールルールを作成し、それ以外のすべてのソースに対しては、より優先度の高い拒否ルールを作成して、パケット破棄を監視するためにロギングを有効にします。

ネットワークポリシーとdataplane v2

• Kubernetes NetworkPolicyを有効にし、GKE Dataplane V2を使用してeBPFベースの強制を行うことで、iptablesベースのエンジンと比較してパフォーマンスと忠実度を向上させます。
• ベースラインのポスチャ:
  • namespaceに対してegressとingressをデフォルトで拒否し、PodからPod、PodからServiceへのフローを明示的に許可します。
  • namespaceとpodSelectorsを使用してサービスティア（フロントエンド、バックエンド、データ）を作成し、必要最小限の方向とポートのみを許可します。
• セキュアなサービス通信:
  • クラスター内のゼロトラストには、サービスメッシュによるmTLSの提供が最適です。NetworkPolicyはL3/L4を処理しますが、IDを認証することはできません。
  • 南北トラフィックには、HTTP(S) LBにCloud Armorをアタッチして、WAF、レート制限、およびプレビューモードを使用し、ユーザーに影響を与えることなく、疑わしい攻撃者に対する拒否をテストします。

障害モードとトレードオフ

• NetworkPolicyが多すぎたり、範囲が広すぎたりすると、予期せぬパケット破棄が発生する可能性があります。段階的なロールアウト、ロギング、ポリシー解析ツールで検証してください。
• NodePortと外部ファイアウォールルールに依存する構成は脆弱です。マネージドロードバランサーとPod NEGの使用を推奨します。
• Gateway APIは豊富な機能をもたらしますが、コントローラーの成熟度とチームの習熟度が必要です。ヘッダーベースのルーティングやmTLSパススルーなどの機能は、リリースチャネルごとに検証してください。

マルチクラスタ、サービスメッシュ、アイデンティティ

マルチクラスタサービスとフリートネットワーキング

• フリートにクラスタを登録して Multi-Cluster Services (MCS) を使用し、クラスタ間のサービスディスカバリとロードバランシングを実現します。各クラスタからサービスをエクスポートすると、クライアントは複数のクラスタにまたがるエンドポイントによってバックアップされた単一のDNS名を解決します。
• クラスタ間のトラフィックパターン:
  • 同一 VPC、異なるサブネット: トラフィックはプライベートな RFC1918 経由で流れ、コストとレイテンシが最適化されます。
  • 異なる VPC: 推移的な接続性がないプライベートでシンプルな接続には VPC Peering を使用します。組織が異なる場合やインターネット経由での暗号化が必要な場合は、Cloud VPN/Cloud Router を使用します。一元管理のためには、Shared VPC を使用して必要なサブネットのみをサービスプロジェクトに公開します。
• 障害モード:
  • CIDR の重複はルーティングをブロックします。ピアリングや VPN を設定する前に、PodCIDR と ServiceCIDR が重複しないことを確認してください。
  • DNS スプリットホライズンの問題はクラスタ間の名前解決を妨げる可能性があります。検索パスとスタブドメインを検証してください。

サービスメッシュ、East-West、オブザーバビリティ

• Anthos Service Mesh などのサービスメッシュをデプロイして、以下を実現します:
  • 強力なワークロードアイデンティティによる mTLS、トラフィックポリシー（リトライ、タイムアウト、外れ値検出）、トラフィックスプリット。
  • メッシュフェデレーションまたはマルチプライマリトポロジを使用して、クラスタ間で一貫した East-West ポリシーを適用。
  • 豊富なテレメトリ: ワークロードごとのゴールデンシグナル、リクエストトレース、ポリシー監査。
• トレードオフ:
  • サイドカーはリソースのオーバーヘッドを増加させます。アンビエントモードやサイドカーレスモードはコストを削減できますが、機能の同等性を検証する必要があります。
  • メッシュはコントロールプレーンへの依存関係を追加します。HA 構成のコントロールプレーンとグレースフルデグラデーションを考慮して設計してください。

Workload Identity、シークレット、最小権限

• Workload Identity を使用して Kubernetes Service Account (KSA) を Google サービスアカウント (GSA) にマッピングし、有効期間の長いキーを排除します。KSA に GSA のメールアドレスでアノテーションを付け、GSA には最小限の IAM ロールを付与します。
• シークレット管理:
  • CSI ドライバを使用して Secret Manager で実行時にシークレットをマウントすることを推奨します。機密データにはプレーンな Kubernetes Secret の使用を避け、もし保持する場合は CMEK を使用して保存時に暗号化します。
  • GSA レベルでシークレットやバケットへの最小権限アクセスを付与します。プロジェクト全体のロールは避け、該当する場合は storage.objectViewer のようなリソースレベルのロールにスコープを絞ります。

回復性とセキュアなプラットフォーム設計に関する考慮事項

• 高可用性のためにリージョンクラスタを使用し、ノードを複数のゾーンに分散させます。North-South トラフィックには、グローバルなユーザーへのレイテンシを最小化するために、グローバル HTTP(S) ロードバランシングを使用します。
• コントロールプレーンの接続性: プライベートコントロールプレーンを選択します。承認済みネットワーク (Authorized Networks) を使用して厳密に必要とされる場合を除き、パブリックへの公開は避けてください。
• 下り（Egress）: 外部 IP を持たないノードに Cloud NAT と PGA (Private Google Access) を組み合わせることで、セキュリティと機能性のバランスを取ります。
• オブザーバビリティ: ファイアウォールロギング、VPC フローログ、メッシュテレメトリを有効にして、ポリシーによるパケット破棄やレイテンシの急上昇を迅速に診断できるようにします。

実践的な問題シナリオ

Contoso Retail は、us-east1 と europe-west1 に 2 つのプライベート GKE リージョンクラスタを運用しています。要件は次のとおりです: ノードに外部 IP を持たせない、Ingress を企業の CIDR に限定してセキュアにする、ストアフロントサービスのグローバルな可用性を確保する、インターネットに公開せずにイメージをプルする、API 層でクラスタ間のフェイルオーバーを実現する。以前、トラフィック急増時に Pod IP の枯渇が発生しました。

アプローチ

1. 潤沢なセカンダリレンジを持つ VPC ネイティブサブネットを設計する。

   • 理由: 100 ノード × 200 Pod/ノード と 1,500 サービスをカバーし、さらに 20～30% のヘッドルームを確保するために、リージョンごとに /17 の Pod レンジと /21 の Service レンジを割り当てます。これにより、Pod IP 枯渇の再発を防ぎ、成長に伴う IP アドレスの再割り当てを回避します。

2. プライベートコントロールプレーンエンドポイントを持つプライベートクラスタを作成する。

   • 理由: コントロールプレーンの公開を VPC 内に限定します。オペレーターは管理サブネット上の踏み台サーバー (bastion) を経由して接続します。これにより、承認済みネットワーク (Authorized Networks) を使用したパブリックエンドポイントと比較して、攻撃対象領域を削減できます。

3. ノードサブネットで Cloud NAT と Private Google Access を有効にする。

   • 理由: ノードは外部 IP を持ちませんが、Artifact Registry からイメージをプルしたり、OS/パッケージのミラーにアクセスしたりする必要があります。PGA はパブリックなソース IP なしでの Google API へのアクセスを保証し、Cloud NAT は必要に応じて Google 以外の Egress トラフィックを処理します。

4. Pod NEG を使用した Gateway API を用いて、グローバル HTTP(S) Ingress を実装する。

   • 理由: 単一のグローバルエニーキャスト VIP により、世界中のユーザーのレイテンシが削減されます。GKE Pod NEG はヘルスチェックを Pod に直接送信し、障害検出を改善します。Gateway API は、インフラの Gateway とアプリ所有の Route を明確に分離します。

5. クライアントアクセスを制限し、ヘルスチェックを許可する。

   • 理由: Cloud Armor ポリシーをアタッチして、企業の CIDR のみを許可し、デフォルトで拒否するように設定します。また、プレビューモードを使用して新しいブロックを安全に評価します。さらに、VPC ファイアウォールルールで Google のヘルスチェックソースレンジからバックエンド NEG への通信を許可し、ヘルスチェックが正常な状態を維持できるようにします。

6. GKE Dataplane V2 を使用して NetworkPolicy を適用する。

   • 理由: 名前空間ごとに Ingress と Egress をデフォルトで拒否し、フロントエンドからバックエンド、バックエンドからデータベースへのポートのみを許可します。Dataplane V2 は eBPF を使用してポリシーを効率的に適用し、侵害された Pod の影響範囲 (blast radius) を縮小します。

7. フリート全体で Multi-Cluster Services を有効にする。

   • 理由: 両方のリージョンで API サービスをエクスポートし、単一の DNS を公開します。クライアントはクラスタ間の正常なエンドポイントに自動的にフェイルオーバーします。両方のクラスタがリージョンサブネットを持つ同一 VPC 内にあるため、リージョン間のトラフィックはプライベートに保たれ、オーバーヘッドは最小限に抑えられます。

8. East-West のセキュリティとオブザーバビリティのためにサービスメッシュを導入する。

   • 理由: サービス間で mTLS を強制し、リトライ/タイムアウトのバジェットを追加し、ルートごとのメトリクスとトレースを取得します。メッシュレベルのポリシーは NetworkPolicy を補完します。NetworkPolicy は L3/L4 の到達可能性を制御し、メッシュは L7 でサービスアイデンティティを認証・認可します。

9. ワークロードアイデンティティとシークレットを強化する。

   • 理由: Workload Identity を介して KSA をスコープを絞った GSA にマッピングし、レポート取得用には storage.objectViewer のような必要なロールのみを付与します。マニフェスト内の静的なシークレットを避けるため、Secret Manager CSI を通じて認証情報を配信します。

10. キャパシティとロギングのガードレールを実装する。

    • 理由: IP 使用量のバランスを取るために max-pods-per-node を慎重に設定します。セカンダリレンジの使用率と VPC フローログを監視します。許可されたパスを維持しつつ、意図しないクライアントトラフィックを表面化させるために、アプリケーションタグに対してロギングを有効にした明示的な高優先度の deny-all ファイアウォールルールを作成します。

この設計により、デフォルトでプライベートなクラスタが実現され、制御された North-South アクセス、回復力のあるマルチクラスタフェイルオーバー、原則に基づいた最小権限のアイデンティティ、そして IP 枯渇を再発させることなくスケールするデータプレーンが提供されます。

← ルーティング、Network Connectivity Center、セグメンテーション · すべてのドメイン · ネットワーク オブザーバビリティ、信頼性、トラブルシューティング →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →