Risolvi i problemi di rete di Google Distributed Cloud

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

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

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. Se si verifica un problema di rete nei cluster GKE, devi identificare se il problema riguarda i componenti 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ò essere una di tre categorie: l'oggetto (da dove), il target (a cui) e il livello della rete.

L'ambito del soggetto 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 esterno al 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 di pod dallo stesso nodo.
  • VIP del servizio ClusterIP dello stesso cluster.
  • VIP del servizio LoadBalancer dallo stesso cluster.
  • LoadBalancer Ingress Layer 7 (Istio).
  • Altri nodi dello stesso cluster.
  • Nome DNS interno (ad esempio *.svc.cluster.local).
  • Nome DNS esterno (ad esempio google.com).
  • Entità esterne al cluster.
  • Entità su internet.

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

  • Problemi di strato di collegamento di livello 2 come sistema vicino, ARP o NDP.
  • Problemi di routing degli indirizzi IP di livello 3.
  • Problemi con l'endpoint TCP o UDP di livello 4.
  • Problemi HTTP o HTTPS di livello 7.
  • Problemi di risoluzione DNS.

Comprendere l'ambito di un problema consente di identificare i componenti coinvolti e il livello in cui si verifica. La raccolta di informazioni quando si verifica il problema è importante perché alcuni problemi sono temporanei, pertanto gli snapshot successivi al ripristino del sistema non includeranno informazioni sufficienti per l'analisi della causa principale.

Problemi relativi al traffico in entrata

Se il soggetto è un client dall'esterno del 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 viaggia attraverso lo stack da sinistra a destra e il traffico di ritorno torna indietro attraverso lo stack da destra a sinistra. Seesaw è diverso perché il traffico di ritorno ignora 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 quindi al backend. Con Seesaw, il traffico in uscita salta 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 dove si trova:

Risolvi i problemi di traffico in entrata nella rete esaminando ogni passaggio effettuato da un pacchetto durante lo spostamento attraverso l'ambiente. Verifica che lungo il percorso esistano le azioni e la connettività appropriate.

In questo diagramma di flusso, le seguenti indicazioni per la risoluzione dei problemi aiutano a determinare dove si trova il problema:

  • Il pacchetto lascia il client? In caso contrario, è probabile che tu abbia un problema di infrastruttura di rete.
  • Stai utilizzando il bilanciatore del carico Seesaw? In tal caso, il pacchetto arriva al nodo Seesaw e l'ARP viene inviato correttamente? In caso contrario, è probabile che tu abbia un problema di infrastruttura di rete.
  • Utilizzi MetalLB? In tal caso, il pacchetto arriva al nodo LB e viene inviato correttamente ARP? In caso contrario, è probabile che ci sia un problema di infrastruttura di rete.
  • Stai utilizzando F5 BIG-IP e, in tal caso, hai controllato se ci sono problemi con F5?
  • La 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, è probabile che esista un problema tra pod in un pod in Calico / Dataplane v2.
  • Il pacchetto arriva al pod? In caso contrario, è probabile che esista un problema di inoltro locale di Calico / Dataplane v2.

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

Il pacchetto lascia il client?

Verifica che il pacchetto lasci correttamente il client e passi attraverso il router configurato nella tua 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 traffico in uscita, questa è la causa del problema.

Il pacchetto arriva a un nodo Seesaw?

Se utilizzi Seesaw come bilanciatore del carico, trova il nodo master e poi connettiti al nodo tramite SSH.

  1. Usa 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, questa è la causa del problema.

Il pacchetto arriva al nodo LoadBalancer?

Se utilizzi MetalLB come bilanciatore del carico:

  1. Esamina il log metallb-controller per determinare quale nodo del bilanciatore del carico serve 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 bilanciatore 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 la NAT prima di inoltrare il pacchetto ai nodi.

    Se non vedi traffico che entra in nessun nodo, questa è l'origine del problema.

Esiste un problema di BIG-IP di F5?

Per risolvere i problemi relativi a BIG-IP di F5, consulta una delle sezioni seguenti 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 è stata inviata correttamente, ma il traffico non arriva, è un segnale di un problema nella tua infrastruttura di rete fisica. Una causa comune di questo problema è che alcune funzionalità di apprendimento piano dati avanzate ignorano la risposta ARP nelle soluzioni di rete software-defined (SDN).

  1. Usa tcpdump per rilevare le risposte ARP:

    tcpdump -ni any arp

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

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

    • Per MetalLB, non vengono inviati ARP gratuiti. La frequenza con cui viene visualizzata una risposta dipende dal momento in cui un altro dispositivo, ad esempio uno switch Top of rack (ToR) o uno switch virtuale, invia una richiesta ARP.

