Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

GKE ネットワークのオブザーバビリティのベストプラクティス

Autopilot Standard

動的な Kubernetes 環境でネットワーク接続とセキュリティポリシーを管理することは、運用上の大きな課題となります。GKE Dataplane V2 のオブザーバビリティは、プラットフォーム管理者にクラスタネットワークトラフィックのカーネルレベルの可視性を提供します。これにより、迅速なトラブルシューティング、継続的なコンプライアンス監査、事前対応型のパス検証が可能になります。

このドキュメントでは、Google Kubernetes Engine（GKE）ネットワークのオブザーバビリティの概念アーキテクチャとベストプラクティスについて説明します。これには、テレメトリースタック、トリアージのメンタルモデル、事前対応型アラートルール、Terraform 自動化、費用最適化手法が含まれます。

トラブルシューティングの手順と診断手順については、ネットワークオブザーバビリティのトラブルシューティングをご覧ください。

GKE ネットワークオブザーバビリティのメリット

GKE でオブザーバビリティ戦略を実装すると、次の主なメリットが得られます。

平均解決時間（MTTR）の短縮: eBPF を活用した指標と Hubble フローログを活用することで、ネットワークの異常をすぐに特定できます。この可視性により、アプリケーションレベルの障害、Kubernetes NetworkPolicy ブロック、VPC ファイアウォールドロップを区別できるため、デバッグサイクルを数時間から数分に短縮できます。
サイドカーなしのカーネルレベルの計測: GKE Dataplane V2 は、eBPF を使用してホスト Linux カーネル内でオブザーバビリティロジックを直接実行します。これにより、リソース集約型のサイドカープロキシやアプリケーションレベルのコード変更が不要になり、オーバーヘッドを最小限に抑え、アプリケーションのパフォーマンスを維持できます。
継続的なセキュリティコンプライアンス監査: NetworkPolicy ロギングは、すべての接続試行（ALLOW または DENY の判定）の詳細な監査ログを生成します。これらのログは、規制遵守フレームワーク（PCI-DSS、SOC 2、HIPAA など）を満たすために不可欠な、クラスタトラフィックの改ざん防止レコードを提供します。
事前対応型のパス検証: 接続テストとの統合により、ワークロードがデプロイされる前にネットワークパスをシミュレートし、GKE NetworkPolicy を静的に評価できます。これにより、構成のずれやデプロイフェーズの接続の問題を防ぐことができます。
リソースと費用の最適化: 詳細なフロートラッキングにより、Cloud NAT ポートの過剰な使用率、ゾーン間のデータ転送の急増、キャッシュに保存されていない DNS の解決パターンなどの非効率性が明らかになり、情報に基づいた容量計画と費用管理が可能になります。

GKE ネットワークオブザーバビリティのアーキテクチャ

GKE Dataplane V2 は、さまざまな運用フェーズ向けに設計された多層オブザーバビリティスタックを提供します。次の表に、コアコンポーネントとその推奨されるユースケースの概要を示します。

