Risolvi i problemi di osservabilità di rete GKE

Questo documento fornisce istruzioni e procedure diagnostiche per diagnosticare i problemi di networking nei cluster Google Kubernetes Engine (GKE) utilizzando l'osservabilità di GKE Dataplane V2, Hubble e Cloud Monitoring.

Per una panoramica dell'architettura e delle best practice concettuali, consulta Best practice per l'osservabilità della rete.

Albero decisionale per la risoluzione dei problemi e concetti principali

Prima di esaminare le procedure, utilizza la seguente matrice decisionale per identificare quale livello dello stack di networking GKE potrebbe causare il problema e vai alla sezione corrispondente.

Sintomo o domanda diagnostica Livello sospetto Procedura consigliata
I pod non riescono a risolvere i domini esterni o i servizi Kubernetes interni (timeout DNS, NXDOMAIN, SERVFAIL). Livello 1: pod e servizio (DNS) Diagnostica gli errori di risoluzione DNS
I servizi non possono comunicare; timeout della connessione o pacchetti ignorati tra i pod. Livello 1: pod e servizio (drop di policy o pacchetti) Diagnostica le interruzioni dei pacchetti e i blocchi di NetworkPolicy
Le repliche del workload hanno un carico di traffico non uniforme o i pod registrano tassi elevati di reset TCP (RST). Livello 1: pod e servizio (bilanciamento del carico o trasporto) Diagnostica gli squilibri del traffico e i reset TCP
Latenza generale, timeout intermittenti o riavvii di CNI tra i nodi. Livello 2: nodo e CNI (kernel) Triage per la latenza a livello di nodo e i colli di bottiglia della CNI
I pod non possono raggiungere risorse esterne a GKE (Cloud SQL, API esterne o altri VPC). Livello 3: VPC e routing Isola i problemi di connettività di GKE rispetto a VPC o esterni
Hai bisogno di una simulazione automatizzata del percorso per verificare se le regole firewall, le route o le NetworkPolicy bloccano il traffico. Livello 3: VPC e routing (simulazione) Diagnostica la connettività utilizzando Connectivity Tests
Devi identificare quali workload inviano traffico a internet e vengono sottoposti a NAT. Livello 4: gateway esterno e costo Identifica il traffico NAT (traffico in uscita verso internet)
Costi elevati per il trasferimento di dati tra zone o necessità di visualizzare i principali comunicatori senza scrivere query SQL. Livello 4: gateway esterno e costo Analizza i costi e le prestazioni del traffico del cluster utilizzando Flow Analyzer

Concetti di base del networking

Se non hai familiarità con Kubernetes o con il networking di Google Cloud , tieni presente questi concetti fondamentali:

  • eBPF (Extended Berkeley Packet Filter): una tecnologia del sistema operativo che consente di eseguire programmi di monitoraggio della sicurezza e routing direttamente all'interno del kernel Linux. GKE Dataplane V2 utilizza eBPF per instradare i pacchetti e applicare i NetworkPolicy con un overhead minimo delle prestazioni.
  • IP masquerading (SNAT): il processo di riscrittura dell'indirizzo IP di origine di un pacchetto. Quando un pod GKE (che ha un indirizzo IP privato) comunica con internet o con risorse VPC esterne, GKE maschera (riscrive) l'indirizzo IP del pod nell'indirizzo IP del nodo in modo che i sistemi esterni sappiano come instradare la risposta.
  • Monitoraggio delle connessioni (Conntrack): una funzionalità del kernel che monitora tutte le connessioni di rete attive. Nei cluster GKE Dataplane V2, questo monitoraggio è suddiviso tra due tabelle: la tabella conntrack standard del kernel Linux (utilizzata da ip-masq-agent) e una tabella conntrack gestita da Cilium e GKE Dataplane V2 archiviata in una mappa eBPF. Se un nodo gestisce troppe connessioni simultanee, una di queste tabelle di monitoraggio può riempirsi (esaurimento di conntrack), causando l'eliminazione silenziosa di nuovi pacchetti da parte del nodo.
  • Hubble: il motore di osservabilità per GKE Dataplane V2. Viene eseguito su eBPF e fornisce visibilità in tempo reale sui flussi di traffico, sulle interruzioni dei pacchetti e sulla valutazione di NetworkPolicy.

Livello 1: osservabilità di pod e servizi (applicazioni)

Il livello Pod e Service copre la comunicazione di rete tra pod, servizi e DNS del cluster. I problemi a questo livello si manifestano in genere come timeout di connessione dell'applicazione, errori di risoluzione dei nomi o distribuzione non uniforme del carico.

Diagnostica gli errori di risoluzione DNS