La funzionalità NAT viene eseguita?

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

  1. Utilizza tcpdump per verificare che il VIP del servizio sia 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 sui problemi relativi a Dataplane v2 / Cilium.

Il pacchetto arriva a un nodo worker?

Sui nodi worker, il pacchetto arriva all'interfaccia esterna e viene quindi consegnato ai pod.

  1. Verifica se il pacchetto arriva all'interfaccia esterna, generalmente 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 in nodi diversi, potrebbe essere difficile risolvere i problemi relativi al nodo in errore. Una soluzione alternativa comune è acquisire il problema abbastanza a lungo da far arrivare qualche pacchetto oppure limitare il numero di backend a uno.

Se il pacchetto non arriva mai al nodo di lavoro, significa che esiste un problema di infrastruttura di rete. Verifica con il team dell'infrastruttura di rete perché il pacchetto viene ignorato tra nodi LoadBalancer e nodi worker. Ecco alcuni problemi comuni:

  • Controlla i log di rete software-defined (SDN). A volte, l'SDN potrebbe eliminare i pacchetti per vari motivi, ad esempio per 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 del nodo o all'interfaccia del tunnel, deve essere inoltrato al pod di destinazione. Se il pod è un pod di networking dell'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 dei tubi. Un pacchetto inviato a un'estremità dell'interfaccia viene ricevuto dall'altra estremità. Una delle interfacce viene spostata nello spazio dei nomi di rete del pod e rinominata eth0. L'altra interfaccia è mantenuta nello spazio dei nomi dell'host. CNI diversi hanno uno schema diverso. Per Dataplane v2, l'interfaccia è in genere denominata lxcxxxx. I nomi contengono numeri di interfaccia consecutivi, come lxc17 e lxc18. Puoi verificare se il pacchetto arriva al pod utilizzando tcpdump oppure puoi anche specificare l'interfaccia:

  tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Se il pacchetto arriva al nodo ma non riesce ad arrivare al pod, controlla la tabella di routing come segue:

  ip route

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

Problemi in uscita

Se il traffico può entrare in un pod, potrebbe esserci un problema con il traffico che evade dal pod. I seguenti diagrammi mostrano che in un esempio funzionante il traffico in entrata passa attraverso lo stack da sinistra a destra:

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

  1. Per verificare che il pacchetto in uscita venga mascherato correttamente da indirizzo IP del nodo, controlla il servizio esterno (livello 4).

    L'indirizzo IP di origine del pacchetto deve essere mappato dall'indirizzo IP del pod all'indirizzo IP del nodo con la Network Address Translation di origine (NAT o SNAT di origine). In Dataplane v2, questo processo si ottiene mediante ebpf caricato su un'interfaccia esterna. Calico utilizza le regole iptables.

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

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    Se tcpdump indica che il mascheramento dei pacchetti è corretto, ma il servizio remoto non risponde, controlla la connessione al servizio esterno nell'infrastruttura.

  2. Se i pacchetti in uscita sono 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 le risposte dei ping, controlla la connessione al servizio esterno nella tua infrastruttura.

Problemi nel cluster

Per i problemi di connettività tra pod, prova a definire l'ambito del problema in base ai nodi. Spesso un gruppo di nodi non può comunicare con un altro gruppo di nodi.

  1. In Dataplane v2, controlla la connettività del nodo dal nodo attuale a tutti gli altri nodi nello stesso cluster. Dall'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 per un nodo manca una route prevista, viene persa la connessione con quel nodo.

Problemi relativi al livello di rete

Identificare il livello di rete in cui si verifica il problema di connettività è un passaggio importante. Un messaggio di errore del tipo "Un problema di connettività da un'origine a una destinazione" non è abbastanza informativo per risolvere il problema, che potrebbe essere un errore dell'applicazione, un problema di routing o un problema relativo al DNS. Capire a quale livello si verifica il problema aiuta a correggere il componente giusto.

