Llevar AKS a producción: las decisiones difíciles de cambiar después

Un clúster de AKS tarda cuatro minutos en crearse y unos dos años en lamentarse. Casi todo el arrepentimiento viene de cuatro decisiones tomadas en el asistente de creación por alguien que necesitaba un clúster esa tarde, y las cuatro exigen recrear el clúster para cambiarlas.

1. Plugin de red: Azure CNI Overlay

La elección está entre kubenet (heredado), Azure CNI (una IP de VNet por pod) y Azure CNI Overlay (IP de pod desde un CIDR de superposición aparte, IP de nodo desde la VNet).

Azure CNI con IP de VNet por pod es el que provoca la caída. Una subred /22 te da unas mil direcciones, que parecen de sobra hasta que cuentas una IP por pod más la capacidad extra durante las actualizaciones, y entonces no puedes escalar. Redimensionar la subred de un clúster en marcha no es algo que se haga a la ligera.

Azure CNI Overlay es hoy el valor por defecto correcto: los pods reciben direcciones de un rango de superposición privado que no consume espacio de VNet, los nodos reciben IP de VNet y mantienes el soporte de políticas de red. Úsalo salvo que tengas un requisito concreto de que los pods sean directamente direccionables desde fuera del clúster.

Elige también el motor de políticas de red en la creación — Cilium es la opción más fuerte y se ofrece como Azure CNI con Cilium. Añadir políticas de red a un clúster que no las tenía significa auditar todos los flujos en producción.

2. Identidad: Workload Identity, y nada más

Las identidades gestionadas por pod están obsoletas. Usa Microsoft Entra Workload ID: una cuenta de servicio de Kubernetes se federa con una aplicación de Entra y los pods reciben tokens de vida corta sin ningún secreto en ningún sitio. Activa el emisor OIDC y workload identity en la creación del clúster — ambos son ajustes de nivel clúster.

Para la identidad del propio clúster, una identidad gestionada asignada por el usuario, no un principal de servicio con un secreto que tendrás que rotar.

Para los humanos, integración con Entra ID y Azure RBAC para la autorización de Kubernetes, de modo que el acceso por kubectl lo gobiernen los mismos grupos y la misma elevación de PIM que todo lo demás. Cuentas locales desactivadas. Si no, tienes un clúster con un kubeconfig de administrador estático circulando por una wiki.

3. Pools de nodos: al menos tres, con taints

Un pool de sistema para CoreDNS, metrics-server y el resto de componentes cercanos al plano de control, con taint CriticalAddonsOnly para que las cargas no caigan ahí. Después pools de usuario por clase de carga: general, optimizado en memoria, Spot.

Los pools Spot llevan un taint de desalojo por defecto, que es lo correcto — pon ahí cargas sin estado y replicadas con una toleración y mantén todo lo demás fuera. En un entorno con lotes o CI, Spot es el mayor descuento restante tras el redimensionado.

Autoescalador de clúster por pool y, más importante, requests fijadas a partir del uso observado, que es la misma lección que por qué tu clúster de EKS cuesta el doble y se aplica idéntica aquí. El aprovisionamiento automático de nodos (Karpenter para AKS) es la mejor respuesta donde esté disponible para tu configuración.

4. Actualizaciones: automáticas, con ventana de mantenimiento

Las versiones de AKS salen de soporte según un calendario, y un clúster tres versiones por detrás es un proyecto urgente en lugar de una rutina. Configura un canal de actualización automática (stable o patch), define una ventana de mantenimiento planificada, usa Pod Disruption Budgets para que el vaciado respete tus requisitos de disponibilidad y fija un max surge para que las actualizaciones no sean glaciales.

Prueba la actualización primero en un clúster de preproducción de la misma versión. El modo de fallo es casi siempre una API obsoleta en un chart de Helm, no la imagen de nodo.

Lo que muerde en el segundo mes

• La ingesta de Log Analytics desde Container Insights puede ser una de las tres líneas mayores de la factura. Configura la regla de recogida de datos para excluir namespaces que no necesitas y evita recoger el stdout de sidecars habladores a volumen completo.
• Clúster privado o no. Un servidor de API privado es la respuesta correcta en producción y significa que tu CI necesita un runner autoalojado en la VNet, o un rango de IP autorizado. Decide antes, no después.
• Ingress. Application Gateway for Containers o un controlador ingress-nginx con balanceador interno. Cualquiera vale; lo que no vale es que tres equipos instalen el suyo.
• El driver CSI de Key Vault para secretos, para que nada viva en un Secret de Kubernetes en etcd sin cifrar con tu propia clave.
• Defender for Containers, que es la capa de detección que entiende AKS y merece el coste por nodo en producción.

Las cuatro decisiones iniciales son operaciones de recreación de clúster, y por eso les dedicamos tiempo real al comienzo de un proyecto cloud en lugar de descubrirlas después.

Qué hacer esta semana

Comprueba el plugin de red de tu clúster y el tamaño de la subred de pods. az aks show te lo dice en un comando. Si estás en Azure CNI con IP de VNet por pod y menos de un /21, calcula cuántos pods puedes ejecutar antes de agotarla — ese número es tu techo real de escalado, y es mejor saberlo ahora que durante un incidente.