Risolvere i problemi di rete di Google Distributed Cloud

Questa pagina mostra come risolvere i problemi di networking con Google Distributed Cloud. Vengono fornite informazioni e indicazioni generali per la risoluzione dei problemi, oltre a strumenti suggeriti. Sono incluse anche informazioni sulla risoluzione dei problemi DNS e alcuni problemi comuni per Calico, Seesaw e MetalLB.

Risoluzione dei problemi di connettività di rete

Il networking di GKE Enterprise si basa sulla tua infrastruttura di rete fisica. Ad esempio, Seesaw o MetalLB si basano sugli switch che rispettano l'ARP gratuito, il bilanciamento del carico in bundle con Border Gateway Protocol (BGP) si basa sui router e tutti i nodi devono essere in grado di comunicare tra loro. Quando si verifica un problema di rete nei cluster GKE, devi identificare se il problema riguarda i componenti di GKE Enterprise o la tua infrastruttura.

Innanzitutto, determina l'ambito del problema, quindi prova a identificare i componenti interessati. L'ambito di un problema può rientrare in una delle tre categorie: il soggetto (da dove), il target (a cui) e il livello di rete.

L'ambito dell'argomento può essere uno dei seguenti:

  • Tutti i nodi (o pod hostNetwork) a livello di cluster.
  • Tutti i pod a livello di cluster.
  • Tutti i pod su un singolo nodo o un insieme di nodi.
  • Tutti i pod dello stesso deployment o DaemonSet.
  • Client dall'esterno del cluster.

L'ambito del target può essere uno o più dei seguenti:

  • Tutti gli altri indirizzi IP dei pod dello stesso cluster.
  • Tutti gli altri indirizzi IP dei pod dello stesso nodo.
  • VIP del servizio ClusterIP dello stesso cluster.
  • VIP del servizio LoadBalancer dello stesso cluster.
  • Bilanciatore del carico di livello 7 in entrata (Istio).
  • Altri nodi dello stesso cluster.
  • Nome DNS interno (ad es. *.svc.cluster.local).
  • Nome DNS esterno (ad es. google.com).
  • Entità esterne al cluster.
  • Entità su internet.

Il livello di rete può essere uno o più dei seguenti:

  • Problemi del livello di collegamento di livello 2, come sistema vicino, ARP o NDP.
  • Problemi di routing dell'indirizzo IP di livello 3.
  • Problemi relativi agli endpoint TCP o UDP di livello 4.
  • Problemi HTTP o HTTPS di livello 7.
  • Problemi di risoluzione DNS.

Comprendere l'ambito di un problema aiuta a identificare i componenti coinvolti e a capire a quale livello si verifica il problema. La raccolta di informazioni quando si verifica il problema è importante perché alcuni problemi sono temporanei, quindi gli snapshot dopo il ripristino del sistema non includeranno informazioni sufficienti per l'analisi della causa principale.

Problemi di Ingress

Se il soggetto è un client esterno al cluster e non è riuscito a connettersi a un servizio LoadBalancer, si tratta di un problema di connettività nord-sud. Il seguente diagramma mostra che in un esempio funzionante il traffico in entrata attraversa lo stack da sinistra a destra, mentre il traffico di ritorno lo attraversa da destra a sinistra. Seesaw è diverso perché il traffico di ritorno salta il bilanciatore del carico e torna direttamente al client:

Il traffico in entrata passa dall'utente all'infrastruttura fisica, attraverso un bilanciatore del carico ad anetd / kube-proxy e poi al backend. Con Seesaw, il traffico in uscita ignora il bilanciatore del carico.

Quando si verifica un problema con questo flusso di traffico, utilizza il seguente diagramma di flusso per la risoluzione dei problemi per identificare la causa del problema:

Risoluzione dei problemi di ingresso di rete esaminando ogni passaggio di un pacchetto mentre si sposta nel tuo ambiente. Controlla se lungo il percorso esistono le azioni e la connettività appropriate.

In questo diagramma di flusso, le seguenti indicazioni per la risoluzione dei problemi aiutano a determinare la causa del problema:

  • Il pacchetto esce dal client? In caso contrario, è probabile che si sia verificato un problema con l'infrastruttura di rete.
  • Utilizzi il bilanciatore del carico di Seesaw? In tal caso, il pacchetto arriva al nodo Seesaw e l'ARP viene inviato correttamente? In caso contrario, è probabile che si sia verificato un problema con l'infrastruttura di rete.
  • Utilizzi MetalLB? In tal caso, il pacchetto arriva al nodo LB e l'ARP viene inviato correttamente? In caso contrario, probabilmente hai un problema con l'infrastruttura di rete.
  • Utilizzi F5 BIG-IP e, in caso affermativo, hai verificato la presenza di problemi con F5?
  • Network Address Translation (NAT) viene eseguita correttamente? In caso contrario, è probabile che tu abbia un problema con kube-proxy / Dataplane V2.
  • Il pacchetto arriva al nodo worker? In caso contrario, probabilmente hai un problema di Calico / Dataplane v2 Pod-to-Pod.
  • Il pacchetto arriva al pod? In caso contrario, è probabile che si sia verificato un problema di inoltro locale di Calico / Dataplane v2.

