Best Practices für die Beobachtbarkeit von GKE-Netzwerken

Die Verwaltung von Netzwerkverbindungen und Sicherheitsrichtlinien in dynamischen Kubernetes-Umgebungen stellt eine erhebliche betriebliche Herausforderung dar. Die Beobachtbarkeit von GKE Dataplane V2 bietet Plattformadministratoren Einblicke in den Netzwerkverkehr des Clusters auf Kernelebene. Dies kann zu einer schnellen Fehlerbehebung, kontinuierlichen Compliance-Prüfung und proaktiven Pfadvalidierung beitragen.

In diesem Dokument werden die konzeptionelle Architektur und Best Practices für die Netzwerkbeobachtbarkeit von Google Kubernetes Engine (GKE) beschrieben, einschließlich des Telemetriestacks, eines mentalen Modells für die Fehlerbehebung, proaktiver Benachrichtigungsregeln, Terraform-Automatisierung und Techniken zur Kostenoptimierung.

Eine detaillierte Anleitung zur Fehlerbehebung und zu Diagnoseverfahren finden Sie unter Fehlerbehebung bei der Netzwerkbeobachtbarkeit.

Vorteile der GKE-Netzwerkbeobachtbarkeit

Die Implementierung einer Beobachtbarkeitsstrategie in GKE bietet die folgenden wichtigen Vorteile:

• Schnellere durchschnittliche Zeit bis zur Problemlösung (Mean Time to Resolution, MTTR): Mithilfe von eBPF-basierten Messwerten und Hubble-Flusslogs können Sie Netzwerkanomalien sofort isolieren. So können Sie zwischen Fehlern auf Anwendungsebene, Kubernetes NetworkPolicy-Blockierungen und VPC-Firewall-Drops unterscheiden und die Debugging-Zyklen von Stunden auf Minuten verkürzen.
• Instrumentierung auf Kernelebene ohne Sidecars:GKE Dataplane V2 führt die Observability-Logik direkt im Linux-Kernel des Hosts mit eBPF aus. Dadurch sind keine ressourcenintensiven Sidecar-Proxys oder Codeänderungen auf Anwendungsebene erforderlich. Das sorgt für minimalen Overhead und eine gleichbleibende Anwendungsleistung.
• Kontinuierliche Prüfung der Sicherheits-Compliance:Durch die NetworkPolicy-Protokollierung werden detaillierte Audit-Logs für jeden Verbindungsversuch (Ergebnisse von ALLOW oder DENY) generiert. Diese Logs bieten einen manipulationssicheren Datensatz des Cluster-Traffics, der für die Einhaltung regulatorischer Anforderungen (z. B. PCI-DSS, SOC 2 und HIPAA) unerlässlich ist.
• Proaktive Pfadvalidierung:Durch die Integration mit Konnektivitätstests können Sie Netzwerkpfade simulieren und GKE-NetworkPolicies statisch bewerten, bevor Arbeitslasten bereitgestellt werden. So lassen sich Konfigurationsabweichungen und Konnektivitätsprobleme in der Bereitstellungsphase vermeiden.
• Ressourcen- und Kostenoptimierung:Durch die detaillierte Flussverfolgung werden Ineffizienzen wie eine übermäßige Nutzung von Cloud NAT-Ports, Spitzen bei der Datenübertragung zwischen Zonen und nicht im Cache gespeicherte DNS-Auflösungsmuster aufgedeckt. So können Sie fundierte Kapazitätsplanung und Kostenverwaltung vornehmen.

Architektur der GKE-Netzwerkbeobachtbarkeit

GKE Dataplane V2 bietet einen mehrschichtigen Beobachtbarkeitsstack, der für verschiedene Betriebsphasen entwickelt wurde. In der folgenden Tabelle sind die wichtigsten Komponenten und ihre empfohlenen Anwendungsfälle aufgeführt:

In der Tabelle oben bedeutet ein Leistungs-Overhead von Geringfügig, dass Komponenten unabhängig von Trafficvolumen oder Systemskalierung einen minimalen Ressourcenbedarf haben (in der Regel <0,1 vCPU und minimaler Arbeitsspeicher). Niedrige Komponenten haben unter Standardbedingungen einen minimalen Ressourcenbedarf, werden aber dynamisch mit der Trafficdichte skaliert. Bei Szenarien mit hohem Durchsatz kann die Ressourcennutzung auf bis zu 2 vCPUs und mehrere Hundert Megabyte Arbeitsspeicher skaliert werden.

GKE-Beobachtbarkeit – mentales Modell und Triage-Schleife

Um Netzwerkabweichungen effektiv zu beheben, müssen Sie das geeignete Telemetriesignal für Ihren Betriebsbereich auswählen und eine konsistente Triage-Methode anwenden.

Die richtige Telemetriequelle auswählen

Da mehrere Telemetriequellen verfügbar sind, sollten Sie das Tool auswählen, das zu Ihrer aktuellen betrieblichen Aufgabe passt:

Standardisierte Schleife zur Fehlerbehebung

Verwenden Sie diesen wiederholbaren Workflow, um GKE-Netzwerkvorfälle zu priorisieren:

1. Anomalie erkennen:Identifizieren Sie das Problem anhand von Cloud Monitoring-Benachrichtigungen (z. B. Spitzen bei TCP-Resets, Ablehnungen aufgrund des DNS-Limits für gleichzeitige Anfragen oder Paketverluste).
2. Tier isolieren:Führen Sie den GCE-VM-Basistest aus (siehe Fehlerbehebung bei Latenz auf Knotenebene und CNI-Engpässen), um festzustellen, ob sich der Block innerhalb des GKE-Cluster (CNI, NetworkPolicy, IP-Masquerade) oder außerhalb im VPC (Firewallregeln, Routing, Cloud NAT) befindet.
3. Ursache untersuchen:Führen Sie eine detaillierte Analyse des Ablaufs durch:
   • Bei Live-Vorfällen: Verwenden Sie die Hubble-Befehlszeile (hubble observe), um Flows in Echtzeit zu streamen und Gründe für das Beenden von Verbindungen zu ermitteln.
   • Bei früheren oder zeitweiligen Problemen: Fragen Sie NetworkPolicy-Logs oder VPC-Flusslogs in Cloud Logging ab.
4. Abhilfemaßnahmen validieren:Führen Sie einen simulierten Konnektivitätstest aus, um zu prüfen, ob der Pfad statisch zulässig ist. Sehen Sie dann im Messwert-Dashboard nach, ob die Drop-Rate wieder null beträgt.

Proaktives Netzwerkmonitoring und Benachrichtigungen

Um eine Hochverfügbarkeit zu gewährleisten, sollten Plattformadministratoren Benachrichtigungsrichtlinien in Cloud Monitoring einrichten, um eine Beeinträchtigung des Netzwerks zu erkennen, bevor sie sich auf Arbeitslasten auswirkt.

Benachrichtigung bei Spitzenwerten bei Paketverlusten

Ein anomaler Anstieg der verworfenen Netzwerkflüsse deutet in der Regel auf eine falsch konfigurierte Sicherheitsrichtlinie oder eine Erschöpfung des Connection-Tracking (conntrack) auf Knotenebene hin.

• Prometheus-Abfrage (PromQL):

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

• Empfohlene Maßnahme:Weitere Informationen finden Sie unter Paketverluste und NetworkPolicy-Blockierungen diagnostizieren, um die spezifische GKE-NetworkPolicy oder den eBPF-Löschgrund zu ermitteln, der den Paketverlust verursacht.

Benachrichtigung bei DNS-Sättigung

Wenn CoreDNS oder NodeLocal DNSCache das Limit für gleichzeitige Abfragen erreicht, werden nachfolgende DNS-Lookups abgelehnt, was zu zeitweiligen Zeitüberschreitungen bei Anwendungen führt.

• Prometheus-Abfrage (PromQL):

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

