Disponibilidad de aplicaciones en AKS habilitada por Azure Arc

Se aplica a: AKS en Azure Stack HCI 22H2, AKS en Windows Server

Azure Kubernetes Service (AKS) habilitado por Azure Arc ofrece una plataforma de contenedor totalmente compatible que puede ejecutar aplicaciones nativas de nube en la plataforma de orquestación de contenedores de Kubernetes. La arquitectura admite la ejecución de cargas de trabajo virtualizadas de Windows y Linux.

La arquitectura de AKS se crea con clústeres de conmutación por error y migración en vivo que se habilita automáticamente para los clústeres de destino (carga de trabajo). Durante varios eventos de interrupción, las máquinas virtuales que hospedan cargas de trabajo del cliente se mueven libremente sin que se perciba un tiempo de inactividad para la aplicación. Esta arquitectura significa que un cliente empresarial tradicional, que administra una aplicación heredada como singleton para AKS en Azure Stack HCI o Windows Server, obtiene un tiempo de actividad similar (o mejor) que el que se experimenta actualmente en una aplicación de máquina virtual heredada.

En este artículo se describen algunos conceptos fundamentales para los usuarios que desean ejecutar aplicaciones en contenedores en AKS Arc con la migración en vivo habilitada para garantizar que las aplicaciones están disponibles durante una interrupción. Para hacer referencia al tiempo de inactividad de una aplicación que se ejecuta en un pod se utiliza la terminología de Kubernetes, términos como interrupción voluntaria e interrupción involuntaria.

¿Qué es la migración en vivo?

La migración en vivo es una característica de Hyper-V que permite trasladar máquinas virtuales en ejecución desde un host de Hyper-V a otro sin que se perciba tiempo de inactividad y de manera transparente. La principal ventaja de la migración en vivo es la flexibilidad; la ejecución de máquinas virtuales no está vinculada a una sola máquina host. Esto permite a los usuarios llevar a cabo acciones como el purgado de un host específico de máquinas virtuales antes de retirar o actualizar el host. Cuando se empareja con clústeres de conmutación por error de Windows, la migración en vivo permite la creación de sistemas de alta disponibilidad y tolerancia a errores.

La arquitectura actual de AKS en Azure Stack HCI y Windows Server supone que ha habilitado la migración en vivo en el entorno en clúster de Azure Stack HCI. Por lo tanto, todas las máquinas virtuales del nodo de trabajo de Kubernetes se crean con la migración en vivo configurada. Estos nodos se pueden mover por los hosts físicos en caso de interrupción para garantizar que la plataforma tiene alta disponibilidad.

Al ejecutar una aplicación heredada como singleton sobre Kubernetes, esta arquitectura satisface las necesidades de alta disponibilidad. Kubernetes administra la programación de pods en nodos de trabajo disponibles mientras que la migración en vivo administra la programación de máquinas virtuales de nodos de trabajo en hosts físicos disponibles.

Escenarios de interrupción de aplicaciones

Un estudio comparativo de los tiempos de recuperación de las aplicaciones que se ejecutan en VM en AKS en Azure Stack HCI y Windows Server muestra claramente que el impacto en la aplicación cuando se producen eventos de interrupción comunes es mínimo. Aquí se muestran tres escenarios de ejemplo de interrupción:

• Aplicación de una actualización que da como resultado un reinicio de la máquina física.
• Aplicación de una actualización que implica volver a crear el nodo de trabajo.
• Error de hardware no planeado en una máquina física.

Nota:

En estos escenarios se supone que el propietario de la aplicación todavía usa la configuración de afinidad y antiafinidad de Kubernetes para garantizar la programación adecuada de los pods entre nodos de trabajo.

Evento de interrupción	Ejecución de aplicaciones en máquinas virtuales en Azure Stack HCI	Ejecución de aplicaciones en máquinas virtuales en AKS en Azure Stack HCI o Windows Server
Aplicación de una actualización que da como resultado un reinicio de la máquina física	Ningún impacto	Ningún impacto
Aplicar una actualización que implique volver a crear el nodo de trabajo (o reiniciar la máquina virtual)	Ningún impacto	Varía
Error de hardware no planeado en una máquina física	6-8 minutos	6-8 minutos

Aplicación de una actualización que da como resultado un reinicio de la máquina física

Durante un evento de mantenimiento de host físico, como la aplicación de una actualización que da como resultado el reinicio de una máquina host, no se espera impacto en las aplicaciones que se ejecutan en el clúster. El administrador del clúster purga el host y garantiza que todas las máquinas virtuales se migran en vivo antes de aplicar la actualización.

Aplicar una actualización que implique volver a crear el nodo de trabajo

Este escenario implica la detención de una máquina virtual del nodo de trabajo para el mantenimiento rutinario. Para prepararse para la actualización, el administrador del clúster purga y aísla el nodo, de modo que todos los pods se expulsan a un nodo de trabajo disponible antes de aplicar las actualizaciones. Una vez completada la actualización, el nodo de trabajo se vuelve a unir y está disponible para la programación.

Nota

La disponibilidad de una aplicación varía, ya que incluye el tiempo necesario para descargar la imagen de contenedor base, especialmente para imágenes más grandes almacenadas en la nube pública. Por lo tanto, se recomienda usar imágenes de contenedor base pequeñas y, para contenedores de Windows, se recomienda usar la nano server imagen base.

Error de hardware no planeado en una máquina física

En este escenario se produce un evento de interrupción involuntaria en una máquina física que hospeda un contenedor o pod de aplicación heredados en una de las máquinas virtuales del nodo de trabajo. La agrupación en clústeres de conmutación por error coloca el host en un estado aislado y, a continuación, después de un período de 6 a 8 minutos, inicia el proceso de migración en vivo de estas máquinas virtuales a hosts supervivientes. En este caso, el tiempo de inactividad de la aplicación es el equivalente al tiempo que se tarda en reiniciar el host y las máquinas virtuales del nodo de trabajo.

Conclusión

Las tecnologías de clústeres de conmutación por error de AKS están diseñadas para asegurarse de que los entornos informáticos de Azure Stack HCI y Windows Server sean altamente disponibles y tolerantes a errores. Sin embargo, el propietario de la aplicación todavía tiene que configurar las implementaciones para usar características de Kubernetes, como Deployments, Affinity Mapping o RelicaSets, para garantizar que los pods son resistentes en los escenarios de interrupción.

Pasos siguientes

Introducción a AKS en Windows Server y Azure Stack HCI