Prima di risolvere i problemi relativi al DNS, esamina l'ambito della diagnostica e i prerequisiti:

  • Area di interesse: comunicazione tra i pod e CoreDNS o NodeLocal DNSCache, latenza DNS, timeout della risoluzione DNS upstream e convalida di NetworkPolicy FQDN.
  • Prerequisiti: metriche di GKE Dataplane V2 abilitate; accesso a kubectl.
  • Compatibilità CNI: GKE Dataplane V2 (Advanced Datapath) e CNI GKE standard.
  • Sintomo: i pod registrano dial tcp: lookup <domain>: i/o timeout, NXDOMAIN o latenza intermittente sulle chiamate API in uscita.
  • Obiettivo: determinare se l'errore DNS ha origine all'interno del cluster (saturazione di kube-dns o NodeLocal DNSCache), se un criterio di rete blocca la porta UDP o TCP 53 o se si tratta di un degrado della rete upstream.

Passaggio 1: controllo di base della raggiungibilità

Prima di risolvere i problemi relativi ai livelli DNS, verifica se la destinazione è raggiungibile direttamente utilizzando il suo indirizzo IP dall'interno del pod interessato:

# 1. Test raw IP reachability (bypasses DNS entirely)
kubectl exec -it my-pod -n default -- curl -v --connect-timeout 5 http://10.240.0.10:8080

# 2. Test domain resolution
kubectl exec -it my-pod -n default -- curl -v --connect-timeout 5 http://my-service.default.svc.cluster.local:8080
  • Se la connessione IP va a buon fine, ma il dominio non riesce: il problema è isolato al livello di risoluzione DNS. Vai al passaggio 2.
  • Se entrambi i test non vanno a buon fine: il problema riguarda il routing a livello di rete o l'applicazione delle policy. Vai a Diagnostica le perdite di pacchetti e i blocchi di NetworkPolicy.
Controlla la precompilazione DNS di NetworkPolicy FQDN

Se il cluster utilizza NetworkPolicy basate su FQDN (FQDNNetworkPolicy), verifica che il nome di dominio sia esplicitamente consentito. Se un pod esegue una query su un dominio esterno che non è precompilato nella cache del proxy DNS di GKE Dataplane V2 o consentito dalla policy, GKE Dataplane V2 blocca il traffico in uscita verso l'indirizzo IP risolto:

# Verify whether UDP or TCP port 53 egress is permitted in the Pod's namespace
kubectl get networkpolicy -n default -o yaml | grep -A 5 -B 2 "port: 53"

Passaggio 2: controlla le metriche DNS in Cloud Monitoring

GKE espone le metriche DNS integrate in Cloud Monitoring con il prefisso kubernetes.io/networking/dns/.

Per controllare le metriche DNS in Cloud Monitoring, segui questi passaggi:

  1. Nella console Google Cloud , vai a Cloud Monitoring > Dashboard.
  2. Seleziona la dashboard predefinita GKE DNS Observability - Cluster View (o vai a Esplora metriche e filtra per kubernetes.io/networking/dns/).
  3. Valuta i seguenti indicatori principali (per NodeLocal DNSCache, sostituisci kubedns con node_local_dns nel percorso della metrica):
Nome metrica Soglia di avviso Causa principale
kubernetes.io/networking/dns/kubedns/max_concurrent_rejected_request_count > 0 Limite di query simultanee raggiunto. kube-dns o NodeLocal DNSCache sta ignorando le query.
kubernetes.io/networking/dns/kubedns/dns_request_latencies p99 > 100ms Latenza elevata della risoluzione DNS end-to-end in kube-dns o NodeLocal DNSCache.
kubernetes.io/networking/dns/kubedns/forwarding_request_latencies p99 > 100ms Latenza o saturazione del server DNS upstream.
Sequenza di triage per prestazioni e timeout DNS

Segui questa sequenza di triage per diagnosticare la latenza DNS, i fallimenti della cache e i timeout upstream:

  1. Controlla la percentuale successi cache: esegui una query su kubernetes.io/networking/dns/kubedns/dns_cache_request_count (o node_local_dns/dns_cache_request_count) raggruppata per l'etichetta cache_status. Se cache_status="hit" è basso e cache_status="miss" è alto, le applicazioni potrebbero inviare query non FQDN (ad esempio my-service anziché my-service.default.svc.cluster.local), causando l'attraversamento del percorso di ricerca in tutte le voci in /etc/resolv.conf.
  2. Valuta la latenza upstream: un valore forwarding_request_latencies elevato indica problemi con il server DNS upstream (ad esempio, DNS on-premise aziendale raggiunto tramite Cloud Interconnect o Cloud VPN o limiti di Cloud DNS).

  3. Controlla gli override DNS personalizzati: controlla i ConfigMap kube-dns personalizzati per individuare stub o forwarding upstream configurati in modo errato:

    kubectl get configmap kube-dns -n kube-system -o yaml

Passaggio 3: trasmetti in streaming il traffico DNS in tempo reale con Hubble CLI

Utilizza l'alias helper dell'interfaccia a riga di comando di Hubble per ispezionare le richieste e le risposte DNS in tempo reale trasmesse in streaming dal kernel del nodo:

# 1. Ensure the helper alias is set in your terminal session
alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

# 2. Observe live DNS (Port 53) traffic for a specific Pod
gke-hubble observe --pod default/my-pod --port 53

Passaggio 4: convalida la correzione

