Escalador automático de clústeres

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.

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.

Descripción general

El escalador automático de clústeres de Kubernetes es una popular solución de escalado automático de clústeres mantenida por SIG Autoscaler. Es responsable de garantizar que el clúster tenga suficientes nodos para programar los pods sin desperdiciar recursos. Presta atención a los pods que no se programan y a los nodos que están infrautilizados. A continuación, simula la adición o eliminación de nodos antes de aplicar el cambio al clúster. La implementación de AWS Cloud Provider en Cluster AutoScaler controla el .DesiredReplicas campo de sus grupos de EC2 Auto Scaling.

Esta guía proporcionará un modelo mental para configurar el escalador automático de clústeres y elegir el mejor conjunto de ventajas y desventajas para cumplir con los requisitos de su organización. Si bien no existe una configuración única que sea la mejor, hay un conjunto de opciones de configuración que le permiten equilibrar el rendimiento, la escalabilidad, el costo y la disponibilidad. Además, en esta guía se ofrecen consejos y prácticas recomendadas para optimizar la configuración de AWS.

Glosario

La siguiente terminología se utilizará con frecuencia a lo largo de este documento. Estos términos pueden tener un significado amplio, pero se limitan a las siguientes definiciones para los fines de este documento.

La escalabilidad se refiere al rendimiento del escalador automático de clústeres a medida que el clúster de Kubernetes aumenta en número de pods y nodos. A medida que se alcanzan los límites de escalabilidad, el rendimiento y la funcionalidad del escalador automático de clústeres se degradan. A medida que el escalador automático de clústeres supere sus límites de escalabilidad, ya no podrá añadir ni eliminar nodos del clúster.

El rendimiento se refiere a la rapidez con la que el escalador automático de clústeres puede tomar y ejecutar decisiones de escalado. Un escalador automático de clústeres que funcione perfectamente tomaría una decisión al instante y activaría una acción de escalado en respuesta a estímulos, como la imposibilidad de programar un módulo.

La disponibilidad significa que los módulos se pueden programar rápidamente y sin interrupciones. Esto incluye cuándo es necesario programar los pods recién creados y cuándo un nodo reducido cierra los pods restantes programados para él.

El costo viene determinado por la decisión que hay detrás de la ampliación y la escalabilidad en función de los eventos. Los recursos se desperdician si un nodo existente está infrautilizado o si se agrega un nodo nuevo que es demasiado grande para los pods entrantes. Según el caso de uso, la cancelación prematura de los módulos puede conllevar costes debido a una decisión agresiva de reducción.

Los grupos de nodos son un concepto abstracto de Kubernetes para un grupo de nodos dentro de un clúster. No es un verdadero recurso de Kubernetes, sino que existe como una abstracción en el escalador automático de clústeres, la API de clústeres y otros componentes. Los nodos de un grupo de nodos comparten propiedades, como etiquetas y defectos, pero pueden constar de varias zonas de disponibilidad o tipos de instancias.

EC2 Los grupos de Auto Scaling se pueden utilizar como una implementación de los grupos de nodos en EC2. EC2 Los grupos de Auto Scaling están configurados para lanzar instancias que se unen automáticamente a sus clústeres de Kubernetes y aplican etiquetas y contaminantes a su recurso de nodo correspondiente en la API de Kubernetes.

EC2 Los grupos de nodos gestionados son otra implementación de los grupos de nodos. EC2 Eliminan la complejidad al configurar manualmente los grupos de EC2 escalado automático y proporcionan funciones de administración adicionales, como la actualización de la versión de los nodos y la terminación sencilla de los nodos.

Uso del escalador automático de clústeres

Normalmente, el Cluster Autoscaler se instala como una Implementación en su clúster. Utiliza la elección del líder para garantizar una alta disponibilidad, pero el trabajo lo realiza una sola réplica a la vez. No es escalable horizontalmente. Para las configuraciones básicas, la configuración predeterminada debería funcionar de inmediato siguiendo las instrucciones de instalación proporcionadas, pero hay algunas cosas a tener en cuenta.

Asegúrese de que:

