Confiabilidad en Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) es un servicio de orquestación de contenedores administrado que simplifica la implementación, la administración y las operaciones de Kubernetes.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure Kubernetes Service (AKS) sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones en regiones. También se describe cómo puede usar copias de seguridad para recuperarse de otros tipos de problemas y se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Kubernetes Service (AKS).

Recomendaciones de implementación de producción

Para obtener recomendaciones sobre cómo implementar cargas de trabajo de producción confiables en AKS, consulte los siguientes artículos:

• Procedimientos recomendados de implementación y confiabilidad de clústeres para AKS
• Descripción general de la alta disponibilidad (HA) y la recuperación ante desastres (DR) para AKS
• Consideraciones de resistencia de zona para AKS

Introducción a la arquitectura de confiabilidad

Al crear un clúster de AKS, la plataforma Azure crea y configura automáticamente:

• Un plano de control que tiene el servidor de API, etcd, el programador y otros pods necesarios para administrar la carga de trabajo.

• Un grupo de nodos del sistema a tu suscripción que hospeda los complementos y pods adicionales que se ejecutan en el espacio de nombres kube-system.

Una vez completada la configuración del grupo de nodos inicial, puede agregar o eliminar grupos de nodos para sus propias cargas de trabajo de usuario. AKS no administra grupos de nodos para la confiabilidad y debe asegurarse de que las cargas de trabajo son resistentes a los errores de infraestructura.

La resistencia es una responsabilidad compartida entre usted y Microsoft. Como servicio de cálculo, AKS administra algunos aspectos de la fiabilidad del clúster, pero usted es responsable de gestionar otros aspectos.

• Microsoft administra el plano de control y otros componentes administrados de AKS.

• Es su responsabilidad:

  • Defina cómo deben configurarse los componentes, incluidos los grupos de nodos y los equilibradores de carga que se conectan a los servicios, para satisfacer los requisitos de confiabilidad. Después de definir los componentes, Microsoft los implementa y administra en su nombre.

  • Administre los componentes fuera del clúster de AKS, incluido el almacenamiento y las bases de datos. Compruebe que estos componentes cumplen los requisitos de confiabilidad. Al implementar las cargas de trabajo, asegúrese de que otros componentes de Azure también están configurados para la resistencia siguiendo los procedimientos recomendados para esos servicios.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que sus aplicaciones puedan administrar errores transitorios, generalmente reintentando las solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Cuando utilizas AKS, pueden ocurrir fallos transitorios por varias razones, como fallos de aplicaciones, operaciones de escalado y balanceo de pods, actualización de nodos y fallos temporales en la infraestructura, como problemas de hardware o de redes.

Es imposible eliminar todos los errores transitorios, por lo que los clientes que acceden a las aplicaciones hospedadas en AKS deben estar preparados para reintentar las solicitudes con errores y seguir otras recomendaciones de control de errores transitorios. Puede minimizar la probabilidad de errores transitorios y evitar o mitigar el tiempo de inactividad que podrían provocar siguiendo los procedimientos recomendados de Kubernetes y Azure en la implementación.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Al implementar un clúster de AKS en una región que admita zonas de disponibilidad, los distintos componentes requieren distintos tipos de configuración.

El plano de control de AKS es resiliente a zonas por defecto. Si se produce un error en una zona, el plano de control no requiere ninguna configuración ni administración para lograr resistencia. Sin embargo, la resistencia del plano de control no es suficiente para que el clúster permanezca operativo cuando se produce un error en una zona. Para el grupo de nodos del sistema y los grupos de nodos de usuario que implemente, debe habilitar la compatibilidad con zonas de disponibilidad para ayudar a garantizar que las cargas de trabajo son resistentes a los errores de zona de disponibilidad.

Requisitos

Compatibilidad con regiones: Puede implementar clústeres de AKS resistentes a zonas en cualquier región que admita zonas de disponibilidad.

Consideraciones

Para mejorar la confiabilidad y la resistencia de las cargas de trabajo de producción de AKS en una región, debe configurar AKS para la redundancia de zona mediante la realización de las siguientes configuraciones:

• Implemente varias réplicas. Kubernetes distribuye los pods entre nodos en función de las etiquetas de nodo. Para distribuir la carga de trabajo entre zonas, debe implementar varias réplicas del pod. Por ejemplo, si configura el grupo de nodos con tres zonas pero solo implementa una única réplica de su pod, su implementación no es resiliente a las zonas.

• Habilite el escalado automático. Los grupos de nodos de Kubernetes proporcionan opciones de escalado manuales y automáticas. Con el escalado manual, puedes agregar o eliminar nodos según sea necesario y los pods pendientes esperan hasta que escales verticalmente un grupo de nodos. El escalado administrado por AKS usa el escalador automático del clúster o el aprovisionamiento automático de nodos (NAP). AKS aumenta o reduce el grupo de nodos según los requisitos del pod y teniendo en cuenta la cuota y capacidad de la SKU de tu suscripción. Este método ayuda a garantizar que los pods se programen en los nodos disponibles en las zonas de disponibilidad.

