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.

Escalador automático de clústeres

Descripción general de

El escalador automático de clústeres de Kubernetes es una popular solución de escalado automático de clústeres mantenida por SIG Autoscaling. https://github.com/kubernetes/community/tree/master/sig-autoscaling Es responsable de garantizar que el clúster tenga suficientes nodos para programar los pods sin desperdiciar recursos. Controla los pods que no se programan y 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 te permiten equilibrar el rendimiento, la escalabilidad, el costo y la disponibilidad. Además, esta guía proporcionará 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 definiciones que figuran a continuación para los fines de este documento.

La escalabilidad hace referencia al rendimiento del escalador automático de clústeres a medida que aumenta el número de pods y nodos del clúster de Kubernetes. 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 a la perfección tomaría una decisión al instante y activaría una acción de escalado en respuesta a estímulos, como que un pod dejara de programarse.

La disponibilidad significa que los pods se pueden programar rápidamente y sin interrupciones. Esto incluye los casos en los que es necesario programar los pods recién creados y cuando un nodo reducido finaliza los pods restantes programados para él.

El costo viene determinado por la decisión que hay detrás de los eventos de escalamiento horizontal y escalado interno. 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 finalización prematura de los módulos puede generar costos debido a la decisión agresiva de reducirlos.

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 contaminantes, pero pueden constar de varias zonas de disponibilidad o tipos de instancias.

Los grupos de escalado automático de EC2 se pueden usar como implementación de grupos de nodos en EC2. Los grupos de EC2 Auto Scaling están configurados para lanzar instancias que se unan automáticamente a sus clústeres de Kubernetes y aplicar etiquetas y defectos a su recurso de nodos correspondiente en la API de Kubernetes.

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

Funcionamiento 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 de líderes para garantizar una alta disponibilidad, pero el trabajo se realiza con 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:

Utilice el acceso con menos privilegios a la función de IAM

Cuando utilice la detección https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#Auto-discovery-setup automática, le recomendamos encarecidamente que utilice el acceso con privilegios mínimos limitando las acciones autoscaling:SetDesiredCapacity y autoscaling:TerminateInstanceInAutoScalingGroup a los grupos de Auto Scaling que pertenecen al clúster actual.

Esto impedirá que un escalador automático de clústeres que se ejecute en un clúster modifique los grupos de nodos de otro clúster, aunque el --node-group-auto-discovery argumento no se limite 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 tus grupos de nodos

El escalado automático efectivo comienza con la configuración correcta de un conjunto de grupos de nodos para tu clúster. Seleccionar el conjunto correcto de grupos de nodos es clave para maximizar la disponibilidad y reducir los costos de las cargas de trabajo. AWS implementa los grupos de nodos mediante los grupos de escalado automático de EC2, que son flexibles para una gran cantidad de casos de uso. Sin embargo, el escalador automático de clústeres hace algunas suposiciones sobre sus grupos de nodos. Si las configuraciones de los grupos de EC2 Auto Scaling se ajustan a estas suposiciones, se minimizará el comportamiento no deseado.

Asegúrese de que:

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. https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/proposals/scalability_tests.md

Los principales elementos para ajustar la escalabilidad del escalador automático de clústeres son los recursos proporcionados 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 la programación de los complementos y el número de pods. Se considera que estos parámetros no se pueden configurar, ya que son naturales para la carga de trabajo del clúster y no se pueden ajustar fácilmente.

El escalador automático del clúster 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 pods que no se pueden programar 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 su caso de uso.

Escalar automáticamente de forma vertical el escalador automático de clústeres

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. Se deben aumentar tanto la memoria como la CPU en 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 generar 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 descubres que el ajuste constante de los recursos supone una carga operativa, considera la posibilidad de utilizar el Addon Resizer o el Vertical Pod Autoscaler.

Reducir el número de grupos de nodos

Minimizar el número de grupos de nodos es una forma de garantizar que el escalador automático de clústeres siga funcionando correctamente 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 se trata de un antipatrón del escalador automático de clústeres, con repercusiones en la escalabilidad. Hay muchas razones para usar varios grupos de nodos (por ejemplo, Spot o GPU), pero en muchos casos hay diseños alternativos que logran el mismo efecto con 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 de clústeres responda lo antes posible cuando los pods dejen de ser programables. Sin embargo, cada análisis genera muchas llamadas a la API de Kubernetes y a las API de EC2 Auto Scaling Group o EKS Managed Node Group. Estas llamadas a la API pueden provocar la limitación de la velocidad o incluso la falta de disponibilidad del servicio para tu plano de control de Kubernetes.

El intervalo de análisis 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, cambiar el intervalo a 1 minuto supondrá una compensación entre 6 veces menos llamadas a la API y escalamientos un 38% más lentos.

Dividir 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 te permite utilizar cantidades arbitrariamente grandes de grupos de nodos, lo que supone un cambio entre el coste y la escalabilidad. Solo recomendamos usarlo 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 que no se pueda programar. Esto puede provocar una reducción innecesaria de varios grupos de nodos. Estos nodos adicionales se reducirán después delscale-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 usar instancias puntuales en sus grupos de nodos y ahorrar hasta un 90% respecto al precio bajo demanda, con la desventaja 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. Maximizar la diversidad seleccionando muchas familias de instancias puede aumentar sus probabilidades de lograr la escalabilidad 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. Ten en cuenta que, si necesitas recursos garantizados, usa On-Demand instancias en lugar de instancias puntuales.