Emplee el acceso menos privilegiado a la función de IAM

Cuando utilice el Auto Discovery, le recomendamos encarecidamente que emplee el acceso con privilegios mínimos limitando las acciones autoscaling:SetDesiredCapacity y autoscaling:TerminateInstanceInAutoScalingGroup los grupos de Auto Scaling que están dentro del clúster actual.

Esto evitará que un escalador automático de clústeres que se ejecute en un clúster modifique los grupos de nodos de otro clúster, incluso si el --node-group-auto-discovery argumento no se ha limitado a los grupos de nodos del clúster mediante etiquetas (por ejemplo). k8s.io/cluster-autoscaler/<cluster-name>

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/<my-cluster>": "owned"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeTags",
                "ec2:DescribeImages",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:GetInstanceTypesFromInstanceRequirements",
                "eks:DescribeNodegroup"
            ],
            "Resource": "*"
        }
    ]
}

Configuración de los grupos de nodos

Un escalado automático eficaz comienza con la configuración correcta de un conjunto de grupos de nodos para el clúster. Seleccionar el conjunto correcto de grupos de nodos es clave para maximizar la disponibilidad y reducir los costes de las cargas de trabajo. AWS implementa grupos de nodos mediante grupos de EC2 Auto Scaling, que son flexibles para un gran número de casos de uso. Sin embargo, el escalador automático de clústeres hace algunas suposiciones sobre los grupos de nodos. Mantener la coherencia de las configuraciones de EC2 Auto Scaling Group con estas suposiciones minimizará el comportamiento no deseado.

Asegúrese de que:

Nota: Recomendamos utilizar grupos de nodos gestionados por EKS. Los grupos de nodos gestionados vienen con potentes funciones de administración, que incluyen funciones para Cluster AutoScaler, como la detección automática de grupos de EC2 Auto Scaling y la elegante terminación de nodos.

Optimización del rendimiento y la escalabilidad

Comprender la complejidad del tiempo de ejecución del algoritmo de escalado automático le ayudará a ajustar el escalador automático de clústeres para que siga funcionando sin problemas en clústeres grandes con más de 1000 nodos.

Los principales requisitos para ajustar la escalabilidad del escalador automático de clústeres son los recursos que se proporcionan al proceso, el intervalo de escaneo del algoritmo y el número de grupos de nodos del clúster. Hay otros factores que intervienen en la verdadera complejidad del tiempo de ejecución de este algoritmo, como la complejidad de los complementos de programación y el número de pods. Se consideran parámetros no configurables, ya que son inherentes a la carga de trabajo del clúster y no se pueden ajustar fácilmente.

El escalador automático de clústeres carga todo el estado del clúster en la memoria, incluidos los pods, los nodos y los grupos de nodos. En cada intervalo de escaneo, el algoritmo identifica los módulos no programables y simula la programación para cada grupo de nodos. El ajuste de estos factores conlleva diferentes ventajas y desventajas que se deben considerar cuidadosamente para cada caso de uso.

Escalado automático vertical del escalador automático del clúster

La forma más sencilla de escalar el escalador automático de clústeres a clústeres más grandes es aumentar las solicitudes de recursos para su implementación. Tanto la memoria como la CPU deben aumentarse para los clústeres grandes, aunque esto varía considerablemente según el tamaño del clúster. El algoritmo de escalado automático almacena todos los pods y nodos en la memoria, lo que puede provocar un consumo de memoria superior a un gigabyte en algunos casos. Por lo general, el aumento de los recursos se realiza de forma manual. Si considera que el ajuste constante de los recursos está creando una carga operativa, considere la posibilidad de utilizar el Addon Resizer o el escalador automático Vertical Pod.

Reducir el número de grupos de nodos

Minimizar la cantidad de grupos de nodos es una forma de garantizar que el escalador automático de clústeres siga funcionando bien en clústeres grandes. Esto puede resultar difícil para algunas organizaciones que estructuran sus grupos de nodos por equipo o por aplicación. Si bien esto es totalmente compatible con la API de Kubernetes, se considera que va en contra del patrón del escalador automático de clústeres, lo que repercute en la escalabilidad. Existen muchas razones para usar varios grupos de nodos (por ejemplo, Spot o GPUs), pero en muchos casos existen diseños alternativos que logran el mismo efecto y utilizan un número reducido de grupos.

