GKE 网络可观测性最佳实践

在动态 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）至关重要。
  • 主动路径验证：与 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 和界面 实时互动式流量分析和实时数据包级调试。 仅限 GKE Dataplane V2 临时（节点本地环形缓冲区） 低（动态启用） 实时流量跟踪、详细的丢弃原因（例如政策拒绝或 conntrack 表饱和）。
GKE DNS 指标 监控 DNS 解析性能、缓存效率和上游延迟。 所有集群 长期（Cloud Monitoring） 可忽略 DNS 请求数、缓存命中率和未命中率、上游转发延迟时间以及并发限制拒绝次数。
连接测试 部署前路径验证和静态配置审核。 所有集群 不适用（按需模拟） 无（静态模拟） 模拟的数据包路由路径，包括模拟的 NetworkPolicy 评估。
VPC 流日志 节点间和外部流量审核、安全取证和费用分析。 所有集群 可配置（Cloud Logging 或 BigQuery） 无（可配置的采样率） 5 元组连接详细信息、发送的字节数和数据包数、GKE 元数据（命名空间、工作负载、服务）和 RTT（对于 TCP）。
Flow Analyzer 直观分析 VPC 流量、识别最活跃的通信方，以及分析跨可用区费用，而无需编写 SQL 查询。 所有集群 取决于 Observability Analytics 存储桶保留期限 无（分析型界面） 按 GKE 工作负载或服务分组的汇总流量和延迟时间。

在上表中，性能开销为可忽略不计意味着，无论流量大小或系统规模如何，组件都严格保持在最小资源占用空间（通常 <0.1 vCPU 和最小内存）内。低组件在标准条件下保持最小占用空间，但会根据流量密度动态扩缩。在高吞吐量场景下，资源使用量最多可扩容到 2 个 vCPU 和数百兆内存。

GKE 可观测性思维模式和问题排查循环

如需有效排查网络异常问题，您需要为自己的运营范围选择合适的遥测信号，并遵循一致的分诊方法。

选择合适的遥测数据源

由于有多个遥测数据源可用，请选择适合您当前运营任务的工具：

遥测数据源 回答 适用场景 Google Cloud 目的地
GKE Dataplane V2 指标 发生了什么，规模有多大？ 信息中心、提醒和容量规划。 Cloud Monitoring (prometheus.googleapis.com)
NetworkPolicy 日志 为什么 GKE 内部的连接被屏蔽？ 安全审核和安全政策根本原因分析。 Cloud Logging（policy-action 日志）
VPC 流日志 此流量离开 Pod 后会发生什么情况？ 工作负载之间的历史流量分析、可用区间数据传输费用和 VPC 级丢包归因。 Cloud Logging 和 Observability Analytics （vpc_flows 日志）
Hubble CLI 和界面 节点目前正在传递什么？ 实时调试、tcpdump 替代方案和有效事件。 临时环形缓冲区 (Hubble CLI)
连接测试 流量是否可以成功传输？ 主动数据平面探测和路径分析：验证可达性，并确定 VPC 防火墙、路由和 GKE 节点中的确切丢弃点。 Network Intelligence Center（模拟）

标准化问题排查循环

使用此可重复的工作流程来甄别任何 GKE 网络事件：

  1. 检测异常情况：通过 Cloud Monitoring 提醒（例如，TCP 重置次数激增、DNS 并发限制拒绝或丢包）识别问题。
  2. 隔离层：运行 GCE 虚拟机基准测试（请参阅针对节点级延迟和 CNI 瓶颈进行初步诊断），以确定阻塞是在 GKE 集群内部（CNI、NetworkPolicy、IP 伪装），还是在 VPC 外部（防火墙规则、路由、Cloud NAT）。
  3. 调查根本原因：对流程进行详细分析：
    • 对于实时突发事件：使用 Hubble CLI (hubble observe) 对实时 flow 进行流式处理，并确定丢弃原因。
    • 对于历史问题或间歇性问题：在 Cloud Logging 中查询 NetworkPolicy 日志或 VPC 流日志。
  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 重置数据包的峰值通常表示后端服务正在拒绝连接，这可能是由于应用崩溃循环或套接字队列饱和所致。

  • 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 中的自动化路径验证

将 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 以进行可视化流量分析

如需直观地分析 VPC 流量，而无需使用 SQL，请升级 GKE 日志存储桶（通常为 _Default 存储桶）以使用 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 对象记录被拒绝的流量。

此配置可让您仅为高度关键的工作负载（例如支付网关）启用日志记录，同时忽略嘈杂的低风险服务。

调整 VPC 流日志采样率

在 Terraform 配置（或 Google Cloud 控制台）中，仅在需要流量和费用汇总信息（而非单个流记录）的子网上降低次要抽样率。由于 VPC 流日志会根据抽样的数据包估算总流量，因此在较低的采样率下，字节数和数据包数仍可用于费用分析。请勿将 flow_sampling 比率设置为低于 0.1（满足 constraints/compute.requireVpcFlowLogs 组织政策的 ESSENTIAL 级最低比率）：

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 对象之间的流量不会离开该节点，因此 VPC 流日志无法看到该流量。在 Autopilot 集群中，节点内可见性默认处于启用状态；在标准集群（包括使用 GKE Dataplane V2 的标准集群）中，节点内可见性默认处于停用状态。启用节点内可见性会通过 VPC 将此流量回环，并有助于确保 VPC 防火墙规则和流日志始终适用。

  • 了解服务 VIP 解析行为：在 Kubernetes 服务虚拟 IP (VIP) 解析为后端 Pod IP 地址后，传输层 (OSI 第 4 层) 指标会将其计为 Pod 到 Pod 的流量。如需跟踪最初的目标服务 VIP，请在连接握手期间依赖 Hubble CLI 实时流。

  • 使指标和日志时间戳保持一致：在调查突发事件时，将 Cloud Monitoring 指标中的高峰与在 Cloud Logging 或 Hubble CLI 中查询日志的确切时间窗口相关联，以确保您分析的是同一事件。

后续步骤