Simplificación del ciclo de vida de los nodos con grupos de nodos administrados - Amazon EKS
Conceptos de grupos de nodos administradosTipos de capacidad de grupo de nodos administrado

Simplificación del ciclo de vida de los nodos con grupos de nodos administrados

Los grupos de nodos administrados por Amazon EKS automatizan el aprovisionamiento y la administración del ciclo de vida de nodos (instancias de Amazon EC2) para clústeres de Kubernetes de Amazon EKS.

Con los grupos de nodos administrados por Amazon EKS, no es necesario aprovisionar o registrar por separado las instancias de Amazon EC2 que proporcionan capacidad informática para ejecutar sus aplicaciones de Kubernetes. Puede crear, actualizar o terminar nodos para el clúster con una sola operación y de manera automática. Las actualizaciones y terminaciones de nodos drenan de forma automática los nodos para garantizar que sus aplicaciones permanezcan disponibles.

Todos los nodos administrados se aprovisionan como parte de un grupo de Amazon EC2 Auto Scaling administrado por usted a través de Amazon EKS. Todos los recursos, incluidas las instancias y los grupos de Auto Scaling, se ejecutan dentro de su cuenta de AWS. Cada grupo de nodos puede ejecutarse en varias zonas de disponibilidad que defina.

Puede agregar un grupo de nodos administrado a clústeres nuevos o existentes mediante la consola de Amazon EKS, eksctl, la AWS CLI, la API de AWS o herramientas de infraestructura como código que incluyen AWS CloudFormation. Los nodos lanzados como parte de un grupo de nodos administrado se etiquetan automáticamente para la detección automática por el escalador automático de clústeres de Kubernetes. Puede utilizar el grupo de nodos para aplicar etiquetas de Kubernetes a los nodos y actualizarlos en cualquier momento.

No incurre en costos adicionales por usar grupos de nodos administrados por Amazon EKS, solo paga por los recursos de AWS que aprovisione. Estos incluyen instancias de Amazon EC2, volúmenes de Amazon EBS, horas de clúster de Amazon EKS y cualquier otra infraestructura de AWS. No se requieren pagos mínimos ni compromisos iniciales.

Para comenzar a utilizar un grupo de nodos administrado y un clúster de Amazon EKS nuevos, consulte Introducción a Amazon EKS: AWS Management Console y AWS CLI.

Para agregar un grupo de nodos administrados a un clúster existente, consulte Creación de un grupo de nodos administrados para un clúster.

