Container Service for Kubernetes:Node auto scaling FAQ

Les ressources disponibles sur un nœud peuvent ne pas correspondre aux spécifications du type d'instance

Les ressources disponibles sur un nœud nouvellement provisionné sont toujours légèrement inférieures aux spécifications annoncées pour le type d'instance. Le système d'exploitation sous-jacent et les démons système de l'instance Elastic Compute Service (ECS) consomment une partie du CPU, de la mémoire et du stockage avant qu'un pod ne soit planifié. Pour plus d'informations, consultez la section Pourquoi la taille de la mémoire diffère-t-elle des spécifications du type d'instance après l'achat ?

En raison de cette surcharge, tenez compte des éléments suivants lors de la configuration des demandes de ressources des pods :

• Maintenez le total des demandes en dessous de la capacité totale de l'instance. En règle générale, les demandes totales de ressources d'un pod ne doivent pas dépasser 70 % de la capacité du nœud.

• Prenez en compte les pods statiques non gérés en tant que DaemonSets. Le cluster-autoscaler ne tient compte que des demandes de ressources des pods Kubernetes (y compris les pods en attente et les pods DaemonSet) lors de l'évaluation de la capacité des nœuds. Réservez manuellement des ressources pour tous les pods statiques hors de ce périmètre.

• Testez les pods gourmands en ressources avant de les déployer à grande échelle. Si un pod demande plus de 70 % des ressources d'un nœud, testez et confirmez à l'avance que le pod peut être planifié sur un nœud du même type d'instance.

La prise en charge des politiques de planification est limitée

Le cluster-autoscaler ne prend en charge qu'un ensemble limité de politiques de planification pour déterminer si un pod non planifiable peut s'intégrer dans un pool de nœuds avec la mise à l'échelle automatique activée. Pour plus de détails, voir la section Quelles sont les politiques de planification utilisées par cluster-autoscaler ?.

Seules les politiques de type resource sont prises en charge dans ResourcePolicy

Lorsque vous utilisez ResourcePolicy pour personnaliser la priorité des ressources élastiques, seules les politiques de type resource sont prises en charge. Pour plus d'informations, consultez la page Personnaliser la planification prioritaire des ressources élastiques.

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

La mise à l'échelle vers le haut d'un type d'instance spécifique dans un pool de nœuds multi-types n'est pas prise en charge

Si un pool de nœuds est configuré avec plusieurs types d'instances, vous ne pouvez pas demander au cluster-autoscaler de provisionner un type d'instance spécifique lors de la montée en charge. L'autoscaler modélise la capacité de l'ensemble du pool de nœuds en se basant sur le type d'instance disponible le plus petit, c'est-à-dire celui disposant du moins de ressources parmi tous les types configurés. Pour plus de détails, voir la section Comment l'autoscaler calcule-t-il la capacité d'un pool de nœuds comportant plusieurs types d'instances ?.

Les pods soumis à des contraintes spécifiques à une zone peuvent ne pas déclencher la montée en charge dans les pools de nœuds multi-zones

Si un pool de nœuds s'étend sur plusieurs zones de disponibilité, un pod ayant une dépendance vis-à-vis d'une zone spécifique peut ne pas déclencher une montée en charge. Cela concerne les pods qui nécessitent une zone particulière en raison :

• D'une revendication de volume persistant (PVC) liée à un volume situé dans cette zone.

• D'un nodeSelector, d'une nodeAffinity ou d'une autre règle de planification ciblant la zone.

Dans ces cas, le cluster-autoscaler peut échouer à provisionner un nœud dans la zone requise. Pour d'autres scénarios, consultez la section Pourquoi mon pool de nœuds échoue-t-il à provisionner de nouveaux nœuds ?.

Les contraintes de stockage sont invisibles pour l'autoscaler

L'autoscaler n'a aucune connaissance des contraintes de stockage au niveau des pods, telles que :

• La nécessité de s'exécuter dans une zone de disponibilité spécifique pour accéder à un volume persistant (PV).

• L'exigence d'un nœud prenant en charge un type de disque spécifique (tel que ESSD).

Solution : Configurez un pool de nœuds dédié pour les applications ayant des dépendances de stockage avant d'activer la mise à l'échelle automatique. Prédéfinissez la zone de disponibilité, le type d'instance et le type de disque dans la configuration du pool de nœuds afin de garantir que les nœuds nouvellement provisionnés répondent aux exigences de stockage du pod.

Assurez-vous également que vos pods ne référencent pas un PVC dans un état Terminating. Un pod incapable d'être planifié car son PVC est en cours de terminaison échouera continuellement, ce qui peut amener le cluster-autoscaler à prendre des décisions incorrectes de montée ou de descente en charge (par exemple, en expulsant le pod).

Quelles sont les politiques de planification utilisées par cluster-autoscaler pour déterminer si un pod non planifiable peut être attribué à un pool de nœuds avec la mise à l'échelle automatique activée ?

Le cluster-autoscaler évalue les politiques de planification suivantes :

• PodFitsResources

• GeneralPredicates

• PodToleratesNodeTaints

• MaxGCEPDVolumeCount

• NoDiskConflict

• CheckNodeCondition

• CheckNodeDiskPressure

• CheckNodeMemoryPressure

• CheckNodePIDPressure

• CheckVolumeBinding

• MaxAzureDiskVolumeCount

• MaxEBSVolumeCount

• ready

• NoVolumeZoneConflict

Quels types de ressources le cluster-autoscaler peut-il simuler lors de l'analyse de planification ?

Le cluster-autoscaler peut simuler et évaluer les types de ressources suivants :

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

Pour effectuer une mise à l'échelle basée sur d'autres types de ressources, consultez la section Comment configurer des ressources personnalisées pour un pool de nœuds avec la mise à l'échelle automatique activée ?.

Pourquoi mon pool de nœuds échoue-t-il à provisionner de nouveaux nœuds ?

Vérifiez les causes courantes suivantes :

La mise à l'échelle automatique n'est pas activée sur le pool de nœuds

La mise à l'échelle automatique des nœuds fonctionne uniquement pour les pools de nœuds configurés avec cette fonctionnalité. Assurez-vous que la fonctionnalité de mise à l'échelle automatique au niveau du cluster est activée et que le mode de mise à l'échelle du pool de nœuds est défini sur Auto. Pour plus d'informations, consultez la section Activer la mise à l'échelle automatique des nœuds.

Les demandes de ressources des pods dépassent la capacité allouable

Les spécifications annoncées d'une instance ECS représentent la capacité totale, et non la capacité allouable. ACK réserve une partie du CPU, de la mémoire et du stockage pour le noyau du système d'exploitation, les services système et les démons Kubernetes (kubelet, kube-proxy, Terway et le runtime de conteneur). Le cluster-autoscaler standard calcule les décisions de mise à l'échelle en utilisant la politique de réservation de ressources issue de Kubernetes 1.28 et versions antérieures.

Pour utiliser une politique de réservation plus précise, basculez vers la mise à l'échelle instantanée des nœuds, qui utilise l'algorithme mis à jour. Vous pouvez également définir des réservations de ressources personnalisées dans la configuration du pool de nœuds.

Pour plus de détails sur la consommation de ressources :

• Ressources système : Pourquoi la taille de la mémoire d'une instance achetée diffère-t-elle de celle du type d'instance ?

• Les nœuds par défaut installent des modules complémentaires système ; maintenez les demandes de ressources des pods en dessous de la capacité annoncée du type d'instance. Politique de réservation de ressources

Une contrainte de zone d'un pod empêche la montée en charge

Si un pod a une dépendance de planification vis-à-vis d'une zone de disponibilité spécifique, en raison d'un PVC lié à un volume zonal ou d'une règle d'affinité de nœud, le cluster-autoscaler peut ne pas être en mesure de provisionner un nœud dans cette zone, particulièrement dans un pool de nœuds multi-zones.

Les autorisations requises sont manquantes

Le cluster-autoscaler nécessite des autorisations à l'échelle du cluster, accordées pour chaque cluster individuellement. Effectuez toutes les étapes d'autorisation décrites dans la section Activer la mise à l'échelle automatique des nœuds pour le cluster.

L'autoscaler est temporairement suspendu en raison de nœuds non sains

Si les nœuds provisionnés échouent à rejoindre le cluster ou restent dans l'état NotReady pendant une période prolongée, l'autoscaler suspend temporairement toute nouvelle mise à l'échelle pour éviter des échecs répétés. Résolvez les problèmes liés aux nœuds non sains ; la mise à l'échelle reprend automatiquement une fois la condition résolue.

Le cluster ne comporte aucun nœud de travail

Le cluster-autoscaler s'exécute sous forme de pod au sein du cluster. Sans nœuds de travail, le pod autoscaler ne peut pas s'exécuter ni provisionner de nouveaux nœuds. Configurez des pools de nœuds avec un minimum de deux nœuds pour garantir la haute disponibilité des modules complémentaires essentiels du cluster. Pour une mise à l'échelle depuis zéro ou une réduction à zéro nœud, utilisez la mise à l'échelle instantanée des nœuds.

Si un groupe de mise à l'échelle est configuré avec plusieurs types d'instances, comment l'autoscaler calcule-t-il la capacité du groupe pour les décisions de mise à l'échelle ?

Pour un groupe de mise à l'échelle comportant plusieurs types d'instances, le cluster-autoscaler modélise la capacité du groupe en utilisant la valeur minimale pour chaque dimension de ressource parmi tous les types configurés.

Par exemple, avec deux types d'instances :

• Type d'instance A : 4 vCPU, 32 GiB de mémoire

• Type d'instance B : 8 vCPU, 16 GiB de mémoire

L'autoscaler calcule :

• CPU minimal : min(4, 8) = 4 vCPU

• Mémoire minimale : min(32, 16) = 16 GiB

L'ensemble du groupe de mise à l'échelle est traité comme s'il ne pouvait provisionner que des nœuds dotés de 4 vCPU et 16 GiB. Un pod en attente demandant plus de 4 vCPU ou plus de 16 GiB ne déclenchera pas de montée en charge pour ce groupe, même si le type d'instance B pourrait satisfaire la demande en CPU.

Si plusieurs pools de nœuds avec mise à l'échelle automatique activée sont disponibles, comment le cluster-autoscaler choisit-il celui à mettre à l'échelle ?

Lorsqu'un pod ne peut pas être planifié, le cluster-autoscaler simule quels pools de nœuds peuvent l'accueillir. La simulation évalue les libellés, les taints et les types d'instances disponibles de chaque pool de nœuds.

Si plusieurs pools de nœuds sont éligibles, l'autoscaler applique par défaut la stratégie du moindre gaspillage : il sélectionne le pool de nœuds qui laisse le moins de ressources CPU et mémoire inutilisées après la planification du pod.

Comment configurer des ressources personnalisées pour un pool de nœuds avec la mise à l'échelle automatique activée ?

Ajoutez des tags ECS avec le préfixe suivant au pool de nœuds afin que l'autoscaler puisse reconnaître les ressources personnalisées disponibles dans le pool ou les valeurs précises pour des ressources spécifiques :

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

Exemple :

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

Pourquoi ne puis-je pas activer la mise à l'échelle automatique pour un pool de nœuds ?

La mise à l'échelle automatique ne peut pas être activée dans les cas suivants :

• Il s'agit du pool de nœuds par défaut. La fonctionnalité de mise à l'échelle automatique des nœuds ne prend pas en charge le pool de nœuds par défaut du cluster.

• Le pool de nœuds contient des nœuds ajoutés manuellement. Supprimez d'abord les nœuds ajoutés manuellement, ou créez un nouveau pool de nœuds dédié avec la mise à l'échelle automatique activée dès le départ.

• Le pool de nœuds utilise des instances par abonnement. La mise à l'échelle automatique des nœuds fonctionne uniquement avec des instances en paiement à l'utilisation.

Pourquoi le cluster-autoscaler ne réduit-il pas la taille d'un nœud ?

Le cluster-autoscaler ignore un nœud lors de la descente en charge si l'une des conditions suivantes s'applique :

• L'utilisation des pods dépasse le seuil. Le total des demandes de ressources des pods sur le nœud est supérieur au seuil de descente en charge configuré.

• Le nœud exécute des pods du namespace kube-system. Par défaut, le cluster-autoscaler ne supprime pas les nœuds exécutant des pods du namespace kube-system.

• Un pod possède des contraintes de planification strictes. Si un pod utilise un nodeSelector ou une nodeAffinity qui l'empêche d'être replanifié sur tout autre nœud, le nœud ne peut pas faire l'objet d'une descente en charge.

• Un pod est protégé par un PodDisruptionBudget (PDB). Si l'expulsion d'un pod violerait le paramètre minAvailable ou maxUnavailable du PDB, le nœud est conservé. Pour plus d'informations, consultez la documentation PodDisruptionBudget.

• Pendant la période de délai de descente en charge, si des pods nouvellement planifiés (tels que des pods temporaires créés par un Job) maintiennent l'utilisation des ressources au-dessus du seuil, le nœud ne sera pas réduit. Les pods non créés par un Deployment, ReplicaSet, Job ou StatefulSet bloquent par défaut la suppression de nœuds.

Pour obtenir la liste complète des conditions pouvant bloquer la descente en charge d'un nœud, consultez la FAQ cluster-autoscaler.

Comment activer ou désactiver l'expulsion pour un DaemonSet spécifique ?

Le paramètre Evict DaemonSet Pods dans la configuration du cluster contrôle globalement l'expulsion des DaemonSets. Pour plus d'informations, consultez l'étape 1 de la page Activer la mise à l'échelle automatique des nœuds pour le cluster.

Remplacez ce paramètre par DaemonSet en ajoutant une annotation aux pods du DaemonSet (dans le modèle de pod, et non sur l'objet DaemonSet lui-même) :

• Activer l'expulsion pour les pods d'un DaemonSet spécifique :

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

• Désactiver l'expulsion pour les pods d'un DaemonSet spécifique :

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

Si le paramètre global Evict DaemonSet Pods est désactivé, enable-ds-eviction: "true" s'applique uniquement aux pods DaemonSet sur des nœuds non vides. Pour expulser les pods DaemonSet des nœuds vides, activez d'abord le paramètre global.

Par défaut, le cluster-autoscaler expulse les pods DaemonSet de manière non bloquante et poursuit sans attendre la fin de l'expulsion. Pour forcer l'autoscaler à attendre qu'un pod DaemonSet spécifique soit entièrement expulsé avant de poursuivre, ajoutez l'annotation suivante conjointement à enable-ds-eviction :

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

Ces annotations n'ont aucun effet sur les pods qui ne font pas partie d'un DaemonSet.

Quels types de pods peuvent empêcher le cluster-autoscaler de supprimer un nœud ?

Pour obtenir la liste complète des conditions bloquant la descente en charge d'un nœud, consultez la section What types of pods can prevent CA from removing a node? dans la FAQ upstream du cluster-autoscaler.

Le cluster-autoscaler prend-il en charge les CustomResourceDefinitions (CRD) ?

Non. Le cluster-autoscaler prend uniquement en charge les objets Kubernetes standard et ne prend pas en charge les CRD.

Comment retarder la montée en charge pour un pod spécifique ?

Ajoutez l'annotation cluster-autoscaler.kubernetes.io/pod-scale-up-delay au pod. Le cluster-autoscaler ne prendra pas le pod en compte pour la montée en charge tant qu'il restera non planifiable pendant une durée supérieure au délai spécifié. Cela laisse au planificateur Kubernetes plus de temps pour placer le pod sur des nœuds existants avant de déclencher une montée en charge.

Exemple :

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

Comment utiliser les annotations de pod pour contrôler le comportement de descente en charge ?

Utilisez l'annotation cluster-autoscaler.kubernetes.io/safe-to-evict pour marquer explicitement un pod comme sûr ou non sûr à expulser lors de la descente en charge :

• Empêcher la descente en charge du nœud : Ajoutez "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" à un pod s'exécutant sur le nœud. L'autoscaler ne terminera pas le nœud tant que ce pod est présent.

• Autoriser la descente en charge du nœud : Ajoutez "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" pour marquer explicitement le pod comme sûr à expulser.

Comment empêcher le cluster-autoscaler de réduire la taille d'un nœud spécifique ?

Ajoutez l'annotation cluster-autoscaler.kubernetes.io/scale-down-disabled: "true" au nœud. Remplacez <nodename> par le nom du nœud cible :

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

Comment mettre à niveau cluster-autoscaler vers la dernière version ?

1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

2. Sur la page Clusters, localisez le cluster et cliquez sur son nom. Dans le volet de navigation de gauche, choisissez Nodes > Node Pools.

3. Cliquez sur Edit à droite de Node Scaling. Dans le panneau qui s'affiche, cliquez sur OK pour effectuer la mise à niveau vers la dernière version.

Quelles actions déclenchent une mise à jour automatique de cluster-autoscaler ?

Le cluster-autoscaler est mis à jour automatiquement lorsque :

• La configuration de la mise à l'échelle automatique est modifiée.

• Un pool de nœuds avec mise à l'échelle automatique activée est créé, supprimé ou mis à jour.

• La version Kubernetes du cluster est mise à niveau avec succès.

La mise à l'échelle des nœuds ne fonctionne pas sur mon cluster ACK managé malgré une autorisation de rôle complète

Cela signifie généralement que le jeton addon.aliyuncsmanagedautoscalerrole.token est absent d'un Secret dans le namespace kube-system. ACK utilise le rôle Worker du cluster pour activer la mise à l'échelle automatique, et ce jeton est requis pour l'authentification.

Réappliquez la stratégie requise au rôle Worker via la console ACK :

1. Sur la page Clusters, localisez le cluster et cliquez sur son nom. Dans le volet de navigation de gauche, choisissez Nodes > Node Pools.

2. Sur la page Node Pools, cliquez sur Enable à droite de Node Scaling.

3. Suivez les instructions à l'écran pour autoriser le KubernetesWorkerRole et attacher la stratégie système AliyunCSManagedAutoScalerRolePolicy.

   

4. Redémarrez manuellement le déploiement cluster-autoscaler (mise à l'échelle automatique des nœuds) ou le déploiement ack-goatscaler (mise à l'échelle instantanée des nœuds) dans le namespace kube-system pour que les autorisations prennent effet immédiatement.