Compartir a través de


Escenarios de disponibilidad para Azure Kubernetes Service (AKS) habilitados por Azure Arc en Azure Local de dos nodos

Se aplica a: Azure Stack HCI, versión 22H2

En este artículo se describe la arquitectura para implementar un clúster de Kubernetes en un clúster local de Azure de dos nodos. En el artículo se describen varios escenarios de error que pueden producirse, su impacto en el clúster y la capacidad de recuperación de estos escenarios de error.

Arquitectura

Las implementaciones tradicionales de Kubernetes requieren tres máquinas físicas para mitigar un único error. Este requisito normalmente significa un costo total mayor de propiedad (TCO). En el caso de las implementaciones sensibles a los costos, AKS habilitado por Arc se puede implementar en un sistema local de Azure de dos nodos, como se muestra a continuación, con algunas ventajas en la disponibilidad. Estas ventajas y desventajas se describen en Escenarios de disponibilidad y su impacto en el clúster de AKS de dos nodos.

Ilustración que muestra la arquitectura de un clúster de AKS que se ejecuta en un clúster local de Azure de dos nodos.

Para más información sobre la arquitectura, las estrategias de implementación de clústeres, las consideraciones de confiabilidad y la optimización de costos para AKS, consulte Arquitectura de línea de base de Azure Kubernetes Service (AKS).

Terminología

En este artículo se usa la siguiente terminología:

Término Definición
Host local de Azure físico El nodo de clúster local de Azure físico que hospeda las máquinas virtuales necesarias para ejecutar AKS habilitado por Arc.
SO invitado Sistema operativo que se ejecuta dentro de la máquina virtual (VM) del plano de control, la máquina virtual del equilibrador de carga o las máquinas virtuales del grupo de nodos.
Clúster de conmutación por error Los clústeres de conmutación por error para Azure Local y Windows Server proporcionan características de infraestructura que admiten la alta disponibilidad de máquinas virtuales y aplicaciones. Si se produce un error en un nodo o servicio de clúster, las máquinas virtuales o aplicaciones hospedadas en ese nodo se pueden transferir automáticamente o manualmente a otro nodo disponible en un proceso conocido como conmutación por error.
Clúster de carga de trabajo Un clúster de Kubernetes implementado por Azure Kubernetes Service (AKS) para hospedar la aplicación o carga de trabajo del usuario final en contenedor, también conocida como clúster de destino.
Clúster de administración (host de AKS) Proporciona el mecanismo de orquestación principal y la interfaz para implementar y administrar uno o varios clústeres de cargas de trabajo. El clúster de administración contiene una sola máquina virtual del plano de control.
Equilibrador de carga Una sola máquina virtual Linux dedicada con una regla de equilibrio de carga para el servidor de API.
Servidor de API Permite la interacción con el clúster de Kubernetes, lo que proporciona interacción con herramientas de administración como Windows Admin Center, módulos de PowerShell y kubectl.
CRUD Crear, leer, actualizar y eliminar operaciones.

Escenarios de disponibilidad y su impacto en el clúster de AKS de dos nodos

La arquitectura escalada en una implementación local de Azure con dos nodos físicos implica algunas ventajas de disponibilidad. En esta sección se describe el comportamiento del nodo durante los siguientes modos de error y durante las actualizaciones:

Actualizaciones

Use la tabla siguiente para determinar el posible impacto de las actualizaciones de Azure Local y AKS en las cargas de trabajo:

Cargas de trabajo existentes CRUD en clústeres de cargas de trabajo Nuevo ciclo de vida del clúster de carga de trabajo Disponibilidad del servidor de API
Sin interrupción Sin interrupción Sin interrupción Sin interrupción
La actualización compatible con clústeres en Azure Local migra los nodos de trabajo al otro nodo antes de reiniciarse. Las aplicaciones no se interrumpen durante esta migración. La actualización compatible con clústeres en Azure Local migra la máquina virtual del plano de control del clúster de carga de trabajo al otro nodo antes de reiniciarse. Las cargas de trabajo existentes se pueden escalar sin interrupciones durante una actualización. La actualización compatible con clústeres en Azure Local migra la máquina virtual del plano de control del clúster de administración al otro nodo antes de reiniciarse. Las nuevas cargas de trabajo se pueden crear sin interrupciones durante una actualización. La actualización compatible con clústeres en Azure Local migra la máquina virtual del plano de control del clúster de carga de trabajo al otro nodo antes de reiniciarse. El clúster del servidor de API permanece disponible durante una actualización.

Error de hardware en el host

