Escalado automático - Amazon EKS

Escalado automático

El escalado automático es una función que aumenta o disminuye automáticamente la escala de los recursos para satisfacer las demandas cambiantes. Esta es una función importante de Kubernetes que, de otro modo, requeriría muchos recursos humanos para funcionar manualmente.

Amazon EKS admite dos productos de escalado automático. El escalador automático del clúster de Kubernetes y el proyecto Karpenter de escalado automático de código abierto. El escalador automático del clúster utiliza grupos de escalado de AWS, mientras que Karpenter trabaja directamente con Amazon EC2 Fleet.

Escalador automático del clúster

El Cluster Autoscaler de Kubernetes ajusta de forma automática el número de nodos del clúster cuando los pods fallan o se reprograman en otros nodos. Normalmente, el Cluster Autoscaler se instala como una Implementación en su clúster. Utiliza la elección de líderes para garantizar una alta disponibilidad, pero el escalado se realiza mediante una sola réplica a la vez.

Antes de implementar el Cluster Autoscaler, asegúrese de estar familiarizado con la interfaz de los conceptos de Kubernetes con características de AWS. Los siguientes términos se utilizan en este tema:

  • Cluster Autoscaler de Kubernetes: un componente principal del plano de control de Kubernetes que toma decisiones de programación y escalado. Para obtener más información, consulte Preguntas frecuentes sobre el plano de control de Kubernetes en GitHub.

  • AWSImplementación de proveedores de nube: una extensión del Cluster Autoscaler de Kubernetes que implementa las decisiones del Cluster Autoscaler mediante la comunicación con productos y servicios de AWS como Amazon EC2. Para obtener más información, consulte Cluster Autoscaler en AWS en GitHub.

  • Grupos de nodos: una abstracción de Kubernetes para un grupo de nodos dentro de un clúster. Los grupos de nodos no son un recurso de Kubernetes verdadero, pero se encuentran como una abstracción en el Cluster Autoscaler, la API de clúster y otros componentes. Los nodos que se encuentran dentro de un solo grupo de nodos pueden compartir varias propiedades comunes, como etiquetas y taints. Sin embargo, pueden estar formados por más de una zona de disponibilidad o tipo de instancia.

  • Grupos de Amazon EC2 Auto Scaling: una característica de AWS que utiliza el Cluster Autoscaler. Los grupos de Auto Scaling son adecuados para un gran número de casos de uso. Los grupos de Amazon EC2 Auto Scaling se han configurado para lanzar instancias que se unen a su clúster de Kubernetes de forma automática. También aplican etiquetas y taints a su recurso de nodo correspondiente en la API de Kubernetes.

Para referencia, Grupos de nodos administrados se administran mediante grupos de Amazon EC2 Auto Scaling y son compatibles con el Cluster Autoscaler.

En este tema se describe cómo implementar el Cluster Autoscaler en su clúster de Amazon EKS y cómo configurarlo para modificar sus grupos de Amazon EC2 Auto Scaling.

Requisitos previos

Antes de implementar el Cluster Autoscaler, debe cumplir los siguientes requisitos previos:

  • Un clúster de Amazon EKS existente: si no dispone de un clúster, consulte Creación de un clúster de Amazon EKS.

  • Un proveedor de OIDC de IAM existente para el clúster. Para determinar si ya tiene uno o si debe crearlo, consulte Crear un proveedor de OIDC de IAM para su clúster.

  • Grupos de nodos con etiquetas de grupos de Auto Scaling. Cluster Autoscaler requiere las siguientes etiquetas en los grupos de Auto Scaling para que se puedan detectar automáticamente.

    • Si utilizó eksctl para crear sus grupos de nodos, estas etiquetas se aplicarán de forma automática.

    • Si no utilizó eksctl, debe etiquetar manualmente sus grupos de Auto Scaling con las siguientes etiquetas. A fin de obtener más información, consulte Etiquetado de los recursos de Amazon EC2 en la Guía del usuario de Amazon EC2 para instancias de Linux.

    Clave Valor
    k8s.io/cluster-autoscaler/<my-cluster>

    owned

    k8s.io/cluster-autoscaler/enabled TRUE

Crear una política y un rol de IAM

