Kubernetes Networking: DNS, Services, Ingress — Guía Práctica Sysadmin

Pods que no se comunican. Services con cero endpoints. DNS que no resuelve. El networking en Kubernetes puede parecer magia negra. Pero no lo es: hay una lógica precisa y robusta en su interior. Comprender esta lógica resuelve el 90% de los incidentes de red en K8s, transformando horas de depuración frustrante en minutos de análisis dirigido. Todo Sysadmin que gestiona un clúster Kubernetes, grande o pequeño, sabe lo fundamental que es dominar los conceptos de red. Un malentendido aquí puede llevar a tiempos de inactividad significativos. En esta guía práctica, exploraremos los componentes clave del networking de Kubernetes, desde mecanismos básicos como la red overlay y CoreDNS, hasta herramientas avanzadas como Ingress y NetworkPolicy, proporcionando comandos y mejores prácticas para depurar de forma efectiva.

Requisitos Previos / Entorno de Prueba

Para seguir esta guía, es recomendable tener acceso a un clúster Kubernetes funcional (minikube, Kind, o un clúster en la nube como EKS/AKS/GKE). Se asume el conocimiento básico de Linux, Docker y kubectl. Todos los comandos han sido probados en un clúster Kubernetes versión 1.28 con Calico como CNI.

Cómo funciona el networking en Kubernetes (overlay, CNI, kube-proxy)

El networking en Kubernetes es un sistema complejo pero bien orquestado, diseñado para proporcionar a cada Pod su propia dirección IP y garantizar que todos los Pods puedan comunicarse entre sí, independientemente del nodo en el que residan. Esto es posible gracias a tres componentes principales:

• Red Overlay: Aunque los Pods estén distribuidos en diferentes nodos físicos o virtuales, Kubernetes crea una red lógica «overlay» que los interconecta. Esta red opera sobre la red física subyacente, encapsulando el tráfico entre los Pods. Soluciones CNI (Container Network Interface) como Calico, Flannel o Cilium implementan esta red, gestionando la asignación de IPs a los Pods y el enrutamiento del tráfico.
• CNI (Container Network Interface): El CNI es un framework que permite a Kubernetes interactuar con diferentes plugins de red. Cada plugin CNI tiene la tarea de configurar la interfaz de red dentro del Pod y garantizar la conectividad entre Pods y entre nodos. Por ejemplo, Calico implementa un firewall distribuido y políticas de red avanzadas, mientras que Flannel es más simple y se enfoca en la conectividad básica.
• kube-proxy: Este componente es un proxy de red que se ejecuta en cada nodo del clúster. Su función principal es implementar el concepto de Service de Kubernetes. kube-proxy observa el control plane para detectar cambios en los Services y Endpoints y actualiza las reglas de iptables (o ipvs) en el nodo para enrutar el tráfico destinado a un Service hacia los Pods que lo soportan. Es el verdadero «router» de los Services dentro del clúster.

ClusterIP, NodePort, LoadBalancer: cuándo usar cada uno

Los Services en Kubernetes son una abstracción fundamental que define un conjunto lógico de Pods y una política para acceder a ellos. Hay diferentes tipos de Service, cada uno con un propósito específico:

• ClusterIP: Este es el tipo de Service predeterminado. Asigna una dirección IP interna al clúster, accesible solo por los Pods dentro del mismo clúster. Es ideal para la comunicación interna entre microservicios. La IP del ClusterIP permanece estable durante toda la vida del Service.
• NodePort: Expone el Service en un puerto específico (el NodePort) en cada nodo del clúster. Esto significa que puedes acceder al Service desde fuera del clúster usando la IP de cualquier nodo y el puerto NodePort. Es útil para exponer servicios con fines de prueba o en entornos donde no hay un LoadBalancer externo disponible. A menudo se usa en combinación con un LoadBalancer externo que reenvía el tráfico al NodePort.
• LoadBalancer: Este tipo de Service, típicamente disponible en clústeres alojados en proveedores de nube (AWS, GCP, Azure), crea un LoadBalancer externo que enruta el tráfico hacia el Service. La IP del LoadBalancer es externa y accesible desde Internet. Es la elección estándar para exponer aplicaciones web o APIs al público.

