Risolvi i problemi di osservabilità di rete GKE

Questo documento fornisce istruzioni e procedure diagnostiche per diagnosticare i problemi di rete 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 il livello dello stack di rete GKE che probabilmente causa il problema e vai alla sezione corrispondente.

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

Concetti di base del networking

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

  • eBPF (Extended Berkeley Packet Filter): una tecnologia del sistema operativo che consente di eseguire programmi di monitoraggio e routing sicuri direttamente all'interno del kernel Linux. GKE Dataplane V2 utilizza eBPF per instradare i pacchetti e applicare NetworkPolicy con un overhead delle prestazioni minimo.
  • 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 con l'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: conntrack del kernel Linux standard (utilizzata da ip-masq-agent) e una tabella conntrack gestita da Cilium e GKE Dataplane V2 memorizzata 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 su flussi di traffico, perdita di pacchetti e valutazione di NetworkPolicy.

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

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

Diagnosticare gli errori di risoluzione DNS

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

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

Passaggio 1: controllo di raggiungibilità di base

Prima di risolvere i problemi relativi ai livelli DNS, verifica se la destinazione è raggiungibile direttamente utilizzando il relativo 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 funziona: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 dei criteri. Vai a Diagnosticare i pacchetti ignorati e i blocchi NetworkPolicy.
Controlla il pre-popolamento 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:

  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 eliminando le query.
kubernetes.io/networking/dns/kubedns/dns_request_latencies p99 > 100ms Latenza di risoluzione DNS end-to-end elevata 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 delle prestazioni e del timeout DNS

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

  1. Controlla la percentuale successi cache:query 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 di /etc/resolv.conf.
  2. Valuta la latenza upstream:un valore elevato di forwarding_request_latencies indica problemi con il server DNS upstream (ad esempio, il DNS on-premise aziendale raggiunto tramite Cloud Interconnect o Cloud VPN oppure limiti di Cloud DNS).

  3. Controlla gli override DNS personalizzati:esamina i ConfigMap kube-dns personalizzati per 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 live con Hubble CLI

Utilizza l'alias helper Hubble CLI per esaminare 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 simultanei, 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

Prima di esaminare le eliminazioni di pacchetti e i rifiuti delle norme, rivedi l'ambito della diagnostica e i prerequisiti:

  • Area di interesse:cali di traffico tra oggetti Pod o tra oggetti Pod e Service, applicazione di NetworkPolicy, motivi di eliminazione di eBPF del kernel.
  • Prerequisiti: osservabilità del flusso di GKE Dataplane V2 abilitata; registrazione di NetworkPolicy configurata.
  • Compatibilità CNI:solo GKE Dataplane V2.
  • Sintomo:i tentativi di connessione dell'applicazione non riescono con Connection timed out o Connection reset by peer.
  • Obiettivo: individuare il motivo esatto per cui NetworkPolicy o eBPF eliminano i pacchetti senza modifiche per tentativi alle norme di sicurezza.

Passaggio 1: monitora le metriche di Hubble Drop

Quando GKE Dataplane V2 elimina un pacchetto, emette la metrica hubble_drop_total taggata con il motivo dell'eliminazione e i metadati di origine e destinazione. Per monitorare le metriche di Hubble Drop:

  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 criterio di rete Kubernetes blocca esplicitamente o implicitamente la connessione.
    • CT: Map insertion failed: la tabella di monitoraggio delle connessioni (conntrack) è esaurita.
    • Unsupported L3 protocol: pacchetto non IPv4 o IPv6 o intestazione danneggiata.

Passaggio 2: controlla i log NetworkPolicy in Cloud Logging

La registrazione di NetworkPolicy esporta log JSON strutturati per tutte le decisioni relative ai criteri. Per interrogare i log NetworkPolicy in Cloud Logging:

  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. Ispeziona il payload JSON:

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

Se non vengono visualizzati log NetworkPolicy, verifica che la registrazione sia abilitata 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 le interruzioni live con Hubble CLI

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

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'esatta NetworkPolicy che blocca il traffico (backend-deny-all).

Passaggio 4: controlla l'esaurimento di conntrack

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

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

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

  2. Controlla le dimensioni massime 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, esegui lo scale out dei carichi di lavoro su più nodi o riduci la frequenza di connessione dai pod client.

Diagnosticare lo sbilanciamento del traffico e i reset TCP

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

  • Area di interesse:bilanciamento del carico non uniforme, errori di handshake TCP, interruzione improvvisa della connessione.
  • Prerequisiti:metriche GKE Dataplane V2 abilitate.
  • Compatibilità CNI: GKE Dataplane V2.
  • Sintomo:alcune repliche del pod ricevono traffico eccessivo, mentre altre rimangono inattive; le applicazioni client registrano connection reset by peer o broken pipe.
  • Obiettivo:determinare se lo sbilanciamento del traffico è causato dalla persistenza della connessione a livello di trasporto (livello 4 OSI, TCP) rispetto al livello 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 del flusso di ingresso 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 permanenti:

    • gRPC o HTTP/2:le connessioni TCP di lunga durata fanno sì che tutte le richieste attraversino un singolo flusso TCP a 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à sessione ClientIP:verifica se il servizio è configurato con sessionAffinity: ClientIP.
    • Servizi headless:i client potrebbero risolvere il DNS una sola volta e memorizzare nella cache l'indirizzo IP singolo in modo permanente.