オブザーバビリティコンポーネント	主なユースケース	対象	データの保持	パフォーマンスのオーバーヘッド	主なテレメトリーシグナル
GKE Dataplane V2 指標	システム全体のヘルスモニタリング、傾向分析、アラート。	GKE Dataplane V2 のみ	過去のテレメトリーの保持（Cloud Monitoring と Google Cloud Managed Service for Prometheus は 30 日以上の指標とログを保存します）	無視できる（カーネルレベルの集計）	パケットとバイトのカウンタ、TCP リセット数、接続ドロップ率（`pod_flow_drop_count`）。
NetworkPolicy ログ	セキュリティポリシーの監査、過去の接続分析、コンプライアンス。	GKE Dataplane V2 のみ（`NetworkLogging` カスタムリソース構成の場合）	構成可能（Cloud Logging）	低（バッファリングされたログエクスポート）	接続メタデータ（送信元と宛先のラベル、IP アドレス、ポート）とポリシー判定（`ALLOW` または `DENY`）。
Hubble CLI と UI	ライブのインタラクティブなトラフィック分析とリアルタイムのパケットレベルのデバッグ。	GKE Dataplane V2 のみ	エフェメラル（ノードローカルリングバッファ）	低（動的に有効化）	リアルタイムのフロートレース、詳細なドロップ理由（ポリシー拒否や conntrack テーブルの飽和など）。
GKE DNS 指標	DNS の解決パフォーマンス、キャッシュ効率、アップストリームレイテンシをモニタリングします。	すべてのクラスタ	長期（Cloud Monitoring）	最小	DNS リクエスト数、キャッシュヒット率とミス率、アップストリーム転送レイテンシ、同時実行上限の拒否。
接続テスト	デプロイ前のパス検証と静的構成監査。	すべてのクラスタ	該当なし（オンデマンドシミュレーション）	なし（静的にシミュレート）	シミュレートされた NetworkPolicy 評価を含む、シミュレートされたパケットルーティングパス。
VPC フローログ	ノード間トラフィックと外部トラフィックの監査、セキュリティフォレンジック、費用分析。	すべてのクラスタ	構成可能（Cloud Logging または BigQuery）	なし（構成可能なサンプリングレート）	5 タプル接続の詳細、送信されたバイト数とパケット数、GKE メタデータ（Namespace、ワークロード、Service）、RTT（TCP の場合）。
Flow Analyzer	SQL クエリを記述せずに、VPC トラフィックの視覚的な分析、トップトーカーの特定、クロスゾーン費用の分析を行います。	すべてのクラスタ	オブザーバビリティ分析バケットの保持に依存する	なし（分析 UI）	GKE ワークロードまたはサービス別にグループ化されたトラフィック量とレイテンシの集計。

上記の表で、パフォーマンスオーバーヘッドが「無視できる」とは、トラフィック量やシステム規模に関係なく、コンポーネントが最小限のリソースフットプリント（通常は 0.1 vCPU 未満と最小限のメモリ）内に厳密に収まることを意味します。低コンポーネントは、標準条件では最小限のフットプリントを維持しますが、トラフィック密度に応じて動的にスケーリングします。高スループットのシナリオでは、リソース使用量は最大 2 個の vCPU と数百メガバイトのメモリまでスケールアップできます。

GKE オブザーバビリティのメンタルモデルとトリアージループ

ネットワークの異常を効果的にトラブルシューティングするには、運用範囲に適したテレメトリーシグナルを選択し、一貫したトリアージ方法に従う必要があります。

適切なテレメトリーソースを選択する

複数のテレメトリーソースが利用可能な場合は、現在の運用タスクに適したツールを選択します。

テレメトリーソース	回答	推奨用途	Google Cloud destination
GKE Dataplane V2 指標	どのようなことが、どの程度の規模で発生しているか。	ダッシュボード、アラート、キャパシティプランニング。	Cloud Monitoring（`prometheus.googleapis.com`）
NetworkPolicy ログ	GKE 内で接続がブロックされたのはなぜですか？	セキュリティ監査とセキュリティポリシーの根本原因分析。	Cloud Logging（`policy-action` ログ）
VPC フローログ	Pod から出た後、このトラフィックはどうなりましたか？	ワークロード間の過去のトラフィック分析、ゾーン間のデータ転送料金、VPC レベルのドロップの属性。	Cloud Logging とオブザーバビリティ分析（`vpc_flows` ログ）
Hubble CLI と UI	現在ノードを通過しているものは何ですか？	ライブデバッグ、tcpdump の代替、アクティブなインシデント。	エフェメラルリングバッファ（Hubble CLI）
接続テスト	トラフィックは正常に転送されますか？	アクティブなデータプレーンのプローブと経路の分析: VPC ファイアウォール、ルート、GKE ノード間のネットワーク到達性を検証し、正確なドロップポイントを特定します。	Network Intelligence Center（シミュレーション）

標準化されたトラブルシューティングループ

この繰り返し可能なワークフローを使用して、GKE ネットワーキングインシデントをトリアージします。

