Best practice per l'osservabilità della rete GKE

La gestione della connettività di rete e delle policy di sicurezza in ambienti Kubernetes dinamici presenta sfide operative significative. L'osservabilità di GKE Dataplane V2 fornisce agli amministratori della piattaforma una visibilità a livello di kernel sul traffico di rete del cluster, che può contribuire a consentire una rapida risoluzione dei problemi, un audit di conformità continuo e una convalida proattiva del percorso.

Questo documento descrive l'architettura concettuale e le best practice per l'osservabilità della rete Google Kubernetes Engine (GKE), inclusi lo stack di telemetria, un modello mentale per la valutazione, regole di avviso proattive, automazione Terraform e tecniche di ottimizzazione dei costi.

Per istruzioni dettagliate sulla risoluzione dei problemi e sulle procedure di diagnostica, consulta Risolvi i problemi di osservabilità della rete.

Vantaggi dell'osservabilità di rete GKE

L'implementazione di una strategia di osservabilità in GKE offre i seguenti vantaggi principali:

  • Tempo medio di risoluzione (MTTR) accelerato: sfruttando le metriche basate su eBPF e i log di flusso di Hubble, puoi isolare immediatamente le anomalie di rete. Questa visibilità ti consente di distinguere tra errori a livello di applicazione, blocchi di NetworkPolicy di Kubernetes e eliminazioni del firewall VPC, riducendo i cicli di debug da ore a minuti.
  • Strumentazione a livello di kernel senza sidecar: GKE Dataplane V2 esegue la logica di osservabilità direttamente all'interno del kernel Linux host utilizzando eBPF. In questo modo, non sono necessari proxy sidecar che richiedono molte risorse o modifiche al codice a livello di applicazione, garantendo un overhead minimo e preservando le prestazioni dell'applicazione.
  • Audit continuo della conformità alla sicurezza: la registrazione di NetworkPolicy genera log di controllo dettagliati per ogni tentativo di connessione (verifiche di ALLOW o DENY). Questi log forniscono un record a prova di manomissione del traffico del cluster, essenziale per soddisfare i framework di conformità legale (come PCI-DSS, SOC 2 e HIPAA).
  • Convalida proattiva del percorso:l'integrazione con Connectivity Tests ti consente di simulare i percorsi di rete e valutare staticamente NetworkPolicy di GKE prima del deployment dei workload, evitando la deriva della configurazione e i problemi di connettività nella fase di deployment.
  • Ottimizzazione delle risorse e dei costi:il monitoraggio dettagliato del flusso espone inefficienze come l'utilizzo eccessivo delle porte Cloud NAT, picchi di trasferimento di dati tra zone e pattern di risoluzione DNS non memorizzati nella cache, consentendo una pianificazione della capacità e una gestione dei costi informate.

Architettura di osservabilità della rete GKE

GKE Dataplane V2 offre uno stack di osservabilità multilivello progettato per diverse fasi operative. La tabella seguente illustra i componenti principali e i relativi casi d'uso consigliati:

Componente di osservabilità Caso d'uso primario Disponibilità Conservazione dei dati Overhead delle prestazioni Indicatori di telemetria chiave
Metriche GKE Dataplane V2 Monitoraggio dello stato di salute a livello di sistema, analisi delle tendenze e avvisi. Solo GKE Dataplane V2 Conservazione della telemetria storica (Cloud Monitoring e Google Cloud Managed Service per Prometheus archiviano metriche e log per almeno 30 giorni) Trascurabile (aggregazione a livello di kernel) Contatori di pacchetti e byte, conteggi di reset TCP e frequenze di interruzione della connessione (pod_flow_drop_count).
Log di NetworkPolicy Audit delle norme di sicurezza, analisi della cronologia delle connessioni e conformità. Solo GKE Dataplane V2 (per la configurazione della risorsa personalizzata NetworkLogging) Configurabile (Cloud Logging) Bassa (esportazione log con buffer) Metadati di connessione (etichette di origine e destinazione, indirizzi IP, porte) e verdetti delle norme (ALLOW o DENY).
Interfaccia a riga di comando e UI di Hubble Analisi del traffico interattiva e in tempo reale e debug a livello di pacchetto in tempo reale. Solo GKE Dataplane V2 Temporaneo (buffer circolare locale del nodo) Bassa (attivazione dinamica) Tracce di flusso in tempo reale, motivi dettagliati dell'interruzione (ad esempio, criterio negato o saturazione della tabella conntrack).
Metriche DNS GKE Monitoraggio delle prestazioni di risoluzione DNS, dell'efficienza della cache e della latenza upstream. Tutti i cluster A lungo termine (Cloud Monitoring) Trascurabile Conteggio delle richieste DNS, rapporto tra successi e fallimenti della cache, latenza di forwarding upstream e rifiuti dei limiti di concorrenza.
Connectivity Tests Convalida del percorso pre-deployment e controllo della configurazione statica. Tutti i cluster Non applicabile (simulazione on demand) Nessuno (simulazione statica) Percorso di routing dei pacchetti simulato, inclusa la valutazione simulata di NetworkPolicy.
Log di flusso VPC Controllo del traffico tra nodi ed esterno, analisi forense della sicurezza e analisi dei costi. Tutti i cluster Configurabile (Cloud Logging o BigQuery) Nessuno (frequenza di campionamento configurabile) Dettagli della connessione a 5 tuple, byte e pacchetti inviati, metadati GKE (spazio dei nomi, workload, servizio) e RTT (per TCP).
Flow Analyzer Analisi visiva del traffico VPC, identificazione dei principali interlocutori e analisi dei costi tra zone senza scrivere query SQL. Tutti i cluster Dipende dalla conservazione del bucket Observability Analytics Nessuno (UI analitica) Volume del traffico e latenza aggregati raggruppati per servizio o workload GKE.

Nella tabella precedente, un overhead delle prestazioni Trascurabile indica che i componenti rimangono rigorosamente all'interno di un footprint di risorse minimo (in genere <0,1 vCPU e memoria minima) indipendentemente dal volume di traffico o dalla scalabilità del sistema. I componenti Low mantengono un ingombro minimo in condizioni standard, ma vengono scalati dinamicamente in base alla densità del traffico. In scenari a velocità effettiva elevata, l'utilizzo delle risorse può essere scalato fino a 2 vCPU e diverse centinaia di megabyte di memoria.

Modello mentale e ciclo di triage dell'osservabilità di GKE

Per risolvere efficacemente le anomalie di rete, devi selezionare l'indicatore di telemetria appropriato per il tuo ambito operativo e seguire una metodologia di triage coerente.

Scegliere l'origine di telemetria giusta

Con più origini di telemetria disponibili, scegli lo strumento più adatto all'attività operativa corrente:

Origine della telemetria Risposte Ideale per Google Cloud destination
Metriche GKE Dataplane V2 Che cosa sta succedendo e su quale scala? Dashboard, avvisi e pianificazione della capacità. Cloud Monitoring (prometheus.googleapis.com)
Log NetworkPolicy Perché una connessione è stata bloccata all'interno di GKE? Audit di sicurezza e analisi delle cause principali delle policy di sicurezza. Cloud Logging (log policy-action)
Log di flusso VPC Cosa è successo a questo traffico dopo aver lasciato il pod? Analisi del traffico storico tra workload, costi di trasferimento dei dati tra zone e attribuzione delle interruzioni a livello di VPC. Cloud Logging e Observability Analytics (vpc_flows log)
Hubble CLI e UI Che cosa sta passando attraverso il nodo in questo momento? Debug in tempo reale, alternativa a tcpdump e incidenti attivi. Buffer circolare temporaneo (Hubble CLI)
Connectivity Tests Il traffico può viaggiare correttamente? Sondaggio attivo del piano dati e analisi dei percorsi: verifica la raggiungibilità e identifica i punti di interruzione esatti tra firewall VPC, route e nodi GKE. Network Intelligence Center (simulazione)

Ciclo di risoluzione dei problemi standardizzato

Utilizza questo flusso di lavoro ripetibile per eseguire il triage di qualsiasi incidente di networking GKE:

  1. Rileva anomalie:identifica il problema tramite gli avvisi di Cloud Monitoring (ad esempio, picchi di ripristini TCP, rifiuti del limite simultaneo DNS o perdite di pacchetti).
  2. Isola il livello: esegui il test di base della VM GCE (consulta Triage per la latenza a livello di nodo e i colli di bottiglia CNI) per determinare se il blocco si trova all'interno del cluster GKE (CNI, NetworkPolicy, IP masquerading) o all'esterno nel VPC (regole firewall, routing, Cloud NAT).
  3. Esamina la causa principale:esegui un'analisi dettagliata del flusso:
    • Per gli incidenti live: utilizza Hubble CLI (hubble observe) per lo streaming dei flussi in tempo reale e identifica i motivi dell'interruzione.
    • Per problemi storici o intermittenti: esegui query sui log NetworkPolicy o sui log di flusso VPC in Cloud Logging.
  4. Convalida della correzione:esegui un test di Connectivity Tests simulato per verificare che il percorso sia consentito staticamente, quindi controlla la dashboard delle metriche per confermare che il tasso di abbandono è tornato a zero.

