Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe la compatibilidad con la confiabilidad en Azure Container Instances, que proporciona una manera sencilla de ejecutar contenedores de Linux o Windows en Azure, sin necesidad de administrar máquinas virtuales (VM) o adoptar un servicio de nivel superior más complejo.
Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.
En este artículo se describe cómo hacer que Azure Container Instances sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. Resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Container Instances.
Recomendaciones de implementación de producción para la confiabilidad
Para aumentar la confiabilidad de las aplicaciones de producción basadas en Container Instances, se recomienda realizar las siguientes acciones:
- Ejecute las aplicaciones en varias zonas de disponibilidad.
- Considere si también se deben ejecutar grupos de contenedores independientes en varias regiones.
- Use sondeos de actividad para detectar y automáticamente reiniciar contenedores no saludables.
- Utilice sondeos de preparación para esperar hasta que los contenedores estén listos antes de recibir tráfico.
- Use actualizaciones graduales para aplicar cambios progresivamente si usa NGroups. Este enfoque reduce la probabilidad de tiempo de inactividad debido a las actualizaciones.
- Revise los procedimientos recomendados y las consideraciones para Container Instances.
Introducción a la arquitectura de confiabilidad
Para usar Container Instances, implemente un grupo de contenedores. Un grupo de contenedores contiene uno o varios contenedores. Cada contenedor se crea a partir de una imagen de contenedor, que se almacena en un registro como Azure Container Registry.
Todos los contenedores de un grupo de contenedores se implementan juntos como una sola unidad lógica y comparten la misma infraestructura física.
En el diagrama siguiente se muestra la relación entre grupos de contenedores, contenedores e imágenes.
La imagen muestra dos contenedores dentro de una sección de grupo de contenedores. Dos líneas de puntos conectan los contenedores a dos secciones de imagen en la sección de registro.
Container Instances proporciona las siguientes características para administrar grupos de contenedores:
NGroups (versión preliminar) proporciona un conjunto de funcionalidades para administrar varios grupos de contenedores relacionados. Al crear un NGroup, se define el número de grupos de contenedores para crear. Container Instances proporciona funcionalidades como implementaciones automatizadas de actualización y distribución de grupos de contenedores entre zonas de disponibilidad.
Los grupos en espera crean un grupo de grupos de contenedores aprovisionados previamente que se pueden usar en respuesta al tráfico entrante. Los grupos en espera están concebidos para optimizar la creación de grupos de contenedores y no para aumentar la resiliencia.
Resistencia a errores transitorios
Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.
Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.
Los SDK proporcionados por Microsoft suelen controlar errores transitorios. Dado que hospeda sus propias aplicaciones en Container Instances, siga los pasos necesarios para reducir la posibilidad de errores transitorios:
Ejecute varios grupos de contenedores para cargas de trabajo importantes para asegurarse de que un error en un contenedor o grupo de contenedores no afecte a toda la aplicación.
Construye el código de tu aplicación para que sea resistente a errores transitorios en los servicios a los que te conectas, por ejemplo, utilizando políticas de reintentos con estrategias de espera incremental.
Para obtener más información sobre otros errores que pueden producirse en tiempo de ejecución y cómo responder a ellos, consulte Problemas durante el tiempo de ejecución del grupo de contenedores.
Resistencia a errores de zona de disponibilidad
Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.
Container Instances admite zonas de disponibilidad de diferentes maneras, en función de cómo implemente los grupos de contenedores:
Grupos de contenedores creados manualmente: Un grupo de contenedores individual es un recurso zonal , lo que significa que se puede implementar en una sola zona de disponibilidad que seleccione. Todos los contenedores del grupo se despliegan en la misma zona de disponibilidad. Si esa zona de disponibilidad tiene una interrupción, el grupo de contenedores y todos sus contenedores podrían experimentar tiempo de inactividad.
En el diagrama siguiente se muestra un grupo de contenedores que se ha implementado manualmente en la zona de disponibilidad 1:
La imagen muestra tres zonas de disponibilidad: Zona de disponibilidad 1, Zona de disponibilidad 2 y Zona de disponibilidad 3. Un grupo de contenedores de la zona de disponibilidad 1 incluye dos contenedores.
Nota:
Para asegurarse de que la aplicación sigue ejecutándose cuando cualquier zona única de la región experimenta una interrupción, se recomienda crear un mínimo de dos grupos de contenedores en dos zonas de disponibilidad diferentes.
Si no especifica zonas de disponibilidad que se van a usar para el grupo de contenedores, es no zonal o regional, lo que significa que podría colocarse en cualquier zona de disponibilidad dentro de la región o dentro de la misma zona. Si alguna zona de disponibilidad de la región tiene un problema, el grupo de contenedores podría experimentar tiempo de inactividad.
NGroups: Al implementar un NGroup, puede especificar una o varias zonas en las que implementarla. Si implementa un NGroup en dos o más zonas, se trata de un NGroup con redundancia de zona y una interrupción de una zona de disponibilidad solo provoca problemas para los grupos de contenedores dentro de la zona afectada.
En el diagrama siguiente se muestra un NGroup que se implementa en tres zonas de disponibilidad:
La imagen muestra tres zonas de disponibilidad. Cada zona de disponibilidad incluye un grupo de contenedores y dos contenedores. Un rectángulo con la etiqueta NGroupdesiredCount=3, zones=1,2,3 abarca las tres zonas de disponibilidad.
Si no especifica zonas de disponibilidad para su NGroup, será no zonal y podría experimentar tiempo de inactividad si alguna zona de disponibilidad en la región presenta un problema.
Grupos en espera: Al implementar un grupo en espera, puede especificar opcionalmente una o varias zonas. La plataforma puede solicitar contenedores en las zonas que seleccione.
Sin embargo, los grupos en espera no tienen redundancia de zona ni resistencia de zona porque no hay garantía de que los contenedores se creen en varias zonas. Si se produjese una interrupción de zona, es posible que todos los contenedores del grupo se coloquen en la zona afectada.
Debido a que los grupos de respaldo no están diseñados para soportar la resiliencia ante fallos de zona, esta guía no describe el comportamiento detallado de los grupos de respaldo con zonas de disponibilidad.
Importante
Los grupos en espera no se diseñaron para tener resistencia de zona. No deben usarse para cargas de trabajo que requieran resistencia a errores de zona.
Soporte para regiones
Las implementaciones de grupos de contenedores zonales se admiten en todas las regiones con zonas de disponibilidad.
Requisitos
Las implementaciones zonales están disponibles para grupos de contenedores de Linux y Windows Server 2019.
Para seleccionar una zona de disponibilidad, debe usar la SKU estándar. Los grupos de contenedores zonales no están disponibles con la SKU confidencial.
Consideraciones
Los contenedores de acceso puntual no admiten zonas de disponibilidad y siempre son no zonales.
Cost
No hay ningún costo adicional para configurar zonas de disponibilidad para un grupo de contenedores.
Configurar soporte de zonas de disponibilidad
Cree grupos de contenedores con soporte para zonas de disponibilidad. El enfoque que se usa para configurar zonas de disponibilidad depende de cómo cree grupos de contenedores.
Grupos de contenedores creados manualmente: Para crear un grupo de contenedores zonales en una zona específica, puede usar uno de los métodos siguientes:
NGroups: Puede implementar un grupo de NGroup con redundancia de zona mediante un archivo de Bicep o una plantilla de ARM y especificando varias zonas. Para obtener más información, consulte ejemplo de NGroups con zonas.
Grupos en espera: Puede implementar un grupo en espera que use zonas de disponibilidad especificando una o varias zonas al crear o actualizar el grupo. Sin embargo, es posible que los contenedores no se creen en varias zonas. Los grupos En espera no deben usarse para cargas de trabajo que requieran resistencia a fallos de zona. Para obtener más información, consulte Creación de un grupo en espera para Container Instances.
Habilitar soporte para zonas de disponibilidad en los recursos existentes. El enfoque que se usa para configurar zonas de disponibilidad depende de cómo cree grupos de contenedores.
Grupos de contenedores creados manualmente: No se pueden habilitar zonas de disponibilidad en un grupo de contenedores nozonal existente. Debe eliminar el grupo de contenedores y crear un grupo de contenedores zonal.
NGroups: No se pueden habilitar zonas de disponibilidad en un NGroup no zonal existente. Debe eliminar el NGroup y crear un NGroup con redundancia zonal.
Grupos en espera: No se pueden habilitar zonas de disponibilidad en un grupo de espera no zonal existente. Debe eliminar el grupo de contenedores y crear un nuevo grupo de espera que use varias zonas de disponibilidad.
Mueva grupos de contenedores entre zonas o deshabilite el soporte para zonas de disponibilidad. El enfoque que se usa para modificar zonas de disponibilidad depende de cómo cree grupos de contenedores.
Grupos de contenedores creados manualmente: Para cambiar la zona de disponibilidad de un grupo de contenedores, debe eliminar el grupo de contenedores y crear otro grupo de contenedores con la nueva zona de disponibilidad. Para obtener información sobre cómo eliminar el grupo de contenedores, consulte los siguientes recursos:
NGroups: Puede agregar zonas a un NGroup, pero no puede quitar zonas.
Grupos en espera: Puede agregar zonas a un grupo en espera, pero no puede quitar zonas.
Distribución de grupos de contenedores
La forma en que los grupos de contenedores se distribuyen entre zonas de disponibilidad depende de cómo implemente los grupos de contenedores.
Grupos de contenedores creados manualmente: Es responsable de distribuir los grupos de contenedores creados manualmente en varias zonas de disponibilidad.
NGroups: Durante las operaciones de escalado horizontal, NGroups elimina aleatoriamente instancias, lo que podría no mantener una distribución entre zonas de disponibilidad. Las operaciones de escalabilidad horizontal intentan reequilibrar la distribución entre zonas.
Grupos en espera: Un grupo en espera puede crear contenedores en cualquiera de las zonas de disponibilidad que configure en el grupo. Sin embargo, es posible que los contenedores no se creen en varias zonas. Los grupos En espera no deben usarse para cargas de trabajo que requieran resistencia a fallos de zona.
Planeamiento y administración de capacidad
** Para prepararse para un fallo de zona de disponibilidad, considere el sobreaprovisionamiento del número de grupos de contenedores que despliegue. Este enfoque permite que la solución tolere cierta pérdida de capacidad y siga funcionando sin que se vea afectado su rendimiento. Para obtener más información, consulte Administración de la capacidad mediante el sobreaprovisionamiento.
El enfoque que se usa para sobreaprovisionar grupos de contenedores depende de cómo implemente los grupos de contenedores.
Grupos de contenedores creados manualmente: Es responsable de planear la capacidad de los grupos de contenedores creados manualmente, incluido el planeamiento del número de grupos de contenedores que se van a implementar en cada zona.
NGroup: Considere la posibilidad de sobreaprovisionar la capacidad de NGroup para tolerar la pérdida de una zona.
Grupos en espera: Los grupos en espera no están diseñados para ser resistentes a los errores de zona. Considere la posibilidad de usar varios grupos en espera en diferentes zonas o usar NGroups.
Comportamiento cuando todas las zonas están en buen estado
En esta sección se describe qué esperar cuando los recursos de Container Instances están configurados para la compatibilidad con zonas de disponibilidad y todas las zonas de disponibilidad están operativas.
Enrutamiento de tráfico entre zonas: Usted es responsable de dirigir el tráfico a sus contenedores. Por ejemplo, puede usar Azure Application Gateway como puerta de enlace y equilibrador de carga para los grupos de contenedores.
Al usar grupos NGroups o grupos en espera, es responsable del equilibrio de carga de cada contenedor. También debe configurar el sistema de enrutamiento de tráfico para detectar el estado de cada grupo de contenedores y redirigir el tráfico a un grupo alternativo cuando sea necesario.
Replicación de datos entre zonas: Los contenedores y los grupos de contenedores no tienen estado. Puede adjuntar su propio recurso compartido de archivos o conectarse a bases de datos u otros servicios de almacenamiento desde sus aplicaciones. Usted es responsable de asegurar que los recursos compartidos de archivos y los servicios de almacenamiento sean resilientes por zonas. Revise las guías de confiabilidad de cada servicio para comprender cómo hacer que cada zona de componentes sea resistente.
Comportamiento durante un fallo de zona
En esta sección se describe qué esperar cuando los recursos de Instancias de Contenedor están configurados para la compatibilidad con las zonas de disponibilidad y ocurre una interrupción en ellas.
Detección y respuesta: La responsabilidad de la detección de errores de zona y la respuesta asociada dependen de cómo implemente los grupos de contenedores.
Grupos de contenedores creados manualmente: debe detectar la pérdida de una zona de disponibilidad e iniciar una conmutación por error a un grupo de contenedores alternativo que ha creado en otra zona de disponibilidad.
NGroups: La plataforma Container Instances es responsable de detectar un error en una zona de disponibilidad y responder.
Sin embargo, es responsable de garantizar que ese tráfico se enrute a los contenedores en una zona saludable.
Grupos en espera: No se garantiza que la plataforma Container Instances responda a errores de zona para grupos en espera. Los grupos En espera no deben usarse para cargas de trabajo que requieran resistencia a fallos de zona.
- Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.
Solicitudes activas: si se produjese un error en una zona, es probable que todos los contenedores que se ejecuten en esa zona se detengan, incluyendo cualquier trabajo activo que controlen
Pérdida de datos esperada: Dado que los contenedores y los grupos de contenedores no tienen estado, no se espera ninguna pérdida de datos debido a un fallo de zona. Sin embargo, es responsable de garantizar que cada componente de la carga de trabajo sea resistente a la zona, incluidos los servicios de almacenamiento y las bases de datos.
Tiempo de inactividad esperado: El tiempo de inactividad que puede esperar de un error de zona depende de cómo implemente los grupos de contenedores.
Grupos de contenedores creados manualmente: En el caso de los grupos de contenedores zonales, cuando una zona no está disponible, el grupo de contenedores y sus contenedores no están disponibles hasta que se recupere la zona de disponibilidad.
NGroups: En el caso de NGroups, si una zona deja de funcionar, la aplicación sigue estando disponible porque los grupos de contenedores restantes de NGroups siguen ejecutándose en otras zonas. No se espera ningún tiempo de inactividad.
Grupos en espera: Los grupos en espera no proporcionan resistencia de zona. Si todos los grupos de contenedores del grupo en espera se encontrasen en una sola zona de disponibilidad, es posible que todos los grupos de contenedores y sus contenedores queden inaccesibles hasta que se recupere la zona de disponibilidad.
Reenrutamiento del tráfico: Dado que es responsable del enrutamiento del tráfico a los contenedores, también es responsable de volver a enrutar el tráfico si se produce un error en un grupo de contenedores debido a una interrupción de zona de disponibilidad.
Recuperación de zona
Una vez recuperada la zona, la plataforma Azure reinicia automáticamente los grupos de contenedores que se habían detenido. No se requiere ninguna acción del cliente.
Prueba de fallos de zona
No hay ninguna manera de simular una interrupción de la zona de disponibilidad que contiene el grupo de contenedores. Sin embargo, puede configurar manualmente puertas de enlace ascendentes o equilibradores de carga para redirigir el tráfico a otro grupo de contenedores en una zona de disponibilidad diferente.
Resistencia a errores en toda la región
Container Instances es un servicio de una sola región. Si la región deja de estar disponible, los grupos de contenedores y sus contenedores tampoco están disponibles.
Soluciones personalizadas de varias regiones para la resistencia
Opcionalmente, puede implementar grupos de contenedores independientes en varias regiones. Es responsable de implementar y configurar los grupos de contenedores en cada región. También debe configurar el equilibrio de carga mediante un servicio como Azure Traffic Manager o Azure Front Door. Usted es responsable de cualquier sincronización, conmutación por error y recuperación después de falla de datos.
Acuerdo de nivel de servicio
El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.