Le sezioni seguenti forniscono i passaggi per risolvere i problemi di ogni fase e determinare se il traffico scorre correttamente o meno.

Il pacchetto esce dal client?

Controlla se il pacchetto esce correttamente dal client e passa attraverso il router configurato nell'infrastruttura di rete fisica.

  1. Utilizza tcpdump per controllare il pacchetto quando lascia il client per il servizio di destinazione:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Se non vedi il traffico in uscita, questa è la causa del problema.

Il pacchetto arriva a un nodo Seesaw?

Se utilizzi Seesaw, consulta la documentazione della versione 1.16, trova il nodo master e poi connettiti al nodo utilizzando SSH.

  1. Utilizza tcpdump per verificare se i pacchetti previsti sono arrivati al nodo Seesaw:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Se non vedi traffico in entrata, questo è l'origine del problema.

Il pacchetto arriva a un nodo LoadBalancer?

Se utilizzi MetalLB come bilanciatore del carico:

  1. Esamina il log metallb-controller per determinare quale nodo del bilanciatore del carico gestisce il VIP del servizio:

    kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP

  2. Connettiti al nodo tramite SSH.

  3. Per un nodo MetalLB, utilizza tcpdump per esaminare il traffico:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Per ManualLB, il traffico potrebbe arrivare su qualsiasi nodo. A seconda della configurazione del bilanciamento del carico, puoi scegliere uno o più nodi. Utilizza tcpdump per esaminare il traffico:

    tcpdump -ni any host NODE_IP and port NODE_PORT

    Il comando è diverso tra i tipi di bilanciatore del carico, poiché MetalLB e Seesaw non eseguono NAT prima di inoltrare il pacchetto ai nodi.

    Se non vedi traffico in nessun nodo, questo è l'origine del problema.

Si è verificato un problema con F5 BIG-IP?

Per risolvere i problemi relativi a F5 BIG-IP, consulta una delle seguenti sezioni in Il servizio F5 non riceve traffico.

L'ARP è stato inviato correttamente?

Il nodo del bilanciatore del carico per MetalLB o Seesaw si basa su ARP per pubblicizzare il VIP del servizio. Se la risposta ARP viene inviata correttamente, ma il traffico non viene ricevuto, è un segnale di un problema nell'infrastruttura di rete fisica. Una causa comune di questo problema è che alcune funzionalità di apprendimento avanzate del dataplane ignorano la risposta ARP nelle soluzioni di rete definita dal software (SDN).

  1. Utilizza tcpdump per rilevare le risposte ARP:

    tcpdump -ni any arp

    Cerca di trovare il messaggio che pubblicizza il VIP con cui riscontri problemi.

    • Per Seesaw, vengono inviati ARP gratuiti per tutti i VIP. Dovresti visualizzare i messaggi ARP per ogni VIP ogni 10 secondi.

    • Per MetalLB, non invia ARP gratuiti. La frequenza con cui visualizzi una risposta dipende da quando un altro dispositivo, ad esempio uno switch ToR (Top of Rack) o uno switch virtuale, invia una richiesta ARP.

Viene eseguito il NAT?

Dataplane v2 / kube-proxy esegue la Network Address Translation di destinazione (NAT di destinazione o DNAT) per tradurre il VIP di destinazione in un indirizzo IP del pod di backend. Se sai quale nodo è il backend del bilanciatore del carico, connettiti al nodo utilizzando SSH.

  1. Utilizza tcpdump per verificare se il VIP del servizio è tradotto correttamente:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. Per Dataplane v2, puoi anche connetterti ai pod anetd e utilizzare gli strumenti di debug Cilium incorporati:

    cilium monitor --type=drop

Per ulteriori informazioni, consulta una delle seguenti sezioni relative ai problemi di Dataplane V2 / Cilium.

Il pacchetto arriva a un nodo worker?

Sui nodi worker, il pacchetto arriva sull'interfaccia esterna e viene poi recapitato ai pod.

  1. Verifica se il pacchetto arriva all'interfaccia esterna, in genere denominata eth0 o ens192, utilizzando tcpdump:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

Poiché i backend di servizio normali contengono più pod su nodi diversi, potrebbe essere difficile risolvere i problemi relativi al nodo in errore. Una soluzione alternativa comune è acquisire il problema per un periodo di tempo sufficiente affinché arrivi un pacchetto o limitare il numero di backend a uno.