Monitoraggio e avvisi di rete proattivi

Per mantenere l'alta affidabilità, gli amministratori della piattaforma devono stabilire policy di avviso in Cloud Monitoring per identificare il degrado della rete prima che influisca sui carichi di lavoro.

Avviso sui picchi di pacchetti eliminati

Un aumento anomalo dei flussi di rete interrotti in genere indica un criterio di sicurezza configurato in modo errato o l'esaurimento del monitoraggio delle connessioni (conntrack) a livello di nodo.

  • Query Prometheus (PromQL):

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

  • Comportamento consigliato: consulta Diagnostica i pacchetti ignorati e i blocchi di NetworkPolicy per isolare la NetworkPolicy GKE specifica o il motivo dell'eliminazione di eBPF che causa la perdita di pacchetti.

Avviso sulla saturazione DNS

Quando CoreDNS o NodeLocal DNSCache raggiunge il limite di query simultanee, le ricerche DNS successive vengono rifiutate, causando timeout intermittenti delle applicazioni.

  • Query Prometheus (PromQL):

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

  • Azione consigliata: scala il conteggio delle repliche di kube-dns o implementa NodeLocal DNSCache per distribuire il carico di risoluzione. Per i passaggi dettagliati, vedi Diagnosticare gli errori di risoluzione DNS.

Avviso sui picchi di ripristino TCP

Un picco di pacchetti di reimpostazione TCP spesso indica che un servizio di backend sta rifiutando le connessioni, potenzialmente a causa di loop di arresto anomalo dell'applicazione o saturazione della coda dei socket.

  • 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

  • Comportamento consigliato: consulta Diagnostica lo squilibrio del traffico e i reset TCP per esaminare la persistenza della connessione o la saturazione della coda dell'applicazione.

Convalida automatizzata dei percorsi in CI/CD

Integra i Connectivity Tests nelle pipeline di deployment per convalidare staticamente i percorsi di rete prima di instradare il traffico di produzione. Utilizza gcloud CLI per verificare che i workload appena implementati possano raggiungere le dipendenze esterne (come database e API) senza blocchi delle policy.

  • Comando di esempio:

    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 \
    --round-trip

Abilitare Observability Analytics per l'analisi del flusso visivo

Per abilitare l'analisi visiva e senza SQL dei flussi di traffico VPC, esegui l'upgrade del bucket di log GKE (in genere il bucket _Default) per utilizzare Observability Analytics. In questo modo, gli amministratori della piattaforma possono utilizzare Flow Analyzer per esaminare la distribuzione del traffico e i costi di trasferimento dei dati. Per saperne di più, consulta Analizza i costi e le prestazioni del traffico del cluster utilizzando Flow Analyzer.

Automazione Terraform: Observability-as-Code

Per implementare questa architettura di osservabilità in modo coerente ed evitare errori di configurazione manuale, esegui il deployment della pipeline di telemetria utilizzando la seguente configurazione Terraform (richiede il provider 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"
}

Ottimizzazione dei costi e riduzione del rumore

La telemetria di rete (metriche e log) può generare volumi di dati sostanziali, con conseguenti costi elevati di importazione e archiviazione. Utilizza le seguenti strategie per ottimizzare la raccolta della telemetria senza perdere visibilità sul traffico critico:

Disabilita i log delle connessioni consentite

Per impostazione predefinita, il logging di NetworkPolicy acquisisce sia le connessioni consentite sia quelle rifiutate. Le connessioni consentite dominano il volume dei log (spesso il 99% o più del traffico). Puoi aggiornare la configurazione NetworkLogging del cluster per acquisire solo le connessioni rifiutate (interruzioni), il che riduce drasticamente i costi di logging:

  1. Salva il seguente manifest come 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. Applica la configurazione:

    kubectl apply -f network-logging-config.yaml

