Configurazione dei pod

1. Crea un nuovo spazio dei nomi privilegiato per i tuoi pod di test. La creazione di un nuovo spazio dei nomi impedisce che le politiche o le configurazioni personalizzate negli spazi dei nomi esistenti influenzino i tuoi pod di test. In questo esempio, il nuovo spazio dei nomi è denominato pod-network-test.

   Crea lo spazio dei nomi.

   oc create ns pod-network-test
   

2. Aggiungere le etichette al nuovo spazio dei nomi privilegiato.

   oc label namespace pod-network-test --overwrite=true \
               pod-security.kubernetes.io/enforce=privileged \
               pod-security.kubernetes.io/enforce-version=latest \
               pod-security.kubernetes.io/audit=privileged \
               pod-security.kubernetes.io/audit-version=latest \
               pod-security.kubernetes.io/warn=privileged \
               pod-security.kubernetes.io/warn-version=latest \
               security.openshift.io/scc.podSecurityLabelSync="false"
   

3. Eseguire il comando per consentire allo spazio dei nomi di eseguire i pod con un contesto di sicurezza privilegiato.

   oc adm policy add-scc-to-group privileged system:serviceaccounts:pod-network-test
   

4. Creare e applicare il seguente set di demoni per creare un pod di prova su ogni nodo.

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     labels:
       name: webserver-test
       app: webserver-test
     name: webserver-test
   spec:
     selector:
       matchLabels:
         name: webserver-test
     template:
       metadata:
         labels:
           name: webserver-test
           app: webserver-test
       spec:
         tolerations:
         - operator: "Exists"
         containers:
         - name: webserver
           securityContext:
             privileged: true
           image: us.icr.io/armada-master/network-alpine:latest
           env:
             - name: ENABLE_ECHO_SERVER
               value: "true"
             - name: POD_NAME
               valueFrom:
                 fieldRef:
                   fieldPath: metadata.name
         restartPolicy: Always
         terminationGracePeriodSeconds: 1
   

5. Applicare il daemonset per distribuire un pod di prova su ogni nodo worker.

   oc apply --namespace pod-network-test -f <daemonset-file>
   

6. Verificare che i pod vengano avviati correttamente, elencando tutti i pod nello spazio dei nomi.

   oc get pods --namespace pod-network-test -o wide
   

Esecuzione dei test all'interno dei pod

Esegui i comandi curl, ping e nc per verificare la connessione di rete di ciascun pod e il comando dig per verificare il DNS del cluster. Esaminare ciascun output, quindi consultare Identificazione dei problemi per individuare il significato dei risultati.

1. Elencare i pod di test e annotare il nome e l'IP di ciascun pod.

   oc get pods --namespace pod-network-test -o wide
   

   Output di esempio

   NAME                   READY   STATUS    RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
   webserver-test-2fv7c   1/1     Running   0          68s   172.17.36.169    10.245.0.4  <none>           <none>
   webserver-test-4mktb   1/1     Running   0          68s   172.17.61.240    10.245.0.5  <none>           <none>
   

2. Esegui il comando " exec " per accedere a un pod.

   kubectl exec -it --namespace pod-network-test <pod_name> -- sh
   

3. Esegui il comando curl sul pod e prendi nota dell'output. Specificare l'IP di un pod di prova a cui non si è effettuato l'accesso. Questo verifica la connessione di rete tra i pod su nodi differenti.

   curl <pod_ip>:8080
   

   Output di esempio riuscito.

   Hostname: webserver-test-4mktb
   Pod Information:
     node name:	env var NODE_NAME not set
     pod name:	webserver-test-4mktb
     pod namespace:	env var POD_NAMESPACE not set
     pod IP:  	env var POD_IP not set
   Connection Information:
     remote address:	172.17.36.169
     remote port:	56042
     local address:	172.17.61.240
     local port:	8080
   