Cree una política de IAM que otorgue los permisos que requiere el Cluster Autoscaler para utilizar un rol de IAM. Sustituya todas los <example-values> (incluido <example-values>) con sus valores a lo largo de los procedimientos.

  1. Cree una política de IAM.

    1. Guarde el siguiente contenido en un archivo denominado cluster-autoscaler-policy.json. Si sus grupos de nodos existentes se crearon con eksctl y utilizó la opción eksctl, esta política ya existe y puede pasar al paso dos.

      { "Version": "2012-10-17", "Statement": [ { "Action": [ "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeTags", "autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup", "ec2:DescribeLaunchTemplateVersions" ], "Resource": "*", "Effect": "Allow" } ] }
    2. Cree la política mediante el siguiente comando. Puede cambiar el valor de policy-name.

      aws iam create-policy \ --policy-name AmazonEKSClusterAutoscalerPolicy \ --policy-document file://cluster-autoscaler-policy.json

      Tome nota del nombre de recurso de Amazon (ARN) que se devuelve en la salida. Lo utilizará en un paso posterior.

  2. Puede crear un rol de IAM y adjuntarle una política de IAM mediante eksctl o la eksctl. Seleccione la pestaña deseada para las siguientes instrucciones.

    eksctl
    1. Ejecute el siguiente comando si creó el clúster de Amazon EKS con eksctl. Si ha creado los grupos de nodos mediante la opción --asg-access, reemplace <AmazonEKSClusterAutoscalerPolicy> por el nombre de la política de IAM que --asg-access ha creado en su nombre. El nombre de la política es similar a eksctl-<my-cluster>-nodegroup-ng-<xxxxxxxx>-PolicyAutoScaling.

      eksctl create iamserviceaccount \ --cluster=<my-cluster> \ --namespace=kube-system \ --name=cluster-autoscaler \ --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/<AmazonEKSClusterAutoscalerPolicy> \ --override-existing-serviceaccounts \ --approve
    2. Recomendamos que, si ha creado los grupos de nodos con la opción --asg-access, desconecte la política de IAM que eksctl ha creado y adjuntado al Rol de IAM de nodo de Amazon EKS que eksctl ha creado para los grupos de nodos. Desconecte la política del rol de IAM del nodo para que el Cluster Autoscaler funcione correctamente. Al desconectar la política no se otorgan a otros pods de los nodos los permisos de la política. A fin de obtener más información, consulte Eliminación de permisos de identidad de IAM en la Guía del usuario de Amazon EC2 para instancias de Linux.

    AWS Management Console
    1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.

    2. En el panel de navegación izquierdo, seleccione Roles. A continuación, elija Create role.

    3. En la sección Trusted entity type (Tipo de entidad de confianza), elija Web identity (Identidad web).

    4. En la sección Web identity (Identidad web):

      1. En Identity provider (Proveedor de identidad), elija la URL de su clúster de Amazon EKS.

      2. En Audience (Audiencia), elija sts.amazonaws.com.

    5. Elija Next (Siguiente).

    6. En el cuadro Filter policies (Políticas de filtro), escriba AmazonEKSClusterAutoscalerPolicy. A continuación, seleccione la casilla de verificación situada a la izquierda del nombre de la política que obtuvo en la búsqueda.

    7. Elija Next (Siguiente).

    8. En Role name (Nombre de rol), escriba un nombre único para su rol, por ejemplo, AmazonEKSClusterAutoscalerRole.

    9. En Description (Descripción), ingrese texto descriptivo, como Amazon EKS - Cluster autoscaler role.

    10. Elija Create role (Crear rol).

    11. Una vez creado el rol, seleccione el rol en la consola para abrirlo y editarlo.

    12. Elija la pestaña Trust relationships (Relaciones de confianza) y, a continuación, Edit trust policy (Editar política de confianza).

    13. Busque la línea que se parezca a la siguiente:

      "oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"

      Cambie la línea para que tenga el siguiente aspecto. Reemplace <EXAMPLED539D4633E53DE1B716D3041E> (incluido <>) por el ID del proveedor de OIDC de su clúster y reemplace <region-code> por el código de región en la que se encuentra el clúster.

      "oidc.eks.<region-code>.amazonaws.com/id/<EXAMPLED539D4633E53DE1B716D3041E>:sub": "system:serviceaccount:kube-system:cluster-autoscaler"
    14. Elija Update policy (Actualizar política) para terminar.

Implementación del escalador automático del clúster

Complete los siguientes pasos para implementar el Cluster Autoscaler. Recomendamos que revise Consideraciones sobre la implementación y optimice la implementación del Cluster Autoscaler antes de implementarlo en un clúster de producción.