Passaggio 2: analizza le metriche di ripristino TCP

I reset 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 ripristino:

  • RST in uscita (traffic_direction=egress): il pod locale genera il ripristino. Controlla se l'applicazione Pod va in arresto anomalo, raggiunge il limite di connessione o rifiuta attivamente la connessione.
  • RST in entrata (traffic_direction=ingress): il peer remoto (database esterno, API o pod remoto) ha inviato il ripristino. Controlla l'integrità del server di destinazione e gli stati del firewall.

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

Utilizza Hubble CLI per acquisire l'handshake di ripristino live:

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

Passaggio 4: correzione e soluzioni pratiche

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

  • Per la persistenza della connessione a livello di applicazione (livello 7 del modello OSI) o gRPC:
    • Esegui il deployment di Cloud Service Mesh per attivare il bilanciamento del carico a livello di richiesta (livello 7 OSI).
    • Configura i limiti di connessione lato client o i timeout keep-alive (ad esempio, gRPC MAX_CONNECTION_AGE e MAX_CONNECTION_AGE_GRACE) per forzare il ristabilimento periodico della connessione.
  • Per l'affinità IP del servizio, rimuovi service.spec.sessionAffinity a meno che lo stato dell'applicazione non lo richieda rigorosamente.
  • Per la memorizzazione nella cache DNS del servizio headless, assicurati che i runtime dell'applicazione (ad esempio JVM networkaddress.cache.ttl) non memorizzino nella cache i risultati DNS in modo indefinito.
  • 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. Fare lo scale out delle repliche dei pod o aumentare il backlog di ascolto dell'applicazione (somaxconn).

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

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

Controllo dell'integrità del sistema: rileva l'applicazione di patch non autorizzate ad anetd

GKE Dataplane V2 viene eseguito come DaemonSet gestito (anetd) nello spazio dei nomi kube-system. In Cloud Logging, puoi eseguire query sui log di controllo 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 una patch non autorizzata, ripristina la configurazione predefinita di 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 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, perdita di pacchetti nell'interfaccia VM, saturazione dell'agente eBPF di GKE Dataplane V2, esaurimento di conntrack.
  • Prerequisiti:metriche VM di Compute Engine abilitate; accesso kubectl.
  • Compatibilità CNI:GKE Dataplane V2 e CNI GKE standard.
  • Sintomo:il traffico tra nodi subisce picchi di latenza o cali casuali, mentre il traffico all'interno del nodo rimane integro.
  • Obiettivo:distinguere tra limitazione della larghezza di banda della rete VM host, eliminazioni del kernel Linux e colli di bottiglia a livello di CNI.

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

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

  • Se la VM autonoma presenta gli stessi pacchetti persi 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 Isolare i problemi di connettività GKE rispetto a VPC o esterna.
  • Se la VM autonoma comunica normalmente, ma i pod GKE non funzionano:il problema si verifica all'interno di GKE (eBPF a livello di nodo, conntrack o CNI). Vai al passaggio 2.

Passaggio 2: differenzia i problemi dell'applicazione dai problemi dei livelli di nodi e 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 riscontrando limitazione della CPU o pressione della memoria, il che ritarda l'elaborazione dei pacchetti nello spazio utente:

    kubectl top nodes
kubectl top pods -n default

  2. Ispeziona 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 delle eliminazioni di pacchetti 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 eliminato a causa della saturazione della coda Fair Queuing o CoDel (limite di larghezza di banda in uscita della VM superato).
  • FIREWALL_RULE_DROP: pacchetto eliminato da una regola firewall VPC.
  • RATE_LIMIT_DROP: pacchetto eliminato perché la VM ha superato la quota massima di pacchetti al secondo (PPS) dell'interfaccia di rete.

Passaggio 4: esamina i cali a livello di kernel utilizzando eBPF

Se le metriche a livello di VM mostrano zero pacchetti eliminati, ma i pod GKE eliminano comunque pacchetti, ispeziona l'agente GKE Dataplane V2 (anetd) per verificare se sono stati eliminati pacchetti 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 connette i nodi GKE ad altri Google Cloud servizi, reti on-premise e internet. Gli errori in questa sezione in genere derivano da regole firewall VPC, route personalizzate o configurazioni del gateway.

Isolare i problemi di connettività GKE rispetto a VPC o alla connettività esterna

Esamina l'ambito e i prerequisiti della diagnostica prima di isolare i problemi di rete esterni dagli errori nel 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 Google Cloud rete VPC o esterna.