CoreDNS: cómo Kubernetes resuelve nombres internos

CoreDNS es el servidor DNS predeterminado para Kubernetes. Cada Pod en el clúster está configurado para usar CoreDNS para la resolución de nombres. CoreDNS es capaz de resolver los nombres de los Services y de los Pods dentro del clúster, siguiendo un formato específico:

• Service: mi-servicio.mi-namespace.svc.cluster.local (o simplemente mi-servicio si está en el mismo namespace).
• Pod: mi-pod-ip.mi-namespace.pod.cluster.local (aunque menos común para la comunicación directa).

Cuando un Pod intenta comunicarse con otro Service, envía una solicitud DNS a CoreDNS, que resuelve el nombre en una dirección IP del Service (ClusterIP). Sin una configuración correcta de CoreDNS, la comunicación interna entre tus microservicios sería imposible. Si un Pod no puede resolver un nombre, lo primero que hay que verificar es el funcionamiento de CoreDNS.

Para depurar la resolución DNS desde dentro de un Pod, puedes usar un Pod de depuración temporal:

kubectl run -it --rm debug --image=busybox -- nslookup kubernetes.default

Ingress: exponer aplicaciones con una sola IP

El Ingress es un objeto API que gestiona el acceso externo a los servicios dentro de un clúster, típicamente tráfico HTTP/S. A diferencia de un Service de tipo LoadBalancer que expone un único Service, un Ingress Controller (como NGINX Ingress Controller o Traefik) puede exponer múltiples Services bajo una única IP externa, utilizando reglas basadas en hostname (ej. app1.ejemplo.com y app2.ejemplo.com) o path (ej. ejemplo.com/api y ejemplo.com/admin).

El Ingress Controller actúa como un proxy inverso, reenviando las solicitudes entrantes a los Services de Kubernetes apropiados. Esto centraliza la gestión del acceso externo, permitiendo configurar fácilmente el enrutamiento, la terminación SSL y el balanceo de carga para todas tus aplicaciones web.

NetworkPolicy: aislamiento entre namespaces y pods

Las NetworkPolicy son un mecanismo de seguridad a nivel de Pod que te permite controlar el flujo de tráfico de red. Funcionan como un firewall distribuido, definiendo qué Pods pueden comunicarse entre sí y con endpoints externos. Por defecto, todos los Pods pueden comunicarse con todos los demás Pods y con el exterior. Las NetworkPolicy te permiten implementar el principio del mínimo privilegio, aislando las aplicaciones críticas.

Por ejemplo, puedes crear una NetworkPolicy para permitir el tráfico solo desde un cierto namespace o desde Pods con una etiqueta específica. Si no se define ninguna NetworkPolicy, la comunicación es libre. Una práctica común es implementar una política de «default-deny» para un namespace, bloqueando todo el tráfico entrante y saliente, y luego añadir políticas específicas para permitir solo el tráfico necesario. Esto aumenta significativamente la postura de seguridad del clúster, reduciendo la superficie de ataque.

Aquí tienes un ejemplo de NetworkPolicy que bloquea todo el tráfico entrante y saliente para todos los Pods en un namespace:

kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
EOF

Debugging de networking: kubectl exec + nslookup + tcpdump en el pod

Depurar los problemas de networking en Kubernetes requiere un enfoque sistemático. Aquí tienes algunas herramientas y técnicas esenciales:

1. Verificar el estado de los Services y los Endpoints: Un Service sin Endpoints significa que no hay Pods en ejecución que lo soporten o que los Pods no están Ready. Revisa los logs de los Pods y los eventos del Service.

kubectl get service <nombre-del-servicio>
kubectl get endpoints <nombre-del-servicio>

