Container Service for Kubernetes:FAQ sur la mise à l'échelle automatique des nœuds

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 du type d'instance. Le système d'exploitation sous-jacent et les daemons système de l'instance Elastic Compute Service (ECS) consomment une partie du CPU, de la mémoire et du stockage avant toute planification de pod. Pour plus de détails, consultez 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 points 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 composant cluster-autoscaler ne prend en compte que les 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 un déploiement à 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 composant cluster-autoscaler ne prend en charge qu'un ensemble limité de politiques de planification pour déterminer si un pod non planifiable convient à un pool de nœuds avec la mise à l'échelle automatique activée. Pour plus de détails, consultez Quelles politiques de planification utilise 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 de détails, consultez 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 montée en charge 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 composant cluster-autoscaler de provisionner un type d'instance spécifique lors de la montée en charge. L'autoscaler modélise la capacité globale du pool de nœuds en se basant sur le plus petit type d'instance disponible, c'est-à-dire celui disposant du moins de ressources parmi tous les types configurés. Pour plus de détails, consultez Comment l'autoscaler calcule-t-il la capacité d'un pool de nœuds avec plusieurs types d'instances ?

Les pods avec 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 de zone peut ne pas déclencher de montée en charge. Cela s'applique aux pods qui nécessitent une zone spécifique en raison :

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

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

Dans ces cas, le composant cluster-autoscaler peut échouer à provisionner un nœud dans la zone requise. Pour d'autres scénarios, consultez 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 du pod, 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 de PVC dans un état Terminating. Un pod qui ne peut pas être planifié car son PVC est en cours de terminaison échouera continuellement, ce qui peut amener le composant cluster-autoscaler à prendre des décisions incorrectes de montée ou de descente en charge (par exemple, en expulsant le pod).

Quelles politiques de planification cluster-autoscaler utilise-t-il pour déterminer si un pod non planifiable peut être planifié sur un pool de nœuds avec la mise à l'échelle automatique activée ?

Le composant 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 cluster-autoscaler peut-il simuler lors de l'analyse de planification ?

Le composant 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 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 la mise à l'échelle automatique. 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 de détails, consultez 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 daemons Kubernetes (kubelet, kube-proxy, Terway et le runtime de conteneur), ce qui crée un écart entre la capacité totale du nœud et ses ressources allouables.

Lors de la prise de décisions de montée en charge, le composant cluster-autoscaler utilise la politique de réservation de ressources de Kubernetes 1.28 et versions antérieures, quelle que soit la version du cluster ACK.

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 une instance achetée a-t-elle une taille de mémoire différente 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 sur 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 composant cluster-autoscaler peut ne pas être en mesure de provisionner un nœud dans cette zone, en particulier dans un pool de nœuds multi-zones.

Les autorisations requises sont manquantes

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

Comportement d'amortissement pour les nœuds non sains

L'autoscaler entre dans un état d'amortissement lorsque l'une des conditions suivantes se produit dans un pool de nœuds à mise à l'échelle automatique :

• Un nœud ne parvient pas à rejoindre le cluster dans le délai prévu.

• Un nœud reste dans l'état NotReady au-delà de la durée autorisée.

Pendant cet état d'amortissement, toutes les opérations de mise à l'échelle sont suspendues jusqu'à ce que les nœuds non sains soient résolus, garantissant ainsi l'exactitude des décisions de mise à l'échelle ultérieures.

Aucun nœud dans le cluster

Le composant cluster-autoscaler ne peut pas s'exécuter lorsque le cluster ne contient aucun nœud. Configurez chaque pool de nœuds avec un minimum de deux nœuds pour assurer le fonctionnement normal des modules complémentaires et des composants du cluster.

Pour une mise à l'échelle à partir de zéro ou jusqu'à 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 avec plusieurs types d'instances, le composant 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 minimum : min(4, 8) = 4 vCPU

• Mémoire minimum : 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 avec 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 de CPU.

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

Lorsqu'un pod est non planifiable, le composant cluster-autoscaler simule les pools de nœuds pouvant 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 utilise par défaut la stratégie least-waste (moins de 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 basées sur un abonnement. La mise à l'échelle automatique des nœuds fonctionne uniquement avec des instances en paiement à l'utilisation.

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

Le composant 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 de l'espace de noms kube-system. Par défaut, le composant cluster-autoscaler ne supprime pas les nœuds exécutant des pods de l'espace de noms kube-system.

• Un pod a 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 être réduit.

• Un pod est protégé par un PodDisruptionBudget (PDB). Si l'expulsion d'un pod violerait le paramètre minAvailable du PDB, le nœud est conservé. Pour plus de détails, consultez 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œud.

Pour une 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 l'expulsion des DaemonSets globalement. Pour plus d'informations, consultez Étape 1 : 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 composant 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 avec 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 cluster-autoscaler de supprimer un nœud ?

Le composant cluster-autoscaler peut bloquer la suppression de nœud dans les cas suivants :

• Le pod n'a pas été créé par un contrôleur Kubernetes natif (par exemple, il n'a pas été créé par un Deployment, ReplicaSet, Job ou StatefulSet).

• Le pod sur le nœud ne peut pas être arrêté ou migré en toute sécurité.

Pour une liste complète des conditions bloquant la descente en charge d'un nœud, consultez Quels types de pods peuvent empêcher CA de supprimer un nœud ?

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

Non. Le composant cluster-autoscaler ne prend en charge que 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 composant cluster-autoscaler ne prendra pas en compte le pod pour la montée en charge tant qu'il restera non planifiable pendant une durée supérieure au délai spécifié. Cela donne 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 pour le 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 pour le nœud : Ajoutez "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" pour marquer explicitement le pod comme sûr à expulser.

Comment empêcher 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 à jour 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, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Nodes > Node Pools.

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

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

Le composant cluster-autoscaler est mis à jour automatiquement lorsque :

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

• Un pool de nœuds avec la 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 géré ACK bien que l'autorisation de rôle soit complète

Cela signifie généralement que le jeton addon.aliyuncsmanagedautoscalerrole.token est manquant dans un Secret de l'espace de noms kube-system. ACK utilise le Worker Role du cluster pour activer la mise à l'échelle automatique, et ce jeton est requis pour l'authentification.

Réappliquez la stratégie requise au Worker Role via la console ACK :

1. Sur la page ACK Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur 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.

   Dans la boîte de dialogue Node Scaling Configuration, après la réussite de la pré-vérification, cliquez sur le lien du nom du rôle dans la zone d'invite pour accéder à Resource Access Management (RAM) et terminer l'autorisation.

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