El host físico que ejecuta las máquinas virtuales que hospedan los nodos de Kubernetes podría dejar de funcionar debido a problemas de hardware o podría convertirse en particiones de red.

Use la tabla siguiente para determinar el posible impacto de los errores de hardware del host en las cargas de trabajo.

Cargas de trabajo existentes CRUD en clústeres de cargas de trabajo Nuevo ciclo de vida del clúster de carga de trabajo Disponibilidad del servidor de API
Posible interrupción
+
Recuperación automática
Posible interrupción
+
Recuperación automática
Posible interrupción
+
Recuperación automática
Posible interrupción
+
Recuperación automática
Las cargas de trabajo existentes continúan ejecutándose sin interrupciones siempre y cuando:
- Los nodos de trabajo están en hosts independientes.
- La aplicación definió al menos dos réplicas con podAntiAffinity especificado.

Si una aplicación tiene una dependencia en una dirección IP virtual externa (VIP) del servidor de API, se produce una interrupción.
Si la máquina virtual del plano de control del clúster de cargas de trabajo reside en el host que se ha inactivo, las cargas de trabajo no se escalan. La adición de nuevos nodos de trabajo y el escalado de pods no funcionarán. Si la máquina virtual del plano de control del clúster de administración reside en el host que se ha inactivo, no se pueden crear nuevos clústeres. El escalado de clústeres existentes no funcionará. Si la máquina virtual del plano de control del clúster de carga de trabajo o la máquina virtual del equilibrador de carga reside en el host que se ha inactivo, el servidor de API no está disponible.
Si los nodos de trabajo están en el mismo host físico, la agrupación en clústeres de conmutación por error conmuta por error los nodos de trabajo en el host superviviente.

Si la aplicación no se creó con afinidad antiafinidad, Kubernetes mueve el pod al nodo de trabajo existente.

Si la aplicación depende del servidor de API y la máquina virtual del plano de control o la máquina virtual del equilibrador de carga del clúster de carga de trabajo deja de funcionar, los clústeres de conmutación por error mueven esas máquinas virtuales al host superviviente y la aplicación se reanuda el funcionamiento. En función de cómo controla la aplicación la pérdida del servidor de API, es posible que los pods se reinicien en el nuevo host.
La agrupación en clústeres de conmutación por error conmuta por error la máquina virtual del plano de control del clúster de carga de trabajo en el host correcto. Después de la conmutación por error, se pueden escalar las cargas de trabajo. La agrupación en clústeres de conmutación por error conmuta por error la máquina virtual del plano de control del clúster de administración en el host correcto. Después de la conmutación por error, funcionan las operaciones CRUD en los nuevos clústeres de destino. La agrupación en clústeres de conmutación por error conmuta por error la máquina virtual del plano de control del clúster de carga de trabajo en el host correcto. Después de la conmutación por error, el servidor de API está disponible.

Error del sistema operativo del host

El host físico que ejecuta las máquinas virtuales que hospedan los nodos de Kubernetes puede tener un problema de software en el sistema operativo y provocar un error.

Use la tabla siguiente para determinar el posible impacto de los errores del sistema operativo host en las cargas de trabajo.

Cargas de trabajo existentes CRUD en clústeres de cargas de trabajo Nuevo ciclo de vida del clúster de carga de trabajo Disponibilidad del servidor de API
Posible interrupción
+
Recuperación automática
Posible interrupción
+
Recuperación automática
Posible interrupción
+
Recuperación automática
Posible interrupción
+
Recuperación automática
Las cargas de trabajo existentes continúan ejecutándose sin interrupciones siempre y cuando:
- Los nodos de trabajo están en hosts independientes.
- La aplicación definió al menos dos réplicas con podAntiAffinity especificado.

Si la aplicación tiene una dependencia en una VIP externa del servidor de API, se produce una interrupción.
Si la máquina virtual del plano de control del clúster de destino reside en el host con errores del sistema operativo, la adición de nuevos nodos de trabajo y pods de escalado no funcionará. Si la máquina virtual del plano de control del clúster de administración reside en el host con errores del sistema operativo, no se crearán clústeres nuevos y no se podrán escalar los clústeres existentes. Si la máquina virtual del plano de control reside en el host con errores del sistema operativo, el servidor de API no estará disponible.
Si los nodos de trabajo están en el mismo host físico, la agrupación en clústeres de conmutación por error conmuta por error los nodos de trabajo en el host superviviente.

Si la aplicación no se creó con antiafinidad, Kubernetes moverá el pod al nodo de trabajo existente.

