En entornos empresariales donde la seguridad y las políticas de red son prioridad, es habitual que los servidores, incluidos los nodos worker de Kubernetes, residan en subredes privadas sin acceso directo a internet. Todo el tráfico saliente debe pasar por un proxy HTTP HTTPS centralizado y monitorizado. Esto plantea un reto para servicios como Amazon EKS que necesitan descargar imágenes, comunicarse con APIs de AWS y realizar tareas de arranque. Al usar el módulo terraform-aws-modules/eks/aws es imprescindible una forma automatizada y fiable de inyectar la configuración del proxy en los grupos de nodos administrados para que el sistema operativo, el runtime de contenedores containerd y los componentes de Kubernetes sean conscientes del proxy desde el primer arranque.
El reto principal es asegurar una configuración completa del proxy más allá de definir solo las variables de entorno HTTP_PROXY y HTTPS_PROXY. Un nodo EKS moderno basado en la AMI optimizada de Amazon Linux 2 requiere configuración diferenciada para varios componentes: el sistema operativo para sesiones de shell y utilidades, el runtime containerd para poder extraer imágenes de Docker Hub o ECR, el proceso de bootstrap nodeadm para comunicarse con el control plane evitando el proxy cuando proceda, y el gestor de paquetes yum si se instalan paquetes adicionales durante el user data.
La solución robusta pasa por ejecutar un script de cloud init antes del arranque del agente de bootstrap. El hook cloudinit_pre_nodeadm del módulo terraform-aws-modules/eks/aws permite ejecutar un script justo después de la inicialización básica del SO y antes de que se inicie nodeadm. De este modo se garantiza que containerd, nodeadm y kubelet hereden una configuración de red y proxy correcta en cuanto se pongan en marcha.
Conceptualmente los pasos a seguir son los siguientes. Usar IMDSv2 para recuperar de forma segura metadatos de la instancia y obtener la CIDR de la VPC para incorporarla al NO_PROXY. Recepcionar desde Terraform la variable cluster_service_ipv4_cidr y añadirla también a NO_PROXY para que el rango interno de servicios de Kubernetes omita el proxy. Persistir HTTP_PROXY HTTPS_PROXY y NO_PROXY en /etc/environment para que sean variables del sistema. Crear overrides de systemd para containerd y nodeadm que incluyan EnvironmentFile=/etc/environment de forma que los servicios carguen esas variables al iniciarse. Añadir la configuración proxy a /etc/yum.conf para las operaciones de instalación. Finalmente recargar systemd y reiniciar containerd para aplicar los cambios; nodeadm arrancará después con la configuración correcta.
En la práctica esto se implementa pasando al parámetro cloudinit_pre_nodeadm del módulo un script que realiza las acciones anteriores y que construye dinámicamente la variable NO_PROXY incorporando la CIDR de la VPC y la CIDR de servicios de Kubernetes proporcionada desde Terraform. De este modo se evita codificar valores en duro y se logra una solución reutilizable y declarativa que garantiza que los nodos se unan al clúster y descarguen imágenes sin incidentes aun cuando están detrás de un proxy corporativo.
En Q2BSTUDIO somos especialistas en transformar estos diseños en despliegues operativos. Ofrecemos servicios de consultoría e implementación de infraestructuras seguras y automatizadas en la nube, y podemos ayudarte a integrar EKS con políticas corporativas de salida mediante proxies y Endpoint Services. Si buscas desarrollar soluciones personalizadas contamos con experiencia en software a medida y aplicaciones a medida y en arquitectura cloud. También ofrecemos migraciones y operaciones en servicios cloud en AWS y Azure, y servicios avanzados en inteligencia artificial, ciberseguridad, servicios inteligencia de negocio y automatización.
Palabras clave y capacidades que podemos aportar: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi. Nuestro enfoque combina infraestructura como código, prácticas de seguridad y despliegue automatizado para ofrecer plataformas Kubernetes seguras, repetibles y auditablemente configuradas.
En resumen, usar cloudinit_pre_nodeadm para inyectar la configuración del proxy asegura que el sistema operativo, containerd y nodeadm estén preparados antes de iniciar los servicios críticos. Esta aproximación reduce fallos de extracción de imágenes y problemas de comunicación con el control plane, ofreciendo una solución escalable y compatible con políticas empresariales de red. Si deseas una implementación a medida o una auditoría de tu arquitectura Kubernetes, en Q2BSTUDIO podemos acompañarte desde el diseño hasta la puesta en producción.
