Debug dei Problemi di Rete in Kubernetes: Tecniche Essenziali

I problemi di rete in Kubernetes si manifestano solitamente come timeout, Connection refused, errori DNS, endpoint di servizio vuoti o risposte Ingress errate. Per risolverli rapidamente, traccia il percorso: pod sorgente, pod destinazione, servizio, DNS, NetworkPolicy e poi Ingress o load balancer.

Questa guida fornisce una sequenza pratica di controlli e i comandi kubectl che rivelano dove il traffico si interrompe.

Comprensione dei Fondamenti di Rete di Kubernetes

Prima di addentrarsi nel debug, è importante comprendere i concetti fondamentali di rete in Kubernetes:

Rete dei Pod: Ogni pod ottiene un indirizzo IP unico. I pod all'interno dello stesso nodo possono comunicare direttamente. I pod su nodi diversi comunicano tramite una rete virtuale (plugin CNI).
Servizi: I servizi forniscono un indirizzo IP stabile e un nome DNS per un insieme di pod. Fungono da livello di astrazione, consentendo ad altri pod o client esterni di accedere ai backend dell'applicazione senza dover conoscere gli IP dei singoli pod.
DNS: Il DNS di Kubernetes (solitamente CoreDNS) risolve i nomi dei servizi in IP del cluster, abilitando il service discovery.
Network Policies: Queste risorse controllano il traffico dei pod quando il plugin CNI le applica. Un cluster senza supporto per NetworkPolicy accetterà gli oggetti ma potrebbe non applicare le regole.
Ingress: I controller Ingress gestiscono l'accesso esterno ai servizi all'interno del cluster, tipicamente HTTP e HTTPS. Forniscono routing, bilanciamento del carico e terminazione SSL.

Problemi di Rete Comuni e Strategie di Debug

1. Problemi di Comunicazione Pod-Pod

Quando i pod non possono comunicare tra loro, anche all'interno dello stesso namespace, è un indicatore primario di un problema di rete.

Sintomi:

Errori dell'applicazione che indicano timeout o rifiuti di connessione.
Comandi curl o ping da un pod all'altro falliscono.

Passaggi di Debug:

Verifica gli IP dei Pod: Assicurati che sia il pod sorgente che quello destinazione abbiano indirizzi IP validi. Usa kubectl exec <nome-pod> -- ip addr.
Controlla la Connettività di Rete (all'interno del pod): Dal pod sorgente, prova a eseguire il ping dell'indirizzo IP del pod destinazione. Se fallisce, il problema potrebbe essere con il plugin CNI o la rete del nodo.
```
kubectl exec <nome-pod-sorgente> -- ping <ip-pod-destinazione>
```
Ispeziona le Network Policies: Le Network Policies sono una causa comune. Controlla se qualche policy blocca inavvertitamente il traffico tra i pod.
```
kubectl get networkpolicies -n <namespace>
```
Esamina il podSelector e le regole ingress/egress per capire quale traffico è permesso o negato. Una volta che un pod è selezionato da una policy di ingresso, solo il traffico in ingresso esplicitamente consentito è permesso.
Stato del Plugin CNI: Assicurati che il plugin CNI (Container Network Interface) (es. Calico, Flannel, Cilium) sia in esecuzione correttamente su tutti i nodi. Controlla i log dei pod del daemonset CNI.
```
kubectl get pods -n kube-system -l k8s-app=<etichetta-plugin-cni>
kubectl logs <nome-pod-plugin-cni> -n kube-system
```

2. Problemi di Service Discovery

Quando i pod non riescono a raggiungere altri servizi tramite i loro nomi DNS o IP del cluster, indica un problema con il DNS di Kubernetes o la configurazione dell'oggetto Service.

Sintomi:

Errori dell'applicazione come Name or service not known.
Comandi nslookup o dig all'interno di un pod non riescono a risolvere i nomi dei servizi.

Passaggi di Debug:

Verifica la Risoluzione DNS: Da un pod, testa la risoluzione DNS per un servizio noto.

kubectl exec <nome-pod> -- nslookup <nome-servizio>.<namespace>.svc.cluster.local

Se fallisce, controlla i pod di CoreDNS per errori.

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs <nome-pod-coredns> -n kube-system

Controlla l'Oggetto Service: Assicurati che l'oggetto Service sia configurato correttamente e abbia endpoint che puntano a pod sani.
```
kubectl get service <nome-servizio> -n <namespace> -o yaml
kubectl get endpoints <nome-servizio> -n <namespace>
```
L'output di endpoints dovrebbe elencare gli indirizzi IP dei pod che supportano il servizio.
Probe di Readiness dei Pod: Se i pod non superano i probe di readiness, non verranno aggiunti agli endpoint del servizio. Controlla le configurazioni dei probe di readiness e i log dei pod per eventuali problemi.

3. Problemi del Controller Ingress

L'accesso esterno ai tuoi servizi è gestito dalle risorse Ingress e dai controller Ingress. I problemi qui possono rendere la tua applicazione inaccessibile dall'esterno del cluster.

Sintomi:

Errori 502 Bad Gateway, 404 Not Found o 503 Service Unavailable quando si accede alle applicazioni tramite il loro URL esterno.
Log del controller Ingress che mostrano errori relativi ai servizi backend.

Passaggi di Debug:

Controlla i Pod del Controller Ingress: Assicurati che i pod del controller Ingress (es. Nginx Ingress, Traefik) siano in esecuzione e sani.

kubectl get pods -l app.kubernetes.io/component=controller # Regola l'etichetta in base al tuo controller ingress
kubectl logs <nome-pod-controller-ingress> -n <namespace-ingress>

Verifica la Risorsa Ingress: Controlla la configurazione della tua risorsa Ingress.
```
kubectl get ingress <nome-ingress> -n <namespace> -o yaml
```
Assicurati che la sezione rules mappi correttamente hostname e percorsi al service.name e service.port appropriati.
Controlla Servizio ed Endpoint: Come per il service discovery, assicurati che il servizio backend a cui punta l'Ingress sia configurato correttamente e abbia endpoint sani.
```
kubectl get service <nome-servizio-backend> -n <namespace>
kubectl get endpoints <nome-servizio-backend> -n <namespace>
```
Firewall e Load Balancer: Se si accede dall'esterno del cluster, assicurati che eventuali firewall esterni o load balancer del provider cloud siano configurati correttamente per inoltrare il traffico al servizio del controller Ingress (spesso un servizio di tipo LoadBalancer).

4. Applicazione delle Network Policy

Le Network Policies possono essere potenti ma anche una fonte di problemi di connettività se configurate male. Operano secondo il principio del minimo privilegio; se una policy non consente esplicitamente il traffico, questo viene negato.

Passaggi di Debug:

Identifica le Policy Applicate: Determina quali Network Policies stanno interessando i pod in questione.
```
kubectl get networkpolicy -n <namespace>
```
Ispeziona i Selettori delle Policy: Esamina attentamente il podSelector in ogni NetworkPolicy pertinente. Questo selettore determina a quali pod si applica la policy. Se un pod è selezionato da più policy, il traffico consentito è l'unione delle regole di quelle policy, non la singola regola più restrittiva.
Rivedi le Regole Ingress/Egress: Analizza le sezioni ingress e egress della Network Policy. Se stai cercando di stabilire una connessione dal Pod A al Pod B, devi assicurarti che:
- Una Network Policy applicata al Pod B consenta il traffico in ingresso dal Pod A (o un selettore di etichette più ampio che includa il Pod A).
- Una Network Policy applicata al Pod A consenta il traffico in uscita verso il Pod B (o un selettore di etichette più ampio che includa il Pod B).
Testa con una Policy Aperta: Come passaggio temporaneo di risoluzione dei problemi, puoi creare una Network Policy che consenta tutto il traffico da e verso pod o namespace specifici per vedere se la connettività viene ripristinata. Questo aiuta a isolare se il problema è effettivamente con le Network Policies.
```
# Esempio: Consenti tutto il traffico in ingresso e in uscita per i pod con etichetta app=my-app
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-for-my-app
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
    - {}
  egress:
    - {}
```
Attenzione: Questa policy allow-all dovrebbe essere utilizzata solo per debug temporaneo. Rimuovila non appena finisci il test.

Strumenti e Comandi Essenziali

kubectl exec: Esegue comandi all'interno di un pod (es. ping, curl, nslookup).
kubectl logs: Visualizza i log dei pod, specialmente per i componenti del control plane e i plugin di rete.
kubectl describe: Ottiene informazioni dettagliate su pod, servizi, ingress e network policies, che spesso rivelano stato ed eventi.
kubectl get: Elenca le risorse e il loro stato di base.
tcpdump: Un potente analizzatore di pacchetti a riga di comando. Puoi eseguirlo all'interno di un pod o su un nodo per catturare il traffico di rete.
```
# Esempio: Cattura il traffico sull'interfaccia eth0 all'interno di un pod
kubectl exec <nome-pod> -- tcpdump -i eth0 -nn port 80
```

Conclusione

Debugga la rete di Kubernetes dall'interno verso l'esterno. Prova prima la connettività IP del pod, poi gli endpoint del servizio, poi il DNS, poi la NetworkPolicy e infine il comportamento dell'Ingress o del load balancer esterno. Questo ordine ti impedisce di inseguire un sintomo di Ingress quando il servizio non ha endpoint pronti.