Solución de problemas comunes en Azure Container Instances

En este artículo se muestra cómo solucionar problemas comunes para administrar o implementar contenedores en Azure Container Instances. Consulte también Preguntas más frecuentes.

Si necesita más soporte técnico, consulte las opciones de ayuda y soporte técnico disponibles en el portal de Azure.

Problemas durante la implementación del grupo de contenedores

Convenciones de nomenclatura

Al definir la especificación del contenedor, determinados parámetros requieren el cumplimiento de las restricciones de nomenclatura. En la tabla siguiente se muestran los requisitos específicos para las propiedades del grupo de contenedores. Para obtener más información, consulte Convenciones de nomenclatura en el Centro de arquitectura de Azure y las reglas y restricciones de nomenclatura para los recursos de Azure.

Ámbito Length Carcasa Caracteres válidos Patrón sugerido Ejemplo
Nombredel contenedor 1 1-63 Minúsculas Caracteres alfanuméricos, y guion en cualquier posición excepto como primer o último carácter <name>-<role>-container<number> web-batch-container1
Puertos de contenedor Entre 1 y 65535 Número entero Entero entre 1 y 65535 <port-number> 443
Etiqueta de nombre DNS 5-63 No distinguir mayúsculas de minúsculas Alfanumérico y guion en cualquier lugar excepto el primer o último carácter <name> frontend-site1
Variable del entorno 1-63 No distinguir mayúsculas de minúsculas Alfanumérico y subrayado (_) en cualquier lugar excepto el primer o último carácter <name> MY_VARIABLE
Nombre del volumen 5-63 Minúsculas Caracteres alfanuméricos y guiones en cualquier lugar excepto el primer o último carácter. No puede contener dos guiones consecutivos. <name> batch-output-volume

1La restricción también se aplica a los nombres de grupos de contenedores cuando no se especifican por separado de las instancias de contenedor, por ejemplo, con implementaciones mediante el comando az container create.

No se admite la versión del sistema operativo de la imagen

Si especifica una imagen que Azure Container Instances no admite, se devuelve un OsVersionNotSupported error. El error es similar al siguiente, donde {0} es el nombre de la imagen que intentó implementar:

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

Este error se encuentra con más frecuencia al implementar imágenes de Windows basadas en las versiones 1709 o 1803 del canal semianual (Semi-Annual Channel), que no son compatibles. Para obtener imágenes de Windows compatibles en Azure Container Instances, consulte Preguntas más frecuentes.

No se puede extraer la imagen

Si Azure Container Instances no puede descargar inicialmente su imagen, seguirá reintentándolo durante un tiempo. Si la operación de extracción de imágenes sigue produciendo un error, ACI finalmente produce un error en la implementación y es posible que vea un Failed to pull image error.

Para resolver este problema, elimine la instancia del contenedor y vuelva a intentar la implementación. Asegúrese de que la imagen existe en el Registro y ha escrito correctamente el nombre de la imagen.

Importante

ACI solo admite la extracción de imágenes de registros privados (registros sin una dirección IP pública) al usar Azure Container Registry (ACR) con un punto de conexión privado y una identidad administrada. No se admite la extracción de imágenes de registros privados que no son de ACR, incluso si la conectividad de red virtual está configurada entre ACI y el registro. Si necesita usar un registro privado, migre las imágenes a ACR y configure un punto de conexión privado con una identidad administrada. Para obtener más información, consulte Escenarios y recursos de red virtual: escenarios de red no admitidos.

Si no se puede extraer la imagen, los eventos como los siguientes se muestran en la salida de az container show:

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

Error de recurso no disponible

Debido a la variación de la carga de recursos regionales en Azure, es posible que reciba el siguiente error al intentar implementar una instancia de contenedor:

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

Este error indica que debido a una carga pesada en la región en la que se intenta implementar, los recursos especificados para el contenedor no se pueden asignar en ese momento. Use uno o varios de los pasos de mitigación siguientes para ayudar a resolver el problema.

  • Compruebe que la configuración de implementación del contenedor se encuentra dentro de los parámetros definidos en Disponibilidad de región para Azure Container Instances
  • Especificar la configuración de CPU y memoria inferiores para el contenedor
  • Implementación en una región de Azure diferente
  • Implementar más tarde