異常を検出する: Cloud Monitoring アラート（TCP リセットの急増、DNS 同時接続数の上限超過、パケットドロップなど）で問題を特定します。
階層を分離する: GCE VM ベースラインテスト（ノードレベルのレイテンシと CNI ボトルネックのトリアージを参照）を実行して、ブロックが GKE クラスタ内（CNI、NetworkPolicy、IP マスカレード）にあるか、VPC 内（ファイアウォールルール、ルーティング、Cloud NAT）にあるかを判断します。
根本原因を調査する: フローの詳細な分析を行います。
- ライブインシデントの場合: Hubble CLI（hubble observe）を使用してリアルタイムフローをストリーミングし、ドロップの理由を特定します。
- 過去または断続的な問題の場合: Cloud Logging で NetworkPolicy ログまたは VPC Flow Logs をクエリします。
修復を検証する: シミュレーションされた接続テストを実行して、パスが静的に許可されていることを確認し、指標ダッシュボードをチェックして、ドロップ率がゼロに戻ったことを確認します。

プロアクティブなネットワークモニタリングとアラート

高可用性を維持するには、プラットフォーム管理者は Cloud Monitoring でアラートポリシーを設定し、ワークロードに影響を与える前にネットワークのパフォーマンス低下を特定する必要があります。

パケットドロップの急増に関するアラート

ネットワークフローのドロップ数の異常な増加は、通常、セキュリティポリシーの構成ミスまたはノードレベルの接続トラッキング（conntrack）の枯渇を示します。

Prometheus クエリ（PromQL）:

sum(rate(pod_flow_egress_flows_count{verdict="DROPPED"}[5m])) by (source) > 10

推奨される対応: パケットドロップと NetworkPolicy ブロックを診断するを参照して、パケットロスの原因となっている特定の GKE NetworkPolicy または eBPF ドロップの理由を特定します。

DNS 飽和に関するアラート

CoreDNS または NodeLocal DNSCache が同時クエリの上限に達すると、後続の DNS ルックアップが拒否され、アプリケーションのタイムアウトが断続的に発生します。

Prometheus クエリ（PromQL）:

sum by (cluster_name) (rate(kubernetes_io_networking_dns_kubedns_max_concurrent_rejected_request_count[5m])) > 0

推奨される対応策: kube-dns レプリカ数をスケーリングするか、NodeLocal DNSCache を実装して解決負荷を分散します。詳細な手順については、DNS 解決の失敗を診断するをご覧ください。

TCP リセットの急増に関するアラート

TCP リセットパケットの急増は、バックエンドサービスが接続を拒否していることを示していることが多く、アプリケーションクラッシュループやソケットキューの飽和が原因である可能性があります。

Monitoring Query Language（MQL）:

fetch prometheus_target
| metric 'prometheus.googleapis.com/hubble_tcp_flags_total/counter'
| filter (metric.flag == 'RST')
| align rate(1m)
| every 1m
| group_by [metric.source, metric.destination], sum(val())
| condition val() > 50

推奨される対応: トラフィックの不均衡と TCP リセットを診断するを参照して、接続のスティッキー性またはアプリケーションキューの飽和状態を調査します。

CI/CD での自動パス検証

接続テストをデプロイパイプラインに統合して、本番環境トラフィックを転送する前にネットワークパスを静的に検証します。gcloud CLI を使用して、新しくデプロイされたワークロードがポリシーのブロックなしで外部依存関係（データベースや API など）にアクセスできることを確認します。

コマンドの例:

gcloud network-management connectivity-tests create test-prod-db-egress \
    --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/my-app-pod \
    --destination-ip-address=10.240.0.100 \
    --protocol=TCP \
    --destination-port=5432

ビジュアルフロー分析用にオブザーバビリティ分析を有効にする

VPC トラフィックフローの SQL なしでの視覚的な分析を有効にするには、GKE ログバケット（通常は _Default バケット）をアップグレードして、オブザーバビリティ分析を使用します。これにより、プラットフォーム管理者は Flow Analyzer を活用して、トラフィック分配とデータ転送費用を調査できます。詳細については、Flow Analyzer を使用してクラスタトラフィックの費用とパフォーマンスを分析するをご覧ください。

Terraform 自動化: Observability-as-Code

このオブザーバビリティアーキテクチャを一貫して実装し、手動設定のエラーを回避するには、次の Terraform 構成を使用してテレメトリーパイプラインをデプロイします（google-beta プロバイダが必要です）。