Spesso i messaggi di errore indicano direttamente su quale livello si verifica il problema. Gli esempi seguenti possono aiutarti a risolvere le domande a livello di rete:

  • Gli errori HTTP indicano che si tratta di un problema di livello 7.
    • Gli errori dei codici HTTP 40x, 50x o di handshake TLS indicano che tutto funziona normalmente a livello 4.
  • Gli errori "Connessione reimpostata dal peer" indicano che si tratta di un problema di livello 4.
    • Molte volte il socket remoto non riesce a essere d'accordo con lo stato attuale di una connessione, quindi invia un pacchetto RESET. potrebbe trattarsi di un errore nel monitoraggio della connessione, o NAT.
  • Gli errori "Nessuna route all'host" e "Timeout connessione" sono in genere problemi di livello 3 o 2.
    • Questi errori indicano che non è possibile instradare il pacchetto correttamente alla destinazione.

Strumenti utili per la risoluzione dei problemi

I DaemonSet relativi alla rete vengono eseguiti sui tuoi nodi e potrebbero causare problemi di connettività. Tuttavia, anche la configurazione errata di nodi, switch top of rack (ToR), router spine o firewall possono causare problemi. Puoi utilizzare gli strumenti seguenti per determinare l'ambito o il livello del problema e determinare se si tratta di un problema dei tuoi nodi GKE Enterprise o della tua infrastruttura fisica.

Dindin

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

Tuttavia, non è possibile inviare un ping a tutti gli indirizzi IP. Ad esempio, alcuni VIP non possono inviare un ping se sono 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 usare ping per verificare la connettività. Sebbene F5 sia diverso, supporta anche ICMP. Puoi utilizzare ping per verificare la connettività al VIP F5.

Arredamento

L'Arping è simile al ping, ad eccezione del fatto che funziona per il livello 2. I problemi di livello 2 e 3 presentano spesso 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 ad eseguire l'associazione della destinazione, si tratta di un problema di livello 2.

Un'istruzione arping <ip> riuscita restituisce l'indirizzo MAC della destinazione. Al livello 2, questo indirizzo indica spesso un problema di infrastruttura fisica. Si tratta di un errore di configurazione dello switch virtuale.

Arping può anche rilevare conflitti tra indirizzi IP. Un conflitto di indirizzi IP si verifica quando due macchine sono configurate per utilizzare lo stesso indirizzo IP nella stessa subnet o 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 dell'indirizzo MAC, significa che è presente 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 è proprietaria del blocco 00:50:56, quindi un indirizzo MAC 00:50:56:xx:yy:zz è una VM nel tuo ambiente vSphere.

iproute2

L'interfaccia a riga di comando ip per iproute2 dispone di molti sottocomandi utili, tra cui:

  • ip r: stampa la tabella delle route
  • ip n: stampa la tabella vicina per la mappatura tra indirizzi IP e indirizzi MAC
  • ip a: stampa tutte le interfacce della macchina

Una route mancante o una voce mancante nella tabella vicina potrebbe causare problemi di connettività dal nodo. Sia Anetd che Calico gestiscono la tabella delle route e la tabella dei vicini. Un'errata configurazione 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 utili di debug per i problemi di connettività:

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

IPtables

Gli iptable vengono utilizzati in molti componenti e sottosistemi di Kubernetes. kube-proxy utilizza iptables per implementare la risoluzione del servizio. Calico utilizza iptables per implementare il criterio 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 vedere se aumentano nel tempo.

Tcpdump

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

Risoluzione dei problemi del DNS

I problemi di risoluzione DNS rientrano in due categorie principali:

  • Pod normali, che utilizzano i server DNS nel cluster.
  • Pod o nodi della 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 per 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 1.9.0 e versioni successive.

Ogni cluster ha due o più pod coredns e un gestore della scalabilità automatica responsabile della scalabilità del numero di pod DNS rispetto 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 è per un dominio cluster.local, si tratta di un nome DNS in-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, allora la richiesta riguarda un dominio esterno.
    • CoreDNS inoltra la richiesta ai server dei nomi upstream. Per impostazione predefinita, CoreDNS utilizza i server dei nomi upstream configurati sul nodo su cui viene eseguito.

Per ulteriori informazioni, consulta la panoramica sul funzionamento e la configurazione del DNS in Kubernetes.

Suggerimenti per la risoluzione dei problemi relativi al DNS

Per risolvere i problemi relativi al DNS, puoi usare 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.

  • Usa 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

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

Pod normali

Il primo passaggio per eseguire il debug di un problema DNS consiste nel determinare se le richieste vengono inviate o meno ai pod coredns. Spesso un problema generale di connettività dei cluster viene visualizzato come problemi DNS, perché una richiesta DNS è il primo tipo di traffico inviato da un carico di lavoro.

Esamina i messaggi di errore delle tue applicazioni. Errori come io timeout o simili indicano che non è stata ricevuta alcuna risposta e un problema di connettività di rete generale.