Para implementar el escalador automático del clúster

  1. Descargue el archivo YAML de Cluster Autoscaler.

    curl -o cluster-autoscaler-autodiscover.yaml https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml
  2. Modifique el archivo YAML y reemplace <YOUR CLUSTER NAME> por el nombre del clúster.

  3. Aplique el archivo YAML al clúster.

    kubectl apply -f cluster-autoscaler-autodiscover.yaml
  4. Agregue un comentario en la cuenta de servicio del cluster-autoscaler con el ARN del rol de IAM que creó anteriormente. Sustituya los <valores de ejemplo> por sus propios valores.

    kubectl annotate serviceaccount cluster-autoscaler \ -n kube-system \ eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/<AmazonEKSClusterAutoscalerRole>
  5. Aplique un parche en la implementación para agregar el comentario de cluster-autoscaler.kubernetes.io/safe-to-evict a los pods del Cluster Autoscaler con el siguiente comando.

    kubectl patch deployment cluster-autoscaler \ -n kube-system \ -p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"}}}}}'
  6. Edite la implementación del escalador automático del clúster con el siguiente comando.

    kubectl -n kube-system edit deployment.apps/cluster-autoscaler

    Edite el comando del contenedor de cluster-autoscaler para sustituir <YOUR CLUSTER NAME> (incluido <>) por el nombre del clúster y agregue las siguientes opciones.

    • --balance-similar-node-groups

    • --skip-nodes-with-system-pods=false

    spec: containers: - command: - ./cluster-autoscaler - --v=4 - --stderrthreshold=info - --cloud-provider=aws - --skip-nodes-with-local-storage=false - --expander=least-waste - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> - --balance-similar-node-groups - --skip-nodes-with-system-pods=false

    Guarde y cierre el archivo para aplicar los cambios.

  7. Abra la página de versiones del Cluster Autoscaler desde GitHub en un navegador web y busque la versión más reciente del Cluster Autoscaler que coincida con la versión principal y secundaria de Kubernetes de su clúster. Por ejemplo, si la versión de Kubernetes del clúster es 1.21, busque la última versión del Cluster Autoscaler que comience por 1.21. Registre el número de versión semántica (1.21.n) de esa versión para utilizarlo en el paso siguiente.

  8. Establezca la etiqueta de la imagen del escalador automático del clúster en la versión que ha registrado en el paso anterior con el comando siguiente. Reemplace 1.21.n por su propio valor.

    kubectl set image deployment cluster-autoscaler \ -n kube-system \ cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v<1.21.n>

Consulte los registros del escalador automático del clúster

Después de haber implementado el Cluster Autoscaler, podrá ver los registros y comprobar que monitorea la carga de su clúster.

Consulte los registros del escalador automático del clúster con el siguiente comando.

kubectl -n kube-system logs -f deployment.apps/cluster-autoscaler

La salida es la siguiente:

I0926 23:15:55.165842 1 static_autoscaler.go:138] Starting main loop I0926 23:15:55.166279 1 utils.go:595] No pod using affinity / antiaffinity found in cluster, disabling affinity predicate for this loop I0926 23:15:55.166293 1 static_autoscaler.go:294] Filtering out schedulables I0926 23:15:55.166330 1 static_autoscaler.go:311] No schedulable pods I0926 23:15:55.166338 1 static_autoscaler.go:319] No unschedulable pods I0926 23:15:55.166345 1 static_autoscaler.go:366] Calculating unneeded nodes I0926 23:15:55.166357 1 utils.go:552] Skipping ip-192-168-3-111.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166365 1 utils.go:552] Skipping ip-192-168-71-83.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166373 1 utils.go:552] Skipping ip-192-168-60-191.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166435 1 static_autoscaler.go:393] Scale down status: unneededOnly=false lastScaleUpTime=2019-09-26 21:42:40.908059094 ... I0926 23:15:55.166458 1 static_autoscaler.go:403] Starting scale down I0926 23:15:55.166488 1 scale_down.go:706] No candidates for scale down

Consideraciones sobre la implementación

Revise las siguientes consideraciones para optimizar la implementación del Cluster Autoscaler.

Consideraciones de escalado

El Cluster Autoscaler se puede configurar para incluir cualquier característica adicional de los nodos. Estas características pueden incluir volúmenes de Amazon EBS conectados a nodos, tipos de nodos de instancias de Amazon EC2 o aceleradores de GPU.

Asignar grupos de nodos en más de una zona de disponibilidad

Recomendamos que configure varios grupos de nodos, asigne cada grupo a una única zona de disponibilidad y habilite la característica --balance-similar-node-groups. Si solo crea un grupo de nodos, asigne ese grupo de nodos para abarcar más de una zona de disponibilidad.

Al configurar --balance-similar-node-groups en verdadero, asegúrese de que los grupos de nodos que desea que el escalador automático del clúster equilibre tengan etiquetas coincidentes (excepto las etiquetas de zona agregadas automáticamente). Puede pasar una marca --balancing-ignore-label a nodos con etiquetas diferentes para equilibrarlos de forma independiente, pero esto solo debe hacerse según sea necesario.

Optimizar los grupos de nodos