# Configure the VPC Subnet with VPC Flow Logs enabled and all metadata included
resource "google_compute_subnetwork" "gke_subnet" {
  name          = "gke-subnet"
  ip_cidr_range = "10.0.0.0/20"
  region        = "us-central1"
  network       = google_compute_network.custom.id

  # Enable VPC Flow Logs. flow_sampling is the secondary sampling rate, which
  # applies to flow log entries after they are generated. The primary packet
  # sampling rate is dynamic and isn't configurable.
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.5 # Default rate; satisfies the LIGHT org policy tier
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# Configure GKE Cluster with Dataplane V2, Intranode Visibility, and Hubble
resource "google_container_cluster" "primary" {
  provider   = google-beta
  name       = "gke-observability-cluster"
  location   = "us-central1"
  network    = google_compute_network.custom.id
  subnetwork = google_compute_subnetwork.gke_subnet.id

  # Enable Dataplane V2 (Required for all advanced telemetry)
  datapath_provider = "ADVANCED_DATAPATH"

  # Enable Intranode Visibility (ensures local node pod-to-pod traffic hits the VPC)
  enable_intranode_visibility = true

  # Enable Managed Service for Prometheus (GMP)
  monitoring_config {
    enable_components = ["SYSTEM_COMPONENTS"]
    managed_prometheus {
      enabled = true
    }

    # Enable Dataplane V2 Flow Observability (Hubble Relay and metric exposure)
    advanced_datapath_observability_config {
      enable_metrics = true
      enable_relay   = true
    }
  }
}

# Upgrade the Default log bucket to use Log Analytics (required for Flow Analyzer)
resource "google_logging_project_bucket_config" "default_analytics" {
  project          = var.project_id
  location         = "global"
  bucket_id        = "_Default"
  enable_analytics = true
}

# Define a baseline static path validation test (Pod to external internet gateway)
resource "google_network_management_connectivity_test" "pod_to_internet" {
  name = "pod-to-internet-egress"
  source {
    gke_pod = "projects/${var.project_id}/locations/us-central1/clusters/${google_container_cluster.primary.name}/k8s/namespaces/prod/pods/my-app-pod"
  }
  destination {
    ip_address = "8.8.8.8"
    port       = 443
  }
  protocol = "TCP"
}

コストの最適化とノイズリダクション

ネットワークテレメトリー（指標とログ）では、大量のデータが生成されるため、取り込みとストレージの費用が高くなる可能性があります。次の戦略を使用して、重要なトラフィックの可視性を損なうことなくテレメトリー収集を最適化します。

許可された接続ログを無効にする

デフォルトでは、NetworkPolicy ロギングは許可された接続と拒否された接続の両方をキャプチャします。許可された接続がログボリュームの大部分を占めている（トラフィックの 99% 以上を占めることが多い）。クラスタの NetworkLogging 構成を更新して、拒否された接続（ドロップ）のみをキャプチャすると、ロギング費用を大幅に削減できます。

次のマニフェストを network-logging-config.yaml として保存します。

apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: false # Disable logging for allowed traffic
      delegate: false
    deny:
      log: true  # Keep logging for blocked traffic (critical for security/triage)
      delegate: false

構成を適用します。

kubectl apply -f network-logging-config.yaml

アノテーションによるロギングの委任

きめ細かい費用管理を行うには、NetworkLogging カスタムリソースで delegate: true を設定して、ロギングをアノテーションに委任します。この構成により、次のことが保証されます。

一致する NetworkPolicy にアノテーション policy.network.gke.io/enable-logging: "true" がある場合にのみ、許可されたトラフィックがログに記録されます。
拒否されたトラフィックは、policy.network.gke.io/enable-deny-logging: "true" でアノテーションが付けられた Namespace の Pod オブジェクトに対してのみロギングされます。

この構成では、ノイズが多くリスクの低いサービスを無視しながら、非常に重要なワークロード（支払いゲートウェイなど）に対してのみロギングを有効にできます。

VPC Flow Logs のサンプリングレートを調整する

Terraform 構成（または Google Cloud コンソール）で、個々のフローレコードではなくトラフィック量と費用の集計が必要なサブネットでのみ、セカンダリサンプリングレートを下げます。VPC Flow Logs はサンプリングされたパケットから合計トラフィックを推定するため、バイト数とパケット数は、低いレートで費用分析に使用できます。constraints/compute.requireVpcFlowLogs 組織のポリシーの ESSENTIAL 階層を満たす最小レートである 0.1 より低いレートを flow_sampling に設定しないでください。

resource "google_compute_subnetwork" "gke_subnet" {
  # ... other subnet configs ...
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.1 # ESSENTIAL tier: volume and cost analysis, not per-flow troubleshooting
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

次の表に、セカンダリサンプリングレートと、対応する constraints/compute.requireVpcFlowLogs 組織のポリシーの階層をまとめます。

セカンダリサンプリングレート	組織のポリシーの階層	使用する場面
`1.0`	`COMPREHENSIVE`	フロー単位のフォレンジックまたはセキュリティ監査の継続的な要件があるクラスタ。インシデント後にレートを上げても、キャプチャされなかったフローは復元されないため、サブネットを構成するときにこのレートを選択します。
`0.5`（デフォルト）	`LIGHT`	トラブルシューティングを行うクラスタをバックアップするサブネット。これがデフォルトのレートであり、推奨されるベースラインです。
`0.1`	`ESSENTIAL`	個々のフローではなく、トラフィック量と費用の集計が必要なサブネット。

Cloud Logging の除外を適用する

Cloud Logging シンクレベルで、ノイズの多いログや無関係なログ（kube-system 内部トラフィックなど）を直接除外します。_Default シンクに除外フィルタを追加して、内部メタデータまたはシステム Pod ログを削除します。

resource.type="gce_subnetwork" AND
log_name:"projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND
jsonPayload.src_gke_details.pod.pod_namespace="kube-system"

ベストプラクティスと運用に関するヒント

クラスタテレメトリーパイプラインをデプロイして維持する場合は、次の運用ガイドラインを考慮してください。

GKE Dataplane V2 フローのオブザーバビリティをオンデマンドで有効にする: フローのオブザーバビリティ（hubble-relay）では、わずかなオーバーヘッドが発生する可能性があります。本番環境クラスタでは、デバッグセッション中に有効にして、後で無効にすることで、ノードのリソース消費を最小限に抑えることができます。
```
gcloud container clusters update CLUSTER_NAME \
    --enable-dataplane-v2-flow-observability \
    --location=LOCATION
```
ノード内の可視化を有効にする: デフォルトでは、同じノード上の 2 つの Pod オブジェクト間のトラフィックはノードから離れないため、VPC Flow Logs に表示されません。ノード内可視性は、Autopilot クラスタではデフォルトで有効になっており、GKE Dataplane V2 を使用する Standard クラスタを含む Standard クラスタではデフォルトで無効になっています。ノード内の可視化を有効にすると、このトラフィックが VPC を経由してヘアピンされます。これにより、VPC ファイアウォールルールとフローログが常に適用されます。
Service VIP の解決動作を理解する: Kubernetes Service 仮想 IP（VIP）がバックエンド Pod の IP アドレスに解決されると、トランスポートレイヤ（OSI レイヤ 4）の指標は、それを Pod 間トラフィックとしてカウントします。どのサービス VIP が最初にターゲットにされたかをトレースするには、接続ハンドシェイク中に Hubble CLI のライブフローを使用します。
指標とログのタイムスタンプを調整する: インシデントを調査するときは、Cloud Monitoring の指標の急増を、Cloud Logging または Hubble CLI でログをクエリする正確な時間枠と関連付けて、同じイベントを分析していることを確認します。

GKE ネットワークのオブザーバビリティのベスト プラクティス コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

GKE ネットワーク オブザーバビリティのメリット

GKE ネットワーク オブザーバビリティのアーキテクチャ

GKE オブザーバビリティのメンタルモデルとトリアージ ループ

適切なテレメトリー ソースを選択する

標準化されたトラブルシューティング ループ

プロアクティブなネットワーク モニタリングとアラート

パケット ドロップの急増に関するアラート