Depuración de Problemas de Red en Kubernetes: Técnicas Esenciales

Los problemas de red en Kubernetes suelen manifestarse como tiempos de espera, Connection refused, fallos de DNS, endpoints de servicio vacíos o respuestas incorrectas de Ingress. Para solucionarlos rápidamente, sigue la ruta: pod de origen, pod de destino, Servicio, DNS, NetworkPolicy y luego Ingress o balanceador de carga.

Esta guía te proporciona una secuencia práctica de verificaciones y los comandos kubectl que exponen dónde se detiene el tráfico.

Comprendiendo los Fundamentos de Red en Kubernetes

Antes de sumergirnos en la depuración, es importante comprender los conceptos centrales de red en Kubernetes:

Red de Pods: Cada pod obtiene su propia dirección IP única. Los pods dentro del mismo nodo pueden comunicarse directamente. Los pods en diferentes nodos se comunican a través de una red virtual (plugin CNI).
Servicios: Los Servicios proporcionan una dirección IP estable y un nombre DNS para un conjunto de pods. Actúan como una capa de abstracción, permitiendo que otros pods o clientes externos accedan a los backends de la aplicación sin necesidad de conocer las IPs individuales de los pods.
DNS: El DNS de Kubernetes (generalmente CoreDNS) resuelve los nombres de los Servicios a IPs del clúster, permitiendo el descubrimiento de servicios.
Políticas de Red: Estos recursos controlan el tráfico de pods cuando tu plugin CNI las aplica. Un clúster sin soporte de NetworkPolicy aceptará los objetos pero puede no aplicar las reglas.
Ingress: Los controladores Ingress gestionan el acceso externo a los servicios dentro del clúster, típicamente HTTP y HTTPS. Proporcionan enrutamiento, balanceo de carga y terminación SSL.

Problemas Comunes de Red y Estrategias de Depuración

1. Fallos de Comunicación Pod a Pod

Cuando los pods no pueden comunicarse entre sí, incluso dentro del mismo namespace, es un indicador principal de un problema de red.

Síntomas:

Errores de aplicación que indican tiempos de espera o rechazos de conexión.
Comandos curl o ping desde un pod a otro fallan.

Pasos de Depuración:

Verificar IPs de Pods: Asegúrate de que tanto el pod de origen como el de destino tengan direcciones IP válidas. Usa kubectl exec <nombre-pod> -- ip addr.
Verificar Conectividad de Red (dentro del pod): Desde el pod de origen, intenta hacer ping a la IP del pod de destino. Si esto falla, el problema podría estar en el plugin CNI o en la red del nodo.
```
kubectl exec <nombre-pod-origen> -- ping <ip-pod-destino>
```
Inspeccionar Políticas de Red: Las Network Policies son un culpable común. Verifica si alguna política está bloqueando inadvertidamente el tráfico entre los pods.
```
kubectl get networkpolicies -n <namespace>
```
Examina las reglas podSelector e ingress/egress para entender qué tráfico está permitido o denegado. Una vez que un pod es seleccionado por una política de ingreso, solo se permite el tráfico de ingreso explícitamente autorizado.
Estado del Plugin CNI: Asegúrate de que tu plugin de Interfaz de Red de Contenedores (CNI) (ej., Calico, Flannel, Cilium) se esté ejecutando correctamente en todos los nodos. Verifica los logs de los pods del daemonset CNI.
```
kubectl get pods -n kube-system -l k8s-app=<etiqueta-plugin-cni>
kubectl logs <nombre-pod-plugin-cni> -n kube-system
```

2. Problemas de Descubrimiento de Servicios

Cuando los pods no pueden alcanzar otros servicios por sus nombres DNS o IPs de clúster, indica un problema con el DNS de Kubernetes o la configuración del objeto Service.

Síntomas:

Errores de aplicación como Name or service not known.
Comandos nslookup o dig dentro de un pod fallan al resolver nombres de servicio.

Pasos de Depuración:

Verificar Resolución DNS: Desde un pod, prueba la resolución DNS para un servicio conocido.

kubectl exec <nombre-pod> -- nslookup <nombre-servicio>.<namespace>.svc.cluster.local

Si esto falla, verifica los pods de CoreDNS en busca de errores.

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

Verificar Objeto Service: Asegúrate de que el objeto Service esté configurado correctamente y tenga endpoints que apunten a pods saludables.
```
kubectl get service <nombre-servicio> -n <namespace> -o yaml
kubectl get endpoints <nombre-servicio> -n <namespace>
```
La salida de endpoints debe listar las direcciones IP de los pods que respaldan el servicio.
Sondas de Preparación de Pods: Si los pods no están pasando sus sondas de preparación, no se agregarán a los endpoints del Servicio. Verifica las configuraciones de las sondas de preparación y los logs de los pods para detectar problemas.