El Cluster Autoscaler realiza suposiciones sobre cómo se utilizan los grupos de nodos. Esto incluye los tipos de instancias que se utilizan dentro de un grupo. Para alinearse con estos supuestos, configure el grupo de nodos en función de estas consideraciones y recomendaciones:

  • Cada nodo de un grupo de nodos debe tener propiedades de programación idénticas. Esto incluye etiquetas, taints y recursos.

    • Para MixedInstancePolicies, los tipos de instancias deben tener especificaciones compatibles de CPU, memoria y GPU.

    • El primer tipo de instancia que se especifica en la política simula la programación.

    • Si la política tiene tipos de instancias adicionales con más recursos, es posible que los recursos se desperdicien después de escalar horizontalmente.

    • Si la política tiene tipos de instancias adicionales con menos recursos que los tipos de instancias originales, es posible que los pods no se programen en las instancias.

  • Configure un número menor de grupos de nodos con un mayor número de nodos, porque la configuración opuesta puede afectar a la escalabilidad de forma negativa.

  • Utilice las características de Amazon EC2 siempre que ambos sistemas ofrezcan soporte (por ejemplo, utilice regiones y ). MixedInstancePolicy.)

Recomendamos que utilice siempre que sea posible Grupos de nodos administrados. Los grupos de nodos administrados cuentan con características de administración potentes. Entre ellas se incluyen características para el Cluster Autoscaler, como la detección automática de grupos de Amazon EC2 Auto Scaling y la terminación correcta de nodos.

Utilizar volúmenes de EBS como almacenamiento persistente

El almacenamiento persistente es fundamental para crear aplicaciones con estado, como bases de datos y cachés distribuidas. Con los volúmenes de Amazon EBS, puede crear aplicaciones con estado en Kubernetes. Sin embargo, está limitado a crearlas en una misma zona de disponibilidad. Para obtener más información, consulte ¿Cómo se utiliza el almacenamiento persistente en Amazon EKS?. A fin de obtener una mejor solución, considere la creación de aplicaciones con estado que se encuentren compartidas en más de una zona de disponibilidad con un volumen de Amazon EBS independiente para cada zona de disponibilidad. Llevar a cabo esto hace que su aplicación se encuentre altamente disponible. Además, el Cluster Autoscaler puede equilibrar la escala de los grupos de Amazon EC2 Auto Scaling. Para ello, asegúrese de que se cumplan las siguientes condiciones:

  • El equilibrio del grupo de nodos se habilita al establecer balance-similar-node-groups=true.

  • Los grupos de nodos se ajustan con una configuración idéntica (aparte de estar en más de una zona de disponibilidad y utilizar diferentes volúmenes de Amazon EBS).

Programación conjunta

Los trabajos de entrenamiento distribuidos de machine learning se benefician significativamente de la latencia minimizada de las configuraciones de nodos de la misma zona. Estas cargas de trabajo implementan varios pods en una zona específica. Puede lograrlo al establecer la afinidad de pods para todos los pods programados conjuntamente o la afinidad de nodos mediante topologyKey: topology.kubernetes.io/zone. Mediante esta configuración, el Cluster Autoscaler escala horizontalmente una zona específica para que coincida con las demandas. Asigne varios grupos de Amazon EC2 Auto Scaling, uno para cada zona de disponibilidad, a fin de habilitar la conmutación por error para toda la carga de trabajo programada en conjunto. Asegúrese de que se cumplan las siguientes condiciones:

  • El equilibrio del grupo de nodos se habilita al establecer balance-similar-node-groups=true.

  • Afinidad de nodo, prioridad de pods, o ambos, se utilizan cuando los clústeres incluyen grupos de nodos regionales y zonales.

    • Utilice la afinidad de nodo para forzar o alentar los pods regionales y evitar los grupos de nodos zonales.

    • No programe pods zonales en grupos de nodos regionales. Si lo hace, puede dar lugar a una capacidad desequilibrada para los pods regionales.

    • Configure la prioridad de pods si sus cargas de trabajo zonales pueden tolerar interrupciones y reubicaciones. Al hacerlo, se impone la prioridad y la reprogramación en una zona menos disputada para sus pods escalados de forma regional.

Aceleradores y GPU

Algunos clústeres utilizan aceleradores de hardware especializados, como una GPU dedicada. Al escalar horizontalmente, el acelerador puede tardar varios minutos en anunciar el recurso en el clúster. Durante este tiempo, el Cluster Autoscaler simula que este nodo tiene el acelerador. Sin embargo, hasta que el acelerador esté listo y actualice los recursos disponibles del nodo, los pods pendientes no se pueden programar en el nodo. Esto puede generar un escalado horizontal innecesario repetidas veces.

Los nodos con aceleradores y alta utilización de CPU o memoria no se consideran para reducir verticalmente incluso si el acelerador no se utiliza. Sin embargo, esto puede resultar en costos innecesarios. Para evitar estos costos, el Cluster Autoscaler puede aplicar reglas especiales a fin de considerar nodos para reducir verticalmente si tienen aceleradores desocupados.

Para garantizar el comportamiento correcto en estos casos, configure kubelet en los nodos del acelerador a fin de etiquetar el nodo antes de unirse al clúster. El Cluster Autoscaler utiliza este selector de etiquetas para invocar el comportamiento optimizado del acelerador. Asegúrese de que se cumplan las siguientes condiciones:

  • kubelet para los nodos de GPU se ha configurado con kubelet.

  • Los nodos con aceleradores se adhieren a la regla de propiedades de programación idéntica.

