Recomendaciones de resistencia de zona para Azure Kubernetes Service (AKS)

Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard

La resistencia de zona es una parte clave de la ejecución de clústeres de Kubernetes de nivel de producción. Con la escalabilidad en su núcleo, Kubernetes aprovecha al máximo la infraestructura independiente en los centros de datos sin incurrir en costes adicionales mediante el aprovisionamiento de nuevos nodos solo cuando sea necesario.

En este artículo, obtendrá recomendaciones sobre la resiliencia zonal en AKS, incluido cómo:

• Haga que la zona de componentes del clúster de AKS sea resistente.
• Diseñar aplicaciones sin estado para escenarios de fallo de zona.
• Elija las opciones de redundancia de almacenamiento.
• Pruebe el comportamiento de la aplicación y la plataforma durante los errores zonales.

Modos de clúster de AKS y resistencia de zona

AKS admite dos modos de clúster:

• AKS Automatic, que proporciona más configuraciones predeterminadas de la plataforma preconfiguradas.
• AKS Standard, que proporciona un control de operador directo más amplio.

Los principios de resistencia de zona de este artículo se aplican a ambos modos de clúster. La diferencia clave es la propiedad de las operaciones de plataforma.

Para ver el comportamiento de todas las características según el modo, consulte la comparación de características entre AKS Automatic y AKS Standard.

Hacer que la zona de componentes del clúster de AKS sea resistente

En las secciones siguientes se describen los puntos de decisión clave para la resistencia de zona en AKS. No son exhaustivas. También debe validar la resistencia de zona para dependencias como almacenes de datos, sistemas de identidad y servicios externos.

Creación de clústeres con redundancia de zona y grupos de nodos

AKS le permite seleccionar varias AZ durante la creación del clúster y del grupo de nodos. En las regiones que admiten varias AZ, el plano de control se distribuye automáticamente entre zonas. Los nodos del grupo de nodos se distribuyen entre las zonas seleccionadas. Este enfoque garantiza que el plano de control y los nodos se distribuyan entre varias AZ, lo que proporciona resistencia en caso de error de AZ.

Guía del modo de clúster:

• AKS Automatic: muchos valores predeterminados de la plataforma están preconfigurados. Aun así, debe validar que las cargas de trabajo críticas para el negocio estén distribuidas deliberadamente entre zonas y que el comportamiento ante fallos cumpla los requisitos.
• AKS Estándar: diseñe explícitamente la topología del grupo de nodos, la configuración de escalado y el comportamiento de dominio de error.

En el ejemplo siguiente se muestra cómo crear un clúster con tres nodos distribuidos entre tres AZ mediante la CLI de Azure:

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

Una vez creado el clúster, puedes usar el siguiente comando para recuperar la región y la zona de disponibilidad de cada nodo del agente de las etiquetas:

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

El siguiente ejemplo muestra la región y la zona de disponibilidad de cada nodo agente:

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

Para más información, consulta Uso de zonas de disponibilidad en Azure Kubernetes Service (AKS).

Asegúrate de que los pods se distribuyen entre varias AZ

La estrategia de ubicación de pods es una consideración a nivel de carga de trabajo tanto en AKS Automatic como en AKS Standard. Los valores predeterminados de la plataforma no reemplazan los requisitos de topología de nivel de carga de trabajo.

A partir de la versión 1.33 de Kubernetes, el Kube-Scheduler predeterminado en AKS está configurado para usar un MaxSkew valor de 1 para topology.kubernetes.io/zone:

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

Esta configuración está pensada para que no haya más de un pod de diferencia entre zonas, lo que reduce la probabilidad de que un fallo de zona provoque una interrupción del despliegue.

Si su despliegue tiene necesidades topológicas específicas, anule estos valores predeterminados en la especificación del pod. Puede usar restricciones de dispersión de topología de pods basadas en las etiquetas zone y hostname para distribuir los pods entre zonas de disponibilidad (AZ) dentro de una región y entre hosts dentro de las AZ.

