Redes de EKS: VPC CNI y balanceo de carga

Kubernetes requiere que cada pod tenga una dirección IP única y enrutable, y que los pods se comuniquen entre sí sin NAT. El plugin Container Network Interface (CNI) se encarga de asignar direcciones IP y configurar las rutas de red en los nodos de trabajo. Las distintas plataformas de Kubernetes utilizan implementaciones de CNI diferentes; AWS utiliza el plugin Amazon VPC CNI para integrar directamente las redes de Kubernetes con la capa de VPC.

El plugin Amazon VPC CNI asigna a cada pod una dirección IP directamente del rango CIDR de la subred de su VPC. Esto convierte a los pods en ciudadanos de primera clase de la VPC: otros recursos de la VPC, sistemas locales mediante VPN/Direct Connect y grupos de seguridad pueden acceder a ellos sin traducción mediante una red superpuesta. Cada nodo de trabajo EC2 mantiene un conjunto de IP privadas secundarias (una por ranura de ENI) que se asignan a los pods cuando se programan.

El plugin VPC CNI mantiene en cada nodo un conjunto de direcciones IP preasignadas en reserva para permitir una programación rápida de los pods. Cuando se inicia un nodo, el CNI asocia varias ENI y asigna IP secundarias hasta alcanzar los valores de las variables de entorno WARM_IP_TARGET o MINIMUM_IP_TARGET. Por tanto, el número máximo de pods que puede ejecutar un nodo está limitado por el número de ENI de la instancia multiplicado por las IP por ENI, que varía según el tipo de instancia.

De forma predeterminada, todos los pods de un nodo comparten el grupo de seguridad del nodo. Con la función Security Groups for Pods, puede asignar grupos de seguridad individuales a pods específicos mediante el recurso personalizado SecurityGroupPolicy. Esto permite un control detallado del acceso a la red; por ejemplo, solo un pod de base de datos puede recibir tráfico en el puerto 5432 procedente del grupo de seguridad del pod de API. Esta función requiere la versión 1.7.7 o posterior de VPC CNI y una ENI troncal en el nodo.

Los Services de Kubernetes exponen un conjunto de pods mediante un nombre DNS y una IP estables. En EKS, los tres tipos de servicio relevantes son: ClusterIP (solo para la comunicación interna del clúster), NodePort (abre un puerto en cada nodo; rara vez se utiliza en EKS) y LoadBalancer (aprovisiona automáticamente un balanceador de carga de AWS). El tipo LoadBalancer es la forma en que se exponen la mayoría de los servicios de EKS accesibles desde Internet.

AWS Load Balancer Controller es un controlador de Kubernetes de código abierto que gestiona recursos ALB y NLB en nombre de los clústeres de EKS. Cuando crea un objeto Ingress de Kubernetes, el controlador aprovisiona un Application Load Balancer. Cuando crea un Service de tipo LoadBalancer con las anotaciones correctas, aprovisiona un Network Load Balancer. El controlador sustituye al antiguo proveedor de balanceadores de carga integrado en Kubernetes.

Un objeto Ingress de Kubernetes define reglas de enrutamiento HTTP/HTTPS, basadas en rutas y en hosts, hacia el clúster. AWS Load Balancer Controller lee los objetos Ingress anotados con kubernetes.io/ingress.class: alb y crea un Application Load Balancer correspondiente con reglas de escucha que coinciden con ellas. Esto elimina la necesidad de crear manualmente ALB y grupos de destino para cada servicio de aplicación.

Cuando su carga de trabajo requiere TCP o UDP (no HTTP), como un servidor de juegos, un servicio gRPC o un proxy de base de datos, utilice el NLB en lugar del ALB. Anote el Service de Kubernetes con service.beta.kubernetes.io/aws-load-balancer-type: 'external' y service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'. El controlador aprovisiona un NLB con las IP de los pods como destinos directos, evitando el reenvío de puertos a nivel de nodo para reducir la latencia.

EKS ejecuta CoreDNS como proveedor de DNS del clúster. Cada servicio obtiene un nombre DNS con el formato service-name.namespace.svc.cluster.local, que se resuelve en la ClusterIP del servicio. Los pods también se pueden descubrir mediante DNS. CoreDNS se implementa como un Deployment (no como un DaemonSet), y sus réplicas deben escalarse según el tamaño del clúster. EKS gestiona CoreDNS como un complemento, lo que permite realizar actualizaciones de versión automáticas.

Los objetos NetworkPolicy de Kubernetes definen reglas de permiso para el tráfico entre pods y desde los pods hacia el exterior. De forma predeterminada, todos los pods de un clúster pueden comunicarse libremente. Para aplicar una red de confianza cero, puede instalar el controlador de políticas de red de Amazon VPC CNI (disponible desde VPC CNI v1.14). Las políticas de red se evalúan en el nivel del kernel de Linux mediante eBPF, lo que proporciona una aplicación de alto rendimiento sin necesidad de una red superpuesta.

Entre los problemas habituales de redes de EKS se incluyen el agotamiento de direcciones IP (soluciónelo activando la delegación de prefijos o añadiendo subredes más grandes), los pods atascados en Pending porque el nodo no tiene IP secundarias disponibles y los fallos intermitentes de resolución DNS causados por un número insuficiente de réplicas de CoreDNS. Utilice kubectl describe pod para comprobar los eventos, kubectl describe node para consultar el número de IP asignadas y CloudWatch Container Insights para supervisar las tasas de errores de DNS a escala del clúster.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido lo siguiente: el plugin Amazon VPC CNI asigna IP nativas de la VPC a cada pod para lograr una integración fluida con la VPC, AWS Load Balancer Controller aprovisiona ALB para Ingress HTTP y NLB para Services TCP/UDP, y Security Groups for Pods permite controlar el acceso a la red a nivel de pod. A continuación, exploraremos IRSA para asociar roles de IAM detallados a las cuentas de servicio de Kubernetes.