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:

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:

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.

• Query Prometheus (PromQL):

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

• Comportamento consigliato: consulta Diagnosticare l'eliminazione di pacchetti e i blocchi NetworkPolicy per isolare il motivo specifico dell'eliminazione di GKE NetworkPolicy o 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 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 Cloud de Confiance ), 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:

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

• Risolvere i problemi di osservabilità della rete
• Best practice per il networking di GKE
• Informazioni sull'osservabilità di GKE Dataplane V2
• Osserva il traffico utilizzando l'osservabilità di GKE Dataplane V2