Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Comprenda el desalojo de los pods durante las interrupciones zonales
Cuando se produce una interrupción total de la zona de disponibilidad (es decir, cuando todos los nodos de esa zona de disponibilidad pierden la conectividad con el plano de control de Kubernetes), el controlador del ciclo de vida de los nodos de Kubernetes detecta la situaciónTerminating y se programan nuevos pods para los nodos en buen estado. Durante este período, los nodos afectados muestran un NotReady estado, el planificador impide que se coloquen nuevos módulos en esos nodos y el EndpointSlice controlador elimina del enrutamiento del servicio los puntos finales que están asociados a la zona de disponibilidad dañada hasta que se restablezca la conectividad.
En los casos en los que se producen fallos parciales en los nodos de una zona (en los que solo queda inalcanzable un subconjunto de nodos), el controlador del ciclo de vida de los nodos aplica un comportamiento de desalojo diferente. Si la interrupción persiste más allá del período de tolerancia configurado (de forma predeterminada, cinco minutos), los módulos de los nodos desconectados se marcan como Terminating y se programan nuevos módulos en los nodos en buen estado de las zonas de disponibilidad disponibles.
Implementación del cambio zonal de Amazon EKS para mejorar la resiliencia
El cambio zonal de Amazon EKS, que se integra con Amazon Application Recovery Controller (ARC), proporciona un mecanismo para gestionar el tráfico de forma proactiva durante las alteraciones de la zona de disponibilidad. Esta capacidad permite redirigir temporalmente el tráfico de red desde una zona de disponibilidad en mal estado hacia zonas en buen estado dentro de la misma, Región de AWS a fin de minimizar las interrupciones del servicio.
Comprender el mecanismo de cambio zonal
El cambio zonal de Amazon EKS aborda el tráfico este-oeste (comunicación entre módulos dentro del clúster). Cuando el cambio zonal se configura con balanceadores de carga de aplicaciones o balanceadores de carga de red, también es compatible con el enrutamiento del tráfico de entrada. El mecanismo funciona mediante la coordinación de varios componentes de Kubernetes y del plano de AWS control para redirigir el tráfico de forma segura sin interrumpir las cargas de trabajo en ejecución. Durante un cambio zonal activo, Amazon EKS realiza automáticamente las siguientes acciones coordinadas:
-
Acordonamiento de nodos: todos los nodos de la zona de disponibilidad afectada están acordonados. Esto evita que el programador de Kubernetes coloque nuevos módulos en los nodos mientras mantiene las cargas de trabajo existentes.
-
Suspensión del reequilibrio de la zona de disponibilidad: en el caso de los grupos de nodos gestionados, las operaciones de reequilibrio de la zona de disponibilidad se suspenden y los grupos de Auto Scaling se actualizan para lanzar nuevos nodos del plano de datos exclusivamente en zonas de disponibilidad en buen estado. Esto garantiza que no se aprovisione nueva capacidad en la zona afectada.
-
Eliminación de los puntos finales: el EndpointSlice controlador elimina los puntos finales del módulo situados en la zona de disponibilidad dañada de todos los puntos de conexión relevantes. EndpointSlices Esto garantiza que los mecanismos de descubrimiento de servicios y equilibrio de carga dirijan el tráfico únicamente a los pods que se ejecutan en zonas de disponibilidad en buen estado.
-
Preservación de la carga de trabajo: Amazon EKS se abstiene de cerrar los nodos o desalojar los pods de la zona de disponibilidad afectada. Mantiene toda la capacidad en la zona afectada para que, cuando el cambio zonal caduque o se cancele, el tráfico pueda regresar de forma segura sin necesidad de operaciones de escalado adicionales.
Métodos de activación por turnos zonales
Puede elegir entre dos enfoques para iniciar los cambios zonales, según su modelo operativo:
-
El cambio zonal manual proporciona un control controlado por el operador cuando se detectan problemas específicos en las zonas de disponibilidad mediante la supervisión, las alertas o los informes de los clientes. Este método requiere una acción explícita a través de la consola ARC, AWS Command Line Interface (AWS CLI) o un cambio APIs zonal, en el que los operadores especifican la zona de disponibilidad afectada y definen una hora de caducidad para el turno. Los cambios manuales son adecuados cuando los equipos cuentan con capacidades específicas de monitoreo y de guardia y prefieren mantener un control directo sobre las decisiones de gestión del tráfico.
-
El cambio automático zonal autoriza AWS a iniciar automáticamente los turnos cuando ARC detecta posibles fallos o deficiencias en las zonas de disponibilidad en función de la telemetría interna y las señales de estado en varias zonas, Servicios de AWS incluidas las métricas de red, Amazon Elastic Compute Cloud (Amazon EC2) y Elastic Load Balancing. AWS finaliza automáticamente un cambio automático cuando los indicadores muestran que el problema se ha resuelto. Si desea obtener la máxima disponibilidad con una intervención manual mínima, le recomendamos este enfoque, ya que permite responder en menos de un minuto a las deficiencias detectadas en la zona de disponibilidad.
Requisitos previos para un cambio zonal efectivo
Para que el cambio zonal proteja correctamente las aplicaciones durante las interrupciones de las zonas de disponibilidad, debe diseñar sus clústeres para que sean resilientes en zonas de disponibilidad múltiples antes de activar la función de cambio zonal:
-
Distribución de nodos en zonas de disponibilidad múltiples: aprovisione los nodos de trabajo en al menos tres zonas de disponibilidad para garantizar una redundancia suficiente cuando una zona deje de estar disponible.
-
Planificación de la capacidad: aprovisione previamente suficiente capacidad de cómputo en las zonas de disponibilidad en buen estado para dar cabida a toda la carga de trabajo cuando una zona de disponibilidad quede fuera del servicio, ya que si se escalan las operaciones durante una interrupción activa, es posible que la capacidad no sea suficiente.
-
Distribución de pods y preescalado: Implemente múltiples réplicas de cada aplicación en todas las zonas de disponibilidad y escale previamente los componentes críticos del sistema, como CoreDNS, en cada zona. Esto ayuda a garantizar que quede suficiente capacidad después de que una zona se haya desplazado.
Recomendaciones para la resiliencia a las disrupciones zonales
-
Habilite el cambio zonal al crear el clúster: en el caso de los nuevos clústeres de EKS, habilite la integración del cambio zonal con ARC durante el aprovisionamiento inicial a través de la consola Amazon EKS o de herramientas de infraestructura como código (iAC) AWS CLI, como. AWS CloudFormationLos clústeres del modo automático de EKS que se crean con una configuración rápida tienen activado el cambio zonal de forma predeterminada.
-
Seleccione el método de activación adecuado: elija el cambio automático zonal para los entornos de producción que requieren la máxima disponibilidad con una respuesta automática, especialmente para las aplicaciones orientadas al cliente, en las que los minutos de inactividad durante una zona de disponibilidad reducida pueden tener un impacto empresarial significativo. Utilice el cambio zonal manual en entornos en los que los equipos de operaciones prefieran dar su aprobación explícita antes de los cambios de tráfico o en los que las aplicaciones aún estén en curso de prueba y validación.
-
Pruebe la resiliencia antes del despliegue de producción: valide el comportamiento del clúster en caso de pérdida en una única zona de disponibilidad iniciando manualmente los turnos zonales de prueba o habilitando la práctica de cambio automático zonal para comprobar que las aplicaciones mantienen la disponibilidad, el rendimiento sigue siendo aceptable y la capacidad es suficiente cuando funcionan con un número reducido de zonas de disponibilidad. Recomendamos encarecidamente realizar estas pruebas para poder identificar las brechas de configuración antes de que se produzcan alteraciones reales en la zona de disponibilidad.
-
Coordine con la configuración del balanceador de carga: en el caso de las aplicaciones que reciben tráfico externo, habilite el cambio zonal ARC en los balanceadores de carga de aplicaciones y en los balanceadores de carga de red asociados para garantizar que tanto el tráfico de entrada como el tráfico del clúster de este a oeste se desplacen al mismo tiempo cuando la zona de disponibilidad se deteriora. Esta coordinación evita situaciones en las que las solicitudes externas lleguen a los módulos en buen estado, pero estos no puedan comunicarse con las dependencias de la zona apartada.
-
Supervise las operaciones de turno: después de activar el cambio zonal, configure la supervisión y las alertas de los eventos de turno, incluidas las activaciones de los turnos automáticos, los inicios de los turnos manuales y los vencimientos de los turnos, a fin de mantener la visibilidad operativa de las acciones de gestión del tráfico y su impacto en el comportamiento de las aplicaciones.
Finalización y recuperación de los turnos
Cuando un turno zonal caduca en función de la duración configurada o se cancela manualmente una vez que se resuelve el deterioro de la zona de disponibilidad, el EndpointSlice controlador actualiza automáticamente todo EndpointSlices para volver a incorporar los puntos finales a la zona de disponibilidad restaurada. El tráfico regresa gradualmente a la zona afectada anteriormente a medida que los clientes actualizan la información de los puntos finales y establecen nuevas conexiones. Esto permite utilizar toda la capacidad del clúster sin necesidad de intervención manual ni reprogramar los módulos.
