Risolvere 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, oltre a gli 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 assistenza, contatta Assistenza clienti Google Cloud.

Risoluzione dei problemi di connettività di rete

Il networking di GKE Enterprise si basa sulla tua infrastruttura di rete fisica. Per un esempio, Seesaw o MetalLB utilizzano sulle tue opzioni per rispettare l'ARP gratuito e il bilanciamento del carico in bundle con Border Il protocollo BGP (Gateway Protocol) si basa sui router e tutti i nodi dovrebbero essere in grado 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.

In primo luogo determina l'ambito del problema, quindi prova a identificare il componenti. L'ambito di un problema può rientrare in 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 hostNetwork pod 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 dello stesso 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 Livello 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 del livello di collegamento 2, come il sistema di vicini, ARP o NDP.
  • Problemi di routing degli indirizzi IP di livello 3.
  • Problemi relativi all'endpoint TCP o UDP di livello 4.
  • Problemi relativi a HTTP o HTTPS di livello 7.
  • Problemi di risoluzione DNS.

Comprendere l'ambito di un problema aiuta a identificare i componenti coinvolti nel problema e a quale livello si verifica. La raccolta delle informazioni al verificarsi del problema è importante perché alcuni problemi sono temporanei, pertanto gli istantanei dopo il recupero 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, è un problema di connettività nord-sud. Le seguenti mostra che, in un esempio funzionante, il traffico in entrata passa attraverso la pila da sinistra a destra e il traffico di ritorno torna indietro attraverso la pila da da destra a sinistra. Seesaw è diverso come il ritorno il traffico salta il bilanciatore del carico e torna direttamente al client:

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

In caso di problemi con questo flusso di traffico, utilizza il seguente flusso di lavoro per la risoluzione dei problemi per identificare il problema:

Risolvi i problemi di ingresso della rete esaminando ogni passaggio seguito da un pacchetto mentre si sposta nel tuo ambiente. Verifica se le azioni appropriate e la connettività esiste lungo il percorso.

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

  • Il pacchetto esce dal client? In caso contrario, probabilmente hai una rete dell'infrastruttura.
  • Utilizzi il bilanciatore del carico Seesaw? In questo caso, il pacchetto arriva Seesaw e l'ARP viene inviato correttamente? In caso contrario, probabilmente hai una rete dell'infrastruttura.
  • Utilizzi MetalLB? In tal caso, il pacchetto arriva al nodo LB e viene l'ARP sia stato inviato correttamente? In caso contrario, probabilmente disponi di un'infrastruttura di rete problema.
  • 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 si tratti di un problema di kube-proxy/Dataplane V2.
  • Il pacchetto arriva al nodo worker? Se la risposta è no, è probabile che Pod-to-pod Calico / Dataplane v2 problema.
  • Il pacchetto arriva al pod? Se la risposta è no, è probabile che Calico / Dataplane v2 local un problema di inoltro.

Le sezioni seguenti forniscono i passaggi per la risoluzione dei problemi di ogni fase al fine di determinare se se il traffico è corretto 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. Usa tcpdump per controllare il pacchetto quando lascia il client per il trasferimento 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, individua il nodo principale 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, questa è la causa 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 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 il bilanciamento del carico manuale, il traffico potrebbe essere indirizzato a qualsiasi nodo. A seconda del carico, 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, MetalLB e Seesaw non tramite NAT prima di inoltrare il pacchetto ai nodi.

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

Si è verificato un problema con F5 BIG-IP?

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

L'ARP è stato inviato correttamente?

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

  1. Usa tcpdump per rilevare le risposte ARP:

    tcpdump -ni any arp

    Cerca il messaggio che pubblicizza il VIP con cui hai problemi.

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

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

Viene eseguito il NAT?

Dataplane v2 / kube-proxy esegue la Network Address Translation di destinazione (destination NAT o DNAT) per tradurre il VIP di destinazione in un IP di pod di backend. . Se sai quale nodo è il backend per il bilanciatore del carico, connettiti al nodo utilizzando 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 di Dataplane v2/Cilium.

Il pacchetto arriva a un nodo worker?

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

  1. Controlla 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 normali backend di servizio contengono più pod in nodi diversi, potrebbe essere difficile risolvere i problemi del nodo in errore. Una soluzione comune è registrare il problema per un periodo di tempo sufficientemente lungo in modo che alla fine arrivi qualche pacchetto oppure limitare il numero di backend a uno.

Se il pacchetto non arriva mai al nodo di lavoro, significa che la rete dell'infrastruttura. Consulta il team dell'infrastruttura di rete per capire perché il pacchetto viene scartato tra nodi LoadBalancer e nodi worker. Ecco alcuni problemi comuni:

  • Controlla i log della 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 o all'interfaccia del tunnel del nodo, deve essere inoltrato al pod di destinazione. Se il pod è un networking host questo passaggio non è necessario perché il pod condivide lo spazio dei nomi di rete nel nodo. In caso contrario, è necessario un ulteriore inoltro dei pacchetti.

Ogni pod ha coppie di interfacce Ethernet virtuali, che funzionano come pipe. 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 rinominato in eth0. L'altra interfaccia viene conservata nello spazio dei nomi dell'host. Diverso I CNI 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 arriva al pod, controlla la tabella di routing come segue:

ip route

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

Problemi di traffico in uscita

Se il traffico può entrare in un pod, potresti riscontrare un problema con il traffico in uscita dal pod. Il seguente diagramma mostra che in un esempio funzionante il traffico in entrata attraversa lo stack da sinistra a destra:

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

  1. Per verificare che il pacchetto in uscita si presenti correttamente come 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 a l'indirizzo IP del nodo con Network Address Translation di origine (source NAT o SNAT). In Dataplane 2, questa procedura viene eseguita tramite ebpf caricato su un'interfaccia esterna. Calico utilizza le regole iptables.

    Usa tcpdump per verificare se l'indirizzo IP di origine viene tradotto correttamente da 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 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 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 un ping da uno dei pod:

    kubectl exec POD_NAME ping EXTERNAL_IP

    Se non vedi le risposte del ping, controlla la connessione all'esterno nella tua infrastruttura.

Problemi all'interno del cluster

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

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

    cilium status --all-health

    Google Distributed Cloud utilizza la modalità di routing diretto. Dovresti vedere una voce di route per ogni nodo del 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, la connessione a quel nodo viene persa.

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 è sufficientemente informativa per risolvere il problema, in quanto potrebbe 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 corretto.

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.
    • Gli errori dei codici HTTP 40x, 50x o di TLS handshake indicano che tutto funziona di solito al livello 4.
  • Gli errori "Connessione reimpostata dal peer" indicano che si tratta di un problema di livello 4.
    • Spesso, la socket remota non è in linea con lo stato corrente di una connessione e invia un pacchetto RESET. Questo comportamento potrebbe essere un errore nel monitoraggio delle connessioni o nel NAT.
  • Gli errori "Nessun percorso per l'host" e "Timeout connessione" sono in genere un problema di livello 3 o livello 2.
    • Questi errori indicano che non è possibile instradare il pacchetto correttamente destinazione.

Strumenti utili per la risoluzione dei problemi

I DaemonSet correlati alla rete vengono eseguiti sui tuoi nodi e potrebbero essere la causa problemi di connettività. Tuttavia, la configurazione errata dei nodi, top of rack (ToR) anche gli switch spine, i router spine o i firewall possono causare problemi. Puoi utilizzare i seguenti strumenti per determinare l'ambito o il livello del problema e capire 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 la route tra un'origine e destinazione. Se il ping non riesce a raggiungere una destinazione, spesso significa che il problema è per il livello 3.

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

I bilanciatori di carico BGPLB, MetalLB e Seesaw in Google Distributed Cloud funzionano tutti a livello 3. Puoi utilizzare il comando ping per controllare la connettività. Sebbene F5 sia diverso, supporta anche ICMP. Puoi utilizza 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 spesso hanno messaggi di errore simili nelle applicazioni. Arping e ping possono contribuire a distinguere il problema. Ad esempio, se l'origine e la destinazione si trovano nella stessa sottorete, ma non riesci ad eseguire l'ARPing della destinazione, si tratta di un problema di livello 2.

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

Arping è anche in grado di rilevare conflitti di indirizzi IP. Un conflitto di indirizzi IP si verifica quando in modo che utilizzino lo stesso indirizzo IP sulla stessa subnet, o un indirizzo VIP è utilizzato da un'altra macchina fisica. I conflitti di indirizzi IP possono creare problemi intermittenti difficili da risolvere. Se arping <ip> restituisce altri di una voce di indirizzo MAC, significa che c'è un indirizzo IP in conflitto.

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

iproute2

La CLI ip per iproute2 ha molti sottocomandi utili, ad esempio:

  • ip r: stampa la tabella 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 o una voce mancante nella tabella vicina potrebbe causare la connettività dal nodo. Sia Anetd che Calico gestiscono la tabella route e la tabella dei vicini. Un'errata configurazione di 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 di ogni pacchetto eliminato da anetd/Cilium.
  • hubble observe
    • Stampa tutti i pacchetti che passano per la pila ebpf di anetd.
  • cilium status --all-health
    • Stampa lo stato di Cilium, incluso lo stato della connettività da nodo a nodo. Ciascuna anetd Pod controlla l'integrità di tutti gli altri nodi nel cluster e può aiutarti 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 dei servizi. Calico utilizza iptables per implementare il criterio di rete

  1. Per risolvere i problemi di rete a livello di iptables, usa quanto segue :

    iptables -L -v | grep DROP

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

Tcpdump

tcpdump è un potente strumento di acquisizione di pacchetti che genera dati sul traffico. È prassi comune eseguire tcpdump sia dall'origine che destinazione. Se un pacchetto viene acquisito quando esce dal nodo di origine, ma non viene mai acquisito sul nodo di destinazione, significa che qualcosa nel mezzo perde il pacchetto. Questo comportamento di solito indica che qualcosa nel tuo corpo l'infrastruttura ignora 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 di una di queste categorie.

Architettura DNS cluster

Un servizio DNS del cluster risolve le richieste DNS per i pod nel cluster. CoreDNS offre questo servizio per Google Distributed Cloud versioni 1.9.0 e 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 di pod di backend coredns.

La maggior parte dei pod ha il DNS upstream configurato sull'indirizzo IP del servizio kube-dns e invia 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 nel cluster che fa riferimento a un servizio o a un pod nel cluster.
    • CoreDNS monitora il api-server per tutti i servizi e i pod del cluster e risponde alle richieste di domini cluster.local validi.
  • Se la richiesta non riguarda un dominio cluster.local, allora si riferisce a un dominio esterno dominio.
    • CoreDNS inoltra la richiesta ai server dei nomi upstream. Per impostazione predefinita, CoreDNS utilizza i nameserver upstream configurati sul nodo su cui è eseguito.

Per ulteriori informazioni, consulta Panoramica del funzionamento e della 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 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 di google.com:

    dig google.com
nslookup google.com

  • Usa dig per inviare una richiesta di kubernetes.default.svc.cluster.local a 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 della precedente Comando dig:

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

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

Pod standard

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

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

I messaggi di errore che includono un codice di errore DNS come NXDOMAIN o SERVFAIL indicano che è presente 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 esistono. 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 esista. Per saperne di più, controlla i log dei pod coredns.

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

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 IP indirizzo utilizzando dig o nslookup, come descritto in una sezione precedente:

  • Se queste richieste non funzionano, prova a inviare le richieste all'indirizzo IP di ogni coredns pod.
  • Se alcuni pod funzionano, ma altri no, controlla se sono presenti schemi distinguibili, ad esempio la risoluzione DNS funziona per i pod sullo stesso nodo del pod coredns, ma non su più nodi. Questo comportamento potrebbe indicare che alcuni problema di connettività.

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

Pod o nodi della rete host

I pod della rete host e i nodi utilizzano i nameserver configurati sul nodo per la risoluzione DNS, non il servizio DNS nel cluster. In base al sistema operativo, nameserver è configurato in /etc/resolv.conf o /run/systemd/resolve/resolv.conf. Questa configurazione significa che non possono risolvere cluster.local nomi di dominio.

Se riscontri problemi con la risoluzione dei nomi della rete host, segui i passaggi per la risoluzione dei problemi riportati nelle sezioni precedenti per verificare se il DNS funziona correttamente per i server dei nomi upstream.

Problemi di rete comuni

Le sezioni seguenti descrivono in dettaglio alcuni problemi di rete comuni che potresti riscontrare. Per aiutare a risolvere il problema, segui le istruzioni per la risoluzione dei problemi appropriate guida. 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 le risorse dei nodi inattivi sono configurate per la rete mesh da nodo a nodo. Per risolvere il problema: dismettere 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 per un limite di frequenza. Per ogni nodo, Cilium ha un limite di quattro richieste in parallelo all'endpoint PUT. Quando si verifica un picco di richieste a un nodo, questo comportamento è previsto. L'agente Cilium dovrebbe recuperare le richieste in ritardo.

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

Errore comune: Ebpf map size is full

Dataplane v2 memorizza lo stato in una mappa eBFP. Lo stato include il servizio, il monitoraggio delle connessioni, l'identità del pod e le regole del criterio 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 64.000 voci.

  1. Per controllare le voci della mappa eBFP e le relative dimensioni correnti, 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. Le seguenti un esempio di 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 reintegrare 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 seguenti:

  "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 di non disponibilità, con un errore simile al seguente:

  "Network plugin not installed"

Quando un nodo viene inizializzato, kubelet attende che si verifichino diversi eventi prima di contrassegnarlo come Ready. Uno degli eventi controllati da kubelet è che sia installato il plug-in Container Network Interface (CNI). Il plug-in CNI deve essere installato da anetd o Calico utilizzando un container di inizializzazione per installare sia il file binario CNI che la configurazione le 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 dell'host, quindi non esiste alcuna dipendenza dalla rete.

  1. Controlla lo stato del pod anetd o calico-node. Esamina i seguenti passaggi per la risoluzione dei problemi per determinare la causa del problema:

    • Se il pod è nello stato Crashlooping, controlla i log per capire perché non può essere eseguito correttamente.
    • Se il pod è in stato Pending, usa kubectl describe ed esamina il valore eventi 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 di CNI forniscono opzioni per disattivare l'installazione di CNI, come in Cilium.
    • Nell'account è presente un'opzione di configurazione chiamata custom-cni-conf. Se questa impostazione è configurata come true, anetd non installerà il proprio file binario CNI.

Nodo NON PRONTO a causa di voci ARP obsolete

A volte, le voci ARP obsolete nei nodi del piano di controllo del cluster di amministrazione possono causare una mancata corrispondenza degli indirizzi MAC. La mancata corrispondenza dell'indirizzo può causare, a sua volta, la connessione i timeout per i VIP del piano di controllo dei cluster utente gestiti. I timeout di connessione possono portare al contrassegno come NOT READY del nodo con voci ARP obsolete. 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, svolgi i seguenti passaggi:

  1. Utilizza SSH per connetterti al nodo del piano di controllo 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 dal nodo del piano di controllo.

  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, questo problema ti riguarda.

  5. Per risolvere il problema, svuota la cache ARP nel piano di controllo del cluster di amministrazione nodo:

    ip n flush all

Il servizio F5 non riceve traffico

Se non viene inviato traffico al servizio F5, esamina la procedura di risoluzione dei problemi riportata di seguito passaggi:

  1. Controlla che ogni partizione in F5 BIG-IP sia configurate in un cluster, di amministrazione o di cluster utente. Se una partizione è condivisa da più parti diversi cluster, si verificano interruzioni della connessione intermittenti. Questo comportamento si verifica perché 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. Eventuali 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 ConfigMap esista 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 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, mostrato nell'esempio che segue:

    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 il ConfigMap è configurato correttamente, ma l'istanza BIG-IP non rispetta 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 assistenza, contatta Assistenza clienti Google Cloud.