Kubernetes tiene funciones nativas que le permiten que sus aplicaciones sean más resistentes a eventos como el deterioro del estado o el deterioro de una zona de disponibilidad (AZ). Al ejecutar sus cargas de trabajo en un clúster de Amazon EKS, puede mejorar aún más la tolerancia a errores del entorno y la recuperación de aplicaciones mediante el cambio de zona o cambio de zona automático de Amazon Application Recovery Controller (ARC). El cambio de zona de ARC está diseñado como una medida temporal que permite alejar el tráfico de un recurso de una AZ deteriorada hasta que el cambio de zona caduque o se cancele. Si es necesario, puede extender el cambio de zona.
Puede iniciar un cambio de zona para un clúster EKS, o puede permitir que AWS lo haga por usted activando el cambio de zona automático. Este cambio actualiza el flujo del tráfico de red de este a oeste en su clúster para tener en cuenta únicamente los puntos de conexión de red de los pods que se ejecutan en nodos de trabajo en AZ en buen estado. Además, cualquier ALB o NLB que administre la entrada del tráfico de las aplicaciones de su clúster de EKS enrutará de forma automática el tráfico a los destinos de las AZ en buen estado. Para aquellos clientes que buscan los objetivos de disponibilidad más altos, en caso de que una AZ se estropee, puede ser importante poder desviar todo el tráfico de la AZ afectada hasta que se recupere. Para esto, también puede activar un ALB o un NLB con el cambio de zona de ARC.
Comprensión del flujo de tráfico de red este a oeste entre los pods
El siguiente diagrama ilustra dos ejemplos de cargas de trabajo, Pedidos y Productos. El propósito de este ejemplo es mostrar cómo se comunican las cargas de trabajo y los pods en diferentes AZ.
-
Para que Pedidos se comunique con Productos, primero se debe resolver el nombre DNS del servicio de destino. Pedidos se comunicará con CoredNS para obtener la dirección IP virtual (IP del clúster) de ese servicio. Una vez que Pedidos resuelve el nombre del servicio de Productos, envía el tráfico a esa IP de destino.
-
El kube-proxy se ejecuta en todos los nodos del clúster y supervisa de manera continua los EndpointSlices
en busca de servicios. Cuando se crea un servicio, el controlador EndpointSlice crea y administra un EndpointSlice en segundo plano. Cada EndpointSlice tiene una lista o tabla de puntos de conexión que contiene un subconjunto de direcciones de pods junto con los nodos en los que se ejecutan. El kube-proxy establece reglas de enrutamiento para cada uno de estos puntos de conexión de los pods mediante el uso de iptables
en los nodos. El kube-proxy también es responsable de una forma básica de equilibrio de carga, ya que redirige el tráfico destinado a la IP del clúster de un servicio para que, en su lugar, se envíe directamente a la dirección IP del pod. Para hacer esto, el kube-proxy reescribe la IP de destino en la conexión saliente. -
Luego, los paquetes de red se envían al pod Productos de la AZ 2 a través de los ENI de los nodos respectivos (como se muestra en el diagrama anterior).
Comprender el cambio de zona de ARC en EKS
En el caso de que haya una alteración de la AZ en su entorno, puede iniciar un cambio de zona para su entorno de clústeres de EKS. Como alternativa, puede permitir que AWS gestione esto por usted con el cambio de zona automático. Con el cambio de zona automático, AWS supervisará el estado general de la AZ y responderá a una posible alteración de esta, desplazando el tráfico de la AZ dañada de su entorno de clúster, de manera automática.
Cuando se haya activado el cambio de zona del clúster de Amazon EKS con ARC, puede gestionar los cambios de zona o los cambios de zona automáticos mediante la consola ARC, la AWS CLI o las API de cambio de zona y cambio de zona automático. Durante un cambio de zona en el EKS, automáticamente ocurrirá lo siguiente:
-
Se acordonarán todos los nodos de la AZ afectada. Esto evitará que el programador de Kubernetes programe nuevos pods en los nodos de la AZ en mal estado.
-
Si utiliza grupos de nodos administrados, se suspenderá el reequilibrio de la zona de disponibilidad y se actualizará su Grupo de escalado automático (ASG) para garantizar que los nuevos nodos del plano de datos de EKS solo se lancen en las zonas de disponibilidad en buen estado.
-
Los nodos de la AZ en mal estado no se cerrarán y los pods no se desalojarán de estos nodos. Esto es para garantizar que, cuando un cambio de zona caduque o se cancele, el tráfico pueda devolverse de forma segura a la AZ que aún tiene capacidad plena.
-
El controlador EndpointSlice encontrará todos los puntos de conexión del pod en la AZ defectuosa y los eliminará de los EndpointSlices correspondientes. Esto garantizará que solo los puntos de conexión de pods situados en zonas de disponibilidad en buen estado estén destinados a recibir tráfico de red. Cuando un cambio de zona caduca o se cancela, el controlador EndpointSlice actualizará los EndpointSlices para incluir los puntos de conexión de la AZ restaurada.
Los diagramas a continuación muestran un flujo de alto nivel de cómo el cambio de zona de EKS garantiza que en el entorno de clústeres solo se tomen como objetivo los puntos de conexión de pod en buen estado.
Requisitos del cambio zona de EKS
Para que el cambio de zona funcione de manera correcta en EKS, debe configurar previamente su entorno de clúster para que sea resistente a un deterioro de la AZ. A continuación, se muestra una lista de los pasos que debe seguir.
-
Aprovisione los nodos de trabajo de su clúster en varias zonas de disponibilidad.
-
Aprovisione suficiente capacidad de cómputo para soportar la eliminación de una única AZ.
-
Escale previamente sus pods (incluido CoreDNS) en todas las AZ.
-
Distribuya varias réplicas de pods en todas las zonas de disponibilidad para asegurarse de que, dispondrá de suficiente capacidad si deja de utilizar una única AZ.
-
Ubique los pods interdependientes o relacionados en la misma AZ
-
Inicie un cambio de zona de forma manual para comprobar que el entorno de su clúster funcione según lo esperado con una zona de disponibilidad menos. Como alternativa, puede activar el cambio de zona automático y conocer la respuesta en las sesiones de práctica del cambio automático. Esto no es obligatorio para que el cambio de zona funcione en EKS, pero se recomienda encarecidamente.
Aprovisione los nodos de trabajo de Amazon EKS en varias zonas de disponibilidad
Las regiones AWS tienen varias ubicaciones independientes con centros de datos físicos, conocidas como zonas de disponibilidad (AZ). Las AZ están diseñadas para estar aisladas físicamente unas de otras a fin de evitar un impacto simultáneo que podría afectar a toda una región. Al aprovisionar un clúster de Amazon EKS, debe implementar sus nodos de trabajo en varias AZ de una región. Esto hará que su entorno de clústeres sea más resistente a las deficiencias de una única AZ y le permitirá mantener una Alta disponibilidad (HA) de las aplicaciones que se ejecutan en las demás AZ. Cuando inicie un cambio de zona para alejarse de la zona de disponibilidad afectada, la red integrada en el clúster de su entorno de Amazon EKS se actualizará de forma automática para utilizar solo las AZ en buen estado y, al mismo tiempo, mantener una posición de alta disponibilidad para el clúster.
Asegurarse de disponer de una configuración de múltiples zonas de disponibilidad de este tipo para su entorno de Amazon EKS mejorará la fiabilidad general de su sistema. Sin embargo, los entornos de múltiples AZ pueden desempeñar un papel importante en la forma en que se transfieren y procesan los datos de las aplicaciones, lo que, a su vez, repercutirá en las tarifas de red de su entorno. En particular, el tráfico de salida frecuente entre zonas (tráfico distribuido entre las AZ) puede tener un impacto importante en los costos relacionados con la red. Puede aplicar diferentes estrategias para controlar la cantidad de tráfico entre zonas en los pods de su clúster de Amazon EKS y reducir los costos asociados. Consulte esta guía de prácticas recomendadas
El siguiente diagrama muestra un entorno de Amazon EKS de alta disponibilidad con 3 AZ en buen estado.
El siguiente diagrama muestra cómo un entorno de Amazon EKS con 3 AZ es resistente a una AZ dañada y mantiene una alta disponibilidad gracias a las otras 2 AZ sanas.
Aprovisione suficiente capacidad de cómputo para soportar la eliminación de una única AZ
Para optimizar la utilización de los recursos y los costes de su infraestructura de cómputos en el plano de datos de Amazon EKS, se recomienda alinear la capacidad de cómputos con los requisitos de la carga de trabajo. Sin embargo, si todos sus nodos de trabajo están a plena capacidad, tendrá que añadir nuevos nodos de trabajo al plano de datos de EKS antes de poder programar nuevos pods. Cuando se ejecutan cargas de trabajo esenciales, por lo general siempre es una buena práctica utilizar una capacidad redundante en línea para afrontar eventualidades como el aumento repentino de la carga, los problemas de estado de los nodos, etc. Si piensa utilizar el cambio de zona, tiene pensado eliminar toda una zona de disponibilidad de capacidad, por lo que tendrá que ajustar la capacidad de cómputo redundante a fin de que sea suficiente para gestionar la carga incluso con una zona de disponibilidad desconectada.
A la hora de escalar el cómputo, el proceso de añadir nuevos nodos al plano de datos de Amazon EKS llevará algún tiempo, lo que puede repercutir en el rendimiento y la disponibilidad en tiempo real de las aplicaciones, en especial en el caso de la alteración de una zona. Su entorno de Amazon EKS debe ser resiliente para absorber la carga que supone perder una AZ y evitar que la experiencia de sus usuarios finales o clientes se deteriore. Esto significa minimizar o eliminar cualquier intervalo entre el momento en que se necesita un nuevo pod y el momento real en que se programa en un nodo de trabajo.
Además, en caso de que se produzca un deterioro de zona, debe reducir el riesgo de que se produzca una posible limitación de la capacidad de cómputo que impida añadir nuevos nodos necesarios al plano de datos de Amazon EKS en las AZ en buen estado.
Para ello, se debe aprovisionar un exceso de la capacidad de cómputo en algunos de los nodos de trabajo de cada AZ, de modo que el programador de Kubernetes disponga de una capacidad preexistente para colocar nuevos pods, en especial si tiene una zona de disponibilidad menos en su entorno.
Ejecute y distribuya múltiples réplicas de pods en las zonas de disponibilidad
Kubernetes le permite escalar previamente sus cargas de trabajo mediante la ejecución de varias instancias (réplicas de pods) de una sola aplicación. Al ejecutar varias réplicas de Pod para una aplicación, se elimina un único punto de error y se aumenta su rendimiento general, ya que se reduce la carga de recursos en una sola réplica. Sin embargo, para que sus aplicaciones tengan una alta disponibilidad y una mejor tolerancia a los errores, debe ejecutar y distribuir varias réplicas de una aplicación en distintos dominios de errores (también denominados dominios de topología), en este caso las AZ. Con las restricciones de dispersión topológica
El siguiente diagrama muestra un entorno de Amazon EKS con un flujo de tráfico de este a oeste cuando todas las zonas de disponibilidad están en buen estado.
El siguiente diagrama muestra un entorno de Amazon EKS con un flujo de tráfico de este a oeste cuando se produce un error en una única zona de disponibilidad y se inicia un cambio de zona.
El siguiente fragmento de código es un ejemplo de cómo configurar la carga de trabajo con esta característica de Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
Lo que es más importante, se deben ejecutar varias réplicas del software de su servidor DNS (CoreDNS/kube-dns) y aplicar restricciones de dispersión topológica similares si aún no están configuradas de forma predeterminada. Esto ayudará a garantizar que dispongas de suficientes pods de DNS en AZ en buen estado para poder continuar con la administración de las solicitudes de detección de servicios de otros pods que se comunican entre sí del clúster, en caso de que se dañe un AZ. El complemento CoreDNS de Amazon EKS tiene una configuración predeterminada para que los pods de CoreDNS se distribuyan en las zonas de disponibilidad del clúster si hay nodos en varias AZ disponibles. También puede reemplazar estos ajustes predeterminados por sus propias configuraciones personalizadas.
Al instalar CoredNS con HelmreplicaCount
en el archivo values.yamltopologySpreadConstraints
en el mismo archivo values.yaml. El siguiente fragmento de código muestra cómo configurar CoreDNS para realizar esto.
CoredNS Helm values.yaml
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
En caso de que la AZ se deteriore, puede absorber el aumento de carga de los pods de CoreDNS mediante un sistema de escalado automático para CoreDNS. La cantidad de instancias de DNS que necesite dependerá de la cantidad de cargas de trabajo que se ejecuten en su clúster. CoredNS está vinculado a la CPU, lo que le permite escalar en función de la CPU mediante el Escalador automático de pods horizontales (HPA)
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
Como alternativa, Amazon EKS puede administrar el escalado automático de la implementación de CoreDNS en la versión de CoreDNS del complemento de EKS. Este escalador automático de CoreDNS monitorea continuamente el estado del clúster, incluida la cantidad de nodos y núcleos de CPU. En función de esa información, el controlador adaptará dinámicamente el número de réplicas de la implementación de CoreDNS en un clúster de Amazon EKS.
Para habilitar la configuración de escalado automático en el complemento CoredNS de EKS, deben añadirse los siguientes ajustes de configuración opcionales:
{
"autoScaling": {
"enabled": true
}
}
También puede usar el NodeLocal DNS
Coloque los pods interdependientes en la misma zona de disponibilidad
En la mayoría de los casos, es posible que esté ejecutando cargas de trabajo distintas que deben comunicarse entre sí para ejecutar correctamente un proceso de principio a fin. Si las distintas aplicaciones están distribuidas en diferentes AZ, pero no están ubicadas en la misma zona de disponibilidad, el deterioro de una única zona de disponibilidad puede afectar al proceso subyacente completo. Por ejemplo, si la aplicación A tiene varias réplicas en la AZ 1 y la AZ 2, pero la aplicación B tiene todas sus réplicas en la AZ 3, la pérdida de la AZ 3 afectará a cualquier proceso integral entre estas dos cargas de trabajo (aplicaciones A y B). La combinación de las restricciones de distribución topológica con la afinidad entre los pods puede mejorar la resiliencia de la aplicación, ya que permite distribuir los pods entre todas las AZ y configurar una relación entre determinados pods para garantizar que estén ubicados juntos.
Con las reglas de afinidad de los pods
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
El siguiente diagrama muestra los pods que se han ubicado en el mismo nodo utilizando las reglas de afinidad de los pods.
Compruebe si su entorno de clústeres puede soportar la pérdida de una zona de disponibilidad
Tras cumplir los requisitos anteriores, el siguiente paso importante es comprobar que tiene la capacidad de cómputo y carga de trabajo suficientes para afrontar la pérdida de una AZ. Para ello, puede activar un cambio de zona en Amazon EKS de forma manual. Como alternativa, puede activar el cambio automático de zona y configurar ejecuciones de práctica para comprobar que las aplicaciones funcionan según lo esperado con una zona de disponibilidad menos en el entorno de clúster.
Preguntas frecuentes
¿Por qué debo utilizar esta característica?
Al utilizar el cambio de zona o el cambio de zona automático de ARC en su clúster de Amazon EKS es más fácil mantener la disponibilidad de las aplicaciones de Kubernetes al automatizar el proceso de recuperación rápida que consiste en desviar el tráfico de red de una zona de disponibilidad defectuosa dentro del clúster. Con ARC, puede evitar pasos largos y complicados que, a menudo, conllevan un período de recuperación prolongado cuando se producen alteraciones en las AZ.
¿Cómo funciona esta característica con otros servicios de AWS?
Amazon EKS se integra con ARC, que proporciona la interfaz principal en la que puede realizar las operaciones de recuperación en AWS. Para garantizar que el tráfico interno del clúster se aleje de manera apropiada de una AZ defectuosa, se han realizado modificaciones en la lista de puntos de conexión de red para los pods que se ejecutan en el plano de datos de Kubernetes. Si utiliza equilibradores de carga de AWS para enrutar el tráfico externo al clúster, ya puede registrar los equilibradores de carga en ARC y activar un cambio de zona en ellos para evitar que el tráfico fluya hacia la zona degradada. Esta característica también interactúa con los Grupos de Amazon EC2 Auto Scaling (ASG) creados por los Grupos de nodos administrados (MNG) de Amazon EKS. Para evitar que una AZ dañada se utilice para lanzar nuevos nodos o pods de Kubernetes, Amazon EKS elimina la AZ dañada del ASG.
¿En qué se diferencia esta característica de las protecciones predeterminadas de Kubernetes?
Esta característica funciona en conjunto con varias protecciones integradas nativas de Kubernetes que ayudan a los clientes a mantener su resiliencia. Puede configurar sondeos de disponibilidad y actividad de un pod que decidan cuándo un pod debe recibir tráfico. Cuando estos sondeos fallan, Kubernetes elimina a estos pods como objetivos de un servicio y deja de enviarse el tráfico a allí. Si bien esto es útil, no es fundamental que los clientes configuren estas comprobaciones de estado de forma que se garantice que fallarán cuando una zona se degrade. La característica de cambio de zona de ARC le proporciona una red de seguridad adicional que lo ayuda a aislar por completo una AZ degradada cuando las protecciones nativas de Kubernetes no son suficientes. También le proporciona una forma sencilla de evaluar la capacidad operativa y la resiliencia de su arquitectura.
¿Puede AWS activar un cambio de zona en mi nombre?
Sí, si desea utilizar el cambio de zona de ARC de forma totalmente automática, puede activar el cambio de zona automático de ARC. Con el cambio de zona automático, puede estar seguro de que AWS monitorizará el estado de las AZ de su clúster de Amazon EKS y activará un cambio cuando se detecte una alteración en la AZ de manera automática.
¿Qué ocurre si utilizo esta característica y mis nodos de trabajo y cargas de trabajo no están escaladas previamente?
Si no está preescalado y confía en el aprovisionamiento de nodos o pods adicionales durante un cambio de zona, corre el riesgo de que la recuperación se retrase. El proceso de añadir nuevos nodos al plano de datos de Amazon EKS llevará algún tiempo, lo que puede repercutir en el rendimiento y la disponibilidad en tiempo real de las aplicaciones, en especial en el caso de la alteración de una zona. Además, en caso de que se produzca un deterioro de zona, es posible que se encuentre con una limitación de la capacidad de cómputo que impida añadir nuevos nodos necesarios al plano de datos de Amazon EKS en las AZ en buen estado.
Si sus cargas de trabajo no están preescaladas y distribuidas entre todas las AZ del clúster, el deterioro de una zona podría afectar la disponibilidad de una aplicación que solo se ejecuta en los nodos de trabajo de una AZ afectada. Para reducir el riesgo de una interrupción total de la disponibilidad de la aplicación, Amazon EKS dispone de un sistema de seguridad para que el tráfico se envíe a los puntos de conexión de los pods situados en una zona afectada, si esa carga de trabajo tiene todos sus puntos de conexión en una AZ en mal estado. Sin embargo, se recomienda encarecidamente que prefiera preescalar sus aplicaciones y distribuirlas en todas las AZ para mantener la disponibilidad en caso de que se produzca un problema en un zona.
¿Qué ocurre si ejecuto una aplicación con estado?
Si ejecuta una aplicación con estado, tendrá que evaluar su tolerancia a errores en relación al caso de uso y la arquitectura. Si tiene una arquitectura o un patrón, ya sea activo o en espera, es posible que haya instancias en las que lo activo se encuentre en una AZ deteriorada. A nivel de la aplicación, si el modo en espera no cambia a activo, es posible que tenga problemas con la aplicación. También es posible que tenga problemas cuando se lancen nuevos pods de Kubernetes en AZ en buen estado, ya que no se podrán conectar a los volúmenes persistentes enlazados a la AZ dañada.
¿Funciona esta característica con Karpenter?
Actualmente, Karpenter no es compatible con el cambio de zona y el cambio de zona automático de ARC en Amazon EKS. Si una AZ está averiada, puede ajustar la configuración de Karpenter NodePool correspondiente quitando la AZ en mal estado para que los nuevos nodos de trabajo solo se inicien en las AZ en buen estado.
¿Funciona esta característica con EKS Fargate?
Esta característica no es compatible con EKS Fargate. De forma predeterminada, cuando EKS Fargate reconoce un evento de salud en una zona, los pods preferirán ejecutarse en las otras AZ.
¿Amazon EKS afectará el plano de control de Kubernetes administrado?
No, de manera predeterminada Amazon EKS ejecuta y escala el plano de control de Kubernetes en varias AZ para garantizar una alta disponibilidad. El cambio de zona y el cambio de zona automático de ARC solo actuarán en el plano de datos de Kubernetes.
¿Hay algún costo asociado a esta nueva característica?
Puede utilizar el cambio de zona y el cambio de zona automático de ARC en su clúster de Amazon EKS sin ningún costo adicional. Sin embargo, seguirá pagando por las instancias aprovisionadas y se recomienda encarecidamente que escale previamente el plano de datos de Kubernetes antes de utilizar esta característica. Debe considerar el equilibrio adecuado entre el costo y la disponibilidad de la aplicación.