Se il pacchetto non arriva mai al nodo di lavoro, è un'indicazione di un problema dell'infrastruttura di rete. Contatta il team dell'infrastruttura di rete per scoprire perché il pacchetto viene eliminato tra i nodi LoadBalancer e i nodi worker. Alcuni problemi comuni includono:

  • Controlla i log della rete software-defined (SDN). A volte, la SDN potrebbe eliminare i pacchetti per vari motivi, ad esempio segmentazione, checksum errato o anti-spoofing.
  • Regole firewall che filtrano i pacchetti la cui destinazione è l'indirizzo IP e la porta del pod di backend.

Se il pacchetto arriva all'interfaccia esterna o all'interfaccia tunnel del nodo, deve essere inoltrato al pod di destinazione. Se il pod è un pod di rete host, questo passaggio non è necessario perché il pod condivide lo spazio dei nomi di rete con il nodo. In caso contrario, è necessario l'inoltro di pacchetti aggiuntivi.

Ogni pod ha coppie di interfacce Ethernet virtuali, che funzionano come tubi. Un pacchetto inviato a un'estremità dell'interfaccia viene ricevuto dall'altra estremità dell'interfaccia. Una delle interfacce viene spostata nello spazio dei nomi di rete del pod e rinominata in eth0. L'altra interfaccia viene mantenuta nello spazio dei nomi host. CNI diverse hanno schemi diversi. Per Dataplane v2, l'interfaccia viene normalmente denominata lxcxxxx. I nomi hanno numeri di interfaccia consecutivi, ad esempio lxc17 e lxc18. Puoi controllare se il pacchetto arriva al pod utilizzando tcpdump oppure puoi specificare l'interfaccia:

tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Se il pacchetto arriva al nodo, ma non al pod, controlla la tabella di routing nel seguente modo:

ip route

Normalmente, ogni pod deve avere una voce di routing che indirizzi l'indirizzo IP del pod all'interfaccia lxc. Se la voce non è presente, di solito significa che il percorso dati CNI presenta un errore. Per determinare la causa principale, controlla i log di CNI DaemonSet.

Problemi in uscita

Se il traffico può entrare in un pod, potresti avere un problema con il traffico in uscita dal pod. I seguenti diagrammi mostrano che in un esempio funzionante il traffico in entrata attraversa lo stack da sinistra a destra:

Il traffico in uscita passa dal pod all'interfaccia esterna dell'host all'infrastruttura fisica e poi al servizio esterno.

  1. Per verificare che il pacchetto in uscita si mascheri correttamente come indirizzo IP del nodo, controlla il servizio esterno (livello 4).

    L'indirizzo IP sorgente del pacchetto deve essere mappato dall'indirizzo IP del pod all'indirizzo IP del nodo con Network Address Translation dell'origine (source NAT o SNAT). In Dataplane v2, questo processo viene eseguito tramite ebpf caricato su un'interfaccia esterna. Calico utilizza le regole iptables.

    Utilizza tcpdump per verificare se l'indirizzo IP di origine è stato convertito correttamente dall'indirizzo IP del pod all'indirizzo IP del nodo:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    Se tcpdump mostra che i pacchetti sono mascherati correttamente, ma il servizio remoto non risponde, controlla la connessione al servizio esterno nella tua infrastruttura.

  2. Se i pacchetti in uscita vengono mascherati correttamente come indirizzo IP del nodo, controlla la connettività dell'host esterno (livello 3) utilizzando tcpdump:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    Contemporaneamente all'esecuzione di tcpdump, esegui il ping da uno dei pod:

    kubectl exec POD_NAME ping EXTERNAL_IP

    Se non vedi risposte ping, controlla la connessione al servizio esterno nella tua infrastruttura.

Problemi nel cluster

Per i problemi di connettività tra pod, prova a limitare il problema ai nodi. Spesso, un gruppo di nodi non può comunicare con un altro gruppo di nodi.

  1. In Dataplane v2, controlla la connettività dei nodi dal nodo attuale a tutti gli altri nodi dello stesso cluster. All'interno del pod anetd, controlla lo stato di integrità:

    cilium status --all-health

    Google Distributed Cloud utilizza la modalità di routing diretto. Dovresti vedere una voce di route per nodo nel cluster, come mostrato nell'esempio seguente:

    # <pod-cidr> via <node-ip> dev <external-interface>
192.168.1.0/24 via 21.0.208.188 dev ens192
192.168.2.0/24 via 21.0.208.133 dev ens192

    Se manca una route prevista per un nodo, la connessione a quel nodo viene persa.

Problemi a livello di rete

Identificare in quale livello di rete si verifica il problema di connettività è un passaggio importante. Un messaggio di errore come "Problema di connettività da un'origine a una destinazione" non fornisce informazioni sufficienti per risolvere il problema, che potrebbe essere un errore dell'applicazione, un problema di routing o un problema DNS. Comprendere a quale livello si verifica il problema aiuta a correggere il componente giusto.

