GKE 網路觀測的最佳做法

在動態 Kubernetes 環境中管理網路連線和安全政策，會帶來重大的作業挑戰。GKE Dataplane V2 觀測功能可讓平台管理員掌握叢集網路流量的 Kernel 層級資訊，有助於快速排解問題、持續稽核法規遵循情形，以及主動驗證路徑。

本文將說明 Google Kubernetes Engine (GKE) 網路可觀測性的概念架構和最佳做法，包括遙測堆疊、分流的心智模型、主動式警報規則、Terraform 自動化，以及成本最佳化技術。

如需逐步疑難排解說明和診斷程序，請參閱「排解網路可觀測性問題」。

GKE 網路觀測功能的優點

在 GKE 中實作可觀測性策略，可帶來下列主要優勢：

  • 加快平均解決時間 (MTTR)：運用 eBPF 支援的指標和 Hubble 流量記錄，您可以立即找出網路異常狀況。這項功能可讓您區分應用程式層級的失敗、Kubernetes NetworkPolicy 封鎖和 VPC 防火牆捨棄，將偵錯週期從數小時縮短至數分鐘。
  • 無附屬容器的核心層級檢測：GKE Dataplane V2 會使用 eBPF，直接在主機 Linux 核心中執行可觀測性邏輯。這樣一來，您就不需要耗用大量資源的 Sidecar Proxy，也不必修改應用程式層級的程式碼，確保將負擔降到最低，同時維持應用程式效能。
  • 持續稽核安全法規遵循情形：NetworkPolicy 記錄會為每次連線嘗試 (ALLOW 或 DENY 的判決) 產生詳細的稽核記錄。這些記錄提供叢集流量的防竄改記錄，對於滿足法規遵循架構 (例如 PCI-DSS、SOC 2 和 HIPAA) 至關重要。
  • 主動路徑驗證：與 Connectivity Tests 整合後，您就能模擬網路路徑，並在部署工作負載前靜態評估 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 暫時性 (節點本機環狀緩衝區) 低 (動態啟用) 即時流程追蹤、詳細的捨棄原因 (例如政策拒絕或連線追蹤表飽和)。
GKE DNS 指標 監控 DNS 解析效能、快取效率和上游延遲時間。 所有叢集 長期 (Cloud Monitoring) 可忽略 DNS 要求數、快取命中和未命中率、上游轉送延遲時間，以及並行限制拒絕。
Connectivity Tests 部署前路徑驗證和靜態設定稽核。 所有叢集 不適用 (隨選模擬) 無 (靜態模擬) 模擬封包路由路徑，包括模擬 NetworkPolicy 評估。
虛擬私有雲流量記錄 節點間和外部流量稽核、安全鑑識和成本分析。 所有叢集 可設定 (Cloud Logging 或 BigQuery) 無 (可設定取樣率) 5 元組連線詳細資料、傳送的位元組和封包、GKE 中繼資料 (命名空間、工作負載、服務) 和 RTT (適用於 TCP)。
Flow Analyzer 以視覺化方式分析虛擬私有雲流量、找出高流量來源，以及分析跨區域成本，不必編寫 SQL 查詢。 所有叢集 視 Observability Analytics bucket 保留期限而定 無 (分析 UI) 按照 GKE 工作負載或服務分組的匯總流量和延遲時間。

在上表中，「可忽略」的效能負荷表示無論流量或系統規模為何，元件都會嚴格維持在最低資源用量 (通常 <0.1 vCPU 和最低記憶體)。低元件在標準情況下會維持最小的足跡，但會隨著流量密度動態調整。在高輸送量情境下，資源用量最多可擴充至 2 個 vCPU 和數百 MB 的記憶體。

GKE 觀測能力心智模型和分類迴圈

如要有效排解網路異常問題，您必須為作業範圍選取適當的遙測信號，並遵循一致的分類方法。

選擇合適的遙測來源

有多個遙測來源可供選擇，請選擇適合目前作業工作的工具：

遙測來源 解答 適用情況 Google Cloud 目的地
GKE Dataplane V2 指標 發生了什麼事？規模有多大？ 資訊主頁、警示和容量規劃。 Cloud Monitoring (prometheus.googleapis.com)
NetworkPolicy 記錄 為什麼 GKE 內部的連線遭到封鎖？ 安全稽核和安全政策根本原因分析。 Cloud Logging (policy-action 記錄)
虛擬私有雲流量記錄 離開 Pod 後，這項流量發生了什麼事？ 工作負載之間的歷來流量分析、可用區間資料移轉費用，以及 VPC 層級的捨棄歸因。 Cloud Logging 和 Observability Analytics (vpc_flows 記錄)
Hubble CLI 和 UI 目前通過節點的資料為何？ 即時偵錯、tcpdump 替代方案和進行中的事件。 暫時性環形緩衝區 (Hubble CLI)
Connectivity Tests 流量是否能順利傳輸？ 主動探查資料平面和路徑分析：驗證可連線性，並找出虛擬私有雲防火牆、路徑和 GKE 節點的確切捨棄點。 Network Intelligence Center (模擬)