Delega il logging tramite le annotazioni

Per un controllo dei costi granulare, delega la registrazione alle annotazioni impostando delegate: true nella risorsa personalizzata NetworkLogging. Questa configurazione garantisce quanto segue:

  • Il traffico consentito viene registrato solo se NetworkPolicy corrispondente ha l'annotazione policy.network.gke.io/enable-logging: "true".
  • Il traffico negato viene registrato solo per gli oggetti pod negli spazi dei nomi annotati con policy.network.gke.io/enable-deny-logging: "true".

Questa configurazione ti consente di attivare la registrazione solo per i carichi di lavoro altamente critici (come i gateway di pagamento), ignorando i servizi rumorosi e a basso rischio.

Ottimizzare la frequenza di campionamento dei log di flusso VPC

Nella configurazione di Terraform (o nella console Google Cloud ), riduci la frequenza di campionamento secondaria solo nelle subnet in cui hai bisogno di aggregati di volume di traffico e costi anziché di singoli record di flusso. Poiché i log di flusso VPC stimano il traffico totale dai pacchetti campionati, i conteggi di byte e pacchetti rimangono utilizzabili per l'analisi dei costi a tariffe inferiori. Non impostare la tariffa flow_sampling inferiore a 0.1, la tariffa minima che soddisfa il livello ESSENTIAL della policy dell'organizzazione 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"
  }
}

La tabella seguente riepiloga le frequenze di campionamento secondario e i livelli corrispondenti delle policy dell'organizzazione constraints/compute.requireVpcFlowLogs:

Frequenza di campionamento secondaria Livello della policy dell'organizzazione Quando utilizzarla
1.0 COMPREHENSIVE Cluster con un requisito permanente per la per-flow forensics o il controllo di sicurezza. Scegli questa frequenza quando configuri la subnet, perché l'aumento della frequenza dopo un incidente non recupera i flussi mai acquisiti.
0.5 (valore predefinito) LIGHT Le subnet che supportano i cluster per cui risolvi i problemi. Questa è la frequenza predefinita e la base di riferimento consigliata.
0.1 ESSENTIAL Subnet in cui hai bisogno di aggregati di volume di traffico e costi anziché di singoli flussi.

Applica esclusioni di Cloud Logging

Escludi i log rumorosi o irrilevanti (come il traffico interno di kube-system) direttamente a livello di sink di Cloud Logging. Aggiungi un filtro di esclusione al sink _Default per eliminare i metadati interni o i log dei pod di sistema:

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 practice e suggerimenti operativi

Tieni presente le seguenti linee guida operative quando esegui il deployment e la manutenzione della pipeline di telemetria del cluster:

  • Abilita l'osservabilità dei flussi di GKE Dataplane V2 on demand: l'osservabilità dei flussi (hubble-relay) può introdurre un leggero overhead. Per i cluster di produzione, puoi abilitarlo durante le sessioni di debug e disabilitarlo in seguito per ridurre al minimo il consumo di risorse sui nodi:

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

  • Abilita la visibilità tra nodi:per impostazione predefinita, il traffico tra due oggetti Pod sullo stesso nodo non esce dal nodo, rendendolo invisibile ai log di flusso VPC. La visibilità all'interno del nodo è abilitata per impostazione predefinita nei cluster Autopilot e disabilitata per impostazione predefinita nei cluster Standard, inclusi i cluster Standard che utilizzano GKE Dataplane V2. L'abilitazione della visibilità tra nodi indirizza questo traffico attraverso il VPC e contribuisce a garantire che le regole firewall e i log di flusso VPC vengano applicati in modo coerente.

  • Comprendi il comportamento di risoluzione dell'IP virtuale del servizio:dopo che un IP virtuale del servizio Kubernetes viene risolto in un indirizzo IP del pod di backend, le metriche del livello di trasporto (livello 4 del modello OSI) lo conteggiano come traffico da pod a pod. Per tracciare il VIP del servizio originariamente preso di mira, utilizza i flussi in tempo reale di Hubble CLI durante l'handshake della connessione.

  • Allinea i timestamp di metriche e log:quando esamini un incidente, metti in correlazione il picco nelle metriche di Cloud Monitoring con l'intervallo di tempo esatto quando esegui query sui log in Cloud Logging o nell'interfaccia a riga di comando Hubble per assicurarti di analizzare lo stesso evento.

Passaggi successivi