Azure Container Instances

Azure Container Instances (ACI) es la forma más rápida de ejecutar una carga de trabajo en contenedores en Azure sin administrar servidores ni orquestadores. Usted proporciona una imagen de contenedor y Azure la ejecuta en segundos sobre una infraestructura compartida y multiinquilino. ACI es ideal para tareas de corta duración, trabajos por lotes, agentes de compilación y cargas de trabajo controladas por eventos en las que poner en marcha un clúster completo de Kubernetes supondría una sobrecarga innecesaria.

Inicie un contenedor de ACI con un único comando az container create. Especifique la imagen, el grupo de recursos, la CPU y la memoria. ACI extrae la imagen, asigna los recursos e inicia el contenedor, normalmente en un plazo de 5 a 10 segundos. Cada instancia de contenedor obtiene un nombre de dominio completo (FQDN) único si asigna una etiqueta de nombre DNS, lo que permite acceder a ella inmediatamente desde Internet.

Pase la configuración a los contenedores de ACI mediante variables de entorno especificadas durante la creación. Para valores confidenciales, como claves de API o contraseñas, use variables de entorno seguras: no se muestran en Azure Portal ni en la salida de la CLI después de la implementación, lo que evita su exposición accidental en registros o pistas de auditoría. Los valores seguros siguen siendo accesibles dentro del contenedor durante el tiempo de ejecución como variables de entorno normales.

ACI factura por segundo en función de los núcleos de CPU y los GB de memoria que asigne, sin un periodo mínimo de facturación. Solo paga mientras el contenedor está en ejecución; en cuanto se detiene, también se detiene la facturación. Esto hace que ACI sea extremadamente rentable para cargas de trabajo de corta duración. Puede asignar entre 0,1 y 4 núcleos de CPU y entre 0,1 y 16 GB de memoria por grupo de contenedores, en las combinaciones admitidas.

ACI admite tres políticas de reinicio que controlan el comportamiento del contenedor después de salir. Always (valor predeterminado) reinicia el contenedor cada vez que sale, por lo que es adecuado para servicios de larga duración. Never ejecuta el contenedor una vez y lo deja en estado terminado, por lo que es ideal para trabajos por lotes. OnFailure solo reinicia el contenedor cuando sale con un código de salida distinto de cero, lo que resulta útil para patrones de reintento tras errores.

Un grupo de contenedores es una colección de contenedores que comparten ciclo de vida, red y almacenamiento, de forma similar a un pod de Kubernetes. Los contenedores del mismo grupo comparten una dirección IP local y el espacio de nombres de puertos, lo que les permite comunicarse mediante localhost. Un patrón habitual consiste en un contenedor de aplicación principal y un contenedor sidecar (por ejemplo, un agente de registro o un proxy) en el mismo grupo, definido mediante una plantilla YAML o ARM.

De forma predeterminada, los contenedores de ACI no tienen estado: los datos escritos en el sistema de archivos del contenedor se pierden cuando este se reinicia. Monte un recurso compartido de Azure Files como volumen para conservar los datos entre reinicios del contenedor o compartirlos entre contenedores del mismo grupo. Especifique el nombre y la clave de la cuenta de almacenamiento, así como el nombre del recurso compartido de archivos, al crear la instancia de contenedor.

ACI admite instancias de contenedor con GPU (K80, V100) para cargas de trabajo de inferencia de ML, procesamiento de vídeo y cálculo científico. Las instancias con GPU están disponibles en regiones seleccionadas y requieren contenedores Linux. Se facturan por GPU/segundo, por lo que resultan económicas para escenarios de inferencia en ráfagas en los que se inicia un contenedor con GPU, se ejecuta el modelo y se elimina inmediatamente, a un coste mucho menor que el de una máquina virtual con GPU dedicada en ejecución permanente.

Implemente grupos de contenedores de ACI en una subred dedicada dentro de una VNet para asignarles direcciones IP privadas y permitirles acceder a otros recursos conectados a la VNet (bases de datos y máquinas virtuales) sin exponerlos a Internet. ACI integrado con VNet requiere una subred dedicada y delegada (delegada en Microsoft.ContainerInstance/containerGroups) y no admite la asignación de IP públicas.

ACI se integra con AKS como un nodo virtual mediante el proyecto de código abierto Virtual Kubelet. Cuando un clúster de AKS experimenta una demanda en ráfaga que supera la capacidad de sus nodos de máquinas virtuales, Kubernetes puede programar pods en un nodo virtual de ACI, poniendo en marcha instancias de contenedor de ACI reales. Esto proporciona un escalado ilimitado en ráfagas sin aprovisionar previamente nodos de máquinas virtuales adicionales, y solo paga por el cómputo de ACI durante el periodo de la ráfaga.

Elija ACI para tareas de corta duración, trabajos por lotes, agentes de compilación de CI y contenedores puntuales en los que la sobrecarga de Kubernetes no sea necesaria. Elija AKS para microservicios de varios contenedores y larga duración que requieran detección de servicios, comprobaciones de estado, actualizaciones graduales y redes de clúster. Elija App Service cuando desee las ventajas de PaaS (ranuras de implementación, certificados administrados y autenticación integrada) sin administrar directamente las redes de contenedores.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que Azure Container Instances ejecuta contenedores en segundos sin administrar servidores y factura por segundo de CPU y memoria; los grupos de contenedores permiten que varios contenedores compartan la red y el almacenamiento como un pod de Kubernetes; y las políticas de reinicio (Always, Never, OnFailure) controlan el ciclo de vida del contenedor después de su salida. A continuación exploraremos los conceptos de Kubernetes para Azure.