Por ejemplo, supongamos que tienes un clúster de cuatro nodos donde tres pods con etiqueta app: mypod-app se encuentran en node1, node2 y node3 respectivamente. Si desea que la implementación entrante se hospede en nodos distintos tanto como sea posible, puede usar un manifiesto similar al ejemplo siguiente:

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

Para obtener más información sobre cómo configurar la distribución de pods y comprender las implicaciones de MaxSkew, consulte la documentación de Topología de Pod de Kubernetes. Por ejemplo, cómo nodeTaintsPolicy: Honor afecta a la distribución de pods.

Configuración de redes compatibles con AZ

Si tienes pods que atienden el tráfico de red, debes equilibrar la carga del tráfico entre varias AZ para asegurarte de que la aplicación tiene alta disponibilidad y es resistente a errores. Puedes usar Azure Load Balancer para distribuir el tráfico entrante entre los nodos del clúster de AKS.

Azure Load Balancer admite el equilibrio de carga interna y externa, y puedes configurarlo para usar una SKU estándar para el equilibrio de carga con redundancia de zona. La SKU estándar es la SKU predeterminada en AKS y admite la resistencia regional con zonas de disponibilidad para asegurarse de que la aplicación no se ve afectada por un error de región. En caso de un escenario de error de zona, un equilibrador de carga de SKU estándar con redundancia de zona no se ve afectado por el error y permite que las implementaciones sigan sirviendo tráfico desde las zonas restantes. Puedes usar un equilibrador de carga global, como Front Door o Traffic Manager, o puedes usar equilibradores de carga entre regiones delante de los clústeres de AKS regionales para asegurarte de que la aplicación no se ve afectada por errores regionales. Para crear un equilibrador de carga de SKU estándar en AKS, consulta Uso de un equilibrador de carga estándar en Azure Kubernetes Service (AKS).

Para asegurarte de que el tráfico de red de la aplicación es resistente a los errores, debes configurar redes compatibles con la AZ para las cargas de trabajo de AKS. Azure ofrece varios servicios de red que admiten varias AZ:

• Azure VPN Gateway: puede implementar puertas de enlace VPN y ExpressRoute en AZ de Azure para permitir una mejor resistencia, escalabilidad y disponibilidad en las puertas de enlace de red virtual. Para más información, consulta Crear una puerta de enlace de red virtual con redundancia de zona en zonas de disponibilidad.
• Azure Application Gateway v2: Azure Application Gateway proporciona un equilibrador de carga L7 regional con compatibilidad con la zona de disponibilidad. Para más información, consulta Tráfico web directo con Azure Application Gateway.
• Azure Front Door: Azure Front Door proporciona un equilibrador de carga L7 global y aprovecha puntos de presencia (POP) o Azure Content Delivery Network (CDN). Para más información, consulta Ubicaciones de POP de Azure Front Door.

Configuración de un registro de contenedor con redundancia de zona y replicación geográfica

Para asegurarte de que las imágenes de contenedor son de alta disponibilidad y resistentes a errores, debes configurar un registro de contenedor con redundancia de zona. La SKU Premium de Azure Container Registry (ACR) admite la replicación geográfica y la redundancia de zona opcional. Estas características proporcionan disponibilidad y reducen la latencia de las operaciones regionales.

Garantizar la disponibilidad y la redundancia de las claves y los secretos

Azure Key Vault incluye varias capas de redundancia para asegurarse de que las claves y los secretos permanecen disponibles para la aplicación, incluso si se produce un error en los componentes individuales del servicio o si las regiones de Azure o las zonas de disponibilidad no están disponibles. Para más información, consulte Redundancia y disponibilidad de Azure Key Vault.

Uso de características de escalado automático

Puedes mejorar la disponibilidad y la resistencia de las aplicaciones en AKS mediante características de escalado automático, lo que te ayudará a lograr los siguientes objetivos:

• Optimiza el uso de los recursos y la eficiencia de los costes mediante el escalado o reducción vertical en función del uso de CPU y memoria de los pods.
• Mejora la tolerancia a errores y la recuperación agregando más nodos o pods cuando se produce un error de zona.