• Empfohlene Maßnahme:Skalieren Sie die Anzahl der kube-dns-Repliken oder implementieren Sie NodeLocal DNSCache, um die Auflastung zu verteilen. Eine ausführliche Anleitung finden Sie unter Fehler bei der DNS-Auflösung diagnostizieren.

Benachrichtigung bei Spitzen von TCP-Resets

Ein Anstieg der TCP-Reset-Pakete deutet oft darauf hin, dass ein Backend-Dienst Verbindungen ablehnt, möglicherweise aufgrund von Anwendungsabstürzen oder einer Überlastung der Socket-Warteschlange.

• 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
  

• Empfohlene Maßnahme:Informationen zum Untersuchen von Verbindungsstabilität oder Anwendungswarteschlangensättigung finden Sie unter Ungleichgewicht beim Traffic und TCP-Resets diagnostizieren.

Automatisierte Pfadvalidierung in CI/CD

Integrieren Sie Konnektivitätstests in Bereitstellungspipelines, um Netzwerkpfade statisch zu validieren, bevor Sie Produktionstraffic weiterleiten. Verwenden Sie die gcloud CLI, um zu prüfen, ob neu bereitgestellte Arbeitslasten ohne Richtlinienblockierungen auf externe Abhängigkeiten (z. B. Datenbanken und APIs) zugreifen können.

• Beispielbefehl:

  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 für die visuelle Flussanalyse aktivieren

Wenn Sie VPC-Traffic-Flüsse visuell und ohne SQL analysieren möchten, upgraden Sie den GKE-Log-Bucket (in der Regel den _Default-Bucket), um Observability Analytics zu verwenden. So können Plattformadministratoren mit Flow Analyzer die Traffic-Verteilung und die Kosten für die Datenübertragung untersuchen. Weitere Informationen finden Sie unter Kosten und Leistung von Clustertraffic mit Flow Analyzer analysieren.

Terraform-Automatisierung: Observability-as-Code

Um diese Architektur für die Beobachtbarkeit konsistent zu implementieren und manuelle Einrichtungsfehler zu vermeiden, stellen Sie die Telemetriepipeline mit der folgenden Terraform-Konfiguration bereit (erfordert den google-beta-Anbieter):

# 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"
}

Kostenoptimierung und Rauschunterdrückung

Netzwerktelemetrie (Messwerte und Logs) kann erhebliche Datenmengen generieren, was zu hohen Aufnahme- und Speicherkosten führt. Mit den folgenden Strategien können Sie die Erfassung von Telemetriedaten optimieren, ohne die Sichtbarkeit kritischen Traffics zu verlieren:

Logs für zulässige Verbindungen deaktivieren

Standardmäßig werden beim NetworkPolicy-Logging sowohl zugelassene als auch abgelehnte Verbindungen erfasst. Zulässige Verbindungen machen den Großteil des Logvolumens aus (oft 99% oder mehr des Traffics). Sie können die NetworkLogging-Konfiguration des Clusters so aktualisieren, dass nur abgelehnte Verbindungen (Drops) erfasst werden. Dadurch werden die Loggingkosten erheblich gesenkt:

1. Speichern Sie das folgende Manifest als 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. Wenden Sie die Konfiguration an:

   kubectl apply -f network-logging-config.yaml
   

Logging über Annotationen delegieren

Wenn Sie die Kosten detailliert kontrollieren möchten, können Sie die Protokollierung an Anmerkungen delegieren, indem Sie delegate: true in der benutzerdefinierten Ressource NetworkLogging festlegen. Diese Konfiguration sorgt für Folgendes:

• Zulässiger Traffic wird nur protokolliert, wenn die entsprechende NetworkPolicy die Annotation policy.network.gke.io/enable-logging: "true" hat.
• Abgelehnter Traffic wird nur für Pod-Objekte in Namespaces protokolliert, die mit policy.network.gke.io/enable-deny-logging: "true" annotiert sind.

Mit dieser Konfiguration können Sie die Protokollierung nur für hochkritische Arbeitslasten (z. B. Zahlungs-Gateways) aktivieren und Dienste mit geringem Risiko ignorieren.