Escalado desde cero

El Cluster Autoscaler puede escalar los grupos de nodos hasta y desde cero. Este ahorro podría ser considerable. El Cluster Autoscaler detecta los recursos de CPU, memoria y GPU de un grupo de Auto Scaling al inspeccionar el InstanceType que se especifica en su LaunchConfiguration o InstanceType. Algunos pods requieren recursos adicionales, como WindowsENI o WindowsENI. O pueden requerir NodeSelectors o NodeSelectors específicos. Estos dos últimos no se pueden identificar en la LaunchConfiguration. Sin embargo, el Cluster Autoscaler puede tener en cuenta estos factores al identificarlos en las siguientes etiquetas del grupo de Auto Scaling.

Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME Value: 5 Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY Value: $LABEL_VALUE Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY Value: NoSchedule
nota
  • Al escalar a cero, su capacidad se devuelve a Amazon EC2 y puede que no se encuentre disponible en el futuro.

  • Puede utilizar describeNodegroup para diagnosticar problemas con grupos de nodos administrados al escalar hasta y desde cero.

Parámetros de configuración adicionales

Existen muchas opciones de configuración que se pueden utilizar para ajustar el comportamiento y el rendimiento del Cluster Autoscaler. Para obtener una lista completa de parámetros, consulte ¿Cuáles son los parámetros de CA? en GitHub.

Consideraciones sobre el rendimiento

Hay algunos elementos clave que puede cambiar para ajustar el rendimiento y la escalabilidad del Cluster Autoscaler. Los principales son los recursos que se proporcionan al proceso, el intervalo de exploración del algoritmo y el número de grupos de nodos en el clúster. Sin embargo, también hay varios otros factores que están involucrados en la verdadera complejidad del tiempo de ejecución de este algoritmo. Estos incluyen la complejidad del complemento de programación y la cantidad de pods. Se consideran parámetros que no se pueden configurar porque son parte integral de la carga de trabajo del clúster y no se pueden ajustar de forma sencilla.

La escalabilidad hace referencia al rendimiento del Cluster Autoscaler a medida que aumenta el número de pods y nodos en el clúster de Kubernetes. Si se alcanzan las cuotas de escalabilidad, el rendimiento y la funcionalidad del Cluster Autoscaler se degradan. Además, cuando supera las cuotas de escalabilidad, el Cluster Autoscaler ya no puede agregar ni quitar nodos del clúster.

El rendimiento hace referencia a la rapidez con la que el Cluster Autoscaler puede tomar e implementar decisiones de escalado. Un Cluster Autoscaler que funciona perfectamente toma decisiones de forma instantánea e invoca acciones de escalado en respuesta a condiciones específicas, como un pod que se vuelve imposible de programar.

Familiarícese con la complejidad del tiempo de ejecución del algoritmo de escalado automático. Al hacerlo, es más fácil ajustar el Cluster Autoscaler para que funcione bien en clústeres grandes (con más de 1000 nodos).

El Cluster Autoscaler carga el estado de todo el clúster en la memoria. Esto incluye los pods, nodos y grupos de nodos. En cada intervalo de exploración, el algoritmo identifica los pods que no se pueden programar y simula la programación para cada grupo de nodos. Tenga en cuenta que ajustar estos factores de diferentes maneras produce diferentes compensaciones.

Escalado automático vertical

Puede escalar el Cluster Autoscaler a clústeres más grandes al aumentar las solicitudes de recursos para su implementación. Este es uno de los métodos más simples de hacer esto. Aumente la memoria y la CPU de los clústeres grandes. Tenga en cuenta que la medida en que debe aumentar la memoria y la CPU depende en gran parte del tamaño específico del clúster. El algoritmo de escalado automático almacena todos los pods y nodos en la memoria. Esto puede dar lugar a una huella de memoria mayor que un gigabyte en algunos casos. Por lo general, necesita aumentar los recursos de forma manual. Si a menudo necesita aumentar los recursos de forma manual, considere la posibilidad de utilizar Addon Resizer o Vertical Pod Autoscaler para automatizar el proceso.

Reducción del número de grupos de nodos