4. Esegui il comando ping sul pod e prendi nota dell'output. Specificare l'IP di un pod di prova a cui non ci si è connessi con il comando exec. Questo verifica la connessione di rete tra i pod su nodi differenti.

   ping -c 5 <pod_ip>
   

   Output di esempio riuscito.

   PING 172.17.61.240 (172.17.61.240) 56(84) bytes of data.
   64 bytes from 172.17.61.240: icmp_seq=1 ttl=62 time=0.473 ms
   64 bytes from 172.17.61.240: icmp_seq=2 ttl=62 time=0.449 ms
   64 bytes from 172.17.61.240: icmp_seq=3 ttl=62 time=0.381 ms
   64 bytes from 172.17.61.240: icmp_seq=4 ttl=62 time=0.438 ms
   64 bytes from 172.17.61.240: icmp_seq=5 ttl=62 time=0.348 ms
   --- 172.17.61.240 ping statistics ---
   5 packets transmitted, 5 received, 0% packet loss, time 4086ms
   rtt min/avg/max/mdev = 0.348/0.417/0.473/0.046 ms
   

5. Esegui il comando nc sul pod e prendi nota dell'output. Specificare l'IP di un pod di prova a cui non ci si è connessi con il comando exec. Questo verifica la connessione di rete tra i pod su nodi differenti.

   nc -vzw 5 <pod_ip> 8080
   

   Output di esempio riuscito.

   nc -vzw 5 172.17.61.240 8080
   172.17.61.240 (172.17.61.240:8080) open
   

6. Eseguire i comandi dig per verificare il DNS.

   dig +short kubernetes.default.svc.cluster.local
   

   Output di esempio

   172.21.0.1
   

   dig +short ibm.com
   

   Output di esempio

   23.50.74.64
   

7. Eseguire i comandi curl per testare una connessione completa TCP o HTTPS al servizio. Questo esempio verifica la connessione tra il pod e il master cluster richiamando le informazioni sulla versione del cluster. Il corretto richiamo della versione del cluster indica una connessione integra.

   curl -k https://kubernetes.default.svc.cluster.local/version
   

   Output di esempio

   "major": "1",
   "minor": "34",
   "emulationMajor": "1",
   "emulationMinor": "34",
   "minCompatibilityMajor": "1",
   "minCompatibilityMinor": "33",
   "gitVersion": "v1.34.7+IKS",
   "gitCommit": "67bf12be5abc8e65743a243172693ad1a098a2c4",
   "gitTreeState": "clean",
   "buildDate": "2026-04-16T04:24:50Z",
   "goVersion": "go1.25.9",
   "compiler": "gc",
   "platform": "linux/amd64"
   

8. Esci dal pod.

   exit
   

9. Ripeti i passi precedenti con i pod rimanenti.

Identificazione dei problemi

Esamina gli output della precedente sezione per trovare la causa dei tuoi problemi di rete del pod. Questa sezione elenca alcune cause comuni che possono essere identificate dalla sezione precedente.

• Se i comandi funzionano normalmente sui pod di prova, ma si riscontrano ancora problemi di rete con i pod dell'applicazione nello spazio dei nomi predefinito, è possibile che ci siano problemi legati specificamente alla propria applicazione.

  • Potresti avere in atto Calico o le politiche di sicurezza della rete Kubernetes che limitano il traffico di rete. Se una politica di rete viene applicata a un pod, tutto il traffico non specificamente consentito da tale politica viene eliminato. Per ulteriori informazioni sulle politiche di rete, consulta la documentazione diKubernetes.
  • Se si utilizza Istio o Red Hat OpenShift Service Mesh, potrebbero verificarsi problemi di configurazione del servizio che fanno cadere o bloccano il traffico tra i pod. Per ulteriori informazioni, consultare la documentazione per la risoluzione dei problemi di Istio e Red Hat OpenShift Service Mesh.
  • Il problema potrebbe essere correlato ai bug nell'applicazione piuttosto che al tuo cluster e potrebbe richiedere la tua risoluzione indipendente dei problemi.

• Se i comandi curl, ping o nc non sono riusciti per determinati pod, identifica i nodi di lavoro su cui si trovano tali pod. Se il problema esiste solo su alcuni dei tuoi nodi di lavoro, sostituisci tali nodi di lavoro o visualizza ulteriori informazioni sulla risoluzione dei problemi del nodo di lavoro.

• Se le ricerche DNS dai comandi dig non sono riuscite, consultare Red Hat Informazioni sulla risoluzione dei problemi DNS.

Se non riesci ancora a risolvere il tuo problema di rete del pod, apri un caso di supporto e includi una descrizione dettagliata del problema, come hai provato a risolverlo, quali tipi di test hai eseguito e log pertinenti per i tuoi pod e nodi di lavoro. Per ulteriori informazioni sull'apertura di un caso di supporto e quali informazioni includere, consultare la guida generale al debug.