• Establece las restricciones de la topología del pod. Usa restricciones de propagación de topología de pods para controlar cómo se distribuyen los pods entre distintos nodos o zonas. Las restricciones le ayudan a lograr la alta disponibilidad, la resistencia y el uso eficaz de los recursos. Si prefieres propagar pods estrictamente entre zonas, puedes establecer restricciones para forzar un pod en un estado pendiente a fin de mantener el equilibrio de pods entre zonas. Para más información, consulta Restricciones de propagación de topología de pod.

• Configurar redes con resiliencia zonal. Si los pods sirven tráfico externo, configure la arquitectura de red del clúster mediante servicios como Azure Application Gateway, Azure Load Balancer o Azure Front Door.

• Asegúrese de que las dependencias son resistentes a la zona. La mayoría de las aplicaciones de AKS usan otros servicios para el almacenamiento, la seguridad o las redes. Asegúrese de revisar las recomendaciones de resistencia de zona para esos servicios.

Costos

No hay ningún cargo adicional para habilitar la compatibilidad con la zona de disponibilidad en AKS. Paga por las máquinas virtuales (VM) y otros recursos que implemente en las zonas de disponibilidad.

Configurar soporte de zonas de disponibilidad

• Cree un nuevo clúster de AKS que tenga compatibilidad con la zona de disponibilidad: Para configurar la compatibilidad con zonas de disponibilidad, consulte Creación de un clúster de Azure Kubernetes Service (AKS) que use zonas de disponibilidad.
• Migración: No se puede habilitar la compatibilidad con zonas de disponibilidad después de crear un clúster. En su lugar, debe crear un nuevo clúster que tenga habilitada la compatibilidad con la zona de disponibilidad y eliminar el clúster existente.
• Deshabilite la compatibilidad con zonas de disponibilidad: No se puede deshabilitar la compatibilidad con zonas de disponibilidad después de crear un clúster. En su lugar, debe crear un clúster nuevo que tenga compatibilidad con la zona de disponibilidad deshabilitada y eliminar el clúster existente.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando los clústeres de AKS están configurados para la compatibilidad con zonas de disponibilidad y todas las zonas de disponibilidad están operativas.

• Enrutamiento de tráfico entre zonas: Al implementar un clúster de AKS que usa zonas de disponibilidad, es importante asegurarse de que los componentes de red también son resistentes a la zona. Según los equilibradores de carga y otros componentes de red que use, es posible que tenga que configurar explícitamente los componentes para enrutar el tráfico a los nodos correctos de las zonas correctas y responder a interrupciones de zona. Para más información, consulte Consideraciones de resistencia de zona para AKS.

• Replicación de datos entre zonas: Si ejecuta una carga de trabajo sin estado, debe usar servicios administrados de Azure, como bases de datos de Azure, Azure Cache for Redis o Azure Storage para almacenar los datos de la aplicación. Puede usar estos servicios para ayudar a garantizar que el tráfico se pueda mover entre nodos y zonas sin riesgo de pérdida de datos ni que afecte 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.

  Si necesita almacenar el estado dentro del clúster mediante discos de Azure, use el almacenamiento con redundancia de zona de Azure para asegurarse de que los datos se replican en varias zonas de disponibilidad. Para obtener más información, consulte Elección del tipo de disco adecuado en función de las necesidades de la aplicación.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando se produce una interrupción de zona de disponibilidad mientras los clústeres de AKS están configurados con compatibilidad con zonas de disponibilidad.

• Detección y respuesta: cuando se produce una interrupción de zona, el plano de control conmuta automáticamente por error. Si los grupos de nodos usan zonas de disponibilidad y siguen losprocedimientos recomendados de resistencia de zona, puedes esperar que AKS abra nodos y réplicas en las zonas que están operativas. AKS realiza esta tarea automáticamente cuando se usan soluciones administradas como cluster autoscaler o NAP. Sin el escalado automático, los nodos y las réplicas permanecen en estado Pendiente y esperan a que la intervención manual escale verticalmente el grupo de nodos.

  AKS también intenta reequilibrar los pods en las zonas correctas. Si decides escalar manualmente el grupo de nodos en un escenario de reducción de zona, los pods pueden dejarse en el estado Pendiente cuando no haya nodos disponibles en las zonas correctas. El escalado horizontal en las zonas restantes también está sujeto a la disponibilidad de la cuota y la capacidad de la SKU de máquina virtual que uses.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

  También puede usar las métricas de estado del nodo o pod para supervisar el estado de los nodos y pods.

• Solicitudes activas: Las solicitudes activas pueden experimentar interrupciones. Algunas solicitudes pueden fallar, y la latencia podría aumentar mientras la carga de trabajo se transfiere a otra zona.

• Pérdida de datos esperada: Si almacena el estado dentro del clúster mediante discos de Azure y usa almacenamiento con redundancia de zona, no se espera que un error de zona cause ninguna pérdida de datos.

