Leer en inglés

Compartir a través de


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

En este artículo, obtendrá información sobre las distintas consideraciones para la resistencia de zona en Azure Kubernetes Service (AKS), incluido cómo:

  • Hacer que la zona de componentes del clúster de AKS sea resistente
  • Diseñar una aplicación sin estado
  • Tomar la decisión del disco de almacenamiento
  • Probar la resistencia de zona de disponibilidad (AZ)

Información general

La resistencia de AZ 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.

Importante

Simplemente escalar o reducir verticalmente el número de nodos de un clúster no es suficiente para garantizar la resistencia de la aplicación. Debe comprender mejor la aplicación y sus dependencias para planificar mejor la resistencia. AKS permite configurar zonas de disponibilidad (AZ) para los clústeres y los grupos de nodos para asegurarse de que las aplicaciones son resistentes a los errores y pueden seguir atendiendo el tráfico incluso si una zona completa deja de funcionar.

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

Las siguientes secciones proporcionan orientación sobre los principales puntos de decisión para hacer que los componentes del clúster de AKS sean resistentes a la zona, pero no son exhaustivas. Debes tener en cuenta otros factores en función de tus requisitos y restricciones específicos y comprobar las demás dependencias para asegurarte de que están configurados para la resistencia de zona.

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

AKS permite seleccionar varias AZ durante la creación del clúster y del grupo de nodos. Al crear un clúster con varias AZ, el plano de control se distribuye entre las AZ seleccionadas. Los nodos del grupo de nodos también se distribuyen entre las AZ 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. Puedes configurar las AZ mediante Azure Portal, la CLI de Azure o plantillas de Azure Resource Manager.

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

Puedes usar restricciones de propagación de topología de pod en función de las etiquetas zone y hostname para distribuir pods entre AZ dentro de una región y entre nodos dentro de las AZ.

Por ejemplo, supongamos que tienes un clúster de cuatro nodos donde tres pods con etiqueta foo:bar se encuentran en node1, node2 y node3 respectivamente. Si deseas que un pod entrante se distribuya uniformemente con los pods existentes en las distintas zonas, puedes utilizar un manifiesto similar al del ejemplo siguiente:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Para obtener más información, consulta Restricciones de propagación de topología de pod.

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:

Importante

Con Azure NAT Gateway, puedes crear puertas de enlace NAT en AZ específicas o usar una implementación zonal para el aislamiento en zonas específicas. NAT Gateway admite implementaciones zonales, pero no implementaciones con redundancia de zona. Esto podría ser un problema si configuras un clúster de AKS con el tipo de salida igual a la puerta de enlace NAT y la puerta de enlace NAT está en una sola zona. En este caso, si la zona que hospeda la puerta de enlace NAT deja de funcionar, el clúster pierde la conectividad saliente. Para más información, consulte Puerta de enlace NAT y zonas de disponibilidad.

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.

Aprovechamiento de las 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. Cluster Autoscaler ajusta automáticamente el número de nodos de un grupo de nodos en función de las solicitudes de recursos de los pods que se ejecutan en los nodos. Si deseas usar ambos escaladores automáticos juntos, asegúrate de que los grupos de nodos con el escalador automático habilitado abarcan varias zonas. Si el grupo de nodos está en una sola zona y esa zona deja de funcionar, el escalador automático no puede escalar el clúster entre zonas.

La característica de versión preliminar del proveedor AKS Karpenter 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).

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, debes usar servicios administrados de Azure, como Azure Databases, Azure Cache for Redis o Azure Storage para almacenar los datos de aplicaciones. 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. Puedes usar implementaciones, servicios y sondeos de estado de Kubernetes 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:

Tipo de disco Ventajas Desventajas
LRS • Coste menor
• Compatible con todos los tamaños y regiones de disco
• Fácil de usar y aprovisionar
• Disponibilidad y durabilidad más bajas
• Vulnerable a errores zonales
• No admite la replicación geográfica ni de zona
ZRS • Disponibilidad y durabilidad más altas
• Más resistente a los errores zonales
• Admite la replicación de zona para la resistencia dentro de la región
• Mayor coste
• No es compatible con todos los tamaños de disco y regiones
• Requiere una configuración adicional para habilitar

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:

Ventajas Desventajas
• Imita un escenario de error realista y prueba el proceso de recuperación
• Permite comprobar la disponibilidad y durabilidad de los datos entre regiones.
• Le ayuda a identificar posibles problemas o cuellos de botella en la configuración del clúster o el diseño de la aplicación.
• Puede provocar interrupciones temporales o degradación del servicio para los usuarios
• Requiere intervención manual y coordinación para purgar y restaurar el nodo
• Podría incurrir en costes adicionales debido a un aumento del tráfico de red o la replicación de almacenamiento

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:

Ventajas Desventajas
• Proporciona una manera controlada y automatizada de insertar errores y supervisar los resultados
• Admite varios tipos de errores y escenarios, como latencia de red, estrés de CPU, error de disco, etc.
• Se integra con Azure Monitor y otras herramientas para recopilar y analizar datos
• Puede requerir una configuración adicional para crear y ejecutar experimentos
• Podría no cubrir todos los posibles modos de error y zonas perimetrales que podrían producirse durante una interrupción real
• Puede tener limitaciones o restricciones en el ámbito o duración de los experimentos

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

Pasos siguientes

Para obtener más detalles de implementación, consulte la Guía de clústeres y almacenamiento de AKS con redundancia de zona.