Samplingrate für VPC-Flusslogs anpassen

Reduzieren Sie in Ihrer Terraform-Konfiguration (oder Cloud de Confiance -Console) die sekundäre Samplingrate nur für Subnetze, in denen Sie Trafficvolumen und Kostenaggregate anstelle einzelner Flow-Datensätze benötigen. Da bei VPC-Flusslogs der Gesamttraffic anhand von Stichprobenpaketen geschätzt wird, können Byte- und Paketanzahlen auch bei niedrigeren Raten für die Kostenanalyse verwendet werden. Legen Sie die Rate flow_sampling nicht niedriger als 0.1 fest. Das ist die Mindestrate, die die Stufe ESSENTIAL der Organisationsrichtlinie constraints/compute.requireVpcFlowLogs erfüllt:

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"
  }
}

In der folgenden Tabelle sind die sekundären Sampling-Raten und die entsprechenden Stufen der constraints/compute.requireVpcFlowLogs-Organisationsrichtlinie zusammengefasst:

Cloud Logging-Ausschlüsse anwenden

Schließen Sie irrelevante Logs (z. B. kube-system-internen Traffic) direkt auf der Ebene der Cloud Logging-Senke aus. Fügen Sie Ihrer _Default-Senke einen Ausschlussfilter hinzu, um interne Metadaten oder System-Pod-Logs zu verwerfen:

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"

Best Practices und operative Tipps

Beachten Sie beim Bereitstellen und Warten Ihrer Cluster-Telemetriepipeline die folgenden Betriebsrichtlinien:

• GKE Dataplane V2-Flow-Beobachtbarkeit bei Bedarf aktivieren:Die Flow-Beobachtbarkeit (hubble-relay) kann zu einem geringen Mehraufwand führen. In Produktionsclustern können Sie die Funktion während der Debugging-Sitzungen aktivieren und danach deaktivieren, um den Ressourcenverbrauch auf Knoten zu minimieren:

  gcloud container clusters update CLUSTER_NAME \
      --enable-dataplane-v2-flow-observability \
      --location=LOCATION
  

• Knoteninterne Sichtbarkeit aktivieren:Standardmäßig verlässt der Traffic zwischen zwei Pod-Objekten auf demselben Knoten den Knoten nicht, sodass er für VPC-Flusslogs nicht sichtbar ist. Die knoteninterne Sichtbarkeit ist in Autopilot-Clustern standardmäßig aktiviert und in Standardclustern standardmäßig deaktiviert, einschließlich Standardclustern, die GKE Dataplane V2 verwenden. Durch Aktivieren der Sichtbarkeit innerhalb von Knoten wird dieser Traffic über die VPC geleitet. So wird dafür gesorgt, dass VPC-Firewallregeln und Flusslogs konsistent angewendet werden.

• Verhalten bei der Auflösung der VIP des Dienstes verstehen:Nachdem eine virtuelle IP-Adresse (VIP) eines Kubernetes-Dienstes in eine IP-Adresse eines Backend-Pods aufgelöst wurde, werden Transportebenenmesswerte (OSI-Schicht 4) als Pod-zu-Pod-Traffic gezählt. Um nachzuvollziehen, welche Service-VIP ursprünglich als Ziel festgelegt wurde, können Sie sich während des Verbindungs-Handshakes auf die Live-Flows der Hubble-Befehlszeile verlassen.

• Zeitstempel für Messwerte und Logs abstimmen:Wenn Sie einen Vorfall untersuchen, sollten Sie den Anstieg der Cloud Monitoring-Messwerte mit dem genauen Zeitfenster korrelieren, in dem Sie Logs in Cloud Logging oder der Hubble-Befehlszeile abfragen, um sicherzustellen, dass Sie dasselbe Ereignis analysieren.

Nächste Schritte

• Probleme mit der Netzwerkbeobachtbarkeit beheben
• Best Practices für GKE-Netzwerke
• Informationen zur Beobachtbarkeit von GKE Dataplane V2
• Traffic mit GKE Dataplane V2 beobachten