Conceptos de grupos de nodos administrados

  • Los grupos de nodos administrados por Amazon EKS crean y administran instancias de Amazon EC2 para usted.

  • Todos los nodos administrados se aprovisionan como parte de un grupo de Amazon EC2 Auto Scaling administrado por usted a través de Amazon EKS. Además, todos los recursos, incluidas las instancias de Amazon EC2 y los grupos de Auto Scaling, se ejecutan dentro de su cuenta de AWS.

  • El grupo de Auto Scaling de un grupo de nodos administrados abarca todas las subredes que especifique al crear el grupo.

  • Las etiquetas de Amazon EKS administran recursos de grupo de nodos para que estén configurados para usar el escalador automático de clústeres de Kubernetes.

    importante

    Si está ejecutando una aplicación con estado en varias zonas de disponibilidad respaldadas por volúmenes de Amazon EBS y utilizando el escalador automático de clúster de Kubernetes, debe configurar varios grupos de nodos, cada uno enfocado a una sola zona de disponibilidad. Además, debe habilitar la característica --balance-similar-node-groups.

  • Puede utilizar una plantilla de lanzamiento personalizada para obtener un mayor nivel de flexibilidad y personalización al implementar nodos administrados. Por ejemplo, puede especificar argumentos kubelet adicionales y utilizar una AMI personalizada. Para obtener más información, consulte Personalización de nodos administrados con plantillas de lanzamiento. Si no usa una plantilla de lanzamiento personalizada al crear un grupo de nodos administrados, hay una plantilla de lanzamiento generada automáticamente. No modifique manualmente esta plantilla generada automáticamente o se producirán errores.

  • Amazon EKS sigue el modelo de responsabilidad compartida para CVE y los parches de seguridad en grupos de nodos administrados. Cuando los nodos administrados ejecutan una AMI optimizada para Amazon EKS, Amazon EKS es responsable de crear versiones con parches de la AMI cuando se informa de errores o problemas. Podemos publicar una solución. Sin embargo, es responsable de implementar estas versiones de AMI con parches en los grupos de nodos administrados. Cuando los nodos administrados ejecutan una AMI personalizada, es responsable de crear versiones con parches de la AMI cuando se informa de errores o problemas y, a continuación, implementar la AMI. Para obtener más información, consulte Actualización de un grupo de nodos administrados para un clúster.

  • Los grupos de nodos administrados por Amazon EKS se pueden lanzar tanto en subredes públicas como privadas. Si lanza un grupo de nodos administrado en una subred pública el 22 de abril de 2020 o después, la subred debe tener la opción MapPublicIpOnLaunch establecida en verdadero para que las instancias puedan unirse a un clúster correctamente. Si la subred pública se creó con eksctl o las plantillas de AWS CloudFormation ofrecidas por Amazon EKS el 26 de marzo de 2020 o después, esta configuración ya está establecida en verdadero. Si las subredes públicas se crearon antes del 26 de marzo de 2020, debe cambiar el valor de forma manual. Para obtener más información, consulte Modificación del atributo de direcciones IPv4 públicas de su subred.

  • Al implementar un grupo de nodos administrado en subredes privadas, debe asegurarse de que pueda acceder a Amazon ECR para extraer imágenes de contenedores. Para ello, conecte una puerta de enlace de NAT a la tabla de enrutamiento de la subred o agregue los siguientes puntos de conexión de VPC de AWS PrivateLink:

    • Interfaz de punto de conexión de la API de Amazon ECR: com.amazonaws.region-code.ecr.api

    • Interfaz de punto de conexión de la API de registro de Docker de Amazon ECR: com.amazonaws.region-code.ecr.dkr

    • Punto de conexión de puerta de enlace de Amazon S3: com.amazonaws.region-code.s3

    Para ver otros servicios y puntos de conexión de uso común, consulte Implementación de clústeres privados con acceso limitado a Internet.

  • Los grupos de nodos administrados no se pueden implementar en AWS Outposts ni en AWS Wavelength. Los grupos de nodos administrados se pueden crear en Zonas locales de AWS. Para obtener más información, consulte Lanzamiento de clústeres EKS de baja latencia con zonas locales de AWS.

  • Puede crear varios grupos de nodos administrados dentro de un único clúster. Por ejemplo, puede crear un grupo de nodos con la AMI optimizada de Amazon Linux para Amazon EKS estándar para algunas cargas de trabajo y otro con la variante de GPU para las cargas de trabajo que requieren compatibilidad con GPU.

  • Si el grupo de nodos administrado encuentra un error de comprobación de estado de instancia de Amazon EC2, Amazon EKS devuelve un código de error para ayudarlo a diagnosticar el problema. Para obtener más información, consulte Códigos de error del grupo de nodos administrado.

  • Amazon EKS agrega etiquetas de Kubernetes a instancias de grupos de nodos administrados. Estas etiquetas proporcionadas por Amazon EKS tienen el prefijo eks.amazonaws.com.

  • Amazon EKS drena nodos automáticamente a través de la API de Kubernetes durante las terminaciones o actualizaciones.

  • Los presupuestos de interrupción del pod no se respetan al terminar un nodo con AZRebalance o al reducir el número de nodos deseado. Estas acciones intentan desalojar los Pods en el nodo. Con estas acciones, se intentan expulsar los del nodo, pero si tardan más de 15 minutos, el nodo se termina independientemente de si todos los Pods del nodo están terminados. Para ampliar el período hasta que finalice el nodo, agregue un enlace de ciclo de vida al grupo de escalado automático. Para obtener más información, consulte Agregar enlaces de enlace de ciclo de vida en la guía de hombre del usuario de Amazon EC2 Auto Scaling.

  • Para ejecutar el proceso de drenaje correctamente después de recibir una notificación de interrupción puntual o una notificación de reequilibrio de capacidad, CapacityRebalance debe configurarse en true.

  • La actualización de los grupos de nodos administrados respetan los presupuestos de interrupción Pod que ha establecido para los Pods. Para obtener más información, consulte Descripción de cada fase de las actualizaciones de los nodos.

  • No incurre en costos adicionales por usar grupos de nodos administrados de Amazon EKS. Solo pagará por los recursos de AWS que aprovisione.

  • Si desea cifrar volúmenes de Amazon EBS para sus nodos, puede implementarlos mediante una plantilla de lanzamiento. Para implementar nodos administrados con volúmenes cifrados de Amazon EBS sin utilizar una plantilla de lanzamiento, cifre todos los nuevos volúmenes de Amazon EBS creados en su cuenta. Para obtener más información, consulte Cifrado de forma predeterminada en la Guía del usuario de Amazon EC2.