Asegúrese de que:

Reducir el intervalo de escaneo

Un intervalo de escaneo bajo (por ejemplo, 10 segundos) garantizará que el escalador automático del clúster responda lo más rápido posible cuando los módulos no se puedan programar. Sin embargo, cada escaneo genera muchas llamadas de API a la API de Kubernetes y a EC2 Auto Scaling Group o EKS Managed Node Group. APIs Estas llamadas a la API pueden provocar una limitación de la velocidad o incluso la falta de disponibilidad del servicio para su plano de control de Kubernetes.

El intervalo de escaneo predeterminado es de 10 segundos, pero en AWS, el lanzamiento de un nodo tarda mucho más en lanzar una nueva instancia. Esto significa que es posible aumentar el intervalo sin aumentar significativamente el tiempo de escalado vertical general. Por ejemplo, si se tarda 2 minutos en lanzar un nodo, si se cambia el intervalo a 1 minuto, se compensará con una reducción de 6 veces en las llamadas a la API y con ampliaciones un 38% más lentas.

Fragmentación entre grupos de nodos

El escalador automático de clústeres se puede configurar para que funcione en un conjunto específico de grupos de nodos. Con esta funcionalidad, es posible implementar varias instancias del escalador automático de clústeres, cada una configurada para funcionar en un conjunto diferente de grupos de nodos. Esta estrategia le permite utilizar un número arbitrario de grupos de nodos, lo que supone un coste menor que el de la escalabilidad. Solo recomendamos usar esto como último recurso para mejorar el rendimiento.

El escalador automático de clústeres no se diseñó originalmente para esta configuración, por lo que tiene algunos efectos secundarios. Como los fragmentos no se comunican, es posible que varios escaladores automáticos intenten programar un pod no programable. Esto puede provocar una ampliación innecesaria de varios grupos de nodos. Estos nodos adicionales volverán a reducirse después descale-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:

Optimización del costo y la disponibilidad

Spot Instances

Puede utilizar las instancias puntuales en sus grupos de nodos y ahorrar hasta un 90% con respecto al precio bajo demanda, con la ventaja de que las instancias puntuales pueden interrumpirse en cualquier momento cuando EC2 necesite recuperar la capacidad. Se producirán errores de capacidad insuficiente cuando su grupo de EC2 Auto Scaling no pueda ampliarse debido a la falta de capacidad disponible. Aprovechar al máximo la diversidad mediante la selección de varias familias de instancias puede aumentar sus probabilidades de alcanzar la escala deseada al aprovechar muchos grupos de capacidad puntuales y reducir el impacto de las interrupciones de las instancias puntuales 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. Tenga en cuenta que, si necesita recursos garantizados, utilice instancias bajo demanda en lugar de instancias puntuales.

Es fundamental que todos los tipos de instancias tengan una capacidad de recursos similar al configurar políticas de instancias mixtas. El simulador de programación del escalador automático utiliza el primero InstanceType de. MixedInstancePolicy Si los siguientes tipos de instancias son más grandes, es posible que se desperdicien recursos después de ampliarlos. Si son más pequeños, es posible que los pods no se programen en las nuevas instancias debido a una capacidad insuficiente. Por ejemplo, todas las instancias M4, M5, M5a y M5n tienen cantidades similares de CPU y memoria y son excelentes candidatas para una. MixedInstancePolicy La herramienta de selección de EC2 instancias puede ayudarte a identificar tipos de instancias similares.

Se recomienda aislar la capacidad bajo demanda y la puntual en grupos independientes de EC2 Auto Scaling. Es preferible utilizar esta opción en lugar de utilizar una estrategia de capacidad base, ya que las propiedades de programación son fundamentalmente diferentes. Como las instancias puntuales se interrumpen en cualquier momento (cuando es EC2 necesario recuperar la capacidad), los usuarios suelen contaminar sus nodos prevenibles, por lo que es necesario que el pod tolere explícitamente el comportamiento de prevención. Estas contaminaciones dan como resultado propiedades de programación diferentes para los nodos, por lo que deben separarse en varios grupos de EC2 Auto Scaling.

