Configuración de los pods

1. Cree un nuevo espacio de nombres privilegiado para los pods de prueba. La creación de un nuevo espacio de nombres impide que las políticas o configuraciones personalizadas de los espacios de nombres existentes afecten a los pods de prueba. En este ejemplo, el nuevo espacio de nombres se denomina pod-network-test.

   Cree el espacio de nombres.

   kubectl create ns pod-network-test
   

2. Cree y aplique el siguiente conjunto de demonios para crear un pod de prueba en cada 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
         ```
   
   

3. Aplique el daemonset para desplegar pods de prueba en los nodos trabajadores.

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

1. Compruebe que los pods se inician correctamente listando todos los pods del espacio de nombres.

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

Ejecución de pruebas dentro de los pods

Ejecute los mandatos curl, ping y nc para probar la conexión de red de cada pod y el mandato dig para probar el DNS del clúster. Revise cada salida y, a continuación, consulte Identificación de problemas para averiguar qué pueden significar los resultados.

1. Liste los pods de prueba y anote el nombre y la IP de cada pod.

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

   Salida de ejemplo

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

2. Ejecute el comando exec para iniciar sesión en un pod.

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

3. Ejecute el mandato curl en el pod y anote la salida. Especifique la IP del pod en el que no inició sesión. Esto prueba la conexión de red entre pods en nodos diferentes.

   curl <pod_ip>:8080
   

   Salida satisfactoria de ejemplo.

   Hostname: webserver-test-t546j
   
   Pod Information:
     node name:	env var NODE_NAME not set
     pod name:	webserver-test-t546j
     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. Ejecute el mandato ping en el pod y anote la salida. Especifique la IP del pod en el que no inició sesión con el comando exec. Esto prueba la conexión de red entre pods en nodos diferentes.

   ping -c 5 <pod_ip>
   

   Salida satisfactoria de ejemplo.

   PING 172.30.248.201 (172.30.248.201) 56(84) bytes of data.
   64 bytes from 172.30.248.201: icmp_seq=1 ttl=62 time=0.473 ms
   64 bytes from 172.30.248.201: icmp_seq=2 ttl=62 time=0.449 ms
   64 bytes from 172.30.248.201: icmp_seq=3 ttl=62 time=0.381 ms
   64 bytes from 172.30.248.201: icmp_seq=4 ttl=62 time=0.438 ms
   64 bytes from 172.30.248.201: icmp_seq=5 ttl=62 time=0.348 ms
   
   --- 172.30.248.201 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. Ejecute el mandato nc en el pod y anote la salida. Especifique la IP del pod en el que no inició sesión con el comando exec. Esto prueba la conexión de red entre pods en nodos diferentes.

   nc -vzw 5 <pod_ip> 8080
   

   Salida satisfactoria de ejemplo.

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

6. Ejecute los mandatos dig para probar el DNS.

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

   Salida de ejemplo

   172.21.0.1
   

   dig +short ibm.com
   

   Salida de ejemplo

   23.50.74.64
   

7. Ejecute los comandos curl para probar una conexión TCP o HTTPS completa al servicio. Este ejemplo prueba la conexión entre el pod y el maestro de clúster recuperando la información de versión del clúster. La recuperación correcta de la versión del clúster indica una conexión en buen estado.

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

   Salida de ejemplo

   {
   "major": "1",
   "minor": "25",
   "gitVersion": "v1.25.14+bcb9a60",
   "gitCommit": "3bdfba0be09da2bfdef3b63e421e6a023bbb08e6",
   "gitTreeState": "clean",
   "buildDate": "2023-10-30T21:33:07Z",
   "goVersion": "go1.19.13 X:strictfipsruntime",
   "compiler": "gc",
   "platform": "linux/amd64"
   }
   

8. Salga del pod.

   exit
   

9. Repita los pasos anteriores con los pods restantes.

Identificación de problemas

Revise las salidas de la sección anterior para ayudar a encontrar la causa de los problemas de red de pod. Esta sección lista algunas causas comunes que se pueden identificar en la sección anterior.

• Si los mandatos funcionan normalmente en los pods de prueba, pero sigue teniendo problemas de red en los pods de aplicación en el espacio de nombres predeterminado, es posible que haya problemas relacionados específicamente con la aplicación.

  • Es posible que tenga políticas de seguridad de red de Calico o Kubernetes que restrinjan el tráfico de red. Si se aplica una política de red a un pod, se descarta todo el tráfico que no está permitido específicamente por dicha política. Para obtener más información sobre las políticas de red, consulte la documentación deKubernetes.
  • Si utiliza Istio o Red Hat OpenShift Service Mesh, es posible que haya problemas de configuración de servicio que descartan o bloquean el tráfico entre pods. Para obtener más información, consulte la documentación de resolución de problemas para Istio y Red Hat OpenShift Service Mesh.
  • El problema puede estar relacionado con errores en la aplicación en lugar de con el clúster, y puede requerir su propia resolución de problemas independiente.

• Si los mandatos curl, ping o nc han fallado para determinados pods, identifique en qué nodos trabajadores están dichos pods. Si el problema sólo existe en algunos de los nodos trabajadores, sustituya estos nodos trabajadores o consulte información adicional sobre resolución de problemas de nodos trabajadores.

• Si las búsquedas de DNS de los mandatos dig han fallado, compruebe que el DNS del clúster de esté configurado correctamente.

Si todavía no puede resolver el problema de red de pod, abra un caso de soporte e incluya una descripción detallada del problema, cómo ha intentado resolverlo, qué tipos de pruebas ha ejecutado y registros relevantes para los pods y los nodos trabajadores. Para obtener más información sobre cómo abrir un caso de soporte y qué información incluir, consulte la guía de depuración general.