Tipos de capacidad de grupo de nodos administrado

Al crear un grupo de nodos administrado, puede elegir el tipo de capacidad bajo demanda o Spot. Amazon EKS implementa un grupo de nodos administrado con un grupo de Amazon EC2 Auto Scaling que solo contiene instancias de spot bajo demanda o solo instancias de spot de Amazon EC2. Puede programar Pods para aplicaciones con tolerancia a errores en grupos de nodos administrados por spot y aplicaciones intolerantes a errores a grupos de nodos bajo demanda dentro de un único clúster de Kubernetes. De forma predeterminada, un grupo de nodos administrado implementa instancias de Amazon EC2 bajo demanda.

Bajo demanda

Con instancias bajo demanda, paga la capacidad informática por segundo, sin compromisos a largo plazo.

De forma predeterminada, si no especifica un Tipo de capacidad, el grupo de nodos administrado se aprovisionará con instancias bajo demanda. En su nombre, un grupo de nodos administrado configura un grupo de Amazon EC2 Auto Scaling con la siguiente configuración aplicada:

  • La estrategia de asignación para aprovisionar capacidad bajo demanda se establece en prioritized. El grupo de nodos administrado utiliza el orden de los tipos de instancia de la API para determinar qué tipo de instancia se utilizará en primer lugar al cumplir con la capacidad bajo demanda. Por ejemplo, puede especificar tres tipos de instancias en el siguiente orden: c5.large, c4.large y c3.large. Cuando se lanzan las instancias bajo demanda, el grupo de nodos administrado satisface la capacidad bajo demanda, primero en c5.large, luego en c4.large y luego en c3.large. Para obtener más información, consulte Grupo de Amazon EC2 Auto Scaling en la Guía del usuario de Amazon EC2 Auto Scaling.

  • Amazon EKS agrega la siguiente etiqueta de Kubernetes a todos los nodos del grupo de nodos administrado que especifica el tipo de capacidad: eks.amazonaws.com/capacityType: ON_DEMAND. Puede utilizar esta etiqueta para programar aplicaciones con estado o intolerantes a errores en nodos bajo demanda.

Spot

Las instancias de spot de Amazon EC2 son una capacidad de Amazon EC2 de reemplazo que ofrece grandes descuentos con respecto a los precios bajo demanda. Las instancias de spot de Amazon EC2 se pueden interrumpir con una notificación previa de dos minutos cuando EC2 necesita recuperar la capacidad. Para obtener más información, consulte Instancias de spot en Guía del usuario de Amazon EC2. Puede configurar un grupo de nodos administrado con instancias de spot de Amazon EC2 para optimizar los costos de los nodos informáticos que se ejecutan en su clúster de Amazon EKS.