Puede reducir el número de grupos de nodos para mejorar el rendimiento del Cluster Autoscaler en clústeres grandes. Si estructuró los grupos de nodos en función de un equipo individual o de una aplicación, esto podría ser un desafío. Aunque es totalmente compatible con la API de Kubernetes, se considera un antipatrón del Cluster Autoscaler con repercusiones para la escalabilidad. Hay muchas ventajas en el uso de varios grupos de nodos que, por ejemplo, utilizan instancias de spot o de GPU. En muchos casos, hay diseños alternativos que logran el mismo efecto mientras se utiliza un número de grupos pequeño. Asegúrese de que se cumplan las siguientes condiciones:

  • Aísle los pods mediante espacios de nombres en lugar de grupos de nodos.

    • Es posible que no pueda hacerlo en clústeres de varios inquilinos de poca confianza.

    • Establezca los pods ResourceRequests y ResourceRequests correctamente para evitar la contención de recursos.

    • Utilice tipos de instancias más grandes para un empaquetado de contenedores más óptimo y una sobrecarga reducida del pod del sistema.

  • Evite utilizar NodeTaints o NodeTaints para programar pods. Solo utilícelos de forma limitada.

  • Defina los recursos regionales como un único grupo de Amazon EC2 Auto Scaling con más de una zona de disponibilidad.

Reducir el intervalo de exploración

El uso de un intervalo de exploración bajo, como la configuración predeterminada de diez segundos, garantiza que el Cluster Autoscaler responda lo más rápido posible cuando los pods no se pueden programar. Sin embargo, cada análisis resulta en muchas llamadas a la API de Kubernetes y al grupo de Amazon EC2 Auto Scaling o a las API de grupo de nodos administrados por Amazon EKS. Estas llamadas a la API pueden resultar en una limitación de la velocidad o incluso en la falta de disponibilidad del servicio para su plano de control de Kubernetes.

El intervalo de exploración predeterminado es de diez segundos, pero en AWS, lanzar un nodo toma mucho más tiempo en lanzar una instancia nueva. Esto significa que es posible aumentar el intervalo sin aumentar significativamente el tiempo de escalado vertical general. Por ejemplo, si se necesitan dos minutos para lanzar un nodo, no cambie el intervalo a un minuto, ya que esto podría resultar en una compensación de llamadas a la API reducidas seis veces para escalados verticales un 38 % más lentos.

Compartir entre grupos de nodos

Puede configurar el Cluster Autoscaler para que funcione en un conjunto específico de grupos de nodos. Mediante esta funcionalidad, puede implementar varias instancias del Cluster Autoscaler. Configure cada instancia para que funcione en un conjunto de grupos de nodos diferente. Gracias a esto, puede utilizar arbitrariamente grandes cantidades de grupos de nodos, intercambiando costo por escalabilidad. Sin embargo, solo recomendamos que lo haga como último recurso para mejorar el rendimiento del Cluster Autoscaler.

Esta configuración tiene sus desventajas. Puede provocar un escalado horizontal innecesario de varios grupos de nodos. Los nodos adicionales vuelven a escalar después del scale-down-delay.

metadata: name: cluster-autoscaler namespace: cluster-autoscaler-1 ... --nodes=1:10:k8s-worker-asg-1 --nodes=1:10:k8s-worker-asg-2 --- metadata: name: cluster-autoscaler namespace: cluster-autoscaler-2 ... --nodes=1:10:k8s-worker-asg-3 --nodes=1:10:k8s-worker-asg-4

Asegúrese de que las siguientes condiciones sean verdaderas.

  • Se ha configurado cada partición para que apunte a un conjunto único de grupos de Amazon EC2 Auto Scaling.

  • Cada partición se implementa en un espacio de nombres separado para evitar conflictos de elección de líderes.

Rentabilidad y disponibilidad

Las principales opciones para ajustar la rentabilidad del Cluster Autoscaler están relacionadas con el aprovisionamiento de instancias de Amazon EC2. Además, la rentabilidad debe equilibrarse con la disponibilidad. En esta sección se describen estrategias como el uso de instancias de spot para reducir costos y el sobreaprovisionamiento a fin de reducir la latencia al crear nodos nuevos.

  • Disponibilidad: los pods se pueden programar de forma rápida y sin interrupciones. Esto es cierto incluso cuando es necesario programar pods recién creados y cuando un nodo reducido verticalmente finaliza los pods restantes programados para él.

  • Costo: determinado por la decisión detrás de los eventos de reducción y escalado horizontal. Los recursos se desperdician si se infrautiliza un nodo existente o si se agrega un nodo nuevo que es demasiado grande para los pods entrantes. Según el caso de uso específico, pueden surgir costos asociados con la terminación prematura de los pods debido a una decisión agresiva de reducción vertical.

Instancias de spot

Puede utilizar instancias de spot en sus grupos de nodos para ahorrar hasta un 90 % del precio bajo demanda. Esto tiene como compensación la posibilidad de que las instancias de spot se interrumpan en cualquier momento cuando Amazon EC2 necesite recuperar la capacidad. Los Insufficient Capacity Errors se producen siempre que su grupo de Amazon EC2 Auto Scaling no pueda escalar verticalmente debido a la falta de capacidad disponible. Seleccionar muchas familias de instancias diferentes tiene dos beneficios principales. En primer lugar, puede aumentar las posibilidades de lograr la escala deseada al acceder a muchos grupos de capacidad de spot. En segundo lugar, también puede disminuir el impacto de las interrupciones de instancias de spot en la disponibilidad del clúster. Las políticas de instancias mixtas con instancias de spot son una excelente manera de aumentar la diversidad sin aumentar el número de grupos de nodos. Sin embargo, tenga en cuenta que, si necesita recursos garantizados, puede utilizar instancias bajo demanda en lugar de instancias de spot.

