Best practice per l'osservabilità della rete GKE

La gestione della connettività di rete e delle norme di sicurezza in ambienti Kubernetes dinamici presenta sfide operative significative. L'osservabilità di GKE Dataplane V2 fornisce agli amministratori della piattaforma visibilità a livello di kernel nel traffico di rete del cluster, il che può contribuire a risolvere rapidamente i problemi, eseguire audit di conformità continui e convalidare in modo proattivo i percorsi.

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 per la risoluzione dei problemi e procedure diagnostiche, 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:

  • Mean Time to Resolution (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 si elimina la necessità di 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à a più livelli progettato per diverse fasi operative. La seguente tabella descrive 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 30 o più giorni) Trascurabile (aggregazione a livello di kernel) Contatori di pacchetti e byte, conteggi di reimpostazione TCP e tassi 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 della 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. Solo GKE Dataplane V2 Temporaneo (buffer circolare locale al nodo) Bassa (attivazione dinamica) Tracce di flusso in tempo reale, motivi di interruzione dettagliati (ad esempio, criteri rifiutati o saturazione della tabella conntrack).
Metriche DNS di 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 hit e mancati riscontri della cache, latenza di inoltro upstream e rifiuti del limite simultaneo.
Connectivity Tests Convalida del percorso pre-deployment e controllo della configurazione statica. Tutti i cluster Non applicabile (simulazione on demand) Nessuna (simulazione statica) Percorso di routing dei pacchetti simulato, inclusa la valutazione di NetworkPolicy simulata.
Log di flusso VPC Controllo del traffico interno ed esterno ai nodi, 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 significa 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ò fare lo scale up fino a 2 vCPU e diverse centinaia di megabyte di memoria.

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

Per risolvere in modo efficace i problemi relativi alle 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 di 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 (log vpc_flows)
Interfaccia a riga di comando e UI di Hubble 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 dataplane e analisi del percorso: verifica la raggiungibilità e identifica i punti di eliminazione esatti nei firewall VPC, nelle route e nei 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 (vedi 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 Masquerade) 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 perdita è 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.

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 nei pacchetti di reimpostazione TCP spesso indica che un servizio di backend rifiuta 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 sbilanciamento del traffico e i ripristini TCP per esaminare la persistenza della connessione o la saturazione della coda dell'applicazione.

Convalida automatizzata del percorso in CI/CD

Integra i Connectivity Tests nelle pipeline di deployment per convalidare i percorsi di rete in modo statico 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.

  • Esempio di comando:

    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

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 Analizzare 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 di dati di telemetria senza perdere visibilità sul traffico critico:

Disabilita i log delle connessioni consentite

Per impostazione predefinita, la registrazione di NetworkPolicy acquisisce le connessioni consentite e 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

Delegare la registrazione 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 Terraform (o nella console Google Cloud ), riduci la frequenza di campionamento secondaria solo nelle subnet in cui hai bisogno di aggregazioni 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 del criterio 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 riassume i tassi di campionamento secondario e i livelli corrispondenti dei criteri 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 velocità quando configuri la subnet, perché aumentare la velocità dopo un incidente non recupera i flussi che non sono mai stati acquisiti.
0.5 (valore predefinito) LIGHT Le subnet che supportano i cluster per cui risolvi i problemi. Questa è la tariffa 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 (ad esempio il traffico interno kube-system) direttamente a livello di sink 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à del flusso GKE Dataplane V2 on demand: l'osservabilità del flusso (hubble-relay) può introdurre un leggero sovraccarico. 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, fai affidamento ai 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