Spesso, i messaggi di errore indicano direttamente in quale livello si verifica il problema. I seguenti esempi possono aiutarti a risolvere i problemi relativi al livello di rete:

  • Gli errori HTTP indicano che si tratta di un problema di livello 7.
    • I codici HTTP 40x, 50x o gli errori di handshake TLS indicano che tutto funziona normalmente al livello 4.
  • Gli errori "Connessione reimpostata dal peer" indicano un problema di livello 4.
    • Spesso, il socket remoto non è d'accordo con lo stato attuale di una connessione e invia un pacchetto RESET. Questo comportamento potrebbe essere un errore nel monitoraggio delle connessioni o NAT.
  • Gli errori "No route to host" e "Connection timeout" sono in genere un problema di livello 3 o livello 2.
    • Questi errori indicano che il pacchetto non può essere indirizzato correttamente alla destinazione.

Strumenti utili per la risoluzione dei problemi

I DaemonSet correlati alla rete vengono eseguiti sui nodi e potrebbero essere la causa di problemi di connettività. Tuttavia, anche una configurazione errata di nodi, switch top of rack (ToR), router spine o firewall può causare problemi. Puoi utilizzare i seguenti strumenti per determinare l'ambito o il livello del problema e stabilire se si tratta di un problema con i nodi GKE Enterprise o con l'infrastruttura fisica.

Dindin

Ping funziona al livello 3 (livello IP) e controlla il percorso tra un'origine e una destinazione. Se il ping non riesce a raggiungere una destinazione, spesso significa che il problema si verifica al livello 3.

Tuttavia, non tutti gli indirizzi IP sono pingabili. Ad esempio, alcuni VIP del bilanciatore del carico non sono pingabili se si tratta di un bilanciatore del carico di livello 4 puro. Il servizio ClusterIP è un esempio in cui il VIP potrebbe non restituire una risposta ping. Al livello 4, questo servizio restituisce una risposta ping solo quando specifichi un numero di porta, ad esempio VIP:port.

I bilanciatori del carico BGPLB, MetalLB e Seesaw in Google Distributed Cloud funzionano tutti al livello 3. Puoi utilizzare ping per controllare la connettività. Sebbene F5 sia diverso, supporta anche ICMP. Puoi utilizzare ping per controllare la connettività al VIP F5.

Arping

Arping è simile a ping, tranne per il fatto che funziona al livello 2. I problemi di livello 2 e livello 3 spesso hanno messaggi di errore simili dalle applicazioni. Arping e ping possono aiutare a distinguere il problema. Ad esempio, se l'origine e la destinazione si trovano nella stessa subnet, ma non riesci a eseguire arping sulla destinazione, si tratta di un problema di livello 2.

Un arping <ip> riuscito restituisce l'indirizzo MAC della destinazione. Al livello 2, questo indirizzo indica spesso un problema di infrastruttura fisica. Questo problema è dovuto a un'errata configurazione dello switch virtuale.

Arping può anche rilevare conflitti di indirizzi IP. Un conflitto di indirizzi IP si verifica quando due macchine sono configurate per utilizzare lo stesso indirizzo IP sulla stessa subnet oppure quando un VIP viene utilizzato da un'altra macchina fisica. I conflitti di indirizzi IP possono creare problemi intermittenti difficili da risolvere. Se arping <ip> restituisce più di una voce di indirizzo MAC, significa che si è verificato un conflitto di indirizzi IP.

Dopo aver ottenuto l'indirizzo MAC da arping, puoi utilizzare https://maclookup.app/ per cercare il produttore dell'indirizzo MAC. Ogni produttore possiede un prefisso MAC, quindi puoi utilizzare queste informazioni per determinare quale dispositivo sta tentando di utilizzare lo stesso indirizzo IP. Ad esempio, VMware possiede il blocco 00:50:56, quindi un indirizzo MAC 00:50:56:xx:yy:zz è una VM nel tuo ambiente vSphere.

iproute2

La CLI per iproute2ip ha molti sottocomandi utili, ad esempio:

  • ip r: stampa la tabella di routing
  • ip n: stampa la tabella dei vicini per la mappatura dell'indirizzo IP all'indirizzo MAC
  • ip a: stampa tutte le interfacce sulla macchina

Una route mancante o una voce mancante nella tabella dei vicini potrebbe causare problemi di connettività dal nodo. Anetd e Calico gestiscono la tabella di routing e la tabella dei vicini. Una configurazione errata in queste tabelle può causare problemi di connettività.

Interfaccia a riga di comando Cilium / Hubble per Dataplane v2