Se si sono verificati rifiuti di query simultanee, applica NodeLocal DNSCache per assorbire le ricerche DNS ad alta frequenza direttamente sul nodo senza raggiungere i limiti kube-dns a livello di cluster:

# Verify NodeLocal DNSCache DaemonSet is running
kubectl get daemonset node-local-dns -n kube-system

Diagnostica le perdite di pacchetti e i blocchi di NetworkPolicy

Esamina l'ambito della diagnostica e i prerequisiti prima di esaminare i pacchetti ignorati e i rifiuti delle policy:

  • Area di interesse: cali di traffico tra oggetti Pod o tra oggetti Pod e Service, applicazione di NetworkPolicy, motivi di interruzione dell'eBPF del kernel.
  • Prerequisiti: osservabilità dei flussi di GKE Dataplane V2 abilitata; logging di NetworkPolicy configurato.
  • Compatibilità CNI: solo GKE Dataplane V2.
  • Sintomo: i tentativi di connessione dell'applicazione non vanno a buon fine con Connection timed out o Connection reset by peer.
  • Obiettivo: individuare il motivo esatto di NetworkPolicy o eBPF per cui i pacchetti vengono ignorati senza apportare modifiche per tentativi ed errori alle policy di sicurezza.

Passaggio 1: monitora le metriche di interruzione di Hubble

Quando GKE Dataplane V2 ignora un pacchetto, genera la metrica hubble_drop_total con il tag del motivo dell'eliminazione e i metadati di origine e destinazione. Per monitorare le metriche di eliminazione di Hubble, segui questi passaggi:

  1. Se non è già configurata, esegui il deployment di una risorsa PodMonitoring di Google Cloud Managed Service per Prometheus per eseguire lo scraping delle metriche di Hubble:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: hubble-metrics
  namespace: gke-managed-dpv2-observability
spec:
  selector:
    matchLabels:
      k8s-app: cilium
  endpoints:
  - port: hubble-metrics
    interval: 30s

  2. Esegui la seguente query in Cloud Monitoring > Esplora metriche per visualizzare le interruzioni per motivo:

    sum by (reason) (rate(hubble_drop_total[5m])) > 0

  3. Interpreta i codici reason comuni:

    • Policy denied: un NetworkPolicy di Kubernetes blocca la connessione in modo esplicito o implicito.
    • CT: Map insertion failed: la tabella di monitoraggio della connessione (conntrack) è esaurita.
    • Unsupported L3 protocol: pacchetto non IPv4 o IPv6 o intestazione danneggiata.

Passaggio 2: controlla i log di NetworkPolicy in Cloud Logging

Il logging di NetworkPolicy esporta log JSON strutturati per tutte le decisioni relative alle norme. Per eseguire query sui log di NetworkPolicy in Cloud Logging, segui questi passaggi:

  1. Nella console Google Cloud , vai a Cloud Logging > Esplora log.

  2. Esegui questa query:

    resource.type="k8s_node"
log_name:"projects/PROJECT_ID/logs/events"
jsonPayload.connection.verdict="DENY"
jsonPayload.src.pod_name="my-source-pod"

  3. Esamina il payload JSON:

    • jsonPayload.drop_reason: mostra il motivo per cui il pacchetto è stato ignorato.
    • jsonPayload.policies: elenca i NetworkPolicy valutati. Se viene restituito un elenco vuoto con un verdetto DENY, lo spazio dei nomi opera in modalità di negazione predefinita e nessuna policy ha consentito il traffico.

Se non vengono visualizzati log di NetworkPolicy, verifica che il logging sia abilitato nella risorsa personalizzata NetworkLogging del cluster. Ad esempio, verifica che il campo spec.cluster.deny.log sia impostato su true:

kubectl get networklogging default -o yaml

Passaggio 3: Trace i drop in tempo reale con Hubble CLI

Trasmetti in streaming i drop in tempo reale direttamente utilizzando Hubble CLI per ispezionare i pacchetti in tempo reale:

gke-hubble observe --verdict DROPPED --namespace default --follow

Output di esempio:

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:14:22.102          default/frontend     default/backend:80   to-stack DROPPED (Policy denied by NetworkPolicy: backend-deny-all)

L'output indica l'esatto NetworkPolicy che blocca il traffico (backend-deny-all).

Passaggio 4: verifica l'esaurimento di conntrack

Se il motivo della perdita indica CT: Map insertion failed:

  1. Ispeziona il log dell'agente GKE Dataplane V2 per verificare la saturazione della tabella conntrack:

    kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=100 | grep "Conntrack table full"

  2. Controlla la dimensione massima della tabella conntrack sul nodo interessato:

    kubectl exec -it -n kube-system daemonset/anetd -c cilium-agent -- cilium status --all-controllers | grep -i conntrack

    Se la tabella conntrack è piena, fai lo scale out dei workload su più nodi o riduci la frequenza di connessione dai pod client.

Diagnostica lo squilibrio del traffico e i reset TCP