I messaggi di errore che includono un codice di errore DNS come NXDOMAIN o SERVFAIL indicano che esiste connettività al server DNS nel cluster, 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 richiesta 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 di verificare che non esiste. Per saperne di più, controlla i log dei pod coredns.

Puoi trovare l'indirizzo IP del servizio kube-dns utilizzando questo 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 inviare richieste all'indirizzo IP di ogni pod coredns.
  • Se alcuni pod funzionano, ma non altri, controlla se sono presenti pattern distinguibili, 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à nel cluster.

Se CoreDNS non è in grado di risolvere i nomi di dominio esterni, consulta la sezione seguente per la risoluzione dei problemi dei pod della rete host. 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 e i nodi della rete host utilizzano i server dei nomi 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. Se questa configurazione non è in grado di risolvere i nomi di dominio di cluster.local.

In caso di problemi relativi alla risoluzione dei nomi della rete host, utilizza i passaggi di risoluzione dei problemi descritti nelle sezioni precedenti per verificare se il DNS funziona correttamente per i server dei nomi upstream.

Problemi di rete comuni

Le seguenti sezioni descrivono nel dettaglio alcuni problemi di rete comuni che potresti riscontrare. Per risolvere il problema, segui le indicazioni appropriate per la risoluzione dei problemi. Se hai bisogno di ulteriore aiuto, 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 nodo inattive per il mesh nodo-nodo. Per risolvere il problema, disattiva i nodi inattivi.

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 in parallelo all'endpoint PUT. Si tratta di un comportamento previsto in caso di burst di richieste su un nodo. L'agente Cilium dovrebbe recuperare le richieste in ritardo.

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

Errore comune:Ebpf map size is full

Dataplane v2 archivia lo stato in una mappa eBFP. Lo stato include servizio, monitoraggio delle connessioni, identità dei pod e regole dei criteri di rete. Se una mappa è completa, 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 voci di 64.000.

  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 sta per raggiungere il limite di 64 kB, esegui la pulizia delle mappe. L'esempio seguente esegue la pulizia delle 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 aggiungere nuovamente lo stato nella mappa eBFP, riavvia anetd.

Nodo non pronto a causa di errori NetworkConnectinNotReady

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 uno stato non pronto, con un errore simile al seguente esempio:

  "Network plugin not installed"

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

Per risolvere il problema, verifica perché i pod non sono in esecuzione sul nodo. In genere, l'errore non è dovuto a problemi di rete. Questi pod vengono eseguiti sulla rete host, pertanto non c'è dipendenza dalla rete.

  1. Controlla lo stato del pod anetd o calico-node. Consulta la seguente procedura di risoluzione dei problemi per determinare la causa del problema:

    • Se il pod è nello stato Crashlooping, controlla i log per capire perché il pod non può essere eseguito correttamente.
    • Se il pod è in stato Pending, utilizza kubectl describe ed esamina gli eventi del pod. Ad esempio, nel pod potrebbe mancare una risorsa come un volume.
    • Se il pod è in stato Running, controlla i log e la configurazione. Alcune implementazioni CNI offrono opzioni per disabilitare l'installazione di CNI, ad esempio in Cilium.
    • Nell'account è presente un'opzione di configurazione chiamata custom-cni-conf. Se questa impostazione è configurata come true, anetd non installerà il file binario CNI.

Il servizio F5 non riceve traffico

Se il traffico non viene trasferito al servizio F5, rivedi i seguenti passaggi per la risoluzione dei problemi:

  1. Verifica che ogni partizione in F5 BIG-IP sia configurata in un cluster, di amministrazione o di cluster utente. Se una partizione è condivisa da più cluster diversi, si verificano interruzioni della connessione intermittenti. Questo comportamento è dovuto al fatto che due cluster tentano di acquisire il controllo della stessa partizione ed eliminare i servizi da altri cluster.

  2. Verifica che i due pod seguenti 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 tipo di servizio LoadBalancer. Alla fine, il ConfigMap verrà utilizzato dal controller bigip.

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

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

    Il servizio kube-server dovrebbe avere un aspetto 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 avere il VIP e la porta 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 della tua istanza BIG-IP. Se l'oggetto ConfigMap è configurato correttamente, ma l'istanza BIG-IP non riesce a rispettare la configurazione, potrebbe trattarsi di un problema F5. Per i problemi che si verificano all'interno dell'istanza BIG-IP, contatta l'assistenza di F5 per diagnosticare e risolvere i problemi.

Passaggi successivi

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