Puedes usar Horizontal Pod Autoscaler (HPA) y Cluster Autoscaler para implementar el escalado automático en AKS. HPA escala automáticamente el número de pods de una implementación en función del uso observado de la CPU, el uso de la memoria, las métricas personalizadas y las métricas de otros servicios. El escalador automático de clústers ajusta automáticamente el número de nodos en un conjunto de nodos en función de los pods pendientes y las solicitudes de recursos de los pods pendientes.

Guía del modo de clúster:

• AKS Automatic: Concéntrese en las solicitudes y los límites de recursos de las cargas de trabajo, las directivas de distribución de pods y los controles de disrupción para que el escalado preconfigurado de la plataforma pueda restablecer el servicio en situaciones de tensión zonal.
• AKS Estándar: diseñe explícitamente los límites del grupo de nodos, la directiva de escalado y la configuración del escalador automático para alinearse con las restricciones de programación con reconocimiento de zona.

La característica Proveedor de Karpenter de AKS habilita el aprovisionamiento automático de nodos mediante Karpenter en el clúster de AKS. Para obtener más información, consulte la información general sobre la característica de proveedor AKS Karpenter.

El complemento escalado automático controlado por eventos de Kubernetes para AKS aplica el escalado automático controlado por eventos para escalar la aplicación en función de las métricas de servicios externos para satisfacer la demanda. Para más información, consulta Instalación del complemento KEDA en Azure Kubernetes Service (AKS).

Estrategia de escalado de zona mediante el modo de clúster de AKS

Para el comportamiento de escalado vertical con reconocimiento de zona, alinee el modelo de grupo de nodos con las restricciones del planificador y el modo de clúster.

AKS Standard

Al usar Cluster Autoscaler con zonas de disponibilidad, un procedimiento recomendado común es un grupo de nodos por zona. Puede establecer --balance-similar-node-groups en True para mantener la distribución equilibrada de nodos entre zonas durante el escalado vertical.

Por qué esto importa:

• Cluster Autoscaler simula la programación por grupo de nodos, no por ubicación de zona específica.
• En un grupo de nodos de varias zonas, el escalado vertical puede colocar un nuevo nodo en una zona que sigue infringiendo restricciones estrictas de propagación de topología, dejando pendientes los pods.
• Virtual Machine Scale Sets utiliza el equilibrio entre zonas de mejor esfuerzo. Durante las restricciones de capacidad de zona o eventos de zona descendente, la asignación puede producir un error y colocar el grupo de nodos en retroceso.
• El uso de un grupo de nodos por zona mejora el control del comportamiento de escalado específico de la zona.

Cluster Autoscaler no tiene en cuenta las zonas, y la asignación por zonas la gestionan los conjuntos de escalado de máquinas virtuales subyacentes, no AKS. Esta práctica recomendada se vuelve aún más relevante al usar restricciones de distribución de topología de pods basadas en zonas en un único grupo de nodos multizona, ya que unas restricciones demasiado estrictas pueden dejar los pods en estado pendiente, especialmente en regiones con limitaciones de capacidad o durante escenarios de caída de una zona.

AKS Automatic

AKS Automatic usa el comportamiento de nodo administrado preconfigurado y los valores predeterminados de aprovisionamiento automático de nodos. No se puede suponer que las cargas de trabajo críticas sean resistentes entre zonas sin una directiva a nivel de carga de trabajo.

Para los servicios críticos, valide:

• Comportamiento de propagación de topología de pod entre zonas.
• Comportamiento de recuperación durante la presión zonal.
• Programar resultados cuando se usan restricciones estrictas.
• Comportamiento de la aplicación cuando una zona deja de estar disponible.

Diseñar una aplicación sin estado

Cuando una aplicación no tiene estado, la lógica de la aplicación y los datos se desacoplan y los pods no almacenan datos persistentes o de sesión en sus discos locales. Este diseño permite que la aplicación se escale o reduzca verticalmente fácilmente sin preocuparse por la pérdida de datos. Las aplicaciones sin estado son más resistentes a los errores porque se pueden reemplazar o reprogramar fácilmente en un nodo diferente en caso de error de nodo.