Problemas durante el tiempo de ejecución del grupo de contenedores

El contenedor tenía un reinicio aislado sin la entrada explícita del usuario

Hay dos categorías generales por las que un grupo de contenedores puede reiniciarse sin una entrada explícita del usuario. En primer lugar, los contenedores pueden experimentar reinicios causados por un bloqueo del proceso de aplicación. El servicio ACI recomienda aplicar soluciones de observabilidad, como el SDK de Application Insights, las métricas del grupo de contenedores y los registros de grupos de contenedores para determinar por qué la aplicación ha experimentado problemas. En segundo lugar, los clientes pueden experimentar reinicios iniciados por la infraestructura de ACI debido a eventos de mantenimiento. Para aumentar la disponibilidad de la aplicación, ejecute varios grupos de contenedores detrás de un componente de entrada, como Application Gateway o Traffic Manager.

El contenedor se detiene y se reinicia continuamente (sin proceso de larga duración)

Los grupos de contenedores tienen como valor predeterminado una directiva de reinicio de Always, por lo que los contenedores del grupo de contenedores siempre se reinician después de que se ejecuten hasta su finalización. Es posible que tenga que cambiar esto a OnFailure o Nunca si tiene previsto ejecutar contenedores basados en tareas. Si especifica OnFailure y sigue viendo reinicios continuos, puede haber un problema con la aplicación o el script ejecutado en el contenedor.

Nota

La Never directiva de reinicio solo impide los reinicios cuando un contenedor se cierra correctamente con el código de salida 0. Si un contenedor sale con un código de salida distinto de cero, es posible que la plataforma lo reinicie. Para obtener más información, consulte Comportamiento de reinicio con códigos de salida distintos de cero.

Al ejecutar grupos de contenedores sin procesos de larga duración, es posible que observe finalizaciones y reinicios repetidos con imágenes como Ubuntu o Alpine. La conexión a través de EXEC no funcionará porque el contenedor no tiene ningún proceso que lo mantenga activo. Para resolver este problema, incluya un comando start como el ejemplo siguiente con la implementación del grupo de contenedores para mantener el contenedor en ejecución.

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"

## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

La API de Container Instances y Azure portal incluyen una restartCount propiedad . Para comprobar el número de reinicios de un contenedor, puede usar el comando az container show en el CLI de Azure. En la siguiente salida de ejemplo, que truncamos por brevedad, puede ver la propiedad restartCount al final de la salida.

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

Nota

La mayoría de las imágenes de contenedor para distribuciones de Linux establecen un shell, como Bash, como el comando predeterminado. Dado que un shell por sí solo no es un servicio de larga duración, estos contenedores salen inmediatamente y entran en un bucle de reinicio cuando se configuran con la directiva de reinicio siempre predeterminada.

El contenedor tarda mucho tiempo en iniciarse

Los tres factores principales que contribuyen al tiempo de inicio del contenedor en Azure Container Instances son:

Las imágenes de Windows presentan consideraciones adicionales.

Tamaño de imagen

Si el contenedor tarda mucho tiempo en iniciarse, pero finalmente se inicia correctamente, empieza por revisar el tamaño de la imagen del contenedor. Dado que Azure Container Instances descarga la imagen del contenedor bajo demanda, el tiempo de inicio que observe está directamente relacionado con su tamaño.

Puede ver el tamaño de la imagen de contenedor mediante el docker images comando en la CLI de Docker:

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

La clave para mantener pequeños tamaños de imagen es asegurarse de que la imagen final no contenga nada que no sea necesario en tiempo de ejecución. Una manera de hacerlo es con compilaciones de varias fases. Las compilaciones de varias fases facilitan la seguridad de que la imagen final contiene solo los artefactos que necesita para la aplicación y no el contenido adicional que se requería en tiempo de compilación.

