AZ-104
Deep Dive
Servicios de contenedores en Azure: ACI para contenedores simples, ACR para registros privados, AKS para orquestación con Kubernetes. El AZ-104 evalúa la diferencia entre servicios y la configuración básica de AKS.
Contenido
| Dimensión | Virtual Machine | Contenedor |
|---|---|---|
| Aislamiento | Kernel propio, hardware virtualizado | Comparte kernel del host — más ligero |
| Tamaño imagen | GB (incluye OS completo) | MB (solo app + dependencias) |
| Tiempo arranque | Minutos | Segundos o menos |
| Densidad | Decenas por host | Cientos o miles por host |
| Gestión OS | Tú gestionas (parches, config) | Sin SO que gestionar — solo la imagen |
| Portabilidad | Menos portable (driver/OS deps) | Altamente portable: "runs anywhere Docker runs" |
| Seguridad aislamiento | Mayor (kernel separado) | Menor (kernel compartido) — pero suficiente para la mayoría |
Servicios de contenedores en Azure — cuándo usar cada uno
ACI
Un contenedor simple, sin orquestación, rápido. Dev/test, jobs en batch.
ACR
Registro privado para almacenar y distribuir imágenes Docker. Siempre necesario si tienes imágenes propias.
AKS
Kubernetes gestionado para apps en producción que necesitan orquestación, HA, escalado.
Container Apps
PaaS serverless sobre Kubernetes. Sin gestionar clusters. Para microservicios y apps event-driven.
La forma más rápida de ejecutar un contenedor en Azure. Sin Kubernetes, sin clusters, sin infraestructura. Ideal para tareas simples y de corta duración.
Características clave
• Arranque en segundos — sin provision de VMs ni clusters
• Facturación por segundo: CPU y memoria consumidas mientras el contenedor está activo
• Soporta imágenes Linux y Windows
• Puede montarse en Azure Files para almacenamiento persistente
• Container Groups: múltiples contenedores en el mismo host con red y almacenamiento compartidos (similar a un Pod de Kubernetes)
• VNet Integration: desplegar contenedores dentro de una VNet (sin IP pública)
• Restart policy: Always, OnFailure, Never
Cuándo NO usar ACI
Usar ACI para:
CI/CD jobs, procesamiento de datos puntual, desarrollo y pruebas de imágenes, tareas batch programadas con Logic Apps o ADF.
Registro privado para imágenes de contenedores Docker y artefactos OCI. Integrado nativamente con AKS, ACI, App Service y Azure DevOps/GitHub Actions.
Basic
Dev/test. Sin geo-replication ni webhooks.
Standard
Producción general. Sin geo-replication.
Premium
Geo-replication, Private Link, Content Trust, tokens granulares.
Control de acceso a ACR
ACR Tasks — build en la nube
Permite hacer docker build directamente en Azure sin necesitar Docker local. Útil en CI/CD desde máquinas sin Docker daemon.
→ az acr build -t mi-imagen:v1 . — build + push en una sola operación
→ Tasks programadas: rebuild automático cuando el base image cambia
→ Multi-step tasks: build, test, push en un YAML pipeline
Kubernetes gestionado en Azure. Azure gestiona el control plane (API server, etcd, scheduler) sin costo. Tú pagas solo por los nodos worker (VMs) del cluster.
Arquitectura de AKS
Control Plane (gestionado por Azure)
Node Pools (tus VMs)
Tier del cluster AKS
Free
Control plane gratuito. SLA de uptime del API server: 99.5% (best effort). Para dev/test.
Standard
SLA financiero 99.9% del API server. Para producción.
Premium
SLA 99.95%. Long Term Support (LTS) de versiones de Kubernetes. Para apps críticas.
Versiones de Kubernetes en AKS
• AKS soporta N-2 versiones menores de Kubernetes (ej: 1.29, 1.28, 1.27)
• Auto-upgrade channels: none, patch, stable, rapid, node-image
• Actualización de versión es disruption-controlled (one node at a time)
• LTS (Premium): soporte extendido de versiones por 2 años
System vs User Node Pools
System Node Pool
Obligatorio. Corre componentes del sistema de Kubernetes (CoreDNS, tunnel-front, metrics-server). Mínimo 1 nodo. No puede eliminarse.
User Node Pool
Opcional. Para workloads de aplicación. Puede escalarse a cero (si las apps aguantan). Múltiples pools con distintas VM SKUs (ej: un pool GPU para ML).
Cluster Autoscaler
Escala automáticamente el número de nodos en un node pool. Añade nodos cuando hay Pods en estado Pending por falta de recursos. Elimina nodos cuando están infrautilizados.
• Configurable por node pool: min y max nodes
• Scale-down delay: tiempo que espera antes de eliminar un nodo (default 10 min)
• Trabaja junto con el Horizontal Pod Autoscaler (HPA)
• Cuando un nodo se elimina: los Pods se reubican en otros nodos
Escalado de Pods — HPA y KEDA
HPA (Horizontal Pod Autoscaler)
Escala el número de réplicas de un Deployment basado en métricas (CPU, memoria). Nativo de Kubernetes. Reacciona a demanda de recursos dentro del Pod.
KEDA (Kubernetes Event-Driven Autoscaler)
Escala Pods basado en eventos externos: longitud de cola (Service Bus, Storage Queue), HTTP requests, Prometheus metrics, etc. Puede escalar a 0 réplicas.
| Plugin CNI | IPs de Pods | Acceso a Pods desde VNet | Cuándo usar |
|---|---|---|---|
| Kubenet (básico) | IP privada NAT detrás del nodo | No directo (requiere kubectl port-forward o Service) | Clusters pequeños, conservar espacio de IPs en VNet |
| Azure CNI | IP de la subred VNet directamente en cada Pod | Sí — los Pods son ciudadanos de primera en la VNet | Producción, acceso directo a Pods desde on-prem o VNets |
| Azure CNI Overlay | IPs privadas en espacio overlay (no VNet) | Acceso a través de VNet gateway | Clusters grandes donde las IPs de VNet son limitadas |
| Cilium | Azure CNI con eBPF dataplane | Sí | Cuando necesitas Network Policy avanzada y observabilidad eBPF |
Service tipo ClusterIP
Solo accesible dentro del cluster. IP virtual interna. Para comunicación entre microservicios.
Service tipo LoadBalancer
Crea un Azure Load Balancer público (o interno) automáticamente. Expone la app al exterior. IP pública de Azure asignada.
Ingress Controller
Un solo LB público enruta a múltiples servicios por host/path. NGINX Ingress o Application Gateway Ingress Controller (AGIC). Más eficiente que múltiples LoadBalancers.
Identidad del cluster
System-assigned Managed Identity
El cluster tiene una identidad propia. Azure la gestiona. Se usa para que AKS cree recursos en Azure (LBs, discos, IPs).
Service Principal (legacy)
Antes del soporte de Managed Identity. Requiere gestionar y rotar credenciales manualmente. No recomendado para nuevos clusters.
Workload Identity
Las apps dentro del cluster pueden asumir una Managed Identity de Azure vía token OIDC. Permite que un Pod acceda a Key Vault, Storage, SQL, etc. sin credenciales.
RBAC en AKS — dos niveles
Azure RBAC (plano de control)
Controla quién puede acceder y gestionar el cluster desde Azure. Roles: AKS Cluster Admin, AKS Cluster User, etc. Gestiona con az aks get-credentials.
Kubernetes RBAC (plano de datos)
Controla qué recursos dentro del cluster puede hacer un usuario (Pods, Deployments, Services). ClusterRoles + ClusterRoleBindings. Integrable con Entra ID para gestionar via grupos.
PaaS serverless sobre Kubernetes. Sin gestionar clusters ni nodos. Escala a cero automáticamente. Ideal para microservicios y apps event-driven.
| Dimensión | ACI | Container Apps | AKS |
|---|---|---|---|
| Gestión cluster | Sin cluster | Sin cluster (abstraído) | Gestionas el cluster (node pools, upgrades) |
| Escala a 0 | Sí (no arranca hasta necesitar) | Sí nativo | Con KEDA (extra config) |
| HTTP ingress | Manual (LB externo) | Integrado con HTTPS y dominio | Ingress controller propio |
| Dapr integrado | No | Sí — sidecar nativo | Manual |
| Complejidad | Mínima | Baja | Alta (máximo control) |
| Para | Tareas simples/batch | Microservicios, APIs, workers | Apps complejas que necesitan Kubernetes completo |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo quiere ejecutar su imagen Docker en Azure. La app procesa archivos de una cola cada noche durante 20 minutos y luego no hace nada hasta el día siguiente. ¿Qué servicio es más apropiado?