Ogni pod anetd dispone di diversi strumenti di debug utili per i problemi di connettività:

  • cilium monitor --type=drop
    • Stampa il log per ogni pacchetto eliminato da anetd / Cilium.
  • hubble observe
    • Stampa tutti i pacchetti che attraversano lo stack eBPF di anetd.
  • cilium status --all-health
    • Stampa lo stato di Cilium, incluso lo stato della connettività da nodo a nodo. Ogni pod anetd controlla l'integrità di tutti gli altri nodi del cluster e può aiutarti a determinare eventuali problemi di connettività tra i nodi.

iptables

Iptables vengono utilizzati in molti componenti e sottosistemi di Kubernetes. kube-proxy utilizza iptables per implementare la risoluzione dei servizi. Calico utilizza iptables per implementare la policy di rete

  1. Per risolvere i problemi di rete a livello di iptables, utilizza il seguente comando:

    iptables -L -v | grep DROP

    Esamina le regole di eliminazione e controlla il numero di pacchetti e di byte per verificare se aumentano nel tempo.

Tcpdump

Tcpdump è un potente strumento di acquisizione dei pacchetti che genera molti dati sul traffico di rete. Una pratica comune è eseguire tcpdump sia dall'origine che dalla destinazione. Se un pacchetto viene acquisito quando lascia il nodo di origine, ma mai acquisito sul nodo di destinazione, significa che qualcosa nel mezzo lo elimina. Questo comportamento di solito indica che qualcosa nella tua infrastruttura fisica elimina erroneamente il pacchetto.

Metriche

Google Distributed Cloud contiene più metriche per aiutarti a monitorare il comportamento della tua rete. Le seguenti metriche rappresentano un buon punto di partenza:

Categoria Metrica Descrizione
Pacchetti persi cilium_drop_bytes_total Byte eliminati totali, taggati in base al motivo dell'eliminazione e alla direzione in entrata/uscita. Questa metrica è un buon punto di partenza per analizzare i cali a livello di byte.
cilium_drop_count_total Pacchetti eliminati totali, taggati in base al motivo dell'eliminazione e alla direzione in entrata/uscita.
container_network_receive_packets_dropped_total Conteggio cumulativo dei pacchetti eliminati durante la ricezione. Campionamento eseguito ogni 60 secondi.
container_network_transmit_packets_dropped_total Conteggio cumulativo dei pacchetti persi durante la trasmissione. Campionamento eseguito ogni 60 secondi.
Pacchetti inoltrati cilium_forward_bytes_total Byte totali inoltrati, taggati in base alla direzione in entrata/in uscita. Campionamento eseguito ogni 60 secondi. Questa metrica fornisce informazioni sull'inoltro a livello di byte.
cilium_forward_count_total Pacchetti inoltrati totali, taggati in base alla direzione in entrata/in uscita. Campionamento eseguito ogni 60 secondi. Questa metrica indica il conteggio dei pacchetti per il traffico inoltrato.
cilium_policy_l7_forwarded_total Totale richieste inoltrate di livello 7.
Pacchetti ricevuti cilium_policy_l7_received_total Numero totale di richieste/risposte L7 ricevute. Campionamento eseguito ogni 60 secondi.
container_network_receive_bytes_total Conteggio cumulativo dei byte ricevuti. Campionamento eseguito ogni 60 secondi.
container_network_receive_packets_total Conteggio cumulativo dei pacchetti ricevuti. Campionamento eseguito ogni 60 secondi.
container_network_receive_errors_total Conteggio cumulativo degli errori riscontrati durante la ricezione. Campionamento eseguito ogni 60 secondi.
cilium_kubernetes_events_received_total Numero di eventi Kubernetes ricevuti etichettati in base ad ambito, azione, dati validi e uguaglianza. Campionamento eseguito ogni 60 secondi.
BPF cilium_bpf_maps_virtual_memory_max_bytes Le mappe BPF indicano le dimensioni massime di utilizzo della memoria del kernel in byte.
cilium_bpf_progs_virtual_memory_max_bytes Dimensioni massime di utilizzo della memoria del kernel dei programmi BPF in byte.
Conntrack node_nf_conntrack_entries Numero di voci di flusso attualmente allocate per il monitoraggio delle connessioni. Campionamento eseguito ogni 60 secondi.
node_nf_conntrack_entries_limit Dimensione massima della tabella di monitoraggio delle connessioni. Campionamento eseguito ogni 60 secondi.
Connettività cilium_node_connectivity_latency_seconds L'ultima latenza osservata tra l'agente Cilium corrente e gli altri nodi Cilium in secondi. Campionamento eseguito ogni 60 secondi.
cilium_node_connectivity_status L'ultimo stato osservato della connettività ICMP e HTTP tra l'agente Cilium attuale e gli altri nodi Cilium. Campionamento eseguito ogni 60 secondi.
Operatori Cilium cilium_operator_process_cpu_seconds_total Tempo di CPU totale di utente e sistema trascorso in secondi. Campionamento eseguito ogni 60 secondi.
cilium_operator_process_max_fds Numero massimo di descrittori di file aperti. Campionamento eseguito ogni 60 secondi.
cilium_operator_process_open_fds Numero di descrittori di file aperti. Campionamento eseguito ogni 60 secondi.
cilium_operator_process_resident_memory_bytes Dimensioni della memoria residente in byte. Campionamento eseguito ogni 60 secondi.
cilium_operator_process_start_time_seconds Ora di inizio del processo dall'epoca Unix in secondi. Campionamento eseguito ogni 60 secondi.
cilium_operator_process_virtual_memory_bytes Dimensioni della memoria virtuale in byte. Campionamento eseguito ogni 60 secondi.
cilium_operator_process_virtual_memory_max_bytes Quantità massima di memoria virtuale disponibile in byte. Campionamento eseguito ogni 60 secondi.
cilium_operator_identity_gc_entries Il numero di identità attive ed eliminate al termine di un'esecuzione del garbage collector. Campionamento eseguito ogni 60 secondi.
cilium_operator_identity_gc_runs Il numero di volte in cui è stato eseguito il Garbage Collector delle identità. Campionamento eseguito ogni 60 secondi.