Para utilizar instancias de spot dentro de un grupo de nodos administrados, cree uno y establezca el tipo de capacidad como spot. Un grupo de nodos administrado configura un grupo de Amazon EC2 Auto Scaling en su nombre con las siguientes prácticas recomendadas de spot aplicadas:

  • Para garantizar que los nodos de spot se aprovisionen en los grupos de capacidad de spot óptima, la estrategia de asignación se establece en una de las siguientes:

    • price-capacity-optimized (PCO): Al crear nuevos grupos de nodos en un clúster con la versión 1.28 de Kubernetes o superior, la estrategia de asignación se establece en price-capacity-optimized. Sin embargo, la estrategia de asignación no cambiará para los grupos de nodos ya creados con capacity-optimized antes de que los grupos de nodos gestionados por Amazon EKS comenzaran a admitir PCO.

    • capacity-optimized (CO): Al crear nuevos grupos de nodos en un clúster con la versión 1.27 de Kubernetes o una versión anterior, la estrategia de asignación se establece en capacity-optimized.

    Para aumentar el número de grupos de capacidad de spot disponibles a fin de asignar su capacidad, configure un grupo de nodos administrados para utilizar varios tipos de instancias.

  • El reequilibrio de capacidad de spot de Amazon EC2 está habilitado para que Amazon EKS pueda drenar y reequilibrar los nodos de spot de forma sencilla para minimizar la interrupción de la aplicación cuando un nodo de spot corre un riesgo elevado de interrupción. Para obtener más información, consulte Reequilibrio de capacidad de Amazon EC2 Auto Scaling en la Guía del usuario de Amazon EC2 Auto Scaling.

    • Cuando un nodo de Spot recibe una recomendación de reequilibrio, Amazon EKS automáticamente intenta lanzar un nuevo nodo de Spot de reemplazo.

    • Si llega un aviso de interrupción de spot de dos minutos antes de que el nodo de spot de reemplazo se encuentre en estado Ready, Amazon EKS comienza a vaciar el nodo de spot que recibió la recomendación de reequilibrio. Amazon EKS drena el nodo haciendo todo lo posible. En consecuencia, no hay garantía de que Amazon EKS espere a que el nodo de reemplazo se una al clúster antes de agotar el nodo existente.

    • Cuando se inicia un nodo spot de reemplazo con el estado Ready en Kubernetes, Amazon EKS acordona y drena el nodo de spot que recibió la recomendación de reequilibrio. El acordonamiento del nodo de spot garantiza que el controlador de servicio no envíe nuevas solicitudes a este nodo de spot. También lo elimina de su lista de nodos de spot activos y en buen estado. Drenar el nodo de spot garantiza que los Pods en funcionamiento se expulsen de manera sencilla.

  • Amazon EKS agrega la siguiente etiqueta de Kubernetes a todos los nodos del grupo de nodos administrado que especifica el tipo de capacidad: eks.amazonaws.com/capacityType: SPOT. Puede utilizar esta etiqueta para programar aplicaciones con tolerancia a errores en nodos de spot.

Al decidir si desea implementar un grupo de nodos con capacidad bajo demanda o de spot, debe tener en cuenta las siguientes condiciones:

  • Las instancias de spot son una buena opción para aplicaciones sin estado, tolerantes a errores y flexibles. Estos incluyen cargas de trabajo de formación de machine learning y por lotes, ETL de big data como Apache Spark, aplicaciones de procesamiento de colas y puntos de conexión de API sin estado. Dado que spot es capacidad de Amazon EC2 de reemplazo y puede cambiar con el tiempo, le recomendamos que utilice la capacidad de spot para cargas de trabajo tolerantes a interrupciones. Más concretamente, la capacidad de spot es adecuada para cargas de trabajo que pueden tolerar periodos en los que la capacidad requerida no está disponible.

  • Recomendamos que utilice la opción bajo demanda para aplicaciones intolerantes a errores. Esto incluye herramientas de administración de clústeres como herramientas operativas y de supervisión, implementaciones que requieren StatefulSets y aplicaciones con estado, como bases de datos.

  • Para maximizar la disponibilidad de las aplicaciones mientras se utilizan instancias de spot, se recomienda configurar un grupo de nodos administrado de spot para que utilice varios tipos de instancias. Se recomienda aplicar las siguientes reglas al utilizar varios tipos de instancias:

    • Dentro de un grupo de nodos administrado, si está utilizando el escalador automático de clústeres, se recomienda utilizar un conjunto flexible de tipos de instancias con la misma cantidad de vCPU y recursos de memoria. Esto es para garantizar que los nodos del clúster se escalen según lo esperado. Por ejemplo, si necesita cuatro vCPU y 8 GiB de memoria, utilice c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge u otros tipos de instancias similares.

    • Para mejorar la disponibilidad de las aplicaciones, recomendamos implementar varios grupos de nodos administrados por spot. Para ello, cada grupo debe utilizar un conjunto flexible de tipos de instancias que tengan los mismos recursos de memoria y vCPU. Por ejemplo, si necesita 4 vCPU y 8 GiB de memoria, le recomendamos que cree un grupo de nodos administrado con c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge u otros tipos de instancias similares, y un segundo grupo de nodos administrado con m3.xlarge, m4.xlarge, m5.xlarge, m5d.xlarge, m5a.xlarge, m5n.xlarge u otros tipos de instancias similares.

    • Al implementar el grupo de nodos con el tipo de capacidad spot que utiliza una plantilla de lanzamiento personalizada, utilice la API para pasar varios tipos de instancia. No pase ni un solo tipo de instancia a través de la plantilla de lanzamiento. Para obtener más información sobre cómo implementar un grupo de nodos con una plantilla de lanzamiento, consulte Personalización de nodos administrados con plantillas de lanzamiento.