Si la aplicación tiene dependencias en el servidor de API y la máquina virtual del plano de control o la máquina virtual del equilibrador de carga del clúster de cargas de trabajo se apaga, la agrupación en clústeres de conmutación por error mueve esas máquinas virtuales al host superviviente y la aplicación se reanuda. En función de cómo controla la aplicación la pérdida del servidor de API, es posible que los pods se reinicien en el nuevo host.
La agrupación en clústeres de conmutación por error conmuta por error la máquina virtual del plano de control del clúster de carga de trabajo en el host correcto. Después de la conmutación por error, se pueden escalar las cargas de trabajo. La agrupación en clústeres de conmutación por error conmuta por error la máquina virtual del plano de control del clúster de administración en el host correcto. Después de la conmutación por error, funcionarán las operaciones CRUD en los nuevos clústeres de destino. La agrupación en clústeres de conmutación por error reinicia la máquina virtual del plano de control del clúster de carga de trabajo en el host correcto. Después, el servidor de API está disponible.

Error de máquina virtual del plano de administración

La máquina virtual del plano de control del clúster de administración podría eliminarse inesperadamente, el disco de arranque podría estar dañado o la máquina virtual del plano de control del clúster de administración podría no arrancar debido a problemas del sistema operativo.

Use la tabla siguiente para determinar el posible impacto del error de la máquina virtual del plano de control del clúster de administración en cargas de trabajo.

Cargas de trabajo existentes CRUD en clústeres de cargas de trabajo Nuevo ciclo de vida del clúster de carga de trabajo Disponibilidad del servidor de API
Sin interrupción Ruptura
+
Recuperación manual
Ruptura
+
Recuperación manual
Sin interrupción
Las cargas de trabajo existentes siguen ejecutándose si se produce un error en la máquina virtual del clúster de administración. No se pueden agregar nodos de trabajo para escalar la aplicación. La creación de una nueva carga de trabajo no se realiza correctamente mientras el clúster de administración está inactivo. El servidor de API debe permanecer disponible en caso de que se produzca un error en la máquina virtual del clúster de administración.
No aplicable Si la agrupación en clústeres de conmutación por error puede recuperarse del error, intenta reiniciar la máquina virtual del plano de administración en un host diferente. Si la agrupación en clústeres de conmutación por error no puede recuperar la máquina virtual, el clúster de administración se debe volver a compilar manualmente. Para más información, consulte Copia de seguridad y restauración de clústeres de cargas de trabajo. Si la agrupación en clústeres de conmutación por error puede recuperarse del error, intenta reiniciar la máquina virtual del plano de administración en un host diferente. Si la agrupación en clústeres de conmutación por error no puede recuperar la máquina virtual, el clúster de administración se debe volver a compilar manualmente. Para obtener instrucciones, consulte Copia de seguridad y restauración de clústeres de cargas de trabajo. No aplicable

Error de máquina virtual del plano de control

La máquina virtual del plano de control del clúster de carga de trabajo podría eliminarse inesperadamente, el disco de arranque podría estar dañado o es posible que la máquina virtual no se inicie debido a problemas del sistema operativo.

Use la tabla siguiente para determinar el posible impacto del error de la máquina virtual del plano de control de un clúster de cargas de trabajo en las cargas de trabajo.

Cargas de trabajo existentes CRUD en clústeres de cargas de trabajo Nuevo ciclo de vida del clúster de carga de trabajo Disponibilidad del servidor de API
Sin interrupción Ruptura
+
Recuperación manual
Sin interrupción Ruptura
+
Recuperación manual
Las cargas de trabajo existentes continúan ejecutándose sin interrupciones siempre y cuando:
- Los nodos de trabajo están en hosts independientes.
- La aplicación definió al menos dos réplicas con podAntiAffinity especificado.

Si la aplicación tiene una dependencia en una VIP externa del servidor de API, se produce una interrupción.
Las cargas de trabajo no se pueden escalar mientras la máquina virtual del plano de control está en estado de error. La adición de nuevos nodos de trabajo y el escalado de pods no funcionarán. La creación de una nueva carga de trabajo se realiza correctamente. El servidor de API no está disponible cuando la máquina virtual del plano de control está en estado de error.
No aplicable Si la agrupación en clústeres de conmutación por error puede recuperarse del error, intenta reiniciar la máquina virtual del plano de control en un host diferente. Si los clústeres de conmutación por error no pueden recuperar la máquina virtual, la máquina virtual del plano de control se debe volver a generar manualmente. Para obtener instrucciones, consulte Copia de seguridad y restauración de clústeres de cargas de trabajo. No aplicable Si la agrupación en clústeres de conmutación por error puede recuperarse del error, intenta reiniciar la máquina virtual del plano de control en un host diferente. Si los clústeres de conmutación por error no pueden recuperar la máquina virtual, la máquina virtual del plano de control se debe volver a generar manualmente. Para obtener instrucciones, consulte Copia de seguridad y restauración de clústeres de cargas de trabajo.