Al diseñar una aplicación sin estado con AKS, debe usar servicios administrados de Azure, como Azure Databases, Azure Managed Redis o Azure Storage para almacenar los datos de la aplicación. El uso de estos servicios garantiza que el tráfico se pueda mover entre nodos y zonas sin arriesgarse a perder datos ni afectar a la experiencia del usuario. Puede usar kubernetes Implementaciones, Servicios, y Sondeos de estado para administrar pods sin estado y garantizar la distribución uniforme entre zonas.

Tomar la decisión del disco de almacenamiento

Elige el tipo de disco adecuado en función de las necesidades de la aplicación

Azure ofrece dos tipos de discos para el almacenamiento persistente: almacenamiento con redundancia local (LRS) y almacenamiento con redundancia de zona (ZRS). LRS replica los datos dentro de una única AZ. ZRS replica los datos en varias AZ dentro de una región. A partir de la versión 1.29 de AKS, la clase de almacenamiento predeterminada usa discos ZRS para el almacenamiento persistente. Para más información, consulta Clases de almacenamiento integradas de AKS.

La forma en que la aplicación replica los datos puede influir en la elección del disco. Si la aplicación se encuentra en varias zonas y replica los datos desde dentro de la aplicación, se puede lograr resistencia con un disco LRS en cada AZ porque, si una AZ deja de funcionar, las otras AZ tendrían disponibles los datos más recientes. Si la capa de aplicación no controla dicha replicación, los discos ZRS son una mejor opción, ya que Azure controla la replicación en la capa de almacenamiento.

En la tabla siguiente se describen las ventajas y desventajas de cada tipo de disco:

Para obtener más información sobre los tipos de disco LRS y ZRS, consulte Redundancia de Azure Storage. Para aprovisionar discos de almacenamiento en AKS, consulte Aprovisionamiento de almacenamiento de Azure Disks en Azure Kubernetes Service (AKS).

Supervisar el rendimiento del disco

Para garantizar el rendimiento y la disponibilidad óptimos de los discos de almacenamiento en AKS, debe supervisar las métricas clave, como IOPS, rendimiento y latencia. Estas métricas pueden ayudarle a identificar cualquier problema o cuellos de botella que puedan afectar al rendimiento de la aplicación. Si observa algún problema de rendimiento coherente, es posible que quiera reconsiderar el tamaño o el tipo de disco de almacenamiento. Puede usar Azure Monitor para recopilar y visualizar estas métricas y configurar alertas para notificarle cualquier problema de rendimiento.

Para más información, consulte Supervisión de Azure Kubernetes Service (AKS) con Azure Monitor.

Prueba de resistencia de AZ

Método 1: Acordonar y purgar nodos en una sola AZ

Una manera de probar el clúster de AKS para la resistencia de AZ es purgar un nodo en una zona y ver cómo afecta al tráfico hasta que se conmuta por error a otra zona. Este método simula un escenario real en el que una zona completa no está disponible debido a un desastre o interrupción. Para probar este escenario, puede usar el comando kubectl drain para expulsar correctamente todos los pods de un nodo y marcarlos como no programados. Después, puede supervisar el tráfico del clúster y el rendimiento mediante herramientas como Azure Monitor o Prometheus.

En la tabla siguiente se describen las ventajas y desventajas de este método:

Método 2: Simulación de un error de AZ mediante Azure Chaos Studio

Otra manera de probar el clúster de AKS para la resistencia de AZ es insertar errores en el clúster y observar el impacto en la aplicación mediante Azure Chaos Studio. Azure Chaos Studio es un servicio que permite crear y administrar experimentos de caos en recursos y servicios de Azure. Puede usar Chaos Studio para simular un error de AZ mediante la creación de un experimento de inserción de errores que tenga como destino una zona específica y detenga o reinicie las máquinas virtuales (VM) en esa zona. Después, puede medir la disponibilidad, la latencia y la tasa de errores de la aplicación mediante métricas y registros.

En la tabla siguiente se describen las ventajas y desventajas de este método:

Para más información, consulte ¿Qué es Inteligencia artificial de Azure Chaos Studio?.

Contenido relacionado

• ¿Qué es AKS Automatic?
• Guía para clústeres de AKS con redundancia de zona y almacenamiento