Ubicación de las imágenes

Otra manera de reducir el impacto de la extracción de imágenes en el tiempo de inicio del contenedor es hospedar la imagen de contenedor en Azure Container Registry en la misma región en la que pretende implementar instancias de contenedor. Esto acorta el trayecto de red que debe recorrer la imagen del contenedor, reduciendo significativamente el tiempo de descarga.

Imágenes almacenadas en caché

Azure Container Instances usa un mecanismo de almacenamiento en caché para ayudar a acelerar el tiempo de inicio del contenedor para las imágenes creadas en imágenes basadas en imágenes base de Windows comunes, como nanoserver:1809, servercore:ltsc2019y servercore:1809. Las imágenes de Linux usadas normalmente como ubuntu:1604 y alpine:3.6 también se almacenan en caché. Para las imágenes de Windows y Linux, evite usar la latest etiqueta . Consulte los procedimientos recomendados de etiquetas de imagen de Container Registry para obtener instrucciones. Para obtener una lista actualizada de imágenes y etiquetas almacenadas en caché, use la API List Cached Images.

Nota

El uso de imágenes basadas en Windows Server 2019 en Azure Container Instances está en versión preliminar.

Lentitud en la preparación de la red en contenedores de Windows

En la creación inicial, es posible que los contenedores de Windows no tengan conectividad entrante o saliente durante un máximo de 30 segundos (o más, en casos poco frecuentes). Si la aplicación contenedora necesita una conexión a Internet, agregue lógica de retraso y reintento para permitir que 30 segundos establezcan la conectividad a Internet. Después de la configuración inicial, las redes de contenedor deben reanudarse correctamente.

No se puede conectar a la API de Docker subyacente ni ejecutar contenedores con privilegios

Azure Container Instances no expone el acceso directo a la infraestructura subyacente que hospeda grupos de contenedores. Esto incluye el acceso al entorno de ejecución del contenedor, la tecnología de orquestación y la ejecución de operaciones de contenedor con privilegios. Para ver qué operaciones admite ACI, consulte la documentación de referencia de REST. Si falta algo, envíe una solicitud en los foros de comentarios de ACI.

Es posible que no se pueda acceder a la dirección IP del grupo de contenedores debido a que no coinciden los puertos

Azure Container Instances aún no admite la asignación de puertos, como con la configuración normal de Docker. Si observa que no se puede acceder a la dirección IP de un grupo de contenedores cuando considera que debería estarlo, asegúrese de configurar la imagen del contenedor para que escuche en los mismos puertos que expone en el grupo de contenedores con la propiedad ports.

Si desea confirmar que Azure Container Instances puede escuchar en el puerto que configuró en la imagen del contenedor, pruebe una implementación de la imagen aci-helloworld que expone ese puerto. Ejecute también la aplicación aci-helloworld para que escuche en ese puerto. aci-helloworld acepta una variable PORT de entorno opcional para invalidar el puerto predeterminado 80 en el que escucha. Por ejemplo, para probar el puerto 9000, establezca la variable de entorno al crear el grupo de contenedores:

  1. Configure el grupo de contenedores para exponer el puerto 9000 y pase el número de puerto como valor de la variable de entorno. El ejemplo está formateado para el shell Bash. Si prefiere otro shell, como PowerShell o Símbolo del sistema, deberá ajustar la asignación de variables en consecuencia.

    az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'

  2. Busque la dirección IP del grupo de contenedores en la salida del comando de az container create. Busque el valor de ip.

  3. Una vez que el contenedor se ha aprovisionado correctamente, vaya a la dirección IP y el puerto de la aplicación contenedora en el explorador, por ejemplo: 192.0.2.0:9000.

    Debería ver el mensaje "Bienvenido a Azure Container Instances!" que muestra la aplicación web.

  4. Cuando haya terminado con el contenedor, quítelo mediante el az container delete comando :

    az container delete --resource-group myResourceGroup --name mycontainer

Problemas durante las implementaciones de grupos de contenedores confidenciales