El escalador automático de clústeres tiene un concepto de expansores, que proporciona diferentes estrategias para seleccionar el grupo de nodos que se va a escalar. La estrategia --expander=least-waste es una buena opción de uso general por defecto y, si va a utilizar varios grupos de nodos para diversificar las instancias puntuales (tal y como se describe en la imagen anterior), podría ayudar a optimizar aún más los costes de los grupos de nodos al escalar el grupo, lo que sería mejor utilizar después de la actividad de escalado.

Priorizar un grupo de nodos o un ASG

También puede configurar el escalado automático basado en prioridades mediante el expansor de prioridad. --expander=prioritypermite que su clúster priorice un grupo de nodos o un ASG y, si no puede escalarse por algún motivo, elegirá el siguiente grupo de nodos de la lista priorizada. Esto resulta útil en situaciones en las que, por ejemplo, quieres usar tipos de instancias P3 porque su GPU proporciona un rendimiento óptimo para tu carga de trabajo, pero como segunda opción también puedes usar tipos de instancias P2.

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

Cluster AutoScaler intentará escalar el grupo EC2 Auto Scaling que coincida con el nombre p3-node-group. Si esta operación no se realiza correctamente--max-node-provision-time, intentará escalar un grupo de EC2 Auto Scaling que coincida con el nombre p2-node-group. Este valor predeterminado es 15 minutos y se puede reducir para seleccionar un grupo de nodos con mayor capacidad de respuesta, aunque si el valor es demasiado bajo, puede provocar escalamientos innecesarios.

Sobreaprovisionamiento

El escalador automático de clústeres minimiza los costos al garantizar que los nodos solo se agreguen al clúster cuando sea necesario y se eliminen cuando no se utilicen. Esto afecta considerablemente a la latencia de implementación, ya que muchos pods se ven obligados a esperar a que el nodo se amplíe antes de poder programarlos. 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 mediante módulos temporales con prioridad negativa, que ocupan espacio en el clúster. Cuando los módulos recién creados no se puedan programar y tengan una prioridad más alta, se sustituirá por los módulos temporales para liberar espacio. A continuación, los módulos temporales dejan de poder programarse, lo que activa el escalador automático de clústeres para escalar los nuevos nodos sobreaprovisionados.

El sobreaprovisionamiento tiene otras ventajas menos obvias. Sin el sobreaprovisionamiento, uno de los efectos secundarios de un clúster muy utilizado es que los pods tomarán decisiones de programación menos óptimas si se sigue la preferredDuringSchedulingIgnoredDuringExecution regla de afinidad entre los nodos y los nodos. Un caso de uso común es separar los pods para una aplicación de alta disponibilidad en las distintas zonas de disponibilidad. AntiAffinity El sobreaprovisionamiento puede aumentar considerablemente las probabilidades de que un nodo de la zona correcta esté disponible.

La cantidad de capacidad sobreaprovisionada es una decisión empresarial cuidadosa para su organización. En esencia, se trata de una compensación entre rendimiento y coste. Una forma de tomar esta decisión consiste en determinar la frecuencia media de ampliación y dividirla entre el tiempo que se tarda en escalar un nodo nuevo. Por ejemplo, si en promedio se necesita un nodo nuevo cada 30 segundos y EC2 se tarda 30 segundos en aprovisionar un nodo nuevo, un solo nodo de sobreaprovisionamiento garantizará que siempre haya un nodo adicional disponible, lo que reducirá la latencia de programación en 30 segundos a costa de una sola instancia adicional EC2 . Para mejorar las decisiones de programación zonal, aprovisione en exceso un número de nodos igual al número de zonas de disponibilidad de su grupo de EC2 Auto Scaling para garantizar que el planificador pueda seleccionar la mejor zona para los pods entrantes.

Evite los desalojos a escala reducida

