Creación de un clúster de Azure Kubernetes Service (AKS) que use zonas de disponibilidad

  • Artículo
  • Tiempo de lectura: 8 minutos

Un clúster de Azure Kubernetes Service (AKS) distribuye recursos como nodos y almacenamiento en secciones lógicas de infraestructura subyacente de Azure. El uso de zonas de disponibilidad separa físicamente los nodos de otros nodos implementados en zonas de disponibilidad diferentes. Los clústeres de AKS implementados con varias zonas de compatibilidad configuradas en un clúster proporcionan un alto nivel de disponibilidad para proteger frente a errores de hardware o eventos de mantenimiento planeados.

Si se definen los grupos de nodos de un clúster de modo que abarquen varias zonas, los nodos de un grupo de nodos determinado pueden seguir funcionando aunque una zona esté fuera de servicio. Las aplicaciones pueden seguir estando disponibles aunque se produzca un error físico en un centro de datos individual, siempre que esté orquestado para tolerar los errores de un subconjunto de nodos.

En este artículo le mostraremos cómo crear un clúster de AKS y distribuir los componentes del nodo en las zonas de disponibilidad.

Antes de empezar

Es preciso que esté instalada y configurada la versión 2.0.76 de la CLI de Azure, o cualquier otra posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

Limitaciones y disponibilidad de región

Los clústeres de AKS pueden usar zonas de disponibilidad en cualquier región de Azure que tenga zonas de disponibilidad.

Las siguientes limitaciones se aplican cuando crea un clúster de AKS mediante zonas de disponibilidad:

  • Las zonas de disponibilidad solo se pueden definir durante cuando la creación del grupo de clústeres o nodos.
  • No es posible actualizar un clúster de una zona de no disponibilidad existente para usar zonas de disponibilidad después de crear el clúster.
  • El tamaño de nodo (SKU de VM) seleccionado debe estar disponible en todas las zonas de disponibilidad seleccionadas.
  • Los clústeres con zonas de disponibilidad habilitadas requieren el uso de equilibradores de Azure Standard Load Balancer para la distribución entre zonas. Este tipo de equilibrador de carga solo se puede definir en el momento de la creación del clúster. Para obtener más información y las limitaciones del equilibrador de carga estándar, consulte las limitaciones de la SKU estándar del equilibrador de carga de Azure.

Compatibilidad con la zona de disponibilidad de disco de Azure

  • Los volúmenes que usan discos de almacenamiento con redundancia local administrados de Azure no son recursos con redundancia de zona, se conectan entre zonas y no se admiten. Debe colocar los volúmenes en la misma zona que el nodo especificado que hospeda el pod de destino.
  • Los volúmenes que usan discos ZRS administrados de Azure (compatibles con la versión 1.5.0 del controlador CSI de Azure Disk, y las versiones posteriores) son recursos con redundancia de zona. Esos volúmenes se pueden programar en todos los nodos de agente de zona y que no son de zona.

Kubernetes tiene en cuenta las zonas de disponibilidad de Azure desde la versión 1.12. Puede implementar un objeto PersistentVolumeClaim que haga referencia a un disco administrado de Azure en un clúster de AKS con varias zonas y Kubernetes se encargará de programar cualquier pod que reclame este PVC en la zona de disponibilidad correcta.

Plantillas de Azure Resource Manager y zonas de disponibilidad

Al crear un clúster de AKS, debe conocer los siguientes detalles sobre cómo especificar zonas de disponibilidad en una plantilla:

  • Si define explícitamente un valor null en una plantilla, por ejemplo, especificando "availabilityZones": null, la plantilla de Resource Manager trata la propiedad como si no existiera, lo que significa que el clúster no se implementa en una zona de disponibilidad.
  • Si no incluye la propiedad "availabilityZones": en la plantilla de Resource Manager, el clúster no se implementa en una zona de disponibilidad.
  • No puede actualizar la configuración de las zonas de disponibilidad de un clúster existente, el comportamiento es diferente al actualizar un clúster de AKS con plantillas de Resource Manager. Si establece explícitamente un valor null en la plantilla de las zonas de disponibilidad y actualiza el clúster, no actualiza el clúster en las zonas de disponibilidad. Sin embargo, si omite la propiedad availability zones con una sintaxis de tipo "availabilityZones": [], la implementación intenta deshabilitar las zonas de disponibilidad en el clúster de AKS existente y "availabilityZones": [].

Introducción a las zonas de disponibilidad para los clústeres de AKS

Las zonas de disponibilidad son una oferta de alta disponibilidad que protege las aplicaciones y datos de los errores del centro de datos. Las zonas son ubicaciones físicas exclusivas dentro de una región de Azure. Cada zona incluye uno o más centros de datos, equipados con redes, alimentación y refrigeración independientes. Para garantizar la resistencia, siempre hay más de una zona en todas las regiones habilitadas para zonas. La separación física de las zonas de disponibilidad dentro de una región protege las aplicaciones y los datos frente a los errores del centro de datos.

Para más información, consulte ¿Qué son las zonas de disponibilidad en Azure?

Los clústeres de AKS que se implementan mediante zonas de disponibilidad que pueden distribuir nodos en varias zonas dentro de una sola región. Por ejemplo, un clúster en la región Este de EE. UU. 2 puede crear nodos en las tres zonas de disponibilidad del Este de EE. UU. 2. Esta distribución de los recursos del clúster de AKS mejora la disponibilidad del clúster, ya que son resistentes a los errores de una zona específica.

Distribución de nodos de AKS en zonas de disponibilidad