Passaggio 1: test di base della VM Compute Engine

Per eseguire il deployment di una VM di base e valutare se il problema persiste al di fuori di GKE, procedi nel seguente modo:

  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 utilizzando SSH e testa la connettività alla destinazione:

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

  3. Valuta il risultato:

    • Se la VM Compute Engine non riesce a connettersi, il problema si trova nella rete VPC o esterna (regole firewall, tabelle di routing, esaurimento degli IP Cloud NAT o inclusione degli IP esterni nella lista consentita).
    • Se la VM Compute Engine si connette correttamente, il problema si verifica all'interno di GKE (NetworkPolicy che blocca il traffico in uscita, CIDR 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 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

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

Diagnosticare la connettività utilizzando Connectivity Tests

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

  • Area di interesse: simulazione automatizzata 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: interruzioni della connettività inspiegabili in cui tutte le configurazioni sembrano valide dopo l'ispezione manuale.
  • Obiettivo: simulare e tracciare staticamente l'intero percorso del pacchetto da un'origine Pod alla destinazione, identificando la riga esatta della policy che causa un errore.

Scenario A: verifica se una NetworkPolicy GKE blocca la raccolta delle metriche

Quando esegui 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 NetworkPolicy di tipo default-deny:

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

Esamina la traccia del 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 della 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

La traccia simulata mostra:

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

Scenario C: diagnostica dei problemi di uscita da 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

  2. Esamina il punto di consegna:

    • Eliminato in NetworkPolicy: il pod non dispone di un NetworkPolicy 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 dispone di una route predefinita al gateway internet o Cloud NAT non è configurato per la subnet.

Livello 4: osservabilità del gateway esterno e dei 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 consente di identificare i carichi di lavoro con traffico in uscita elevato e controllare i costi di trasferimento dei dati.

Identifica il traffico NAT (in uscita verso internet)

Esamina l'ambito e i prerequisiti della diagnostica prima di analizzare il traffico internet in uscita e NAT:

  • Area di interesse:traffico internet in uscita, utilizzo delle porte Cloud NAT, costi di trasferimento dei dati esterni.
  • Prerequisiti: osservabilità del flusso 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 quali oggetti Pod e Service GKE specifici trasmettono traffico a 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 rete VPC (la rete internet pubblica).
  • to-stack: rappresenta i pacchetti che passano dall'interfaccia veth del container eBPF allo stack di rete Linux host per essere sottoposti a mascheramento IP (SNAT) prima di raggiungere Cloud NAT.

Passaggio 2: trasmetti in streaming e filtra il traffico NAT con Hubble CLI

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 mittenti in uscita, puoi anche inviare l'output JSON di Hubble a jq per conteggiare i flussi in uscita esterni 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 il rendimento 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 dei dati tra zone, principali comunicatori, visibilità del traffico tra nodi senza query SQL.
  • Prerequisiti: log di flusso VPC abilitati con INCLUDE_ALL_METADATA; visibilità tra nodi abilitata; analisi dell'osservabilità abilitata nel bucket di log.
  • Compatibilità CNI: tutti i cluster.
  • Sintomo: costi di trasferimento di dati tra zone elevati sulle fatture mensili Google Cloud .
  • Obiettivo:identificare visivamente quali carichi di lavoro 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 i pod venga esposto alla pipeline di logging del flusso 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 ad alto volume in Flow Analyzer:

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

Passaggio 2: analizza i costi del traffico tra zone

Il traffico tra zone comporta costi per il trasferimento di dati. Per individuare i carichi di lavoro che trasmettono dati tra zone:

  1. Nella sezione 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 "non uguale"; confronta invece le coppie di zone nei risultati.
  3. Espandi una coppia di zone ad alto volume per visualizzare i workload GKE di origine e di destinazione sottostanti.

Correzione:

  • Implementa Kubernetes topologySpreadConstraints o podAffinity per collocare i servizi di comunicazione all'interno della stessa zona di disponibilità.
  • Abilita il routing topologia consapevole (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 pod che comunicano di più tra le 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;

Scheda di riferimento e query di Hubble CLI

Hubble CLI trasmette in streaming e filtra i dati sul flusso di rete in tempo reale direttamente dal buffer circolare del kernel 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 di file binari locali:

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

Ricette di filtraggio comuni

Risoluzione dei problemi relativi all'obiettivo Comando Hubble CLI
Osserva tutti i pacchetti eliminati 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
Filtrare 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
Esaminare le query e le risposte DNS live gke-hubble observe --port 53
Visualizza i ripristini TCP attivi (pacchetti RST) gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST
Trasmetti in streaming tutto il traffico in uscita diretto alla 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 ad alto volume 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 locale temporaneo del 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, fai affidamento al logging di NetworkPolicy e ai log di flusso VPC in Cloud Logging.
  • Nessun OR logico integrato:i flag della CLI Hubble valutano più argomenti utilizzando 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