Compartir a través de

Zonas de disponibilidad en Azure Kubernetes Service (AKS)

  • Artículo

Las zonas de disponibilidad ayudan a proteger sus aplicaciones y datos de los fallos 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.

El uso de AKS con zonas de disponibilidad distribuye físicamente los recursos entre diferentes zonas de disponibilidad dentro de una sola región, lo cual mejora la confiabilidad. La implementación de nodos en varias zonas no conlleva costos adicionales.

En este artículo se muestra cómo configurar los recursos de AKS para usar zonas de disponibilidad.

Recursos de AKS

En este diagrama se muestran los recursos de Azure que se crean al crear un clúster de AKS:

Diagrama que muestra varios componentes de AKS, con los componentes de AKS hospedados por Microsoft y los componentes de AKS en la suscripción de Azure.

Plano de control de AKS

Microsoft hospeda el plano de control de AKS, el servidor de API de Kubernetes y servicios como scheduler y etcd como servicio administrado. Microsoft replica el plano de control en varias zonas.

Otros recursos del clúster se implementan en un grupo de recursos administrado en la suscripción de Azure. De forma predeterminada, este grupo de recursos tiene el prefijo MC_ para el clúster administrado y contiene los siguientes recursos:

Grupos de nodos

Los grupos de nodos se crean como un conjunto de escalado de máquinas virtuales en la suscripción de Azure.

Al crear un clúster de AKS, se requiere un grupo de nodos del sistema y se crea automáticamente. Hospeda pods críticos del sistema, como CoreDNS y metrics-server. Se pueden agregar más grupos de nodos de usuario al clúster de AKS para hospedar las aplicaciones.

Hay tres maneras en que se pueden implementar grupos de nodos:

  • Expansión de zona
  • Alineación de zona
  • Regional

Diagrama que muestra la distribución de nodos de AKS entre zonas de disponibilidad en los distintos modelos.

Para el grupo de nodos del sistema, el número de zonas usadas se configura cuando se crea el clúster.

Expansión de zona

Una zona que abarca el conjunto de escalado distribuye los nodos en todas las zonas seleccionadas especificando estas zonas con el parámetro --zones.

# Create an AKS Cluster, and create a zone spanning System Nodepool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1, 2, 3
# Add one new zone spanning User Nodepool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1, 2, 3

AKS equilibra automáticamente el número de nodos entre zonas.

Si se produce una interrupción zonal, los nodos de la zona afectada pueden verse afectados, mientras que los nodos de otras zonas de disponibilidad siguen sin verse afectados.

Alineación de zona

Cada nodo está alineado (anclado) a una zona específica. Para crear tres grupos de nodos para una región con tres zonas de disponibilidad:

# # Add three new zone aligned User Nodepools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

Esta configuración se puede usar cuando necesite menor latencia entre los nodos. También proporciona un control más granular sobre las operaciones de escalado o cuando se usa el escalador automático de clústeres.

Nota:

  • Si se implementa una sola carga de trabajo en grupos de nodos, se recomienda establecer --balance-similar-node-groups en true para mantener una distribución equilibrada de nodos entre zonas para las cargas de trabajo durante las operaciones de escalado vertical.

Regional (no mediante zonas de disponibilidad)

El modo regional se usa cuando la asignación de zona no está establecida en la plantilla de implementación ("zones"=[] or "zones"=null).

En esta configuración, el grupo de nodos crea instancias regionales (no ancladas de zona) y coloca implícitamente instancias en toda la región. No hay ninguna garantía de equilibrio o propagación entre zonas, o que las instancias llegan a la misma zona de disponibilidad.

En el caso excepcional de una interrupción zonal completa, cualquiera o todas las instancias del grupo de nodos pueden verse afectadas.

Para validar las ubicaciones de nodo, ejecute el siguiente comando:

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

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

Implementaciones

Pods

Kubernetes detecta Azure Availability Zones y puede equilibrar los pods entre nodos de distintas zonas. En caso de que una zona deje de estar disponible, Kubernetes mueve los pods fuera de los nodos afectados automáticamente.

Como se documenta en Etiquetas, anotaciones y taints ampliamente conocidas, Kubernetes usa la etiqueta topology.kubernetes.io/zone para distribuir automáticamente los pods en un controlador o servicio de replicación en las diferentes zonas disponibles.

Para ver en qué pods se ejecutan los nodos, ejecute el siguiente comando:

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

El parámetro "maxSkew" describe el grado en que los pods pueden distribuirse de forma desigual. Suponiendo tres zonas y tres réplicas, establecer este valor en 1 garantiza que cada zona tenga al menos un pod en ejecución:

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  replicas: 3
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Almacenamiento y volúmenes

De forma predeterminada, las versiones 1.29 y posteriores de Kubernetes usan Azure Managed Disks mediante ZRS (almacenamiento con redundancia de zona) para notificaciones de volumen persistente.

Estos discos se replican entre zonas, con el fin de mejorar la resistencia de las aplicaciones y protegen los datos frente a errores del centro de datos.

Ejemplo de una notificación de volumen persistente que usa SSD estándar en ZRS:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

En el caso de las implementaciones alineadas con zonas, puede crear una nueva clase de almacenamiento con el parámetro skuname establecido en LRS (almacenamiento con redundancia local). A continuación, puede usar la nueva clase de almacenamiento en la notificación de volumen persistente (PVC).

Aunque los discos LRS son menos costosos, no tienen redundancia de zona y no se admite la conexión de un disco a un nodo de una zona diferente.

Un ejemplo de una clase de almacenamiento SSD estándar de LRS:

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

Equilibradores de carga

Kubernetes implementa una instancia de Azure Standard Load Balancer de forma predeterminada, que equilibra el tráfico entrante en todas las zonas de una región. Si un nodo deja de estar disponible, el equilibrador de carga vuelve a enrutar el tráfico a nodos correctos.

Un servicio de ejemplo que usa Azure Load Balancer:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

Importante

El 30 de septiembre de 2025, se retirará Basic Load Balancer. Para obtener más información, consulte el anuncio oficial. Si actualmente usa Basic Load Balancer, asegúrese de actualizar a Standard Load Balancer antes de la fecha de retirada.

Limitaciones

Se aplican las siguientes limitaciones al usar zonas de disponibilidad:

Pasos siguientes