Per ricevere notifiche quando una di queste metriche supera o scende al di sotto di una determinata soglia, crea criteri di avviso. Per saperne di più, consulta la sezione Creare criteri di avviso basati su soglie delle metriche nella documentazione di Cloud Monitoring.

Per scoprire di più su queste metriche e visualizzare l'elenco completo, consulta Metriche di Google Distributed Cloud.

Risoluzione dei problemi del DNS

I problemi di risoluzione DNS rientrano in due categorie principali:

  • Pod regolari, che utilizzano i server DNS nel cluster.
  • Pod o nodi di rete host, che non utilizzano server DNS nel cluster

Le sezioni seguenti forniscono alcune informazioni sull'architettura DNS del cluster e suggerimenti utili prima di iniziare a risolvere i problemi di una di queste categorie.

Architettura DNS del cluster

Un servizio DNS del cluster risolve le richieste DNS per i pod nel cluster. CoreDNS fornisce questo servizio per Google Distributed Cloud versione 1.9.0 e successive.

Ogni cluster ha due o più pod coredns e un gestore della scalabilità automatica responsabile dello scaling del numero di pod DNS in base alle dimensioni del cluster. Esiste anche un servizio denominato kube-dns che bilancia il carico delle richieste tra tutti i pod coredns di backend.

La maggior parte dei pod ha il DNS upstream configurato sull'indirizzo IP del servizio kube-dns e i pod inviano richieste DNS a uno dei pod coredns. Le richieste DNS possono essere raggruppate in una delle seguenti destinazioni:

  • Se la richiesta riguarda un dominio cluster.local, si tratta di un nome DNS nel cluster che fa riferimento a un servizio o a un pod nel cluster.
    • CoreDNS monitora api-server per tutti i servizi e i pod nel cluster e risponde alle richieste di domini cluster.local validi.
  • Se la richiesta non riguarda un dominio cluster.local, si tratta di un dominio esterno.
    • CoreDNS inoltra la richiesta ai nameserver upstream. Per impostazione predefinita, CoreDNS utilizza i nameserver upstream configurati sul nodo su cui è in esecuzione.

Per saperne di più, consulta la panoramica del funzionamento e della configurazione del DNS in Kubernetes.

Suggerimenti per la risoluzione dei problemi DNS

Per risolvere i problemi DNS, puoi utilizzare gli strumenti dig e nslookup. Questi strumenti ti consentono di inviare richieste DNS per verificare se la risoluzione DNS funziona correttamente. I seguenti esempi mostrano come utilizzare dig e nslookup per verificare la presenza di problemi di risoluzione DNS.

  • Utilizza dig o nslookup per inviare una richiesta per google.com:

    dig google.com
nslookup google.com

  • Utilizza dig per inviare una richiesta di kubernetes.default.svc.cluster.local al server 192.168.0.10:

    dig @192.168.0.10 kubernetes.default.svc.cluster.local

  • Puoi anche utilizzare nslookup per eseguire la stessa ricerca DNS del comando dig precedente:

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    Esamina l'output dei comandi dig o nslookup. Se ricevi una risposta errata o nessuna risposta, significa che si è verificato un problema di risoluzione DNS.

Pod regolari

Il primo passaggio per eseguire il debug di un problema DNS consiste nel determinare se le richieste raggiungono i pod coredns o meno. Spesso un problema generale di connettività del cluster viene visualizzato come problema DNS perché una richiesta DNS è il primo tipo di traffico inviato da un workload.

Controlla i messaggi di errore delle tue applicazioni. Errori come io timeout o simili indicano che non c'è risposta e che si è verificato un problema generale di connettività di rete.