Si una sola zona deja de estar disponible, las aplicaciones siguen ejecutándose en los clústeres configurados para distribuirse entre varias zonas.

Crear un clúster de AKS en zonas de disponibilidad

Si se crea un clúster mediante el comando az aks create, el parámetro --zones especifica las zonas en que se implementan los nodos de agente. Los componentes del plano de control, como etcd o la API, se distribuyen por las zonas disponibles en la región durante la implementación del clúster. Las zonas específicas entre las que se distribuyen los componentes del plano de control son independientes de las zonas explícitas que seleccione para el grupo de nodos inicial.

Si no especifica ninguna zona para el grupo de agentes predeterminado al crear un clúster de AKS, los componentes del plano de control no están presentes las zonas de disponibilidad. Puede agregar más grupos de nodos mediante el comando az aks nodepool add y especificar --zones para los nuevos nodos. El comando convierte el plano de control de AKS para que se pueda realizar la distribución entre las zonas de disponibilidad.

En el ejemplo siguiente se crea un clúster de AKS denominado myAKSCluster en el grupo de recursos denominado myResourceGroup con un total de tres nodos. Un agente en la zona 1, otro en la 2 y un tercero en la 3.

az group create --name myResourceGroup --location eastus2

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --generate-ssh-keys \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --node-count 3 \
    --zones 1 2 3

El clúster de AKS tarda unos minutos en crearse.

A la hora de decidir la zona a la que debe pertenecer un nodo nuevo, un grupo de nodos determinado de AKS usa la mejor opción de equilibrio de zonas que ofrece la instancia subyacente de Azure Virtual Machine Scale Sets. El grupo de nodos dado de AKS está "equilibrado" cuando todas las zonas tienen el mismo número de máquinas virtuales o + una máquina virtual en todas las demás zonas del conjunto de escalado.

Comprobar la distribución de nodos entre zonas

Cuando el clúster esté listo, indique la zona de disponibilidad en que se encuentran los nodos de agente en el conjunto de escalado.

Primero, obtenga las credenciales del clúster de AKS mediante el comando az aks get-credentials:

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

A continuación, use el comando kubectl describe para enumerar los nodos del clúster y filtrar por el valor topology.kubernetes.io/zone. El ejemplo siguiente es para un shell de Bash.

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

El siguiente resultado de ejemplo muestra los tres nodos distribuidos en la región especificada y las zonas de disponibilidad, como eastus2-1 para la primera zona de disponibilidad y eastus2-2 para la segunda zona de disponibilidad:

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

Cuando se agregan más nodos a un grupo de agentes, la plataforma Azure distribuye automáticamente las máquinas virtuales subyacentes en las zonas de disponibilidad especificadas.

A partir de la versión 1.17.0 de Kubernetes, AKS usa la etiqueta topology.kubernetes.io/zone, que es más reciente y failure-domain.beta.kubernetes.io/zone, que está en desuso. Puede obtener el mismo resultado si ejecuta el comando kubelet describe nodes en el paso anterior, para lo que ejecuta el siguiente script:

kubectl get nodes -o custom-columns=NAME:'{.metadata.name}',REGION:'{.metadata.labels.topology\.kubernetes\.io/region}',ZONE:'{metadata.labels.topology\.kubernetes\.io/zone}'

El ejemplo siguiente se parece a la salida, aunque es más detallado:

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

Comprobar la distribución de pods entre zonas

Como se documenta en Etiquetas, anotaciones y taints ampliamente conocidas, Kubernetes usa la etiqueta para distribuir automáticamente los pods en un controlador o servicio de replicación en las diferentes zonas disponibles. Para probar la etiqueta y escalar el clúster de 3 a 5 nodos, ejecute el siguiente comando para comprobar que el pod se distribuye correctamente:

az aks scale \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 5

Cuando la operación de escalado se complete después de unos minutos, el comando kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone" de un shell de Bash. La siguiente salida se parece a los resultados:

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3
Name:       aks-nodepool1-28993262-vmss000003
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            topology.kubernetes.io/zone=eastus2-2

Ahora hay dos nodos más en las zonas 1 y 2. Puede implementar una aplicación que consta de tres réplicas. En el ejemplo siguiente se usa NGINX:

kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
kubectl scale deployment nginx --replicas=3

Si se miran los nodos en los que se están ejecutando los pods, se observa que estos se ejecutan en los nodos correspondientes a tres zonas de disponibilidad diferentes. Por ejemplo, con el comando kubectl describe pod | grep -e "^Name:" -e "^Node:" en un shell de Bash, verá la siguiente salida de ejemplo:

Name:         nginx-6db489d4b7-ktdwg
Node:         aks-nodepool1-28993262-vmss000000/10.240.0.4
Name:         nginx-6db489d4b7-v7zvj
Node:         aks-nodepool1-28993262-vmss000002/10.240.0.6
Name:         nginx-6db489d4b7-xz6wj
Node:         aks-nodepool1-28993262-vmss000004/10.240.0.8

Como puede ver en la salida anterior, el primer pod se ejecuta en el nodo 0, que se encuentra en la zona de disponibilidad eastus2-1. El segundo se ejecuta en el nodo 2, que corresponde a eastus2-3, y el tercero, en el nodo 4, en eastus2-2. Sin necesidad de configuración adicional, Kubernetes extiende los pods correctamente en las tres zonas de disponibilidad.

Pasos siguientes

En este artículo se describe cómo crear un clúster de AKS mediante zonas de disponibilidad. Para obtener más información sobre los clústeres de alta disponibilidad, consulte Best practices for business continuity and disaster recovery in AKS (Procedimientos recomendados para la continuidad empresarial y recuperación ante desastres en AKS).