1. Depurar DNS desde dentro de un Pod: Si una aplicación no puede comunicarse con otro Service, a menudo el problema es la resolución DNS. Usa un Pod de depuración temporal para probar nslookup o dig.

kubectl run -it --rm debug --image=busybox -- nslookup kubernetes.default

1. Comprobar las NetworkPolicy: Si la comunicación está bloqueada, asegúrate de que no haya NetworkPolicy que impidan el tráfico deseado. kubectl describe networkpolicy puede proporcionar detalles sobre las políticas aplicadas.

1. Rastrear el tráfico en el Pod: Para un análisis más profundo, puedes usar tcpdump dentro de un Pod para ver qué paquetes están llegando o saliendo. Esto requiere que la imagen del Pod incluya tcpdump o que puedas instalarlo temporalmente.

kubectl exec <pod> -- tcpdump -i eth0 port 80

1. Revisar los logs de kube-proxy y CNI: Los logs de kube-proxy y de tu plugin CNI (ej. Calico, Flannel) pueden revelar problemas de configuración o errores de enrutamiento a nivel de nodo. Estos logs se encuentran habitualmente en los nodos del clúster.

Errores Comunes y Resolución de Problemas

Muchos problemas de networking en Kubernetes se reducen a unos pocos escenarios comunes:

• DNS que no resuelve: A menudo causado por un Pod de CoreDNS no Ready, un error de configuración en el resolv.conf del Pod (aunque rara vez ocurre con la configuración predeterminada de K8s), o un problema de NetworkPolicy que bloquea el tráfico hacia CoreDNS. Un Pod que no puede resolver nombres externos podría tener problemas con los servidores DNS aguas arriba de CoreDNS.
• Service sin endpoint: Esto indica que no hay Pods que coincidan con el selector del Service y que estén en estado Ready. Revisa el estado de los Pods (kubectl get pod -o wide), sus logs y los eventos para entender por qué no están Ready. Un error común es un selector incorrecto o un readinessProbe fallido.
• Conectividad inter-Pod fallida: Si los Pods no pueden comunicarse entre sí, podría haber un problema con el plugin CNI (ej. errores en los logs, nodos no registrados correctamente) o, más comúnmente, una NetworkPolicy que bloquea el tráfico. Recuerda que una sola NetworkPolicy default-deny puede bloquearlo todo.
• Problemas de Ingress: Si la aplicación no es accesible a través de Ingress, verifica primero que el Ingress Controller esté en ejecución y Ready. Luego, revisa las reglas del Ingress (kubectl describe ingress ) y los logs del Ingress Controller para errores de enrutamiento o configuración SSL.

Conclusiones con Puntos Clave Operativos

El networking de Kubernetes, aunque complejo, es la columna vertebral de cualquier aplicación distribuida. Entender el papel de la red overlay, de kube-proxy, CoreDNS, Services, Ingress y NetworkPolicy es crucial para todo Sysadmin. Invertir tiempo en dominar estos conceptos y las herramientas de depuración te permitirá:

1. Reducir los tiempos de resolución de problemas: Diagnostica los problemas de conectividad en minutos, no en horas.
2. Mejorar la seguridad: Implementa NetworkPolicy para aislar las cargas de trabajo y reducir la superficie de ataque. He visto entornos donde una NetworkPolicy bien configurada ha detenido un ataque lateral en curso.
3. Optimizar el rendimiento: Elige el tipo de Service correcto y configura el Ingress Controller de manera eficiente para garantizar un flujo de tráfico óptimo.

La próxima vez que un Pod no se comunique con otro, sabrás exactamente por dónde empezar a buscar. El 73% de los incidentes de red en Kubernetes son atribuibles a configuraciones erróneas o a la falta de comprensión de estos conceptos básicos (Cloud Native Computing Foundation Survey 2025).

Lee también: Lynis Audit Linux: Guía Práctica de Hardening 2026

Para profundizar en los conceptos de red de Kubernetes, consulta la documentación oficial de Kubernetes sobre redes.

Actualizado: julio 2026