Depuración de conexiones de red entre pods

Revise las opciones y estrategias para depurar problemas de conexión entre pods.

Compruebe el estado de los componentes del clúster y los pods de red

Resuelve problemas de red de los pods y de conectividad.

Siga estos pasos para comprobar el estado de los componentes. Se pueden producir problemas de red si los componentes del clúster no están actualizados o no están en buen estado.

Compruebe que el nodo maestro y los nodos trabajadores del clúster se ejecuten en una versión soportada y estén en buen estado. Si el maestro o los trabajadores del clúster no ejecutan una versión soportada, realice las actualizaciones necesarias para que ejecuten una versión soportada. Si el estado de alguno de los componentes no es Normal o Ready, revise los estados de salud del maestro del clúster, estados del clúster, estados de los nodos trabajadores, o pasos para solucionar problemas de Critical o NotReady nodos trabajadores para obtener más información. Asegúrese de que se resuelvan los problemas relacionados antes de continuar.

Para comprobar la versión y el estado del nodo maestro del clúster:
```
ibmcloud oc cluster get -c CLUSTER-ID
```
Para comprobar las versiones y el estado del nodo trabajador:
```
ibmcloud oc workers -c CLUSTER-ID
```
Para cada nodo trabajador, verifique que Calico y los pods DNS del clúster están presentes y en ejecución en un estado correcto.
1. Ejecuta el comando para obtener los detalles de los pods de tu clúster.
```
 oc get pods -A -o wide | grep -e calico -e dns-default
```
2. En la salida, asegúrese de que el clúster incluya los pods siguientes. Asegúrese de que el estado de cada pod sea Running y de que los pods no tengan demasiados reinicios.
  - Exactamente un pod de calico-node por nodo trabajador.
  - Al menos un pod de calico-typha por clúster. Los clústeres más grandes pueden tener más de uno.
  - Exactamente un pod de calico-kube-controllers por clúster.
  - Un dns-default pod por nodo. Sin embargo, algunos nodos podrían no tener la vaina dns-default si tienen etiquetas adjuntas. Esto es normal y no causa problemas en la red.
  Salida de ejemplo
```
NAMESPACE        NAME                               READY   STATUS     RESTARTS    AGE    IP              NODE           NOMINATED     READINESS GATES
calico-system    calico-kube-controllers-1a1a1a1    1/1     Running     0          37m    172.17.61.195   10.245.0.5     <none>        <none>
calico-system    calico-node-1a1a1a1                1/1     Running     0          37m    10.245.0.5      10.245.0.5     <none>        <none>
calico-system    calico-node-1a1a1a1                1/1     Running     0          37m    10.245.0.4      10.245.0.4     <none>        <none>
calico-system    calico-typha-1a1a1a1               1/1     Running     0          37m    10.245.0.5      10.245.0.5     <none>        <none>
openshift-dns    dns-default-1a1a1a1                2/2     Running     0          33m    172.17.36.144   10.245.0.4     <none>        <none>
openshift-dns    dns-default-1a1a1a1                2/2     Running     0          33m    172.17.61.210   10.245.0.5     <none>        <none>
```
3. Si alguno de los pods listados no está presente o no está en buen estado, pase por el clúster y por la documentación de resolución de problemas de nodo trabajador incluida en los pasos anteriores. Asegúrese de que los problemas con los pods en este paso se resuelvan antes de continuar.

Depurar con pods de prueba

Para determinar la causa de los problemas de red en los pods, puede crear un pod de prueba en cada uno de los nodos trabajadores. A continuación, puede ejecutar pruebas y observar la actividad de red dentro del pod, lo que puede revelar el origen del problema.

Configuración de los pods

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.
```
oc create ns pod-network-test
```

Añade etiquetas al nuevo espacio de nombres privilegiado.

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"

Ejecute el mandato para permitir que el espacio de nombres ejecute pods con un contexto de seguridad privilegiado.
```
oc adm policy add-scc-to-group privileged system:serviceaccounts:pod-network-test
```

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

Aplique el conjunto de demonios para desplegar un pod de prueba en cada nodo trabajador.
```
oc apply --namespace pod-network-test -f <daemonset-file>
```
Compruebe que los pods se inician correctamente listando todos los pods del espacio de nombres.
```
oc 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.

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

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

Salida de ejemplo

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>

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

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

Ejecute el mandato curl en el pod y anote la salida. Especifique la IP de un pod de prueba en el que no haya iniciado 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-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

Ejecute el mandato ping en el pod y anote la salida. Especifique la IP de un pod de prueba en el que no haya iniciado 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.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

Ejecute el mandato nc en el pod y anote la salida. Especifique la IP de un pod de prueba en el que no haya iniciado 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
```

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

Ejecute comandos curl para probar una conexión completa TCP o HTTPS 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": "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"

Cierra sesión en el pod.
```
exit
```
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 comandos funcionaron con normalidad en los pods de prueba, pero sigue teniendo problemas de red con los pods de aplicación en su espacio de nombres predeterminado, es posible que haya problemas relacionados específicamente con su 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 está utilizando Istio o Red Hat OpenShift Service Mesh, puede haber problemas de configuración del servicio que dejen caer o bloqueen el tráfico entre pods. Para más información, consulte la documentación de solución de problemas de 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, consulte la información de resolución de problemas de DNS deRed Hat.

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.