Las instancias de spot pueden terminarse cuando aumenta la demanda de instancias. A fin de obtener más información, consulte Interrupciones de instancias de spot en la Guía del usuario de Amazon EC2 para instancias de Linux. El Controlador de terminación de nodos de AWS alerta automáticamente al plano de control de Kubernetes cuando está decayendo un nodo. El proyecto utiliza la API de Kubernetes para acordonar el nodo a fin de asegurarse de que no hay trabajo nuevo programado allí, luego lo drena y elimina cualquier trabajo existente.

Es fundamental que todos los tipos de instancias tengan una capacidad de recursos similar al configurar políticas de instancia mixtas. El simulador de programación del escalador automático utiliza el primer tipo de instancia en la política de instancia mixta. Si los tipos de instancias posteriores son más grandes, es posible que los recursos se desperdicien después de un escalado vertical. Si las instancias son más pequeñas, es posible que los pods no se programen en las instancias nuevas debido a la capacidad insuficiente. Por ejemplo, las instancias M4, M5, M5a, y M4, todas tienen cantidades similares de CPU y memoria y son excelentes candidatas para una política de instancia mixta. La herramienta Amazon EC2 Instance Selector puede ayudarle a identificar tipos de instancias similares o criterios críticos adicionales, como el tamaño. Para obtener más información, consulte Amazon EC2 Instance Selector en GitHub.

Recomendamos aislar la capacidad de instancias bajo demanda e instancias de spot en grupos de Amazon EC2 Auto Scaling independientes. Recomendamos que se realice mediante una estrategia de capacidad básica porque las propiedades de programación de instancias bajo demanda y de spot son diferentes. Las instancias de spot se pueden interrumpir en cualquier momento. Cuando Amazon EC2 necesita recuperar la capacidad, los nodos preventivos suelen estar contaminados, lo que requiere una tolerancia explícita del pod para el comportamiento de preferencia. Esto resulta en diferentes propiedades de programación para los nodos, por lo que deben separarse en varios grupos de Amazon EC2 Auto Scaling.

El Cluster Autoscaler conlleva el concepto de Expansores. Colectivamente proporcionan diferentes estrategias para seleccionar qué grupo de nodos escalar. La estrategia --expander=least-waste es un buen valor predeterminado de uso general y si va a utilizar varios grupos de nodos para la diversificación de instancias de spot, como se describió anteriormente, podría ayudar a optimizar aún más los costos de los grupos de nodos al escalar el grupo que se utilizaría mejor después de la actividad de escalado.

Priorizar un grupo de nodos o un grupo de Auto Scaling

También puede configurar el escalado automático basado en prioridades mediante el expansor de Priority. El Priority permite que el clúster dé prioridad a un grupo de nodos o a un grupo de Auto Scaling, y si no puede escalar por cualquier motivo, elegirá el siguiente grupo de nodos en la lista priorizada. Esto es útil en situaciones en las que, por ejemplo, desea utilizar P3 porque su GPU proporciona un rendimiento óptimo para su carga de trabajo, pero como segunda opción también puede utilizar tipos de instancias de P3. Por ejemplo:

apiVersion: v1 kind: ConfigMap metadata: name: cluster-autoscaler-priority-expander namespace: kube-system data: priorities: |- 10: - .*p2-node-group.* 50: - .*p3-node-group.*

El Cluster Autoscaler intenta escalar verticalmente el grupo de Amazon EC2 Auto Scaling que coincide con el nombre p3-node-group. Si esta operación no se realiza correctamente dentro del --max-node-provision-time, intenta escalar un grupo de Amazon EC2 Auto Scaling que coincida con el nombre --max-node-provision-time. Este valor predeterminado es de 15 minutos y se puede reducir para una selección de grupos de nodos con mayor capacidad de respuesta. Sin embargo, si el valor es demasiado bajo, puede producirse un escalado horizontal innecesario.

Sobreaprovisionamiento

El Cluster Autoscaler ayuda a minimizar los costos, ya que garantiza que los nodos solo se agregan al clúster cuando se necesitan y se eliminan cuando no se utilizan. Esto afecta significativamente a la latencia de implementación porque muchos pods deben esperar a que un nodo se escale verticalmente antes de que puedan programarse. Los nodos pueden tardar varios minutos en estar disponibles, lo que puede aumentar la latencia de programación de pods en un orden de magnitud.

