Container Apps resolvió el motor de disponibilidad con muy poco esfuerzo, y esa es la mejor noticia de la lección anterior. Pero en Contoso Airlines hay un frente distinto: la plataforma de operaciones de vuelo, doce microservicios que coordinan asignación de puertas, rotación de tripulaciones, carga de combustible y retrasos, escritos por tres equipos, con un componente que exige nodos con mucha memoria y otro que necesita afinidad entre pods. Ese sistema pide control fino de la programación, políticas de red entre servicios y operadores de terceros. Ahí sí, Kubernetes.

Esta lección enseña Azure Kubernetes Service con honestidad: qué te da, qué sigue siendo trabajo tuyo, cuánto cuesta de verdad y en qué casos adoptarlo es sobreingeniería. Contoso lo adopta para operaciones de vuelo, no para toda la plataforma, y esa decisión es la primera lección.

1. Cuándo Kubernetes está justificado y cuándo no
2. Conceptos de Kubernetes, lo imprescindible
3. Qué gestiona AKS y qué sigue siendo tuyo
4. Crear aks-contoso-operaciones y elegir el modelo de red
5. Identidad: Entra ID, RBAC e identidad de carga de trabajo
6. Desplegar la aplicación con manifiestos y kubectl
7. Entrada gestionada y certificados
8. Escalado, solicitudes y límites
9. Actualizaciones, interrupciones y mantenimiento
10. Almacenamiento persistente, observabilidad, Helm y coste realista
11. Errores Comunes y Consejos
12. Ejercicios
13. Conclusión

El coste oculto de Kubernetes no es la factura de los nodos, es el tiempo del equipo: actualizaciones trimestrales, versiones de API que se retiran, depuración de la red, gestión de certificados. Si nadie va a dedicar tiempo a eso, un clúster envejece hasta convertirse en un riesgo. Contoso lo asume solo donde el retorno lo compensa.

• Plano de control: el cerebro. El servidor de API recibe todas las órdenes, etcd guarda el estado deseado, el programador decide en qué nodo cabe cada pod y los controladores corrigen sin parar la diferencia entre lo que hay y lo que debería haber. Ese bucle de reconciliación es la idea central de Kubernetes: tú declaras el destino, el sistema se encarga del camino.
• Nodo: una máquina virtual que ejecuta pods, agrupada con otras en grupos de nodos. Y pod: la unidad mínima programable, uno o más contenedores que comparten red y almacenamiento. Es efímero: si muere, no revive; nace otro con otra dirección IP.
• Despliegue y conjunto de réplicas: el despliegue declara «quiero N réplicas de este pod con esta imagen»; el conjunto de réplicas mantiene la cuenta y orquesta las actualizaciones progresivas.
• Servicio e ingreso: el servicio da IP y nombre DNS estables por delante de un conjunto cambiante de pods —resuelve que los pods no tengan dirección fija—; el ingreso enruta el tráfico HTTP de entrada por nombre de host y ruta, con TLS, en un solo punto de entrada para muchos servicios.
• Espacio de nombres: partición lógica del clúster con cuotas y permisos propios; Contoso usa operaciones-vuelo, integracion y monitorizacion. Y mapa de configuración y secreto: configuración y datos sensibles inyectados como variables de entorno o ficheros. Ojo: un secreto de Kubernetes solo va codificado en base64, no cifrado, por eso Contoso los saca de kv-contoso-pro.

Dilo claro, porque genera muchas facturas sorpresa: el plano de control de AKS es gratuito en el nivel Free; lo que se paga son los nodos, que son máquinas virtuales normales con su precio de cómputo y sus discos. Un clúster «vacío» con tres nodos cuesta lo mismo que tres máquinas virtuales encendidas. El nivel Standard añade un SLA con coste por hora de clúster, y es lo que corresponde en producción.

Y a continuación el grupo de nodos de usuario, porque mezclar cargas de sistema y de aplicación en el mismo grupo es un error clásico:

Las decisiones que hay detrás:

• --nodepool-name sistema con --mode System (implícito en create): aloja CoreDNS, metrics-server y los complementos. Si una carga de aplicación desbocada consume su memoria, se cae el DNS del clúster entero. Sepáralos.
• --zones 1 2 3 reparte los nodos entre zonas de disponibilidad —sin esto, un incidente de zona se lleva el clúster— y --enable-cluster-autoscaler añade y quita nodos según los pods que no caben, que es distinto del escalado de pods (apartado 8).
• --attach-acr acrcontosopro asigna por ti el rol AcrPull a la identidad de tipo kubelet del clúster; sin ella, los pods fallan con ImagePullBackOff y el error es opaco. Y --enable-workload-identity más --enable-oidc-issuer es la base del apartado 5.

El fallo de diseño más caro en AKS es elegir Azure CNI sin echar cuentas: cada nodo reserva por adelantado tantas IP como pods máximos admita (30 por defecto), así que 20 nodos consumen 600 direcciones y una /24 se agota antes de empezar. Contoso usa CNI Overlay sobre snet-app (10.20.2.0/24): los nodos toman IP de la subred, los pods de un espacio superpuesto, y la subred aguanta el crecimiento. Se añade política de red (Cilium) para poder prohibir explícitamente que un pod hable con otro; sin ella, dentro del clúster todo habla con todo.

Con --enable-aad --enable-azure-rbac, quién entra al clúster lo decide Microsoft Entra ID y qué puede hacer lo decide RBAC de Azure, con los mismos grupos del módulo 4:

La identidad de carga de trabajo es la pieza que elimina los secretos dentro del clúster. Una cuenta de servicio de Kubernetes se federa con id-contoso-api-pro: el pod recibe un token firmado por el emisor OIDC del clúster, lo cambia por un token de Entra ID y accede a kv-contoso-pro y a db-reservas con DefaultAzureCredential, el mismo código de 04-02, sin ninguna clave.

Antes del despliegue hace falta la cuenta de servicio sa-operaciones en el espacio de nombres operaciones-vuelo, anotada con azure.workload.identity/client-id apuntando al identificador de cliente de id-contoso-api-pro. Es la contraparte en el clúster de la credencial federada anterior.

Campo a campo, lo que no es evidente:

• selector.matchLabels del despliegue y labels de la plantilla deben coincidir: es la unión entre el despliegue y sus pods, y desalinearlos deja el despliegue sin réplicas. serviceAccountName más la etiqueta azure.workload.identity/use son lo que activa la federación del apartado 5.
• La imagen lleva la etiqueta 4821, el identificador de compilación del pipeline (05-03), nunca latest.
• readinessProbe frente a livenessProbe: la primera controla si el pod entra en el balanceo; la segunda si se reinicia. Confundirlas produce reinicios en cascada bajo carga. Y topologySpreadConstraints obliga a repartir las tres réplicas entre las tres zonas: sin esto, el programador puede colocarlas las tres en el mismo nodo.
• type: ClusterIP: el servicio no se publica solo. Usar LoadBalancer por servicio crea una IP pública por cada uno y multiplica coste y superficie expuesta.

kubectl esencial: kubectl apply -f manifiestos/ aplica; kubectl get pods -n operaciones-vuelo -o wide lista con nodo y IP; kubectl describe pod <nombre> da los eventos, que es donde está siempre la causa del fallo; kubectl logs -f <pod> sigue los registros; kubectl rollout status deploy/panel-operaciones espera al despliegue y kubectl rollout undo lo revierte; kubectl top pods muestra el consumo real, imprescindible para ajustar el apartado 8.

Instalar y mantener a mano un controlador de entrada es trabajo recurrente. El complemento de enrutamiento de aplicaciones despliega un NGINX gestionado y lo integra con DNS y Key Vault:

Con eso, el certificado de operaciones.contosoairlines.example vive en kv-contoso-pro, se sincroniza como secreto de Kubernetes y se renueva sin intervención. El certificado nunca se copia a un repositorio ni a un manifiesto.

Tres escaladores que se confunden constantemente:

Los dos primeros escaladores trabajan en cadena: el HPA pide más réplicas, no caben, quedan pendientes y el escalador de clúster arranca nodos. Y aquí está el punto clave de toda la lección: el HPA calcula el porcentaje de uso sobre la solicitud (requests), y el programador decide dónde cabe un pod mirando su solicitud. Sin requests no hay porcentaje que calcular ni información para programar.