Prima di risolvere i problemi relativi allo squilibrio del traffico e ai reset della connessione, esamina l'ambito della diagnostica e i prerequisiti:

  • Area di interesse: irregolarità del bilanciamento del carico, errori di handshake TCP, interruzione improvvisa della connessione.
  • Prerequisiti: metriche di GKE Dataplane V2 abilitate.
  • Compatibilità CNI: GKE Dataplane V2.
  • Sintomo: alcune repliche di pod ricevono un traffico eccessivo, mentre altre rimangono inattive; le applicazioni client registrano connection reset by peer o broken pipe.
  • Obiettivo: determinare se lo squilibrio del traffico è causato dalla persistenza della connessione a livello di trasporto (livello 4 OSI, TCP) rispetto al livello di applicazione (livello 7 OSI, HTTP/2 o gRPC) e identificare l'origine dei pacchetti TCP RST.

Passaggio 1: confronta il flusso di traffico a livello di pod

Per determinare se il traffico è distribuito in modo uniforme tra le repliche, procedi nel seguente modo:

  1. In Cloud Monitoring, esegui una query sul conteggio dei flussi in entrata in tutti i pod di un deployment:

    sum by (pod) (rate(pod_flow_ingress_flows_count{destination_workload="my-service"}[5m]))

  2. Valuta la distribuzione del traffico tra i pod. Se un singolo pod riceve la maggior parte del traffico, esamina il riutilizzo della connessione o le sessioni sticky:

    • gRPC o HTTP/2: le connessioni TCP di lunga durata fanno sì che tutte le richieste attraversino un singolo stream TCP verso un pod di backend. Il routing del servizio Kubernetes a livello di trasporto (livello 4 OSI, TCP) non può bilanciare le richieste all'interno di una connessione HTTP/2 stabilita.
    • Affinità di sessione ClientIP: verifica se il servizio è configurato con sessionAffinity: ClientIP.
    • Servizi headless: i client potrebbero risolvere il DNS una volta e memorizzare nella cache l'indirizzo IP singolo in modo permanente.

Passaggio 2: analizza le metriche di reimpostazione TCP

Le reimpostazioni TCP (RST) terminano immediatamente le connessioni. Vengono emessi dal kernel del sistema operativo quando un endpoint riceve un pacchetto per una porta sconosciuta o quando un'applicazione chiude una connessione con dati non letti nel buffer.

Esegui la seguente query MQL in Cloud Monitoring:

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, metric.traffic_direction], sum(val())

Esamina i risultati della query per determinare l'origine del reset:

  • RST in uscita (traffic_direction=egress): il pod locale sta generando il reset. Controlla se l'applicazione del pod si arresta in modo anomalo, raggiunge il limite di connessioni o rifiuta attivamente la connessione.
  • RST in entrata (traffic_direction=ingress): il peer remoto (database esterno, API o pod remoto) ha inviato il reset. Controlla lo stato del server di destinazione e del firewall.

Passaggio 3: trasmetti in streaming i reset TCP in tempo reale

Utilizza Hubble CLI per acquisire l'handshake di reset in tempo reale:

gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST --namespace default

Passaggio 4: correzione e soluzioni applicabili

Applica i seguenti passaggi di correzione a seconda della causa dello squilibrio del traffico o dei reset TCP:

  • Per la persistenza della connessione a livello di applicazione (livello 7 OSI) o gRPC:
    • Esegui il deployment di Cloud Service Mesh per abilitare il bilanciamento del carico a livello di richiesta del livello di applicazione (livello 7 OSI).
    • Configura i limiti di connessione lato client o i timeout keep-alive (ad esempio, MAX_CONNECTION_AGE e MAX_CONNECTION_AGE_GRACE di gRPC) per forzare il ripristino periodico della connessione.
  • Per l'affinità IP del servizio: rimuovi service.spec.sessionAffinity, a meno che lo stato dell'applicazione non lo richieda espressamente.
  • Per la memorizzazione nella cache DNS del servizio headless: assicurati che i runtime delle applicazioni (come JVM networkaddress.cache.ttl) non memorizzino nella cache i risultati DNS a tempo indeterminato.
  • Per l'overflow della coda di backlog dell'applicazione: quando una coda di ascolto dell'applicazione è piena, il kernel Linux elimina i pacchetti SYN in entrata o invia un TCP RST. Fai lo scale out delle repliche dei pod o aumenta il backlog di ascolto dell'applicazione (somaxconn).

Livello 2: osservabilità di nodi e CNI (kernel)

Il livello del nodo e della CNI comprende il kernel Linux host, i programmi eBPF e le interfacce di rete dei nodi. I colli di bottiglia a questo livello influiscono su tutti i workload in esecuzione sul nodo interessato.

Controllo dell'integrità del sistema: rilevamento di patch non autorizzate di anetd

GKE Dataplane V2 viene eseguito come DaemonSet gestito (anetd) nello spazio dei nomi kube-system. In Cloud Logging, puoi eseguire query sugli audit log di Kubernetes per rilevare se utenti non autorizzati o script automatici hanno applicato patch o riavviato anetd:

protoPayload.methodName="io.k8s.core.v1.daemonsets.patch" OR
protoPayload.methodName="io.k8s.core.v1.daemonsets.update"
protoPayload.resourceName="namespaces/kube-system/daemonsets/anetd"