Esto se puede mitigar al utilizar el sobreaprovisionamiento, que cambia el costo de la latencia de programación. El sobreaprovisionamiento se implementa al utilizar pods temporales con prioridad negativa. Estos pods ocupan espacio en el clúster. Cuando los pods recién creados no se pueden programar y tienen una prioridad más alta, los pods temporales se anteponen para generar espacio. Luego, los pods temporales se vuelven imposibles de programar, lo que hace que el Cluster Autoscaler escale horizontalmente los nodos sobreaprovisionados nuevos.

Existen otros beneficios en el sobreaprovisionamiento. Sin sobreaprovisionamiento, los pods de un clúster altamente utilizado toman decisiones de programación menos óptimas mediante la regla preferredDuringSchedulingIgnoredDuringExecution. Un caso de uso común para esto es separar los pods para una aplicación de alta disponibilidad en las zonas de disponibilidad mediante AntiAffinity. El sobreaprovisionamiento puede aumentar significativamente la probabilidad de que se encuentre disponible un nodo de la zona deseada.

Es importante elegir una cantidad adecuada de capacidad sobreaprovisionada. Una forma en que puede asegurarse de elegir una cantidad adecuada es tomar su frecuencia promedio de escalado vertical y dividirla por el tiempo que tarda en escalar un nodo nuevo. Por ejemplo, si, de promedio, necesita un nodo nuevo cada 30 segundos y Amazon EC2 tarda 30 segundos en aprovisionar un nodo nuevo, un único nodo de sobreaprovisionamiento garantiza que siempre haya un nodo adicional disponible. Esto puede reducir la latencia de programación en 30 segundos a costa de una sola instancia adicional de Amazon EC2. Para tomar mejores decisiones de programación zonal, también puede aprovisionar en exceso el número de nodos a fin de que sea igual al número de zonas de disponibilidad del grupo de Amazon EC2 Auto Scaling. Al hacerlo, se asegura de que el programador pueda seleccionar la mejor zona para los pods entrantes.

Evitar la expulsión en reducción vertical

Algunas cargas de trabajo son costosas de expulsar. El análisis de big data, las tareas de machine learning y los corredores de prueba pueden tardar mucho tiempo en completarse y deben reiniciarse si se interrumpen. El Cluster Autoscaler ayuda a reducir verticalmente cualquier nodo bajo el scale-down-utilization-threshold. Esto interrumpe los pods restantes en el nodo. Sin embargo, puede evitar que esto suceda al asegurarse de que los pods que son costosos de expulsar se encuentren protegidos por una etiqueta reconocida por el Cluster Autoscaler. Para ello, asegúrese de que los pods costosos de expulsar tengan la etiqueta cluster-autoscaler.kubernetes.io/safe-to-evict=false.

Karpenter

Amazon EKS admite el proyecto Karpenter de escalado automático de código abierto. Consulte la documentación de Karpenter para implementarlo.

Acerca de Karpenter

Karpenter es un escalador automático de clúster de Kubernetes flexible y de alto rendimiento que ayuda a mejorar la disponibilidad de las aplicaciones y la eficiencia del clúster. Karpenter lanza recursos de computación del tamaño correcto (por ejemplo, instancias de Amazon EC2), en respuesta a los cambios en la carga de la aplicación en menos de un minuto. Mediante la integración de Kubernetes con AWS, Karpenter puede aprovisionar recursos informáticos justo a tiempo que cumplen con precisión los requisitos de su carga de trabajo. Karpenter aprovisiona automáticamente nuevos recursos informáticos en función de los requisitos específicos de las cargas de trabajo de un clúster. Estos incluyen requisitos de computación, almacenamiento, aceleración y programación. Amazon EKS admite clústeres que utilizan Karpenter, aunque Karpenter funciona con cualquier clúster de Kubernetes conforme.

Cómo funciona Karpenter

Karpenter funciona en conjunto con el programador de Kubernetes observando los pods entrantes durante toda la vida útil del clúster. Lanza o termina los nodos para maximizar la disponibilidad de las aplicaciones y la utilización del clúster. Cuando haya suficiente capacidad en el clúster, el programador de Kubernetes colocará los pods entrantes como siempre. Cuando se inician pods que no se pueden programar con la capacidad existente del clúster, Karpenter omite el programador de Kubernetes y trabaja directamente con el servicio informático de su proveedor (por ejemplo, Amazon EC2) para lanzar los recursos informáticos mínimos necesarios a fin de adaptarse a esos pods y vincularlos a los nodos aprovisionados. A medida que los pods se eliminan o se reprograman en otros nodos, Karpenter busca oportunidades para terminar nodos infrautilizados. La ejecución de menos nodos más grandes en el clúster reduce la sobrecarga de los componentes del sistema daemonsets y Kubernetes y proporciona más oportunidades de empaquetado eficiente.

Requisitos previos

Antes de implementar Karpenter, debe cumplir los siguientes requisitos previos:

Si lo prefiere, puede implementar Karpenter con eksctl. Consulte Instalar eksctl.