Las solicitudes y los límites son la causa número uno de clústeres inestables. Sin requests, el programador cree que el pod no consume nada y amontona pods en un nodo hasta agotarlo. Sin limits de memoria, una fuga en un pod consume la memoria del nodo y el núcleo empieza a matar procesos: caen pods sanos ajenos al problema. Con limits de CPU demasiado bajos, el pod sufre limitación y la latencia se dispara sin que la CPU parezca alta.

La regla práctica: fija requests en el consumo del percentil 50 medido con kubectl top, y limits en torno al doble. Refuérzalo con ResourceQuota y LimitRange en el espacio de nombres para que ningún manifiesto sin límites llegue a aplicarse.

Kubernetes publica versiones a buen ritmo y AKS solo da soporte a unas pocas. Actualizar no es opcional; es una tarea de calendario.

Actualiza siempre el plano de control primero y los grupos de nodos después, uno a uno, y de una versión menor a la siguiente, sin saltos. Los nodos se sustituyen mediante acordonado y vaciado, y ahí entra el presupuesto de interrupción de pods, que impide que el vaciado deje un servicio por debajo de un mínimo:

Sin él, un vaciado puede llevarse las tres réplicas a la vez y el panel de operaciones desaparece durante la actualización. Complétalo con una ventana de mantenimiento planificado (az aks maintenanceconfiguration add) para que las actualizaciones automáticas del sistema operativo del nodo no caigan en hora punta de facturación.

El disco de un pod es efímero. Para persistir, se declara una reclamación de volumen persistente contra una clase de almacenamiento:

La distinción decisiva es el modo de acceso: un disco de Azure lo monta un solo nodo, así que no sirve para tres réplicas repartidas por zonas; para eso hace falta Azure Files. Y por defecto la política de reclamación es Delete: al borrar la reclamación desaparece el disco y los datos. En producción, Retain.

La observabilidad se resuelve con Container Insights, ya habilitado en el az aks create contra log-contoso-pro: métricas de nodos y pods, registros de contenedor y del plano de control consultables con KQL. Cómo explotarlos es el módulo 7 (07-01 y 07-02); aquí basta con dejarlo activado desde el principio, porque nadie lo activa a tiempo cuando el clúster ya falla.

Helm es el gestor de paquetes de Kubernetes: empaqueta un conjunto de manifiestos en un chart con valores parametrizados, de modo que desplegar en desarrollo y en produccion sea el mismo chart con otro fichero de valores; es a los manifiestos lo que los módulos de Bicep a las plantillas (05-06). GitOps con Flux es la evolución natural: en lugar de que el pipeline empuje con kubectl apply, un agente dentro del clúster vigila el repositorio contoso-infra y reconcilia el clúster hacia lo que dice Git; el repositorio pasa a ser la única fuente de verdad y la desviación de configuración se corrige sola. AKS lo ofrece como extensión gestionada.

Coste realista. Un clúster de producción como el de Contoso, con 3 nodos Standard_D4s_v5 de sistema y 2 a 12 nodos Standard_D8s_v5 de aplicación, más el nivel Standard, discos, balanceador e ingesta de registros, se sitúa en el orden de varios miles de euros al mes, y la ingesta de Log Analytics sorprende más de lo que nadie espera. Cómo reducirlo:

• Instancias de acceso puntual (az aks nodepool add --priority Spot --eviction-policy Delete --spot-max-price -1) en un grupo dedicado para cargas tolerantes a interrupciones —lotes, pruebas—: hasta un 80-90 % menos, a cambio de un desalojo con dos minutos de aviso.
• Escalar a cero los grupos de usuario con --min-count 0, y parar el clúster de desarrollo con az aks stop / az aks start: un clúster parado no factura nodos. Automatízalo por la noche y el fin de semana con Azure Automation (07-04).
• Ajustar requests a lo que se consume de verdad: las solicitudes infladas obligan al escalador a arrancar nodos medio vacíos. Es el ahorro menos visible y a menudo el mayor.