標準化疑難排解迴圈

使用這個可重複的工作流程，對任何 GKE 網路事件進行分類：

  1. 偵測異常狀況：透過 Cloud Monitoring 警告找出問題 (例如 TCP 重設次數暴增、DNS 並行限制遭拒，或封包遺失)。
  2. 隔離層級：執行 GCE VM 基準測試 (請參閱「節點層級延遲和 CNI 瓶頸的分類」)，判斷封鎖是否位於 GKE 叢集 (CNI、NetworkPolicy、IP 位址偽裝) 內，或位於 VPC (防火牆規則、路由、Cloud NAT) 外。
  3. 調查根本原因：詳細分析流程：
    • 即時事件：使用 Hubble CLI (hubble observe) 串流即時流量，並找出捨棄原因。
    • 如要瞭解過去或間歇性問題：請在 Cloud Logging 中查詢 NetworkPolicy 記錄或虛擬私有雲流量記錄。
  4. 驗證修正措施：執行模擬的 Connectivity Tests 測試，確認路徑已靜態允許，然後檢查指標資訊主頁，確認丟包率已恢復為零。

主動監控網路並發出警告

為維持高可用性，平台管理員應在 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 重設封包的尖峰通常表示後端服務拒絕連線，可能是因為應用程式異常終止迴圈或通訊端佇列飽和。

  • 監控查詢語言 (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 中自動驗證路徑

將 Connectivity Tests 整合至部署管道，在路由傳送實際工作環境流量前，先靜態驗證網路路徑。使用 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

啟用 Observability Analytics，進行視覺化流程分析

如要啟用虛擬私有雲流量的視覺化分析 (不需使用 SQL)，請升級 GKE 記錄檔 bucket (通常是 _Default bucket)，以使用 Observability Analytics。平台管理員可運用 Flow Analyzer 調查流量分配情形和資料傳輸費用。詳情請參閱「使用 Flow Analyzer 分析叢集流量成本和效能」。

Terraform 自動化：可觀測性即程式碼

如要一致地實作這項可觀測性架構，並避免手動設定錯誤，請使用下列 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設定，只擷取遭拒連線 (捨棄)，大幅降低記錄費用：

  1. 將下列資訊清單儲存為 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

  2. 套用設定：

    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" 註解的命名空間中，系統才會記錄遭拒的 Pod 物件流量。

這項設定可讓您只為高度關鍵的工作負載 (例如付款閘道) 啟用記錄功能，同時忽略低風險的服務。

調整虛擬私有雲流量記錄取樣率

在 Terraform 設定 (或 Google Cloud 控制台) 中，只在需要流量和費用匯總資料 (而非個別流量記錄) 的子網路上，降低次要取樣率。由於虛擬私有雲流量記錄會根據取樣封包估算總流量，因此位元組和封包計數仍可用於以較低的速率進行成本分析。請勿將flow_sampling費率設為低於0.1，也就是滿足ESSENTIAL層級constraints/compute.requireVpcFlowLogs機構政策的最低費率：

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

  • 啟用節點內瀏覽功能：根據預設，相同節點上兩個 Pod 物件之間的流量不會離開節點，因此虛擬私有雲流量記錄無法看到這類流量。Autopilot 叢集預設會啟用「掌握節點內流量」功能，Standard 叢集則預設會停用這項功能，包括使用 GKE Dataplane V2 的 Standard 叢集。啟用節點內可視性會透過 VPC 轉送此流量，並確保 VPC 防火牆規則和流量記錄檔會持續套用。

  • 瞭解 Service VIP 解析行為：Kubernetes Service 虛擬 IP (VIP) 解析為後端 Pod IP 位址後，傳輸層 (OSI 第 4 層) 指標會將其計為 Pod 對 Pod 流量。如要追蹤原本的目標服務 VIP，請在連線交握期間使用 Hubble CLI 即時流量。

  • 比對指標和記錄的時間戳記：調查事件時，請將 Cloud Monitoring 指標的尖峰與在 Cloud Logging 或 Hubble CLI 中查詢記錄的確切時間範圍相互關聯，確保您分析的是同一事件。

後續步驟