Es fundamental que todos los tipos de instancias tengan una capacidad de recursos similar al configurar las políticas de instancias mixtas. El simulador de programación del escalador automático usa el primero InstanceType del. MixedInstancePolicy Si los siguientes tipos de instancias son más grandes, es posible que se desperdicien recursos tras una ampliación. Si son más pequeños, es posible que sus pods no puedan programar las nuevas instancias debido a la falta de capacidad. 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 instancias EC2 puede ayudarlo a identificar tipos de instancias similares.

Se recomienda aislar On-Demand y clasificar la capacidad en grupos independientes de EC2 Auto Scaling. Es preferible utilizar esta estrategia en lugar de utilizar una estrategia de capacidad básica, ya que las propiedades de programación son fundamentalmente diferentes. Dado que las instancias puntuales se interrumpen en cualquier momento (cuando EC2 necesita recuperar la capacidad), los usuarios suelen dañar los nodos que pueden interceptar, lo que exige que los pods toleren explícitamente el comportamiento de preferencia. Estas alteraciones dan lugar a diferentes propiedades de programación para los nodos, por lo que deben dividirse en varios grupos de escalado automático de EC2.

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

Priorizar un grupo de nodos//ASG

También puedes configurar el escalado automático basado en prioridades mediante el expansor de prioridades. --expander=prioritypermite a tu clúster priorizar un grupo de nodos o un ASG y, si no puede escalar por cualquier motivo, elegirá el siguiente grupo de nodos de la lista priorizada. Esto es útil en situaciones en las que, por ejemplo, quieres usar los tipos de instancia P3 porque su GPU proporciona un rendimiento óptimo para tu carga de trabajo, pero como segunda opción también puedes usar los 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á ampliar el grupo de EC2 Auto Scaling 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 tenga el nombre p2-node-group. Este valor predeterminado es de 15 minutos y se puede reducir para seleccionar grupos de nodos con mayor capacidad de respuesta. Sin embargo, 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 usen. Esto afecta considerablemente a la latencia de implementación, ya que muchos pods se verán obligados a esperar a que un nodo escale hacia arriba 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 pods temporales con prioridad negativa, que ocupan espacio en el clúster. Cuando los pods recién creados no se puedan programar y tengan una prioridad más alta, se preferirán los pods temporales para dejar espacio. Entonces, los pods temporales dejan de ser programables, lo que hace que el escalador automático del clúster escale de forma gradual 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 utilizan la preferredDuringSchedulingIgnoredDuringExecution regla de afinidad de nodos o pods. Un caso práctico habitual es separar los pods de una aplicación de alta disponibilidad en 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 prudente para su organización. En esencia, se trata de un equilibrio entre rendimiento y costo. Una forma de tomar esta decisión es determinar la frecuencia promedio de ampliación y dividirla por la cantidad de tiempo que lleva escalar un nuevo nodo. Por ejemplo, si, de media, se necesita un nodo nuevo cada 30 segundos y EC2 tarda 30 segundos en aprovisionar un nodo nuevo, un único 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 instancia EC2 adicional. Para mejorar las decisiones de programación zonal, aprovisione en exceso una cantidad de nodos igual a la cantidad de zonas de disponibilidad de su grupo de Auto Scaling de EC2 para garantizar que el programador pueda seleccionar la mejor zona para los pods entrantes.

Impida el desalojo 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 ejecutadas 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 que esté por debajo del umbral de reducción de la utilización, lo que interrumpirá los pods que queden en el nodo. Esto se puede evitar asegurándose de que los pods cuyo desalojo es 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 buen estado, como bases de datos o cachés distribuidos. 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 de disponibilidad 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 de EC2.

Asegúrese de que:

Co-Scheduling

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. Esto se puede lograr configurando la afinidad de los pods para todos los pods programados conjuntamente o que se utilice la afinidad de nodos. topologyKey: failure-domain.beta.kubernetes.io/zone A continuación, el escalador automático de clústeres escalará una zona específica para adaptarla a las demandas. Es posible que desee asignar varios grupos de Auto Scaling de EC2, 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 aprovechan los aceleradores de hardware especializados, como la GPU. Al escalar, el complemento del dispositivo acelerador puede tardar varios minutos en anunciar el recurso en el clúster. El escalador automático de clústeres ha simulado que este nodo tendrá el acelerador, pero hasta que el acelerador esté listo y actualice los recursos disponibles del nodo, no se podrán programar los pods pendientes en el nodo. Esto puede generar un escalado horizontal innecesario repetidas veces.

Además, no se considerará la posibilidad de reducir la escala de los nodos con aceleradores y un uso elevado de la CPU o la memoria, aunque el acelerador no esté en uso. 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 de tu 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

Cluster Autoscaler es capaz de escalar grupos de nodos a cero y desde cero, lo que puede generar importantes ahorros de costos. Detecta los recursos de CPU, memoria y GPU de un grupo de Auto Scaling inspeccionando lo InstanceType especificado en su o. LaunchConfiguration LaunchTemplate Algunos pods requieren recursos adicionales, como WindowsENI PrivateIPv4Address manchas específicas NodeSelectors o que no se pueden descubrir desde el. LaunchConfiguration El escalador automático 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

Parámetros adicionales

Existen muchas opciones de configuración que se pueden utilizar para ajustar el comportamiento y el rendimiento del Cluster Autoscaler. La lista completa de parámetros está disponible 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