• Adoptar AKS sin necesidad: si el caso lo cubre Container Apps, AKS solo añade factura y trabajo. Y desplegar sin requests ni limits, causa número uno de clústeres inestables; impónlo con LimitRange.
• Elegir Azure CNI sin calcular las IP. La subred se agota y ampliarla obliga a rehacer el clúster. Usa CNI Overlay.
• Mezclar cargas de aplicación con el grupo de sistema. Un pod desbocado tira CoreDNS y con él el clúster.
• Guardar secretos como Secret de Kubernetes (solo base64) o poner un Service de tipo LoadBalancer por microservicio (doce IP públicas). Identidad de carga de trabajo contra kv-contoso-pro, y un solo ingreso con enrutamiento por host.
• Dejar el clúster sin actualizar: las versiones salen de soporte y la actualización acumulada se vuelve arriesgada. Calendario trimestral.
• Consejo: kubectl describe pod antes que cualquier otra cosa. El 90 % de los fallos (ImagePullBackOff, CrashLoopBackOff, Pending por falta de recursos) se explican en su sección de eventos. Y aplica políticas de red desde el principio: retrofitarlas en un clúster en producción es doloroso.

Ejercicio 1. Un microservicio de operaciones se queda en estado Pending y el escalador de clúster no arranca nodos. Su manifiesto pide requests: { cpu: "8000m", memory: "32Gi" } y el grupo aplicaciones usa Standard_D8s_v5 (8 vCPU, 32 GiB).

1. Explica por qué el pod nunca se programará y por qué el escalador de clúster no lo arregla añadiendo nodos.
2. Da dos soluciones distintas y di cuál elegirías.

Ejercicio 2. Diseña el clúster de la plataforma «Contoso Millas»: seis microservicios, tráfico de día y casi nulo de noche, más un proceso nocturno de recálculo de puntos que tolera interrupciones.

1. Define los grupos de nodos con su modo, tamaño, zonas y límites del escalador.
2. Justifica el uso de instancias de acceso puntual y sus riesgos, indica las etiquetas obligatorias del proyecto secundario y dos medidas de ahorro adicionales.

Ejercicio 3. Un pod debe leer un secreto de kv-contoso-pro y consultar db-reservas.

1. Enumera los pasos para conseguirlo sin ninguna credencial en el clúster, y explica qué relación hay entre el emisor OIDC, la cuenta de servicio y id-contoso-api-pro.
2. ¿Por qué es mejor que montar un Secret de Kubernetes con la cadena de conexión?

Solución 1:

1. Porque la solicitud consume todo el nodo, y el sistema operativo, el kubelet y los complementos del sistema ya reservan una parte: la capacidad asignable de un Standard_D8s_v5 es inferior a 8 vCPU y 32 GiB, así que ningún nodo de ese tamaño tiene hueco. El escalador solo arranca nodos si el pod cabría en un nodo nuevo del grupo; como no cabe, concluye que añadir nodos es inútil y no hace nada. Es correcto, aunque el silencio despiste.
2. (a) Reducir la solicitud a lo que consume de verdad, medido con kubectl top —por ejemplo 4 vCPU y 16 GiB—. (b) Crear un grupo de nodos con máquinas mayores, del tipo Standard_E16s_v5, y dirigir el pod con nodeSelector. Elegiría (a) primero, porque casi siempre la solicitud está inflada «por si acaso»; (b) solo si la medición confirma que la carga necesita de verdad ese tamaño.

Solución 2:

1. Grupo sistema en modo System, 2 nodos Standard_D2s_v5, zonas 1-2-3, escalador de 2 a 3. Grupo aplicaciones en modo User, Standard_D4s_v5, zonas 1-2-3, escalador de 2 a 8 durante el día. Grupo lotes en modo User con --priority Spot, Standard_D8s_v5, escalador de 0 a 6, con su contaminación correspondiente para que solo el proceso nocturno se programe ahí.
2. El recálculo de puntos es idempotente, reanudable y no tiene usuario esperando: si Azure desaloja un nodo con dos minutos de aviso, el trabajo se reprograma y solo se pierde tiempo, a cambio de un ahorro enorme. El riesgo real es usar instancias puntuales para servicios en línea, donde el desalojo se traduce en errores para el usuario; por eso el grupo está separado y contaminado. Etiquetas: entorno, proyecto=contoso-millas, centro-coste=CC-2077 y propietario. Ahorro adicional: escalar a cero el grupo lotes fuera de la ventana nocturna y parar el clúster de desarrollo con az aks stop desde un runbook por la noche y el fin de semana.