Algunas cargas de trabajo son costosas de expulsar. El análisis de macrodatos, las tareas de aprendizaje automático y las pruebas se completarán con el tiempo, pero deberán reiniciarse si se interrumpen. El escalador automático de clústeres intentará reducir la escala de cualquier nodo situado debajo del nodo scale-down-utilization-threshold, lo que interrumpirá los pods que queden en el nodo. Esto se puede evitar asegurándose de que los pods cuyo desalojo resulta caro estén protegidos por una etiqueta reconocida por el escalador automático de clústeres.

Asegúrese de que:

Casos de uso avanzados

Volúmenes de EBS

El almacenamiento persistente es fundamental para crear aplicaciones con estado, como bases de datos o cachés distribuidas. Los volúmenes de EBS permiten este caso de uso en Kubernetes, pero están limitados a una zona específica. Estas aplicaciones pueden tener una alta disponibilidad si se dividen en varias zonas AZs mediante un volumen de EBS independiente para cada zona de disponibilidad. El escalador automático de clústeres puede entonces equilibrar el escalado de los grupos de escalado automático. EC2

Asegúrese de que:

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 módulos en una zona específica. Esto se puede lograr configurando la afinidad de los pods para todos los pods coprogramados o bien utilizando la afinidad de nodos. topologyKey: failure-domain.beta.kubernetes.io/zone A continuación, el escalador automático de clústeres ampliará una zona específica para adaptarla a las demandas. Es posible que desee asignar varios grupos de EC2 Auto Scaling, uno por zona de disponibilidad, para permitir la conmutación por error para toda la carga de trabajo coprogramada.

Asegúrese de que:

Aceleradores

Algunos clústeres utilizan aceleradores de hardware especializados, como la GPU. Al ampliarse, el complemento del dispositivo acelerador puede tardar varios minutos en anunciar el recurso en el clúster. El escalador automático del clúster ha simulado que este nodo tendrá el acelerador, pero hasta que el acelerador esté listo y actualice los recursos disponibles en el nodo, no se podrán programar los módulos pendientes en el nodo. Esto puede generar un escalado horizontal innecesario repetidas veces.

Además, no se considerará la posibilidad de reducir la capacidad de los nodos con aceleradores y un alto uso de la CPU o la memoria, incluso si el acelerador no se utiliza. Este comportamiento puede resultar caro debido al coste relativo de los aceleradores. En cambio, el escalador automático de clústeres puede aplicar reglas especiales para considerar la posibilidad de reducir la escala de los nodos si tienen aceleradores desocupados.

Para garantizar el comportamiento correcto en estos casos, puedes configurar el kubelet de los nodos del acelerador para etiquetar el nodo antes de que se una al clúster. El escalador automático de clústeres utilizará este selector de etiquetas para activar el comportamiento optimizado del acelerador.

Asegúrese de que:

Escalando desde 0

El escalador automático de clústeres es capaz de escalar los grupos de nodos desde y hacia cero, lo que puede generar importantes ahorros de costos. Detecta los recursos de CPU, memoria y GPU de un grupo de Auto Scaling al inspeccionar lo InstanceType especificado en su LaunchConfiguration o LaunchTemplate. Algunos pods requieren recursos adicionales, como WindowsENI o específicos, PrivateIPv4Address NodeSelectors o Taints, que no se pueden detectar en el. LaunchConfiguration El Auto Scaler de clústeres puede tener en cuenta estos factores descubriéndolos a partir de las etiquetas del Grupo EC2 Auto Scaling. Por ejemplo:

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: Tenga en cuenta que, al escalar a cero, su capacidad vuelve a estar disponible EC2 y es posible que no esté disponible en el futuro.

Parámetros adicionales

Existen muchas opciones de configuración que se pueden utilizar para ajustar el comportamiento y el rendimiento del Cluster Autoscaler. Encontrará una lista completa de parámetros en GitHub.

Recursos adicionales

Esta página contiene una lista de presentaciones y demostraciones de Cluster AutoScaler. Si quieres añadir una presentación o una demostración aquí, envía una solicitud de cambios.

Referencias