Errores de directiva al usar la directiva de CCE personalizada

Las directivas de CCE personalizadas deben generarse mediante la extensión confcom de CLI de Azure. Antes de generar la directiva, asegúrese de que todas las propiedades especificadas en la plantilla de ARM sean válidas y coincidan con lo que espera que se represente en una directiva de computación confidencial. Algunas propiedades que se van a validar incluyen la imagen de contenedor, las variables de entorno, los montajes de volumen y los comandos de contenedor.

Falta el hash de la directiva

La extensión CLI de Azure confcom usa imágenes almacenadas en caché en el equipo local que pueden no coincidir con las disponibles de forma remota, lo que puede dar lugar a un error de coincidencia de capas cuando se valida la directiva. Asegúrese de eliminar las imágenes antiguas y descargar las imágenes de contenedor más recientes a su entorno local. Una vez que te hayas asegurado de que tienes el SHA más reciente, debes regenerar la directiva de CCE.

Proceso o contenedor finalizado con código de salida: 139

Este código de salida se produce debido a limitaciones con la imagen base ubuntu versión 22.04. La recomendación es usar una imagen base diferente para resolver este problema.

Códigos de salida del contenedor

Cuando finaliza un contenedor en Azure Container Instances, la plataforma notifica un código de salida que indica por qué se detuvo el proceso. Puede ver los códigos de salida comprobando los eventos de contenedor mediante el comando az container show o en el portal de Azure en Eventos de contenedores>.

En la tabla siguiente se describen los códigos de salida comunes que podría encontrar:

Código de salida Description
0 El proceso se completó correctamente. No se produjo ningún error.
1 El proceso finalizó debido a un error general de aplicación. Compruebe los registros de la aplicación para obtener más detalles.
137 El proceso fue cancelado forzosamente (SIGKILL). Esta condición suele producirse cuando el contenedor supera su límite de memoria. Considere la posibilidad de aumentar la asignación de memoria para el contenedor.
139 El proceso encontró un error de segmentación (SIGSEGV). Este error puede deberse a limitaciones de imagen base, como Ubuntu 22.04. Pruebe a usar una imagen base diferente.
7147 La plataforma apaga correctamente el contenedor mediante el envío de una señal de terminación. Este código se corresponde con los mensajes "Cierre del contenedor iniciado por la plataforma" en los eventos del contenedor.
7148 La plataforma detuvo el contenedor por la fuerza. Esta condición normalmente significa que el contenedor no respondió de forma oportuna después de recibir la señal de terminación inicial. Este código también se correlaciona con los mensajes "Killing container (iniciado por la plataforma)" en los eventos de contenedor.

Finalizaciones iniciadas por la plataforma (códigos de salida 7147 y 7148)

Los códigos de salida 7147 y 7148 son códigos de salida de la plataforma que proceden de la infraestructura subyacente. Es posible que no siempre veas estos códigos directamente en los detalles del contenedor, pero se corresponden con los mensajes «Killing container (iniciado por la plataforma)» que aparecen en los eventos del contenedor. Entre las causas comunes de las finalizaciones iniciadas por la plataforma se incluyen las siguientes:

  • Mantenimiento de la infraestructura: la plataforma ha reubicado el contenedor como parte del mantenimiento rutinario o el equilibrio de carga.
  • Restricciones de recursos: el host subyacente necesitó recuperar recursos.
  • Actualizaciones de la plataforma: La infraestructura se actualizó, lo que requirió reiniciar los contenedores.

Estas finalizaciones se esperan en un entorno de nube. Para aumentar la disponibilidad de la aplicación, ejecute varios grupos de contenedores detrás de un componente de entrada, como Application Gateway o Traffic Manager.

Para obtener más información sobre las finalizaciones iniciadas por la plataforma, consulte Diagnóstico de errores comunes de paquetes de código mediante Service Fabric.

Pasos siguientes

Obtenga información sobre cómo recuperar registros y eventos de contenedor para ayudar a depurar los contenedores.

  • Last updated on