Se viene rilevata un'applicazione di patch non autorizzata, ripristina la configurazione predefinita del DaemonSet o attiva la ricreazione del pool di nodi per ripristinare lo stato gestito.

Triage per la latenza a livello di nodo e i colli di bottiglia della CNI

Esamina l'ambito della diagnostica e i prerequisiti prima di diagnosticare la latenza a livello di nodo e i colli di bottiglia del kernel:

  • Area di interesse: latenza del kernel host, pacchetti persi nell'interfaccia della VM, saturazione dell'agente eBPF di GKE Dataplane V2, esaurimento di conntrack.
  • Prerequisiti: metriche delle VM di Compute Engine abilitate; accesso a kubectl.
  • Compatibilità CNI: GKE Dataplane V2 e CNI GKE standard.
  • Sintomo: il traffico tra nodi presenta picchi di latenza o cali casuali, mentre il traffico all'interno dei nodi rimane integro.
  • Obiettivo: distinguere tra limitazione della larghezza di banda della rete della VM host, interruzioni del kernel Linux e colli di bottiglia a livello di CNI.

Passaggio 1: distingui i problemi esterni a GKE da quelli interni a GKE

Esegui il test di base della VM di Compute Engine: esegui il deployment di una VM di Compute Engine autonoma nella stessa subnet VPC dei nodi del cluster GKE. Testa la connettività dalla VM alla destinazione target.

  • Se la VM autonoma presenta le stesse perdite di pacchetti o la stessa latenza: il problema si trova al di fuori di GKE (firewall VPC, Cloud NAT, Cloud Interconnect o il server esterno). Vai a Isola i problemi di connettività GKE rispetto a VPC o esterna.
  • Se la VM autonoma comunica normalmente, ma i pod GKE non funzionano: il problema è all'interno di GKE (eBPF, conntrack o CNI a livello di nodo). Vai al passaggio 2.

Passaggio 2: distingui i problemi dell'applicazione da quelli del livello dei nodi e di CNI

Per determinare se la latenza ha origine nell'applicazione o nel nodo e nel livello CNI, segui questi passaggi:

  1. Controlla la saturazione delle risorse dell'applicazione: verifica che il nodo non stia subendo una limitazione della CPU o una pressione della memoria, che ritarda l'elaborazione dei pacchetti nello spazio utente:

    kubectl top nodes
kubectl top pods -n default

  2. Controlla il conteggio conntrack del kernel Linux: controlla il conteggio conntrack attivo sull'host:

    # On a node where you have debugging access
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

    Se nf_conntrack_count si avvicina a nf_conntrack_max, il kernel host elimina i nuovi pacchetti TCP SYN.

Passaggio 3: verifica i pacchetti ignorati a livello di VM utilizzando la telemetria di Compute Engine

Google Cloud Compute Engine esporta le metriche dell'interfaccia di rete a livello di VM in Cloud Monitoring.

In Cloud Monitoring > Metrics Explorer, esegui la query:

sum by (drop_reason) (rate(compute_googleapis_com:instance_network_dropped_packets_count[5m]))
  • FQ_CODEL_DROP: pacchetto ignorato a causa della saturazione della coda Fair Queuing o CoDel (limite di larghezza di banda in uscita della VM superato).
  • FIREWALL_RULE_DROP: pacchetto ignorato da una regola firewall VPC.
  • RATE_LIMIT_DROP: pacchetto ignorato perché la VM ha superato la quota di pacchetti al secondo (PPS) massima dell'interfaccia di rete.

Passaggio 4: esamina le interruzioni a livello di kernel utilizzando eBPF

Se le metriche a livello di VM mostrano zero pacchetti persi, ma i pod GKE continuano a perdere pacchetti, controlla l'agente GKE Dataplane V2 (anetd) per verificare se ci sono pacchetti persi nella mappa eBPF:

kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=200 | grep -i "drop"

Cerca ct-map-insertion-failed o fib-lookup-failed.

Livello 3: osservabilità di VPC e routing (rete cloud)

Il livello di routing VPC e Cloud Router connette i nodi GKE ad altri servizi Google Cloud , alle reti on-premise e a internet. Gli errori in questo caso derivano in genere da regole firewall VPC, route personalizzate o configurazioni dei gateway.

Isola i problemi di connettività di GKE rispetto a VPC o esterni