Solución 3:

1. (a) Crear el clúster con --enable-oidc-issuer --enable-workload-identity. (b) Crear la cuenta de servicio sa-operaciones en operaciones-vuelo anotada con el identificador de cliente de id-contoso-api-pro. (c) Crear la credencial federada con az identity federated-credential create y el sujeto system:serviceaccount:operaciones-vuelo:sa-operaciones. (d) Dar a id-contoso-api-pro el rol Usuario de secretos de Key Vault sobre kv-contoso-pro y crear el usuario externo en db-reservas. (e) En el pod, serviceAccountName y la etiqueta azure.workload.identity/use: "true", y en el código DefaultAzureCredential. En cuanto a la relación: el emisor OIDC del clúster firma el token de la cuenta de servicio y la credencial federada declara ante Entra ID que ese emisor y ese sujeto concretos pueden obtener tokens de id-contoso-api-pro; la confianza es criptográfica, no una contraseña compartida.
2. Porque un Secret de Kubernetes está codificado en base64, no cifrado: quien pueda leerlo en el espacio de nombres, o quien acceda a una copia de seguridad de etcd, lo lee en claro. Además hay que rotarlo a mano en todos los clústeres. Con identidad de carga de trabajo no existe el secreto: hay tokens de vida corta emitidos y revocables desde Entra ID, con trazabilidad en los registros de inicio de sesión.

Kubernetes deja de ser una palabra y pasa a ser una herramienta con criterio de uso. Sabes cuándo está justificado y cuándo es sobreingeniería, y has visto a Contoso adoptarlo solo para la plataforma de operaciones de vuelo mientras el motor de disponibilidad se queda tranquilamente en Container Apps. Manejas los conceptos imprescindibles —plano de control y nodos, pod, despliegue, réplica, servicio, ingreso, espacio de nombres, mapa de configuración y secreto— y entiendes el bucle de reconciliación que los sostiene. Tienes clara la frontera de responsabilidades: el plano de control es gratuito, los nodos se pagan, y las actualizaciones, los límites y las políticas siguen siendo tuyos.

Has creado aks-contoso-operaciones con grupos de sistema y de usuario separados, zonas de disponibilidad, escalador automático, CNI Overlay para no agotar la subred, política de red, integración con Entra ID y RBAC de Azure por espacio de nombres, extracción de imágenes desde acrcontosopro con --attach-acr, e identidad de carga de trabajo que da a los pods acceso a kv-contoso-pro y db-reservas sin un solo secreto. Has desplegado con manifiestos explicados campo a campo, publicado con el complemento de enrutamiento y certificados de Key Vault, y sabes usar kubectl para diagnosticar. Dominas los tres escaladores y, sobre todo, por qué la ausencia de requests y limits es la causa número uno de clústeres inestables. Sabes actualizar en el orden correcto protegiendo la disponibilidad con presupuestos de interrupción y ventanas de mantenimiento, persistir con discos frente a Azure Files según el modo de acceso, y dejar Container Insights encendido desde el minuto uno. Y conoces el camino de madurez —Helm, GitOps con Flux— y el coste real con sus palancas: instancias de acceso puntual, grupos que escalan a cero, parar el clúster de desarrollo y ajustar las solicitudes.

Contoso tiene ahora dos formas de ejecutar código propio y una duda razonable: para muchas tareas, mantener algo ejecutándose es absurdo. Generar el PDF de una tarjeta de embarque ocupa dos segundos y ocurre cuando se confirma una reserva; sincronizar el catálogo de tarifas ocurre cuando cambia un documento en cosmos-contoso-tarifas-pro. Para eso no quieres un contenedor esperando ni un pod encendido, quieres que el código se ejecute cuando pasa algo y no exista el resto del tiempo. Esa es la computación sin servidor, y la siguiente lección, Azure Functions, la lleva al detalle: desencadenadores y enlaces, planes de hospedaje, las dos funciones reales de Contoso, Durable Functions para orquestar el check-in y la lección dura que nadie se salta, la idempotencia.