El pasado diciembre en re:Invent 2024, AWS anunció un nuevo modo para gestionar clústeres de Amazon EKS: Amazon EKS Auto Mode. AWS promete que este modo simplifica las operaciones de los clústeres, mejora el rendimiento, la disponibilidad y la seguridad de las aplicaciones, y optimiza continuamente los costos de computación.
Este artículo explorará cómo este nuevo modo de gestión se compara con otros métodos de gestión de nodos. Esto te ayudará a evaluar si adoptar esta función para gestionar tu clúster tiene sentido..
Escalado Dinámico de Cómputo con Karpenter y Auto Mode de Amazon EKS
Orquestar contenedores con Amazon EKS puede volverse un desafío al desplegar y gestionar muchos contenedores, asegurando la escalabilidad y optimizando recursos y costos.
También podrías enfrentar desafíos relacionados con la isolación de cargas de trabajo entre equipos y nodos.Por ejemplo, es posible que necesite dedicar ciertos tipos de instancias a cargas de trabajo específicas.
Karpenter es una herramienta de código abierto inicialmente desarrollada por AWS.Aborda estos desafíos permitiéndote personalizar las políticas de escalado y las asignaciones de nodos para tus cargas de trabajo de Amazon EKS.
Sin embargo, el uso de Karpenter introduce nuevos desafíos. Ahora necesitas gestionar el ciclo de vida de un nuevo componente y asegurar su mantenimiento, ya que se vuelve crítico para la administración del clúster.
Normalmente recomendamos aislar los controladores de Karpenter de otros nodos de carga de trabajo al desplegarlos. Un método podría ser desplegarlos en instancias EC2 dedicadas o nodos Fargate. Esto asegura la asignación consistente de un controlador a una instancia de cómputo.
Arquitectura de clúster de Amazon EKS con instancias EC2 sin Auto Mode
Fuente : AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon Amazon EKS Auto Mode (KUB312)”
Auto Mode de EKS, cambiamos a un modelo donde el cliente ya no es responsable de gestionar el ciclo de vida del controlador Karpenter (así como de los controladores de almacenamiento y red).
En la práctica, al iniciar un clúster con Amazon EKS Auto Mode con solo el Control Plane desplegado, solo necesitas iniciar un despliegue para desplegar pods en el clúster.
El modo automático de EKS luego despliega automáticamente los nodos basándose en los grupos de nodos definidos previamente.Como recordatorio, un Node Pool define la estrategia para asignar pods a un grupo de tipos de instancia.Puedes configurar esto en la configuración.
AArquitectura de clúster de Amazon EKS con instancias EC2 con Auto Mode
Fuente: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”
Furthermore, when creating an EKS Auto Mode cluster, there are two types of Node Pools options: «system» and «general-purpose«.
Además, al crear un clúster de EKS en Auto Mode, hay dos tipos de opciones de Node Pools: «sistema» y «uso general».
El «Node Pool» del sistema te permite aprovisionar instancias para desplegar complementos personalizados que deseas aislar de las instancias utilizadas para tus cargas de trabajo.
El «Node Pool» de «propósito general» simplifica la experiencia de inicio y te permite desplegar pods en instancias bajo demanda de propósito general fácilmente.
Por supuesto, puedes ir más allá de estos para crear Grupos de Nodos que se ajusten a tus necesidades específicas. Por ejemplo, puedes definir Grupos de Nodos que prioricen instancias spot para optimizar costos o instancias GPU para cargas de trabajo de IA.
Utilizas un objeto de Clase de Nodo específico para el Modo Automático de EKS para preconfigurar las instancias creadas en estos casos. Esto te permite definir grupos de seguridad, IDs de subred, y la configuración de almacenamiento, entre otras cosas. Sin embargo, es importante señalar que no puedes especificar un ID de AMI.
Esto se debe a que una característica clave del Modo Automático es la gestión automatizada de actualizaciones del clúster, que se basa en actualizar las AMIs utilizadas por los nodos del plano de datos.
Estos nodos funcionan con una AMI impuesta por AWS basada en Bottlerocket por defecto (un sistema operativo diseñado explícitamente por AWS para ejecutar contenedores). Por lo tanto, no puedes usar tus AMIs personalizadas en este caso.
Ejemplo de una definición de NodeClass
Fuente: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”
Actualizaciones Automáticas de Clúster
Antes de discutir los detalles de la función de actualización automática del clúster, es importante recordar que siempre tienes la opción de activar la actualización del Control Plane.
Entonces, solo Amazon EKS verifica las versiones de los controladores administrados y actualiza solo los controladores que no están actualizados.
Fuente: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”
El proceso de actualización se puede activar en dos escenarios para los nodos del plano de datos.
1- Cuando el Control Plane se actualiza a una nueva versión de Kubernetes, los nodos del Data Plane se reemplazan con una AMI que coincide con la versión de Kubernetes del Control Plane.
Fuente: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”
2- Cuando se lanza una nueva AMI e incorpora los últimos parches de seguridad del sistema operativo, los nodos del plano de datos se reemplazan con la AMI actualizada.
Fuente : AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”
Estos procesos respetan el ciclo de vida de los nodos gestionados por Karpenter y el presupuesto de interrupciones, que deberás definir cuidadosamente para evitar tiempos de inactividad no deseados. También es importante recordar que si los nodos no se actualizan a pesar de los diversos eventos que afectan a las instancias de Karpenter, AWS fuerza la actualización el día 21 de cada mes.
Consideraciones de Precios y Costes
No hay cambios en los costos del plano de control. Amazon EKS Auto Mode sigue el mismo modelo de precios, que es un precio fijo de $0.10/hora o $72/mes para soporte estándar ($0.60/hora para soporte extendido).
Sin embargo, la fijación de precios para el plano de datos es bastante diferente. Se aplica un costo adicional a las instancias de EC2, que varía según el tipo de instancia lanzada. Basado en los tipos de instancias que revisé, encontré una tarifa adicional aproximada del 12%.
Es esencial considerar este factor de costo al evaluar el Modo Automático de EKS. Si la reducción de costos es una prioridad principal, otras opciones como gestionar manualmente el escalado automático con Karpenter podrían ser más ventajosas. Sin embargo, si simplificar las operaciones y reducir los costos operativos son factores esenciales, los beneficios del Modo Automático de EKS pueden justificar el costo adicional.
En el ejemplo anterior, vemos que para tres instancias de diferentes tipos, habilitar el Modo Automático añade una tarifa extra de $125.62 por mes, lo que hace un total de $1,172.44 para los costes del plano de datos.
Fuente : AWS website, Amazon EKS Pricing | Managed Kubernetes Service
Preguntas clave que debes hacerte al considerar el Modo Automático de EKS
Para ayudarte a elegir la mejor opción para gestionar tu clúster de Amazon EKS con capacidades de autoescalado de nodos, aquí tienes algunas preguntas que pueden ser útiles para que te las hagas y consideres si el Modo Automático de EKS es adecuado para tu caso de uso:
¿Es una prioridad simplificar las operaciones de clúster y reducir la carga operativa?
Si gestionar componentes clave como Karpenter, AWS Load Balancer Controller o EBS CSI consume un tiempo y esfuerzo significativos, EKS Auto Mode podría ser una excelente opción ya que reduce la carga operativa. También debería justificar un costo adicional para los nodos del plano de datos.
¿Qué tan crítico es el cumplimiento de las políticas internas?
Si su organización impone requisitos de cumplimiento estrictos, como ejecutar instancias con AMIs personalizadas o instalar agentes y software específicos (por ejemplo, herramientas de registro, monitoreo o seguridad), entonces el Auto Mode de EKS podría no ser la opción adecuada. Solo admite AMIs proporcionadas por AWS, específicamente basadas en Bottlerocket.
¿Necesito capacidades avanzadas de configuración de red?
El modo automático de EKS puede no ser la opción adecuada si su caso de uso requiere, por ejemplo
- Usar CNIs de terceros en lugar de AWS VPC CNI (Cilium, Calico..)
- Asignar rangos CIDR personalizados para pods distintos de los CIDR de la VPC.
- Aprovechando características avanzadas como el calentamiento de ENI/IP/PREFIX o Grupos de Seguridad por Pod.
¿Quiero beneficiarme de las actualizaciones automáticas de clúster, nodos y controladores gestionados?
Si deseas reducir el tiempo dedicado a actualizar los componentes de tu clúster y no requieres un control granular sobre el proceso de actualización, entonces el Modo Automático de EKS es un fuerte contendiente.
Basado en estas preguntas, las resumí con un diagrama de toma de decisiones. Dependiendo de tus necesidades, te guiará para identificar si EKS Auto Mode es una buena opción en comparación con Amazon EKS con instancias EC2 gestionadas por Karpenter.
Conclusión
Amazon EKS Auto Mode ofrece una solución poderosa para gestionar clústeres de Kubernetes:
- Operaciones simplificadas
- Escalado automatizado
- Gestión fácil de nodos
Su capacidad para gestionar el ciclo de vida de componentes clave como Karpenter, redes y controladores de almacenamiento, y proporcionar actualizaciones automáticas para clústeres, nodos y controladores gestionados, lo convierte en una opción atractiva para equipos que buscan reducir la carga operativa, mejorar el rendimiento de las aplicaciones, la disponibilidad y la seguridad, y optimizar los costos de computación.
Sin embargo, esta simplicidad viene con compromisos, como una personalización limitada, un control granular reducido y costos adicionales para los nodos del plano de datos.Estas limitaciones pueden disuadir a equipos con estrictos requisitos de cumplimiento o necesidades avanzadas de personalización.