Esamina l'ambito della diagnostica e i prerequisiti prima di isolare i problemi della rete esterna dagli errori all'interno del cluster:

  • Area di interesse: isolamento dei confini tra il routing interno di Kubernetes e il routing cloud VPC.
  • Prerequisiti: gcloud CLI; autorizzazioni per creare Connectivity Tests.
  • Compatibilità CNI: tutti i cluster.
  • Sintomo: i pod non riescono a connettersi a una risorsa esterna (ad esempio Cloud SQL, un'API on-premise o un endpoint di terze parti).
  • Obiettivo: determinare rapidamente se l'interruzione si verifica all'interno del nodo GKE o all'interno della rete VPC o esterna Google Cloud .

Passaggio 1: test di riferimento della VM di Compute Engine

Per eseguire il deployment di una VM di riferimento e valutare se il problema persiste al di fuori di GKE, segui questi passaggi:

  1. Esegui il deployment di un'istanza VM di Compute Engine temporanea nella stessa subnet VPC e nella stessa zona del pool di nodi GKE:

    gcloud compute instances create gke-baseline-tester \
    --zone=us-central1-a \
    --subnet=gke-subnet \
    --machine-type=e2-micro

  2. Connettiti all'istanza tramite SSH e testa la connettività alla destinazione:

    curl -v --connect-timeout 5 https://api.example.com

  3. Valuta il risultato:

    • Se la VM di Compute Engine non riesce a connettersi: il problema risiede nella rete VPC o nella rete esterna (regole firewall, tabelle di routing, esaurimento degli IP di Cloud NAT o inserimento nella lista consentita degli IP esterni).
    • Se la VM di Compute Engine si connette correttamente: il problema è all'interno di GKE (NetworkPolicy che blocca il traffico in uscita, CIDR del pod non mascherato o DNS a livello di container).

Passaggio 2: esegui un test on demand di Connectivity Tests

Esegui un test di Google Cloud Connectivity Tests dalla VM del nodo alla destinazione:

gcloud network-management connectivity-tests create test-node-to-dest \
    --source-instance=projects/PROJECT_ID/zones/us-central1-a/instances/gke-baseline-tester \
    --destination-ip-address=203.0.113.10 \
    --destination-port=443 \
    --protocol=TCP \
    --round-trip

Controlla il risultato nella console Google Cloud per identificare se una regola firewall o una route VPC sta eliminando il traffico.

Diagnostica la connettività utilizzando Connectivity Tests

Connectivity Tests simula i percorsi dei pacchetti attraverso le risorse GKE e VPC senza inviare traffico in tempo reale. Questa simulazione valuta la risoluzione DNAT da ClusterIP a pod del servizio, le regole in entrata e in uscita di NetworkPolicy di GKE Dataplane V2 e l'IP masquerading del nodo (SNAT). Esamina l'ambito della diagnostica e i prerequisiti prima di eseguire le simulazioni automatiche dei percorsi:

  • Area di interesse: simulazione automatica del percorso statico per pod, servizi, NetworkPolicy e route VPC di GKE.
  • Prerequisiti: Network Intelligence Center abilitato; API di gestione di rete abilitata.
  • Compatibilità CNI: GKE Dataplane V2 (analisi avanzata).
  • Sintomo: cali di connettività inspiegabili in cui tutte le configurazioni sembrano valide dopo un'ispezione manuale.
  • Obiettivo: simulare e tracciare staticamente l'intero percorso dei pacchetti da un pod di origine alla destinazione, identificando la riga esatta della policy che causa un'interruzione.

Scenario A: verifica se un NetworkPolicy GKE sta bloccando la raccolta delle metriche

Quando eseguono lo scraping delle metriche dai pod in uno spazio dei nomi sicuro, i raccoglitori di Google Cloud Managed Service per Prometheus potrebbero essere bloccati da un criterio NetworkPolicy di rifiuto predefinito:

gcloud network-management connectivity-tests create test-gmp-to-pod \
    --source-ip-address=10.0.0.15 \
    --destination-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/backend-pod \
    --destination-port=8080 \
    --protocol=TCP \
    --round-trip

Esamina la traccia di test nella console Google Cloud . Se il test termina al passaggio GKE Network Policy evaluation con DROP, è necessario aggiungere una regola in entrata per consentire il traffico dai pod del raccoglitore.

Scenario B: verifica la raggiungibilità di un servizio GKE

Simula la raggiungibilità da una VM client a un servizio Kubernetes interno:

gcloud network-management connectivity-tests create test-vm-to-service \
    --source-instance=projects/PROJECT_ID/zones/us-central1-a/instances/client-vm \
    --destination-ip-address=10.96.0.100 \
    --destination-port=80 \
    --protocol=TCP \
    --round-trip

La traccia simulata mostra:

  1. Corrispondenza della route VPC.
  2. Traffico in entrata e in uscita consentito dal firewall VPC.
  3. Arrivo al nodo GKE.
  4. DNAT del servizio all'indirizzo IP del pod di backend.
  5. Valutazione di NetworkPolicy in entrata sul pod di backend.

Scenario C: diagnostica i problemi di traffico in uscita dal pod a internet

Quando i pod non riescono a raggiungere un'API esterna su internet:

  1. Crea un test dal pod all'indirizzo IP pubblico esterno (ad esempio 8.8.8.8):

    gcloud network-management connectivity-tests create test-pod-to-internet \
    --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/app-pod \
    --destination-ip-address=8.8.8.8 \
    --destination-port=53 \
    --protocol=UDP \
    --round-trip

  2. Esamina il punto di rilascio:

    • Interrotto in NetworkPolicy: il pod non dispone di un criterio di rete in uscita che consenta il traffico verso 0.0.0.0/0.
    • Eliminato dal firewall VPC: una regola firewall VPC nega il traffico in uscita dalla subnet del nodo.
    • Eliminato in Cloud NAT o Route: la subnet non ha una route predefinita verso il gateway internet o Cloud NAT non è configurato per la subnet.

Livello 4: osservabilità di gateway esterno e costi (internet e NAT)

Il livello del gateway esterno gestisce il traffico in uscita verso destinazioni internet pubbliche tramite Cloud NAT o gateway esterni. L'osservabilità a questo livello aiuta a identificare i workload con traffico in uscita elevato e a controllare i costi di trasferimento dei dati.

Identifica il traffico NAT (traffico in uscita verso internet)

Prima di analizzare il traffico internet in uscita e NAT, esamina l'ambito della diagnostica e i prerequisiti:

  • Area di interesse: traffico internet in uscita, utilizzo delle porte Cloud NAT, costi di trasferimento di dati esterni.
  • Prerequisiti: osservabilità dei flussi di GKE Dataplane V2 abilitata.
  • Compatibilità CNI: GKE Dataplane V2.
  • Sintomo: errori di esaurimento delle porte Cloud NAT o costi di traffico in uscita verso internet inaspettatamente elevati.
  • Obiettivo: identificare gli oggetti pod e servizio GKE specifici che trasmettono traffico agli endpoint internet esterni.

Passaggio 1: comprendi i concetti di "to-stack" e "world" in GKE Dataplane V2

In GKE Dataplane V2:

  • world: rappresenta qualsiasi destinazione al di fuori del cluster GKE e della VPC (internet pubblico).
  • to-stack: rappresenta i pacchetti che passano dall'interfaccia veth del container eBPF allo stack di rete Linux dell'host per essere sottoposti a IP masquerading (SNAT) prima di raggiungere Cloud NAT.

Passaggio 2: trasmetti in streaming e filtra il traffico NAT con l'interfaccia a riga di comando di Hubble

Trasmetti in streaming i flussi internet in uscita in tempo reale provenienti dal tuo cluster:

# Stream egress flows heading to external internet ("world")
gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    --follow

Output di esempio:

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:25:01.120          default/worker-pod   142.250.190.46:443   to-stack FORWARDED

Per identificare i principali talker in uscita, puoi anche inviare l'output JSON di Hubble a jq per conteggiare i flussi di traffico in uscita esterno per pod:

timeout 60s gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    -o json | jq -r '.flow.source.namespace + "/" + .flow.source.pod_name' | sort | uniq -c | sort -nr | head -n 10

Passaggio 3: monitora il traffico esterno utilizzando le metriche

In Cloud Monitoring, monitora il volume dei flussi esterni:

fetch prometheus_target
| metric 'prometheus.googleapis.com/pod_flow_egress_flows_count/counter'
| filter (metric.destination_identity == 'world')
| align rate(1m)
| every 1m
| group_by [metric.source_workload, metric.source_namespace], sum(val())

Analizza i costi e le prestazioni del traffico del cluster utilizzando Flow Analyzer

Esamina l'ambito della diagnostica e i prerequisiti prima di visualizzare i flussi di traffico e i costi tra zone:

  • Area di interesse: costi di trasferimento di dati tra zone, top talker, visibilità del traffico tra nodi senza query SQL.
  • Prerequisiti: log di flusso VPC abilitati con INCLUDE_ALL_METADATA; visibilità tra nodi abilitata; analisi di osservabilità abilitata nel bucket di log.
  • Compatibilità CNI: tutti i cluster.
  • Sintomo: addebiti elevati per il trasferimento di dati tra zone nelle fatture mensili diGoogle Cloud .
  • Obiettivo: identificare visivamente quali workload GKE generano traffico tra zone e ottimizzare il posizionamento senza eseguire query sui log non elaborati.

Prerequisiti

Per utilizzare Flow Analyzer per GKE:

  1. Log di flusso VPC: devono essere abilitati nella subnet del cluster con metadata="INCLUDE_ALL_METADATA".
  2. Visibilità tra nodi: deve essere abilitata sul cluster in modo che il traffico tra pod sia esposto alla pipeline di logging dei flussi VPC.
  3. Analisi dei log: è necessario eseguire l'upgrade del bucket _Default in Cloud Logging per utilizzare Observability Analytics.

Passaggio 1: identifica i talker principali di GKE in Flow Analyzer

Per visualizzare i workload con volumi elevati in Flow Analyzer, segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina Analizzatore di flusso.
  2. Fai clic su Bucket di origine e seleziona il bucket di log che contiene i log di flusso. A meno che non li abbia indirizzati altrove, si tratta del bucket _Default.
  3. In Aggregazione del traffico, seleziona Origine - Destinazione.
  4. Imposta l'intervallo di tempo per la finestra di analisi.
  5. In Organizza i flussi per, seleziona i campi pod o workload GKE.
  6. Fai clic su Esegui nuova query. Il grafico Flussi di dati più elevati mostra quali workload spostano più dati.

Passaggio 2: analizza i costi del traffico tra zone

Il traffico tra zone comporta costi di trasferimento di dati. Per individuare i workload che trasmettono dati tra zone:

  1. In Organizza flussi per, seleziona i campi della zona di origine e della zona di destinazione.
  2. Fai clic su Esegui nuova query e leggi la tabella Tutti i flussi di dati. Le righe in cui le zone di origine e di destinazione sono diverse rappresentano il traffico tra zone. I filtri di Flow Analyzer corrispondono ai valori, quindi non puoi filtrare per "diverso da". Confronta invece le coppie di zone nei risultati.
  3. Espandi una coppia di zone con volumi elevati per visualizzare i workload GKE di origine e di destinazione sottostanti.

Correzione:

  • Implementa topologySpreadConstraints o podAffinity di Kubernetes per collocare i servizi di comunicazione all'interno della stessa zona di disponibilità.
  • Attiva il routing sensibile alla topologia (service.kubernetes.io/topology-mode: Auto) sul servizio per mantenere il traffico all'interno della zona di origine.

Passaggio 3: esegui il drill down in Observability Analytics (per query SQL avanzate)

In Flow Analyzer, fai clic su Visualizza in Analisi dei log per eseguire query SQL sui dati di flusso.

La seguente query SQL calcola i principali pod che comunicano tra zone:

SELECT
  JSON_VALUE(json_payload.src_gke_details.pod.workload.workload_name) AS src_workload,
  JSON_VALUE(json_payload.dest_gke_details.pod.workload.workload_name) AS dest_workload,
  JSON_VALUE(json_payload.src_instance.zone) AS src_zone,
  JSON_VALUE(json_payload.dest_instance.zone) AS dest_zone,
  SUM(CAST(JSON_VALUE(json_payload.bytes_sent) AS INT64)) / 1024 / 1024 / 1024 AS total_gb_sent
FROM
  `PROJECT_ID.global._Default._AllLogs`
WHERE
  log_name LIKE '%vpc_flows%'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND JSON_VALUE(json_payload.src_instance.zone) != JSON_VALUE(json_payload.dest_instance.zone)
GROUP BY
  1, 2, 3, 4
ORDER BY
  total_gb_sent DESC
LIMIT 20;

Riferimento per Hubble CLI e scheda di riferimento per le query

Hubble CLI trasmette e filtra i dati dei flussi di rete in tempo reale direttamente dal buffer circolare del kernel di GKE Dataplane V2.

Configurazione: crea un alias helper

Poiché Hubble viene eseguito all'interno del control plane del cluster, configura un alias della shell per eseguire i comandi Hubble senza eseguire il deployment dei file binari locali:

alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

Formule di filtro comuni

Goal di risoluzione dei problemi Comando Hubble CLI
Osserva tutti i pacchetti ignorati in tempo reale nel cluster gke-hubble observe --verdict DROPPED --follow
Trasmetti in streaming tutto il traffico per un pod specifico in qualsiasi spazio dei nomi gke-hubble observe --pod default/my-pod --follow
Filtra il traffico tra due spazi dei nomi specifici gke-hubble observe --from-namespace frontend --to-namespace backend
Isolare il traffico su una porta specifica (ad esempio la porta 80) gke-hubble observe --port 80
Ispeziona query e risposte DNS in tempo reale gke-hubble observe --port 53
Visualizza i reset TCP in tempo reale (pacchetti RST) gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST
Trasmetti in streaming tutto il traffico in uscita verso la rete internet pubblica gke-hubble observe --traffic-direction egress --to-identity world
Ispeziona il traffico a livello di applicazione HTTP (livello 7 OSI) gke-hubble observe --protocol http

Filtro avanzato con negazione (--not)

Puoi escludere il traffico noto con un volume elevato o integro per concentrarti sulle anomalie:

# Observe drops, but exclude internal kube-system health probes and DNS
gke-hubble observe \
    --verdict DROPPED \
    --not --namespace kube-system \
    --not --port 53

Formattazione dell'output e integrazione di jq

Per elaborare i record di flusso in modo programmatico, genera l'output in formato JSON:

# Extract only source, destination, and drop reason from the last 100 flows
gke-hubble observe --verdict DROPPED -o json --last 100 | \
    jq -r '[.time, .flow.source.pod_name, .flow.destination.pod_name, .flow.drop_reason_desc] | @tsv'

Limitazioni

Quando utilizzi Hubble CLI per la risoluzione dei problemi in tempo reale, tieni presente le seguenti limitazioni tecniche:

  • Buffer circolare temporaneo locale per nodo: i flussi Hubble vengono archiviati in un buffer circolare in memoria su ogni singolo nodo. Durante gli eventi con traffico elevato, i log di flusso meno recenti vengono sovrascritti in pochi secondi. Per l'analisi storica, utilizza il logging di NetworkPolicy e i log di flusso VPC in Cloud Logging.
  • Nessun OR logico integrato: i flag dell'interfaccia a riga di comando di Hubble valutano più argomenti utilizzando l'AND logico. Per cercare più condizioni (ad esempio, porta 80 O porta 443), esegui comandi separati o filtra l'output JSON utilizzando jq.

Passaggi successivi