Conjuntos de disponibilidad en AKS habilitados por Azure Arc
Los conjuntos de disponibilidad son grupos lógicos de máquinas virtuales que tienen relaciones antiafinidad débiles entre sí, para asegurarse de que se distribuyen uniformemente entre los dominios de error disponibles en un clúster físico. Un dominio de error en este contexto es un host físico o un grupo de hosts físicos. Mediante el uso de conjuntos de disponibilidad, AKS Arc puede mejorar la disponibilidad y distribución de las cargas de trabajo de Kubernetes. Los conjuntos de disponibilidad pueden evitar escenarios en los que un error de nodo único puede provocar que varias máquinas virtuales bajen o se desequilibren.
Información general
Los conjuntos de disponibilidad ofrecen varias ventajas para AKS en usuarios locales de Azure, como:
- Mejora la disponibilidad y resistencia de las aplicaciones evitando escenarios en los que varias máquinas virtuales del mismo grupo de nodos o plano de control bajen o se desequilibren debido a un error de nodo único.
- Optimiza el uso y el rendimiento de los recursos del clúster asegurándose de que las máquinas virtuales se distribuyen uniformemente entre los nodos disponibles y no se concentran en un solo nodo o en un subconjunto de nodos.
- Se alinea con los procedimientos recomendados y las expectativas de los clientes y asociados que buscan una experiencia de Kubernetes local confiable y coherente.
Habilitación de conjuntos de disponibilidad
Con AKS en Azure Local, versión 23H2, la característica de conjuntos de disponibilidad está habilitada de forma predeterminada al crear un grupo de nodos. Con AKS en Windows Server, puede habilitar la característica de conjuntos de disponibilidad agregando el -enableAvailabilitySet parámetro al crear un clúster de AKS; por ejemplo, New-AksHciCluster -Name <name> -controlPlaneNodeCount 3 -osType Linux -kubernetesVersion $kubernetesVersion -enableAvailabilitySet.
Funcionamiento de los conjuntos de disponibilidad en AKS habilitados por Azure Arc
Al crear un nuevo clúster de AKS Arc, AKS Arc crea automáticamente conjuntos de disponibilidad, uno para las máquinas virtuales del plano de control y otro para cada uno de los grupos de nodos del clúster de Kubernetes. Cada grupo de nodos tiene su propio conjunto de disponibilidad. Con este diseño, AKS Arc garantiza que las máquinas virtuales del mismo rol (plano de control o grupo de nodos) nunca se encuentren en el mismo host físico y que se distribuyan entre los nodos disponibles en un clúster.
Una vez creados los conjuntos de disponibilidad y las máquinas virtuales asignadas, el sistema los coloca automáticamente en los nodos físicos adecuados. Si se produce un error en un nodo, el sistema también conmuta por error automáticamente las máquinas virtuales a otros nodos y las vuelve a equilibrar cuando el nodo se recupera. De este modo, puede lograr una alta disponibilidad y una distribución óptima de las cargas de trabajo de Kubernetes sin intervención manual.
Considere un clúster de AKS en Azure Local, versión 23H2 con dos máquinas host físicas, Host A y Host B, tres máquinas virtuales del plano de control y dos máquinas virtuales de nodo de trabajo, Nodepool1VM1 y Nodepool1VM2. Para garantizar la alta disponibilidad de las aplicaciones de Kubernetes, las máquinas virtuales del grupo de nodos nunca deben compartir el mismo host, a menos que uno de los hosts no esté disponible temporalmente para el problema de mantenimiento planeado o capacidad, lo que puede hacer que la máquina virtual (máquina virtual) se coloque temporalmente en un host alternativo.
En el diagrama siguiente, cada color representa un grupo de antiafinidad:
Si el host B deja de funcionar debido a un reinicio, el plano de control VM2, el plano de control VM3 y nodepool1VM2 conmutan por error al host A , como se muestra en la ilustración siguiente. Suponiendo que la aplicación ejecuta pods en NodePoolVM1, este reinicio no afecta a la aplicación:
En la arquitectura antigua, si el host B volvió a estar en línea después de un reinicio, no había ninguna garantía de que las máquinas virtuales volverían de host A al host B (reequilibrio), lo que obligaba a las cargas de trabajo a permanecer en el mismo host y crear un único punto de error, como se muestra en el diagrama siguiente:
Los conjuntos de disponibilidad de AKS Arc pueden ayudar a reequilibrar las máquinas virtuales una vez que un host se recupera de una interrupción temporal. En este ejemplo, ControlPlaneVM2, ControlPlaneVM3 y Nodepool1VM2 se mueven automáticamente al host B, como se muestra aquí:
Importante
Los conjuntos de disponibilidad de AKS Arc son una nueva característica que sigue evolucionando y mejorando. Todavía no se admite la configuración manual de los dominios de error o los conjuntos de disponibilidad. No puede cambiar los dominios de error de un conjunto de disponibilidad después de crearlo. Las máquinas virtuales se asignan a un conjunto de disponibilidad en la creación del clúster y no se pueden migrar a otro conjunto de disponibilidad.
Agregar o eliminar máquinas
En un escenario de eliminación de host, el host ya no se considera parte del clúster. Esta eliminación suele producirse cuando se reemplaza una máquina debido a problemas de hardware o se reduce verticalmente el clúster local de Azure por otros motivos. Durante una interrupción del nodo, el nodo sigue siendo parte del clúster local de Azure, pero aparece como Inactivo.
Si una máquina física (dominio de error) se elimina permanentemente del clúster, la configuración del conjunto de disponibilidad no se modifica para reducir el número de dominios de error. En este escenario, el conjunto de disponibilidad entra en un estado incorrecto. Se recomienda volver a implementar los clústeres de Kubernetes para que el conjunto de disponibilidad se actualice con el número adecuado de dominios de error.
Cuando se agrega una nueva máquina física (dominio de error) al clúster, la configuración del conjunto de disponibilidad se expande automáticamente para incluir la nueva máquina. Sin embargo, las máquinas virtuales existentes no se reequilibran para aplicar esta nueva configuración, ya que ya están asignadas a conjuntos de disponibilidad. Se recomienda volver a implementar los clústeres de Kubernetes para que el conjunto de disponibilidad se actualice con el número adecuado de dominios de error.