I messaggi di errore che includono un codice di errore DNS come NXDOMAIN o SERVFAIL indicano che la connettività al server DNS nel cluster è presente, ma il server non è riuscito a risolvere il nome di dominio:

  • Gli errori NXDOMAIN indicano che il server DNS segnala che il dominio non esiste. Verifica che il nome di dominio richiesto dalla tua applicazione sia valido.
  • Gli errori SERVFAIL o REFUSED indicano che il server DNS ha inviato una risposta, ma non è stato in grado di risolvere il dominio o convalidare la sua inesistenza. Per ulteriori informazioni, controlla i log dei pod coredns.

Puoi trovare l'indirizzo IP del servizio kube-dns utilizzando il seguente comando:

kubectl -n kube-system get svc kube-dns

Da un pod in cui il DNS non funziona, prova a inviare una richiesta DNS a questo indirizzo IP utilizzando dig o nslookup, come descritto in una sezione precedente:

  • Se queste richieste non funzionano, prova a inviarle all'indirizzo IP di ciascun pod coredns.
  • Se alcuni pod funzionano, ma altri no, verifica se ci sono pattern riconoscibili, ad esempio la risoluzione DNS funziona per i pod sullo stesso nodo del pod coredns, ma non tra i nodi. Questo comportamento potrebbe indicare un problema di connettività all'interno del cluster.

Se CoreDNS non riesce a risolvere i nomi di dominio esterni, consulta la sezione seguente per risolvere i problemi relativi ai pod host-network. CoreDNS si comporta come un pod di rete host e utilizza i server DNS upstream del nodo per la risoluzione dei nomi.

Pod o nodi di rete host

I pod di rete host e i nodi utilizzano i nameserver configurati sul nodo per la risoluzione DNS, non il servizio DNS nel cluster. A seconda del sistema operativo, questo server dei nomi è configurato in /etc/resolv.conf o /run/systemd/resolve/resolv.conf. Questa configurazione impedisce la risoluzione dei nomi di dominio cluster.local.

Se riscontri problemi con la risoluzione dei nomi di rete host, utilizza i passaggi per la risoluzione dei problemi nelle sezioni precedenti per verificare se il DNS funziona correttamente per i tuoi nameserver upstream.

Problemi di rete comuni

Le sezioni seguenti descrivono in dettaglio alcuni problemi di rete comuni che potresti riscontrare. Per risolvere il problema, segui le indicazioni per la risoluzione dei problemi appropriate. Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Calico

Errore comune: calico/node is not ready: BIRD is not ready: BGP not established

Questo errore di stato "non pronto" in Kubernetes di solito indica che un determinato peer non è raggiungibile nel cluster. Verifica che la connettività BGP tra i due peer sia consentita nel tuo ambiente.

Questo errore può verificarsi anche se sono configurate risorse dei nodi inattive per la mesh da nodo a nodo. Per risolvere il problema, ritira i nodi obsoleti.

Dataplane v2 / Cilium

Errore comune: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

Questo errore indica che l'evento di creazione del pod è stato rifiutato dall'agente Cilium a causa di un limite di frequenza. Per ogni nodo, Cilium ha un limite di quattro richieste simultanee all'endpoint PUT. Quando si verifica un picco di richieste a un nodo, questo comportamento è previsto. L'agente Cilium deve recuperare le richieste in ritardo.

In GKE Enterprise 1.14 e versioni successive, il limite di frequenza si adatta automaticamente alla capacità del nodo. Il limitatore di velocità può convergere verso un numero più ragionevole, con limiti di velocità più elevati per i nodi più potenti.

Errore comune: Ebpf map size is full

Dataplane v2 memorizza lo stato in una mappa eBFP. Lo stato include le regole di servizio, monitoraggio della connessione, identità del pod e Network Policy. Se una mappa è piena, l'agente non può inserire voci, il che crea una discrepanza tra il piano di controllo e il piano dati. Ad esempio, la mappa dei servizi ha un limite di 64.000 voci.

  1. Per controllare le voci della mappa eBFP e le loro dimensioni attuali, utilizza bpftool. L'esempio seguente controlla le mappe del bilanciatore del carico:

    bpftool map dump pinned \
/sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1

bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1

  2. Se la mappa è vicina al limite di 64.000, puliscila. Il seguente esempio pulisce le mappe del bilanciatore del carico:

    bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key

  3. Per riempire nuovamente lo stato nella mappa eBFP, riavvia anetd.

Nodo non pronto a causa di errori NetworkPluginNotReady

Se il pod CNI non è in esecuzione sul nodo, potresti visualizzare un errore simile al seguente:

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Il nodo potrebbe anche essere in stato non pronto, con un errore simile al seguente esempio:

  "Network plugin not installed"

