Container Service for Kubernetes:Node auto scaling FAQ

Los recursos Available del nodo pueden no coincidir con las especificaciones del tipo de instancia

Los recursos disponibles en un nodo recién aprovisionado siempre son ligeramente inferiores a las especificaciones anunciadas del tipo de instancia. El sistema operativo subyacente y los daemons del sistema en la instancia de Elastic Compute Service (ECS) consumen una parte de la CPU, la memoria y el almacenamiento antes de que se programe cualquier pod. Para obtener más detalles, consulte Why is the memory size different from the instance type specification after I purchase an instance?

Debido a este consumo adicional, tenga en cuenta lo siguiente al configurar las solicitudes de recursos de los pods:

• Mantenga el total de solicitudes por debajo de la capacidad completa de la instancia. Como regla general, las solicitudes totales de recursos de un pod no deben superar el 70 % de la capacidad del nodo.

• Considere los pods estáticos que no se gestionan como DaemonSets. El cluster-autoscaler solo toma en cuenta las solicitudes de recursos de los pods de Kubernetes (incluidos los pods pendientes y los de DaemonSet) cuando evalúa la capacidad del nodo. Reserve manualmente recursos para cualquier pod estático que quede fuera de este alcance.

• Pruebe los pods que demandan muchos recursos antes de desplegarlos a gran escala. Si un pod solicita más del 70 % de los recursos de un nodo, pruebe y confirme de antemano que se puede programar en un nodo del mismo tipo de instancia.

La compatibilidad con políticas de programación es limitada

El cluster-autoscaler solo admite un conjunto limitado de políticas de programación cuando determina si un pod no programable cabe en un node pool con Auto Scaling habilitado. Para obtener más información, consulte ¿Qué políticas de programación utiliza cluster-autoscaler?

Solo se admiten políticas de tipo resource en ResourcePolicy

Cuando utilice ResourcePolicy para personalizar la prioridad de los recursos elásticos, solo se admiten las políticas de tipo resource. Para obtener más detalles, consulte Customize elastic resource priority scheduling.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
  units:
  - resource: ecs
  - resource: eci

No se admite el escalado de un tipo de instancia específico en un node pool con varios tipos

Si un node pool se configura con varios tipos de instancia, no es posible indicar al cluster-autoscaler que aprovisione un tipo de instancia específico durante el scale-out. El autoscaler modela la capacidad de todo el node pool con base en el tipo de instancia disponible más pequeño, es decir, el que tiene menos recursos entre todos los tipos configurados. Para obtener más detalles, consulte ¿Cómo calcula el autoscaler la capacidad de un node pool con varios tipos de instancia?

Los pods con restricciones de zona específicas podrían no activar el scale-out en node pools multizona

Si un node pool abarca varias zonas de disponibilidad, es posible que un pod con dependencia de zona no active un scale-out. Esto aplica a los pods que requieren una zona específica debido a:

• Una solicitud de volumen persistente (PVC) vinculada a un volumen en esa zona.

• Un nodeSelector, nodeAffinity u otra regla de programación dirigida a la zona.

En estos casos, el cluster-autoscaler podría no aprovisionar un nodo en la zona requerida. Para conocer más escenarios, consulte ¿Por qué mi node pool no aprovisiona nuevos nodos?

Las restricciones de almacenamiento no son visibles para el autoscaler

El autoscaler no detecta las restricciones de almacenamiento a nivel de pod, tales como:

• La necesidad de ejecutarse en una zona de disponibilidad específica para acceder a un volumen persistente (PV).

• El requisito de un nodo compatible con un tipo de disco específico (por ejemplo, ESSD).

Solución: Configure un node pool dedicado para las aplicaciones con dependencias de almacenamiento antes de habilitar Auto Scaling. Establezca previamente la zona de disponibilidad, el tipo de instancia y el tipo de disco en la configuración del node pool. Así se garantiza que los nodos recién aprovisionados cumplan con los requisitos de almacenamiento del pod.

Asegúrese también de que sus pods no hagan referencia a un PVC en estado Terminating. Un pod que no se puede programar porque su PVC está en terminación fallará de manera continua. Esto puede provocar que el cluster-autoscaler tome decisiones incorrectas de scale-out o scale-in (por ejemplo, desalojar el pod).

¿Qué políticas de programación utiliza cluster-autoscaler para determinar si un pod no programable se puede asignar a un node pool con Auto Scaling habilitado?

El cluster-autoscaler evalúa las siguientes políticas de programación:

• PodFitsResources

• GeneralPredicates

• PodToleratesNodeTaints

• MaxGCEPDVolumeCount

• NoDiskConflict

• CheckNodeCondition

• CheckNodeDiskPressure

• CheckNodeMemoryPressure

• CheckNodePIDPressure

• CheckVolumeBinding

• MaxAzureDiskVolumeCount

• MaxEBSVolumeCount

• ready

• NoVolumeZoneConflict

¿Qué tipos de recursos puede simular cluster-autoscaler durante el análisis de programación?

El cluster-autoscaler puede simular y evaluar los siguientes tipos de recursos:

cpu
memory
sigma/eni
ephemeral-storage
aliyun.com/gpu-mem (shared GPUs only)
nvidia.com/gpu

Para escalar con base en otros tipos de recursos, consulte ¿Cómo configuro recursos personalizados para un node pool con Auto Scaling habilitado?

¿Por qué mi node pool no aprovisiona nuevos nodos?

Revise las siguientes causas comunes:

Auto Scaling no está habilitado en el node pool

El escalado automático de nodos solo funciona en node pools con Auto Scaling configurado. Asegúrese de que la función de escalado automático a nivel de clúster esté habilitada y de que el modo de escalado del node pool esté establecido en Auto. Para obtener más detalles, consulte Enable node auto scaling.

Las solicitudes de recursos del pod superan la capacidad asignable

Las especificaciones anunciadas de una instancia ECS representan la capacidad total, no la capacidad asignable. ACK reserva una parte de la CPU, la memoria y el almacenamiento para el kernel del sistema operativo, los servicios del sistema y los daemons de Kubernetes (kubelet, kube-proxy, Terway y el runtime de contenedores). Esto genera una diferencia entre la capacidad total del nodo y sus recursos asignables.

Al tomar decisiones de scale-out, el cluster-autoscaler utiliza la resource reservation policy de Kubernetes 1.28 y versiones anteriores, sin importar la versión del clúster de ACK.

Para usar una política de reserva más precisa, cambie a node instant scaling, que emplea el algoritmo actualizado. También puede definir reservas de recursos personalizadas en la configuración del node pool.

Para obtener detalles sobre el consumo de recursos:

• Recursos del sistema: Why does a purchased instance have a memory size different from the instance type?

• Los nodos predeterminados instalan add-ons del sistema; mantenga las solicitudes de recursos de los pods por debajo de la capacidad anunciada del tipo de instancia. Resource reservation policy

Una restricción de zona del pod impide el scale-out

Si un pod tiene una dependencia de programación en una zona de disponibilidad específica, ya sea por un PVC vinculado a un volumen zonal o por una regla de afinidad de nodos, es posible que el cluster-autoscaler no pueda aprovisionar un nodo en esa zona. Este escenario es más común en un node pool multizona.

Faltan los permisos obligatorios

El cluster-autoscaler requiere permisos con alcance de clúster que se otorgan de forma individual por cada clúster. Complete todos los pasos de autorización descritos en Enable node auto scaling for the cluster.

Comportamiento de amortiguamiento ante nodos con problemas

El autoscaler entra en estado de amortiguamiento cuando ocurre alguna de las siguientes condiciones en un node pool con escalado automático:

• Un nodo no se une al clúster dentro del tiempo esperado.

• Un nodo permanece en estado NotReady más allá de la duración permitida.

Mientras se encuentra en este estado de amortiguamiento, todas las operaciones de escalado se suspenden hasta que se resuelvan los nodos con problemas. De esta forma se garantiza la precisión de las decisiones de escalado posteriores.

No hay nodos en el clúster

El cluster-autoscaler no se puede ejecutar cuando el clúster no tiene nodos. Configure cada node pool con un mínimo de dos nodos para garantizar el funcionamiento normal de los add-ons y componentes del clúster.

Para escalar desde cero nodos o reducir hasta cero nodos, utilice node instant scaling.

Si un grupo de escalado se configura con varios tipos de instancia, ¿cómo calcula el autoscaler la capacidad del grupo para tomar decisiones de escalado?

Cuando un grupo de escalado tiene varios tipos de instancia, el cluster-autoscaler modela la capacidad del grupo con el valor mínimo de cada dimensión de recursos entre todos los tipos configurados.

Por ejemplo, con dos tipos de instancia:

• Tipo de instancia A: 4 vCPU, 32 GiB de memoria

• Tipo de instancia B: 8 vCPU, 16 GiB de memoria

El autoscaler calcula lo siguiente:

• CPU mínima: min(4, 8) = 4 vCPU

• Memoria mínima: min(32, 16) = 16 GiB

Todo el grupo de escalado se trata como si solo pudiera aprovisionar nodos con 4 vCPU y 16 GiB. Un pod pendiente que solicite más de 4 vCPU o más de 16 GiB no activará un scale-out para este grupo, aunque el tipo de instancia B sí podría satisfacer la solicitud de CPU.

Si hay varios node pools con Auto Scaling habilitado, ¿cómo elige cluster-autoscaler cuál escalar?

Cuando un pod no se puede programar, el cluster-autoscaler simula qué node pools tienen capacidad para alojarlo. La simulación evalúa las etiquetas, los taints y los tipos de instancia disponibles de cada node pool.

Si varios node pools cumplen con los requisitos, el autoscaler aplica de forma predeterminada la estrategia de menor desperdicio: selecciona el node pool que deja menos recursos de CPU y memoria sin utilizar después de programar el pod.

¿Cómo configuro recursos personalizados para un node pool con Auto Scaling habilitado?

Agregue etiquetas de ECS con el siguiente prefijo al node pool para que el autoscaler reconozca los recursos personalizados disponibles en el pool o los valores exactos de recursos específicos:

k8s.io/cluster-autoscaler/node-template/resource/{resource_name}:{resource_size}

Por ejemplo:

k8s.io/cluster-autoscaler/node-template/resource/hugepages-1Gi:2Gi

¿Por qué no puedo habilitar Auto Scaling para un node pool?

No es posible habilitar Auto Scaling en los siguientes casos:

• Es el node pool predeterminado. La función de escalado automático de nodos no es compatible con el node pool predeterminado del clúster.

• El node pool contiene nodos agregados manualmente. Elimine primero los nodos agregados de forma manual o cree un nuevo node pool dedicado con Auto Scaling habilitado desde el inicio.

• El node pool utiliza instancias de suscripción. El escalado automático de nodos solo funciona con instancias pay-as-you-go.

¿Por qué cluster-autoscaler no reduce un nodo?

El cluster-autoscaler omite un nodo durante el scale-in si se cumple alguna de las siguientes condiciones:

• La utilización de los pods supera el umbral. Las solicitudes totales de recursos de los pods en el nodo están por encima del umbral de scale-in configurado.

• El nodo ejecuta pods del espacio de nombres kube-system. De forma predeterminada, el cluster-autoscaler no elimina nodos que ejecutan pods del espacio de nombres kube-system.

• Un pod tiene restricciones de programación estrictas. Si un pod utiliza un nodeSelector o nodeAffinity que le impide reprogramarse en cualquier otro nodo, el nodo no se puede reducir.

• Un pod está protegido por un PodDisruptionBudget (PDB). Si desalojar un pod infringe la configuración minAvailable del PDB, el nodo se conserva. Para obtener más detalles, consulte PodDisruptionBudget.

• Durante el periodo de retraso de reducción, si los pods recién programados (como los temporales creados por un Job) mantienen la utilización de recursos por encima del umbral, el nodo no se reduce. Los pods que no crea un Deployment, ReplicaSet, Job o StatefulSet bloquean la eliminación del nodo de forma predeterminada.

Para consultar la lista completa de condiciones que pueden bloquear el scale-in de un nodo, vea las preguntas frecuentes de cluster-autoscaler.

¿Cómo habilito o deshabilito el desalojo para un DaemonSet específico?

La configuración Evict DaemonSet Pods en la configuración del clúster controla el desalojo de DaemonSets de forma global. Para obtener más información, consulte Step 1: Enable node auto scaling for the cluster.

Anule esta configuración por cada DaemonSet mediante una anotación en los pods del DaemonSet (en la plantilla del pod, no en el objeto DaemonSet):

• Habilite el desalojo para los pods de un DaemonSet específico:

  cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"

• Deshabilite el desalojo para los pods de un DaemonSet específico:

  cluster-autoscaler.kubernetes.io/enable-ds-eviction: "false"

Si la configuración global Evict DaemonSet Pods está deshabilitada, enable-ds-eviction: "true" solo aplica a los pods de DaemonSet en nodos no vacíos. Para desalojar pods de DaemonSet de nodos vacíos, habilite primero la configuración global.

De forma predeterminada, el cluster-autoscaler desaloja los pods de DaemonSet sin bloquear el proceso y continúa sin esperar a que finalice el desalojo. Para que el autoscaler espere a que un pod de DaemonSet específico se desaloje por completo antes de continuar, agregue la siguiente anotación junto con enable-ds-eviction:

cluster-autoscaler.kubernetes.io/wait-until-evicted: "true"

Estas anotaciones no tienen efecto en los pods que no forman parte de un DaemonSet.

¿Qué tipos de pods pueden impedir que cluster-autoscaler elimine un nodo?

El cluster-autoscaler puede bloquear la eliminación de un nodo en los siguientes casos:

• El pod no lo creó un controlador nativo de Kubernetes (por ejemplo, no lo generó un Deployment, ReplicaSet, Job o StatefulSet).

• El pod en el nodo no se puede terminar ni migrar de forma segura.

Para consultar la lista completa de condiciones que bloquean el scale-in de un nodo, vea What types of pods can prevent CA from removing a node?

¿cluster-autoscaler es compatible con CustomResourceDefinitions (CRDs)?

No. El cluster-autoscaler solo admite objetos estándar de Kubernetes y no es compatible con CRDs.

¿Cómo retraso el scale-out para un pod específico?

Agregue la anotación cluster-autoscaler.kubernetes.io/pod-scale-up-delay al pod. El cluster-autoscaler no considerará el pod para el scale-out hasta que permanezca sin programarse durante más tiempo que el retraso especificado. Esto le da al programador de Kubernetes tiempo adicional para colocar el pod en nodos existentes antes de activar un scale-out.

Por ejemplo:

cluster-autoscaler.kubernetes.io/pod-scale-up-delay: "600s"

¿Cómo utilizo las anotaciones de pod para controlar el comportamiento de scale-in?

Utilice la anotación cluster-autoscaler.kubernetes.io/safe-to-evict para marcar explícitamente un pod como seguro o no seguro para desalojar durante el scale-in:

• Impedir el scale-in del nodo: Agregue "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" a un pod que se ejecute en el nodo. El autoscaler no terminará el nodo mientras este pod esté presente.

• Permitir el scale-in del nodo: Agregue "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para marcar explícitamente el pod como seguro para desalojar.

¿Cómo evito que cluster-autoscaler reduzca un nodo específico?

Agregue la anotación cluster-autoscaler.kubernetes.io/scale-down-disabled: "true" al nodo. Reemplace <nodename> con el nombre del nodo de destino:

kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

¿Cómo actualizo cluster-autoscaler a la versión más reciente?

1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Nodes > Node Pools.

3. Haga clic en Edit a la derecha de Node Scaling. En el panel que aparece, haga clic en OK para actualizar a la versión más reciente.

¿Qué acciones activan una actualización automática de cluster-autoscaler?

El cluster-autoscaler se actualiza automáticamente cuando:

• Se modifica la configuración de escalado automático.

• Se crea, elimina o actualiza un node pool con Auto Scaling habilitado.

• La versión de Kubernetes del clúster se actualiza correctamente.

El escalado de nodos no funciona en mi clúster administrado de ACK aunque la autorización de roles ya se completó

Esto suele significar que falta el token addon.aliyuncsmanagedautoscalerrole.token en un Secret del espacio de nombres kube-system. ACK utiliza el Worker Role del clúster para habilitar el escalado automático, y este token es obligatorio para la autenticación.

Vuelva a aplicar la política necesaria al Worker Role desde la consola de ACK:

1. En la página Clústeres de ACK, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Nodes > Node Pools.

2. En la página Node Pools, haga clic en Enable a la derecha de Node Scaling.

3. Siga las instrucciones en pantalla para autorizar KubernetesWorkerRole y adjuntar la política de sistema AliyunCSManagedAutoScalerRolePolicy.

   En el cuadro de diálogo Node Scaling Configuration, una vez que la comprobación previa se complete correctamente, haga clic en el enlace del nombre del rol en el área de aviso para ir a Resource Access Management (RAM) y finalizar la autorización.

4. Reinicie manualmente el Deployment cluster-autoscaler (escalado automático de nodos) o el Deployment ack-goatscaler (escalado instantáneo de nodos) en el espacio de nombres kube-system para que los permisos surtan efecto de inmediato.