• Tiempo de inactividad esperado: Si configura correctamente la resistencia de zona para el clúster y los pods, no se espera que un error de zona cause tiempo de inactividad para la carga de trabajo de AKS.

• Redireccionamiento del tráfico: los equilibradores de carga redirigen las nuevas solicitudes entrantes a pods que se ejecutan en nodos saludables.

Para más información, consulte Consideraciones de resistencia de zona para AKS.

Recuperación de zona

Cuando se recupera la zona de disponibilidad, el comportamiento de la conmutación por recuperación depende del componente:

• Plano de control: AKS restaura automáticamente las operaciones del plano de control en todas las zonas de disponibilidad. No se requiere intervención manual.

• Grupos de nodos y nodos: inmediatamente después de la conmutación por recuperación, los nodos permanecen en las zonas previamente correctas y no se restauran en la zona recuperada. Pero la próxima vez que se realice una operación de escalado de nodos, como al escalar horizontalmente el grupo de nodos, el grupo de nodos puede crear nodos en la zona recuperada.

• Pods: inmediatamente después de la conmutación por recuperación, los pods siguen ejecutándose en los nodos en los que se están ejecutando. Cuando se crean nuevos pods o se vuelven a crear los pods existentes, son aptos para usar nodos en la zona recuperada.

• Almacenamiento: cualquier almacenamiento conectado a pods se recupera en función de cómo funciona el almacenamiento con redundancia de zona.

Prueba de fallos de zona

Puede probar la resistencia a los errores de zona de disponibilidad mediante los métodos siguientes:

• Aislar y drenar nodos en una única zona de disponibilidad
• Simulación de un error de zona de disponibilidad mediante Azure Chaos Studio

Resistencia a errores en toda la región

Los clústeres de AKS son recursos de una sola región. Si la región no está disponible, el clúster de AKS tampoco está disponible.

Soluciones personalizadas de varias regiones para la resistencia

Si necesita implementar la carga de trabajo de Kubernetes en varias regiones de Azure, tiene dos opciones para administrar la orquestación de estos clústeres.

• Use Fleet Manager de Azure Kubernetes si desea una experiencia administrada más sencilla. Con Fleet Manager de Azure Kubernetes, puede hacer lo siguiente:

  • Administre un conjunto de clústeres de AKS como una sola unidad y esos clústeres se pueden distribuir entre varias regiones de Azure.

  • Automatice aspectos específicos de la administración de clústeres, como las actualizaciones de imágenes de clúster y nodo.

  • Utilice las capacidades de distribución de tráfico para repartir el tráfico entre los clústeres y realizar una conmutación automática si una región no está disponible.

• Organice la conmutación por error mediante un modelo de implementación activo-activo o activo-pasivo manual si la carga de trabajo requiere un control más matizado sobre los distintos componentes de las conmutaciones por error interregionales. Para obtener más información, consulte Información general sobre alta disponibilidad y recuperación ante desastres para AKS.

Copias de seguridad y restauración

Azure Backup tiene una extensión que puede usar para realizar copias de seguridad de los recursos del clúster de AKS y volúmenes persistentes que se conectan al clúster. El almacén de Backup se comunica con el clúster de AKS a través de la extensión para realizar operaciones de copia de seguridad y restauración.

Si el clúster de AKS está en una región emparejada, puede configurar las copias de seguridad que se almacenarán en el almacenamiento con redundancia geográfica. Puede restaurar copias de seguridad georedundantes en la región emparejada.

Para obtener más información, consulte los artículos siguientes:

• ¿Qué es la copia de seguridad de Azure Kubernetes Service?
• Copia de seguridad de AKS mediante Azure Backup

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

Intente usar clústeres sin estado que minimicen la necesidad de copia de seguridad. Almacene datos en bases de datos y sistemas de almacenamiento externos en lugar de en el clúster.

Resistencia al mantenimiento del servicio

AKS realiza el mantenimiento en el clúster, incluidas las actualizaciones del clúster y las imágenes de nodo. Para asegurarse de que Kubernetes mantiene el número mínimo de instancias de pod necesarias para atender el tráfico de producción incluso durante las actualizaciones, debe configurar los pods para que usen presupuestos de interrupciones del pod.

Para reducir las interrupciones del servicio durante períodos de tiempo críticos, AKS proporciona controles para que pueda especificar los tiempos de mantenimiento planeados. Para más información, consulte Uso del mantenimiento planeado para programar y controlar las actualizaciones del clúster de Azure Kubernetes Service.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

AKS proporciona tres planes de tarifa para la administración de clústeres: Gratis, Estándar y Premium. El nivel Gratis permite usar AKS para probar las cargas de trabajo. Los niveles Estándar y Premium están diseñados para cargas de trabajo de producción. Al implementar un clúster de AKS con zonas de disponibilidad habilitadas, aumenta el porcentaje de tiempo de actividad definido en el Acuerdo de Nivel de Servicio. Sin embargo, el Acuerdo de Nivel de Servicio solo se aplica si implementa un clúster en el plan de tarifa Estándar o Premium.

Contenido relacionado

• Confiabilidad en Azure