Error de máquina virtual del grupo de nodos (nodos de trabajo)

Las máquinas virtuales que hospedan los nodos de Kubernetes podrían eliminarse inesperadamente, el disco de arranque podría estar dañado o es posible que las máquinas virtuales no arranquen debido a problemas del sistema operativo.

Use la tabla siguiente para determinar el posible impacto de un error de una máquina virtual dentro de un grupo de nodos de Kubernetes en cargas de trabajo.

Cargas de trabajo existentes CRUD en clústeres de cargas de trabajo Nuevo ciclo de vida del clúster de carga de trabajo Disponibilidad del servidor de API
Posible interrupción
+
Recuperación manual
Sin interrupción Sin interrupción Sin interrupción
Las cargas de trabajo existentes continúan ejecutándose sin interrupciones siempre y cuando:
- Los nodos de trabajo están en hosts independientes.
- La aplicación definió al menos dos réplicas con podAntiAffinity especificado.
Se pueden agregar nodos de trabajo.
La programación de pods se realiza correctamente si los nodos restantes tienen suficiente capacidad.
La creación de una nueva carga de trabajo se realiza correctamente. El servidor de API permanece disponible en caso de que haya un único error de máquina virtual de trabajo.
Si la agrupación en clústeres de conmutación por error puede recuperarse del error, intenta reiniciar la máquina virtual del plano de control en un host diferente. Si la agrupación en clústeres de conmutación por error no puede recuperar la máquina virtual, debe volver a crear manualmente los nodos de trabajo. No aplicable No aplicable No aplicable

Error de máquina virtual del equilibrador de carga

La máquina virtual del equilibrador de carga puede eliminarse inesperadamente, es posible que el disco de arranque se dañe o que la máquina virtual no arranque debido a problemas del sistema operativo.

Use la tabla siguiente para determinar el posible impacto de un error de la máquina virtual del equilibrador de carga en las cargas de trabajo.

Cargas de trabajo existentes CRUD en clústeres de cargas de trabajo Nuevo ciclo de vida del clúster de carga de trabajo Disponibilidad del servidor de API
Posible interrupción
+
Recuperación automática
Ruptura
+
Recuperación manual
Sin interrupción Ruptura
+
Recuperación manual
Las cargas de trabajo existentes continúan ejecutándose sin interrupciones siempre y cuando:
- Los nodos de trabajo están en hosts independientes.
- La aplicación definió al menos dos réplicas con podAntiAffinity especificado.

Si una aplicación tiene una dependencia en una VIP externa del servidor de API, se produce una interrupción.
Las cargas de trabajo no se pueden escalar mientras la máquina virtual del equilibrador de carga está en estado de error. La adición de nuevos nodos de trabajo y el escalado de pods no funcionarán. La creación de cargas de trabajo se realiza correctamente. El servidor de API sigue sin estar disponible mientras la máquina virtual del equilibrador de carga está inactiva.
Si la agrupación en clústeres de conmutación por error puede recuperarse del error, intenta reiniciar la máquina virtual del equilibrador de carga en un host diferente. Si la agrupación en clústeres de conmutación por error no puede recuperar la máquina virtual, debe volver a generar la máquina virtual del plano de control manualmente. Para obtener instrucciones, consulte Copia de seguridad y restauración de clústeres de cargas de trabajo. Si la agrupación en clústeres de conmutación por error puede recuperarse del error, intenta reiniciar la máquina virtual del equilibrador de carga en un host diferente. Si la agrupación en clústeres de conmutación por error no puede recuperar la máquina virtual, debe volver a generar la máquina virtual del plano de control manualmente. Para obtener instrucciones, consulte Copia de seguridad y restauración de clústeres de cargas de trabajo. No aplicable Si la agrupación en clústeres de conmutación por error puede recuperarse del error, intenta reiniciar la máquina virtual del equilibrador de carga en un host diferente. Si la agrupación en clústeres de conmutación por error no puede recuperar la máquina virtual, debe volver a generar la máquina virtual del plano de control manualmente. Para obtener instrucciones, consulte Copia de seguridad y restauración de clústeres de cargas de trabajo.

Pasos siguientes