Quando un nodo viene inizializzato, kubelet attende che si verifichino diversi eventi prima di contrassegnare il nodo come Ready. Uno degli eventi che kubelet controlla è che il plug-in Container Network Interface (CNI) sia installato. Il plug-in CNI deve essere installato da anetd o Calico utilizzando un contenitore init per installare sia il binario CNI sia la configurazione CNI nelle directory host richieste.

Per risolvere il problema, controlla perché i pod non vengono eseguiti sul nodo. In genere, l'errore non è dovuto a problemi di rete. Questi pod vengono eseguiti sulla rete host, quindi non esiste alcuna dipendenza di rete.

  1. Controlla lo stato del pod anetd o calico-node. Per determinare la causa del problema, segui questi passaggi per la risoluzione dei problemi:

    • Se il pod è nello stato Crashlooping, controlla i log per scoprire perché non può essere eseguito correttamente.
    • Se il pod è nello stato Pending, utilizza kubectl describe e rivedi gli eventi del pod. Ad esempio, al pod potrebbe mancare una risorsa come un volume.
    • Se il pod è nello stato Running, controlla i log e la configurazione. Alcune implementazioni CNI forniscono opzioni per disattivare l'installazione di CNI, come in Cilium.
    • In anetd è presente un'opzione di configurazione chiamata custom-cni-conf. Se questa impostazione è configurata come true, anetd non installerà il proprio binario CNI.

Nodo NOT READY a causa di voci ARP obsolete

A volte, le voci ARP obsolete nei nodi del control plane del cluster di amministrazione possono causare una mancata corrispondenza degli indirizzi MAC. Questo mancato abbinamento degli indirizzi può, a sua volta, causare timeout di connessione ai VIP del control plane dei cluster utente gestiti. I timeout della connessione possono portare al nodo con voci ARP obsolete contrassegnate come NOT READY. I nodi contrassegnati come NOT READY possono bloccare le installazioni e gli upgrade del cluster.

In questa situazione, il log kubelet sul nodo con voci ARP obsolete contiene un errore di timeout dell'handshake TLS come il seguente:

failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout

Per verificare e risolvere il problema, procedi nel seguente modo:

  1. Utilizza SSH per connetterti al nodo del control plane del cluster utente.

  2. Verifica l'indirizzo MAC dell'interfaccia a cui è associato l'indirizzo VIP:

    ip a | grep DEVICE_NAME: -A 6

    Sostituisci DEVICE_NAME con il nome del dispositivo di rete per il nodo del control plane.

  3. Utilizza SSH per connetterti a un nodo del control plane del cluster di amministrazione.

  4. Controlla la cache ARP sul control plane del cluster di amministrazione per l'indirizzo VIP del control plane del cluster utente:

    ip n | grep VIP_ADDRESS

    Sostituisci VIP_ADDRESS con l'indirizzo IP del VIP del control plane del cluster utente (controlPlaneVIP).

    Se i due comandi ip restituiscono un indirizzo MAC diverso, il problema ti riguarda.

  5. Per risolvere il problema, svuota la cache ARP sul nodo del control plane del cluster di amministrazione:

    ip n flush all

Il servizio F5 non riceve traffico

Se non viene trasmesso traffico al servizio F5, esamina i seguenti passaggi per la risoluzione dei problemi:

  1. Verifica che ogni partizione in F5 BIG-IP sia configurata in un cluster, amministrativo o utente. Se una partizione è condivisa da più cluster diversi, si verificano interruzioni intermittenti della connessione. Questo comportamento si verifica perché due cluster tentano di assumere il controllo della stessa partizione ed eliminano i servizi dagli altri cluster.

  2. Verifica che i seguenti due pod siano in esecuzione. I pod non in esecuzione indicano un errore:

    Load-balancer-f5
K8s-bigip-ctlr-deployment-577d57985d-vk9wj

    Load-balancer-f5 di proprietà di GKE Enterprise e crea ConfigMap per ogni servizio di tipo LoadBalancer. Il ConfigMap viene infine utilizzato dal controller bigip.

  3. Assicurati che esista ConfigMap per ogni porta di ogni servizio. Ad esempio, con le seguenti porte:

    Kube-server-443-tcp     2   31h
Kube-server-8132-tcp        2   31h

    Il servizio kube-server dovrebbe essere simile all'esempio seguente:

    Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h

    La sezione dei dati in ConfigMap deve contenere l'indirizzo VIP e la porta del frontend, come mostrato nell'esempio seguente:

    data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
  schema: f5schemadb://bigip-virtual-server_v0.1.7.json

  4. Controlla i log e le metriche dell'istanza BIG-IP. Se ConfigMap è configurato correttamente, ma l'istanza BIG-IP non rispetta la configurazione, potrebbe trattarsi di un problema di F5. Per i problemi che si verificano all'interno dell'istanza BIG-IP, contatta l'assistenza F5 per diagnosticare e risolvere i problemi.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui: