Risolvere i problemi di connettività nel cluster

Questa pagina mostra come risolvere i problemi di connettività nel cluster Google Kubernetes Engine (GKE).

Problemi di connettività relativi all'acquisizione di pacchetti di rete in GKE

Questa sezione descrive come risolvere i problemi di connettività relativi all'acquisizione di pacchetti di rete, inclusi sintomi come timeout della connessione, errori di connessione rifiutata o comportamento imprevisto dell'applicazione. Questi problemi di connettività possono verificarsi a livello di nodo o di pod.

I problemi di connettività nella rete del cluster rientrano spesso nelle seguenti categorie:

  • Pod non raggiungibili: un pod potrebbe non essere accessibile dall'interno o dall'esterno del cluster a causa di errori di configurazione della rete.
  • Interruzioni del servizio: un servizio potrebbe subire interruzioni o ritardi.
  • Problemi di comunicazione tra i pod: i pod potrebbero non essere in grado di comunicare tra loro in modo efficace.

I problemi di connettività nel cluster GKE possono derivare da varie cause, tra cui:

  • Errori di configurazione della rete: criteri di rete, regole firewall o tabelle di routing errati.
  • Bug dell'applicazione: errori nel codice dell'applicazione che influiscono sulle interazioni di rete.
  • Problemi di infrastruttura: congestione della rete, guasti hardware o limitazioni delle risorse.

La sezione seguente mostra come risolvere il problema sui nodi o sui pod problematici.

  1. Identifica il nodo su cui è in esecuzione il pod problematico utilizzando il seguente comando:

    kubectl get pods POD_NAME -o=wide -n NAMESPACE

    Sostituisci quanto segue:

    • POD_NAME con il nome del pod.
    • NAMESPACE con lo spazio dei nomi Kubernetes.

  2. Connettiti al nodo:

    gcloud compute ssh NODE_NAME \
    --zone=ZONE

    Sostituisci quanto segue:

    • NODE_NAME: il nome del nodo.
    • ZONE: il nome della zona in cui viene eseguito il nodo.

  3. Per eseguire il debug di un pod specifico, identifica l'interfaccia veth associata al pod:

    ip route | grep POD_IP

    Sostituisci POD_IP con l'indirizzo IP del pod.

  4. Esegui i comandi di toolbox.

toolbox comandi

toolbox è un'utilità che fornisce un ambiente containerizzato all'interno dei nodi GKE per il debug e la risoluzione dei problemi. Questa sezione descrive come installare l'utilità toolbox e utilizzarla per risolvere i problemi del nodo.

  1. Mentre è connesso al nodo, avvia lo strumento toolbox:

    toolbox

    Vengono scaricati i file che facilitano l'utilizzo dell'utilità toolbox.

  2. Nel prompt root toolbox, installa tcpdump:

    • Per i cluster con indirizzi IP esterni o Cloud NAT:

      apt update -y && apt install -y tcpdump

    • Per i cluster privati senza Cloud NAT:

      Se hai un cluster privato senza Cloud NAT, non puoi installare tcpdump utilizzando apt. Scarica invece i file di rilascio libpcap e tcpdump dal repository ufficiale e copia i file nella VM utilizzando gcloud compute scp o gcloud storage cp. Poi, installa le librerie manualmente seguendo questi passaggi:

      cp /media/root/home/USER_NAME/tcpdump-VERSION.tar.gz  /usr/sbin/
cp /media/root/home/USER_NAME/libpcap-VERSION.tar.gz  /usr/sbin/
cd /usr/sbin/
tar -xvzf tcpdump-VERSION.tar.gz
tar -xvzf libpcap-VERSION.tar.gz
cd libpcap-VERSION
./configure ; make ; make install
cd ../tcpdump-VERSION
./configure ; make ; make install
tcpdump --version

      Sostituisci quanto segue:

      • USER_NAME: il tuo nome utente sul sistema in cui si trovano i file.
      • VERSION: il numero di versione specifico dei pacchetti tcpdump e libpcap.

  3. Avvia l'acquisizione dei pacchetti:

    tcpdump -i eth0 -s 100 "port PORT" \
-w /media/root/mnt/stateful_partition/CAPTURE_FILE_NAME

    Sostituisci quanto segue:

    • PORT: il nome del numero di porta.
    • CAPTURE_FILE_NAME: il nome del file di acquisizione.

  4. Interrompi l'acquisizione dei pacchetti e interrompi tcpdump.

  5. Esci dalla casella degli strumenti digitando exit.

  6. Elenca il file di acquisizione dei pacchetti e controlla le sue dimensioni:

    ls -ltr /mnt/stateful_partition/CAPTURE_FILE_NAME

  7. Copia l'acquisizione dei pacchetti dal nodo alla directory di lavoro corrente sul computer:

    gcloud compute scp NODE_NAME:/mnt/stateful_partition/CAPTURE_FILE_NAME \
    --zone=ZONE

    Sostituisci quanto segue:

    • NODE_NAME: il nome del nodo.
    • CAPTURE_FILE_NAME: il nome del file di acquisizione.
    • ZONE: il nome della tua zona.

Comandi alternativi

Puoi anche utilizzare i seguenti metodi per risolvere i problemi di connettività sui pod problematici:

  • Carico di lavoro di debug temporaneo collegato al container del pod.

  • Esegui una shell direttamente sul pod di destinazione utilizzando kubectl exec, quindi installa e avvia il comando tcpdump.

Problemi di connettività della rete dei pod

Come accennato nella sezione Panoramica della rete, è importante capire come sono collegati i pod dagli spazi dei nomi di rete allo spazio dei nomi principale sul nodo per risolvere i problemi in modo efficace. Per la discussione che segue, se non diversamente specificato, supponi che il cluster utilizzi CNI nativo di GKE anziché quello di Calico. ovvero non è stata applicata alcuna norma di rete.

I pod su alcuni nodi non sono disponibili

Se i pod su nodi selezionati non hanno connettività di rete, assicurati che il bridge Linux sia attivo:

ip address show cbr0

Se il bridge Linux non funziona, riavvialo:

sudo ip link set cbr0 up

Assicurati che il nodo stia apprendendo gli indirizzi MAC dei pod collegati a cbr0:

arp -an

I pod su alcuni nodi hanno una connettività minima

Se i pod su nodi selezionati hanno una connettività minima, devi prima verificare se sono presenti pacchetti persi eseguendo tcpdump nel container toolbox:

sudo toolbox bash

Installa tcpdump nella cassetta degli attrezzi, se non l'hai ancora fatto:

apt install -y tcpdump

Esegui tcpdump rispetto a cbr0:

tcpdump -ni cbr0 host HOSTNAME and port PORT_NUMBER and [TCP|UDP|ICMP]

Se sembra che i pacchetti di grandi dimensioni vengano eliminati a valle del bridge (ad esempio, l'handshake TCP viene completato, ma non vengono ricevuti hello SSL), assicurati che l'MTU per ogni interfaccia del pod Linux sia impostato correttamente sull'MTU della rete VPC del cluster.

ip address show cbr0

Quando vengono utilizzati overlay (ad esempio Weave o Flannel), questo MTU deve essere ulteriormente ridotto per tenere conto dell'overhead di incapsulamento sull'overlay.

MTU GKE

L'MTU selezionata per un'interfaccia pod dipende dall'interfaccia di rete container (CNI) utilizzata dai nodi del cluster e dall'impostazione MTU VPC sottostante. Per ulteriori informazioni, consulta la sezione Pod.

Il valore MTU dell'interfaccia del pod è 1460 o ereditato dall'interfaccia principale del nodo.

CNI MTU GKE Standard
kubenet 1460 Predefinito
kubenet
(GKE versione 1.26.1 e successive) 		Ereditato Predefinito
Calico 1460

Attivata tramite --enable-network-policy.

Per maggiori dettagli, vedi Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete.
netd Ereditato Attivata utilizzando uno dei seguenti metodi:
GKE Dataplane V2 Ereditato

Attivata tramite --enable-dataplane-v2.

Per i dettagli, consulta Utilizzo di GKE Dataplane V2.

Connessioni non riuscite intermittenti

Le connessioni da e verso i pod vengono inoltrate da iptables. I flussi vengono monitorati come voci nella tabella conntrack e, in presenza di molti carichi di lavoro per nodo, l'esaurimento della tabella conntrack può manifestarsi come errore. Questi possono essere registrati nella console seriale del nodo, ad esempio:

nf_conntrack: table full, dropping packet

Se riesci a determinare che i problemi intermittenti sono causati dall'esaurimento di conntrack, puoi aumentare le dimensioni del cluster (riducendo così il numero di carichi di lavoro e flussi per nodo) o aumentare nf_conntrack_max:

new_ct_max=$(awk '$1 == "MemTotal:" { printf "%d\n", $2/32; exit; }' /proc/meminfo)
sysctl -w net.netfilter.nf_conntrack_max="${new_ct_max:?}" \
  && echo "net.netfilter.nf_conntrack_max=${new_ct_max:?}" >> /etc/sysctl.conf

Puoi anche utilizzare NodeLocal DNSCache per ridurre le voci di monitoraggio della connessione.

"bind: Address already in use " segnalato per un container

Un container in un pod non può essere avviato perché, secondo i log del container, la porta a cui l'applicazione sta tentando di eseguire il binding è già riservata. Il container è in crash loop. Ad esempio, in Cloud Logging:

resource.type="container"
textPayload:"bind: Address already in use"
resource.labels.container_name="redis"

2018-10-16 07:06:47.000 CEST 16 Oct 05:06:47.533 # Creating Server TCP listening socket *:60250: bind: Address already in use
2018-10-16 07:07:35.000 CEST 16 Oct 05:07:35.753 # Creating Server TCP listening socket *:60250: bind: Address already in use

Quando Docker si arresta in modo anomalo, a volte un container in esecuzione viene lasciato indietro e diventa obsoleto. Il processo è ancora in esecuzione nello spazio dei nomi di rete allocato per il pod ed è in ascolto sulla relativa porta. Poiché Docker e kubelet non conoscono il container obsoleto, tentano di avviare un nuovo container con un nuovo processo, che non è in grado di eseguire il binding sulla porta perché viene aggiunto allo spazio dei nomi di rete già associato al pod.

Per diagnosticare il problema:

  1. Devi inserire l'UUID del pod nel campo .metadata.uuid:

    kubectl get pod -o custom-columns="name:.metadata.name,UUID:.metadata.uid" ubuntu-6948dd5657-4gsgg

name                      UUID
ubuntu-6948dd5657-4gsgg   db9ed086-edba-11e8-bdd6-42010a800164

  2. Ottieni l'output dei seguenti comandi dal nodo:

    docker ps -a
ps -eo pid,ppid,stat,wchan:20,netns,comm,args:50,cgroup --cumulative -H | grep [Pod UUID]

  3. Controlla i processi in esecuzione da questo pod. Poiché gli spazi dei nomi cgroup contengono l'UUID del pod, puoi cercare l'UUID del pod nell'output di ps. Esegui anche il comando grep sulla riga precedente, in modo da avere anche i processi docker-containerd-shim con l'ID contenitore nell'argomento. Taglia il resto della colonna cgroup per ottenere un output più semplice:

    # ps -eo pid,ppid,stat,wchan:20,netns,comm,args:50,cgroup --cumulative -H | grep -B 1 db9ed086-edba-11e8-bdd6-42010a800164 | sed s/'blkio:.*'/''/
1283089     959 Sl   futex_wait_queue_me  4026531993       docker-co       docker-containerd-shim 276e173b0846e24b704d4 12:
1283107 1283089 Ss   sys_pause            4026532393         pause           /pause                                     12:
1283150     959 Sl   futex_wait_queue_me  4026531993       docker-co       docker-containerd-shim ab4c7762f5abf40951770 12:
1283169 1283150 Ss   do_wait              4026532393         sh              /bin/sh -c echo hello && sleep 6000000     12:
1283185 1283169 S    hrtimer_nanosleep    4026532393           sleep           sleep 6000000                            12:
1283244     959 Sl   futex_wait_queue_me  4026531993       docker-co       docker-containerd-shim 44e76e50e5ef4156fd5d3 12:
1283263 1283244 Ss   sigsuspend           4026532393         nginx           nginx: master process nginx -g daemon off; 12:
1283282 1283263 S    ep_poll              4026532393           nginx           nginx: worker process

  4. In questo elenco puoi visualizzare gli ID contenitore, che dovrebbero essere visibili anche in docker ps.

    In questo caso:

    • docker-containerd-shim 276e173b0846e24b704d4 per mettere in pausa
    • docker-containerd-shim ab4c7762f5abf40951770 per sh con sleep (sleep-ctr)
    • docker-containerd-shim 44e76e50e5ef4156fd5d3 per nginx (echoserver-ctr)

  5. Controlla quelli nell'output docker ps:

    # docker ps --no-trunc | egrep '276e173b0846e24b704d4|ab4c7762f5abf40951770|44e76e50e5ef4156fd5d3'
44e76e50e5ef4156fd5d383744fa6a5f14460582d0b16855177cbed89a3cbd1f   gcr.io/google_containers/echoserver@sha256:3e7b182372b398d97b747bbe6cb7595e5ffaaae9a62506c725656966d36643cc                   "nginx -g 'daemon off;'"                                                                                                                                                                                                                                                                                                                                                                     14 hours ago        Up 14 hours                             k8s_echoserver-cnt_ubuntu-6948dd5657-4gsgg_default_db9ed086-edba-11e8-bdd6-42010a800164_0
ab4c7762f5abf40951770d3e247fa2559a2d1f8c8834e5412bdcec7df37f8475   ubuntu@sha256:acd85db6e4b18aafa7fcde5480872909bd8e6d5fbd4e5e790ecc09acc06a8b78                                                "/bin/sh -c 'echo hello && sleep 6000000'"                                                                                                                                                                                                                                                                                                                                                   14 hours ago        Up 14 hours                             k8s_sleep-cnt_ubuntu-6948dd5657-4gsgg_default_db9ed086-edba-11e8-bdd6-42010a800164_0
276e173b0846e24b704d41cf4fbb950bfa5d0f59c304827349f4cf5091be3327   registry.k8s.io/pause-amd64:3.1

    In genere, in docker ps vengono visualizzati tutti gli ID container di ps. Se non ne vedi uno, si tratta di un contenitore obsoleto e probabilmente vedrai un processo secondario di docker-containerd-shim process in ascolto sulla porta TCP che risulta già in uso.

    Per verificarlo, esegui netstat nello spazio dei nomi di rete del container. Recupera il PID di qualsiasi processo del container (quindi NON docker-containerd-shim) per il pod.

    Dall'esempio precedente:

    • 1283107 - pause
    • 1283169 - sh
    • 1283185 - sleep
    • 1283263 - nginx master
    • 1283282 - nginx worker
    # nsenter -t 1283107 --net netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1283263/nginx: mast
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Path
unix  3      [ ]         STREAM     CONNECTED     3097406  1283263/nginx: mast
unix  3      [ ]         STREAM     CONNECTED     3097405  1283263/nginx: mast

gke-zonal-110-default-pool-fe00befa-n2hx ~ # nsenter -t 1283169 --net netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1283263/nginx: mast
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Path
unix  3      [ ]         STREAM     CONNECTED     3097406  1283263/nginx: mast
unix  3      [ ]         STREAM     CONNECTED     3097405  1283263/nginx: mast

    Puoi anche eseguire netstat utilizzando ip netns, ma devi collegare manualmente lo spazio dei nomi di rete del processo, poiché Docker non esegue il collegamento:

    # ln -s /proc/1283169/ns/net /var/run/netns/1283169
gke-zonal-110-default-pool-fe00befa-n2hx ~ # ip netns list
1283169 (id: 2)
gke-zonal-110-default-pool-fe00befa-n2hx ~ # ip netns exec 1283169 netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1283263/nginx: mast
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Path
unix  3      [ ]         STREAM     CONNECTED     3097406  1283263/nginx: mast
unix  3      [ ]         STREAM     CONNECTED     3097405  1283263/nginx: mast
gke-zonal-110-default-pool-fe00befa-n2hx ~ # rm /var/run/netns/1283169

Mitigazione:

La mitigazione a breve termine consiste nell'identificare i processi obsoleti con il metodo descritto in precedenza e terminare i processi utilizzando il comando kill [PID].

La mitigazione a lungo termine prevede l'identificazione del motivo per cui Docker si arresta in modo anomalo e la sua correzione. Le possibili cause includono:

  • Accumulo di processi zombie, quindi esaurimento degli spazi dei nomi PID
  • Bug in Docker
  • Pressione delle risorse / OOM

Passaggi successivi