3. Problemas del Controlador Ingress

El acceso externo a tus servicios es gestionado por recursos Ingress y controladores Ingress. Los problemas aquí pueden hacer que tu aplicación sea inaccesible desde fuera del clúster.

Síntomas:

Errores 502 Bad Gateway, 404 Not Found o 503 Service Unavailable al acceder a las aplicaciones a través de su URL externa.
Logs del controlador Ingress que muestran errores relacionados con los servicios backend.

Pasos de Depuración:

Verificar Pods del Controlador Ingress: Asegúrate de que los pods del controlador Ingress (ej., Nginx Ingress, Traefik) se estén ejecutando y estén saludables.

kubectl get pods -l app.kubernetes.io/component=controller # Ajusta la etiqueta según tu controlador ingress
kubectl logs <nombre-pod-controlador-ingress> -n <namespace-ingress>

Verificar Recurso Ingress: Verifica la configuración de tu recurso Ingress.
```
kubectl get ingress <nombre-ingress> -n <namespace> -o yaml
```
Asegúrate de que la sección rules mapee correctamente los nombres de host y las rutas al service.name y service.port apropiados.
Verificar Servicio y Endpoints: Al igual que con el descubrimiento de servicios, asegúrate de que el servicio backend al que apunta el Ingress esté configurado correctamente y tenga endpoints saludables.
```
kubectl get service <nombre-servicio-backend> -n <namespace>
kubectl get endpoints <nombre-servicio-backend> -n <namespace>
```
Firewall y Balanceador de Carga: Si se accede desde fuera del clúster, asegúrate de que cualquier firewall externo o balanceador de carga del proveedor de la nube esté configurado correctamente para reenviar el tráfico al servicio del controlador Ingress (a menudo un servicio de tipo LoadBalancer).

4. Aplicación de Políticas de Red

Las Network Policies pueden ser poderosas pero también una fuente de problemas de conectividad si están mal configuradas. Operan bajo el principio de mínimo privilegio; si una política no permite explícitamente el tráfico, este es denegado.

Pasos de Depuración:

Identificar Políticas Aplicadas: Determina qué Network Policies están afectando a los pods en cuestión.
```
kubectl get networkpolicy -n <namespace>
```
Inspeccionar Selectores de Políticas: Examina cuidadosamente el podSelector en cada NetworkPolicy relevante. Este selector determina a qué pods se aplica la política. Si un pod es seleccionado por múltiples políticas, el tráfico permitido es la unión de esas reglas de política, no la regla única más restrictiva.
Revisar Reglas de Ingress/Egress: Analiza las secciones ingress y egress de la Network Policy. Si estás intentando establecer una conexión desde el Pod A hacia el Pod B, debes asegurarte de:
- Una Network Policy aplicada al Pod B permita el tráfico de ingreso desde el Pod A (o un selector de etiquetas más amplio que incluya al Pod A).
- Una Network Policy aplicada al Pod A permita el tráfico de egreso hacia el Pod B (o un selector de etiquetas más amplio que incluya al Pod B).
Probar con una Política Ampliamente Abierta: Como paso temporal de solución de problemas, puedes crear una Network Policy que permita todo el tráfico hacia y desde pods o namespaces específicos para ver si se restablece la conectividad. Esto ayuda a aislar si el problema es realmente con las Network Policies.
```
# Ejemplo: Permitir todo el ingreso y egreso para pods con la etiqueta 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:
    - {}
```
Advertencia: Esta política allow-all solo debe usarse para depuración temporal. Elimínala tan pronto como termines la prueba.

Herramientas y Comandos Esenciales

kubectl exec: Ejecuta comandos dentro de un pod (ej., ping, curl, nslookup).
kubectl logs: Visualiza logs de pods, especialmente para componentes del plano de control y plugins de red.
kubectl describe: Obtén información detallada sobre pods, servicios, ingress y políticas de red, que a menudo revela estado y eventos.
kubectl get: Lista recursos y su estado básico.
tcpdump: Un potente analizador de paquetes de línea de comandos. Puedes ejecutarlo dentro de un pod o en un nodo para capturar tráfico de red.
```
# Ejemplo: Capturar tráfico en la interfaz eth0 dentro de un pod
kubectl exec <nombre-pod> -- tcpdump -i eth0 -nn port 80
```

Conclusión

Depura la red de Kubernetes desde adentro hacia afuera. Primero prueba la conectividad IP del pod, luego los endpoints del Servicio, luego el DNS, luego la NetworkPolicy y finalmente el comportamiento del Ingress o balanceador de carga externo. Ese orden evita que persigas un síntoma de Ingress cuando el Servicio no tiene endpoints listos.