À propos de l'autoscaling des clusters

Autopilot Standard

Cette page explique comment Google Kubernetes Engine (GKE) redimensionne automatiquement les pools de nœuds de votre cluster standard en fonction des demandes de vos charges de travail. Lorsque la demande est élevée, l'autoscaler de cluster ajoute des nœuds au pool de nœuds. Pour savoir comment configurer l'autoscaler de cluster, consultez la page Procéder à l'autoscaling d'un cluster.

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui planifient les besoins en capacité et en infrastructure, et optimisent l'architecture et les ressources des systèmes pour garantir le coût total de possession le plus bas pour leur entreprise ou leur unité commerciale. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avec les clusters Autopilot, vous n'avez pas à vous soucier du provisionnement des nœuds, ni de la gestion des pools de nœuds, car les nœuds sont soumis à un provisionnement automatique et les pools de nœuds font l'objet d'un scaling automatique afin de répondre aux exigences de vos charges de travail.

Bonne pratique:

Planifiez et concevez la configuration de votre cluster avec les administrateurs et les architectes de votre organisation, les développeurs ou toute autre équipe chargée de la mise en œuvre et de la maintenance de votre application.

Pourquoi utiliser l'autoscaler de cluster

L'autoscaler de cluster de GKE redimensionne automatiquement le nombre de nœuds dans un pool de nœuds donné, en fonction des exigences de vos charges de travail. Lorsque la demande est faible, l'autoscaler de cluster redimensionne les pools à la taille minimale que vous avez définie. Cela permet d'augmenter la disponibilité de vos charges de travail lorsque vous en avez besoin, tout en contrôlant les coûts. Vous n'avez pas besoin d'ajouter ou de supprimer manuellement des nœuds, ni de surprovisionner vos pools de nœuds. À la place, il suffit de spécifier une taille minimale et une taille maximale pour le pool de nœuds, après quoi le reste est automatique.

Si des ressources sont supprimées ou déplacées lors de l'autoscaling de votre cluster, vos charges de travail peuvent être temporairement interrompues. Par exemple, si votre charge de travail comprend un contrôleur avec une seule instance dupliquée, le pod de cette instance dupliquée peut être reprogrammé sur un nœud différent si son nœud actuel est supprimé. Avant d'activer l'autoscaler de cluster, concevez vos charges de travail de manière à tolérer des perturbations potentielles ou assurez-vous que les pods critiques ne sont pas interrompus.

Bonne pratique:

Pour augmenter la tolérance aux interruptions de votre charge de travail, déployez-la à l'aide d'un contrôleur avec plusieurs instances répliquées, tel qu'un objet Deployment.

Vous pouvez augmenter les performances de l'autoscaler de cluster avec le streaming d'images, qui diffuse à distance les données d'image requises à partir des images de conteneurs éligibles, tout en mettant en cache simultanément l'image localement pour permettre aux charges de travail de nouveaux nœuds de démarrer plus rapidement.

Fonctionnement de l'autoscaler de cluster

L'autoscaler de cluster fonctionne par pool de nœuds. Lorsque vous configurez un pool de nœuds avec l'autoscaler de cluster, vous spécifiez une taille minimale et maximale pour le pool de nœuds.

L'autoscaler de cluster augmente ou diminue automatiquement la taille du pool de nœuds en ajoutant ou en supprimant des instances de machine virtuelle (VM) dans le groupe d'instances géré Compute Engine sous-jacent pour le pool de nœuds. L'autoscaler de cluster prend ces décisions de scaling en fonction des demandes de ressources (plutôt qu'en fonction de l'utilisation réelle des ressources) des pods exécutés sur les nœuds de ce pool. Il vérifie régulièrement l'état des pods et des nœuds, et prend les mesures suivantes :

Si les pods ne peuvent pas être programmés sur l'un des nœuds actuels, l'autoscaler de cluster ajoute des nœuds jusqu'à atteindre la taille maximale du pool de nœuds. Pour savoir à quel moment l'autoscaler de cluster modifie la taille d'un cluster, consultez la section Quand l'autoscaler de cluster modifie-t-il la taille d'un cluster ?.
Si GKE décide d'ajouter des nœuds au pool de nœuds, l'autoscaler de cluster ajoute autant de nœuds que nécessaire, jusqu'aux limites définies par pool de nœuds ou par cluster.
L'autoscaler de cluster n'attend pas qu'un nœud soit disponible avant de créer le suivant. Une fois que GKE a déterminé le nombre de nœuds à créer, la création des nœuds a lieu en parallèle. L'objectif est de réduire le temps nécessaire pour passer les pods non planifiables à l'état Active.
Si certains nœuds ne peuvent pas être créés en raison de l'épuisement du quota, l'autoscaler de cluster attend que les ressources puissent être planifiées.
Si les nœuds sont sous-utilisés et que tous les pods peuvent être programmés, même avec moins de nœuds dans le pool, l'autoscaler de cluster supprime des nœuds, jusqu'à atteindre la taille minimale du pool de nœuds. Si des pods d'un nœud ne peuvent pas être déplacés vers d'autres nœuds du cluster, l'autoscaler de cluster ne tente pas de réduire la capacité de ce nœud. Si les pods peuvent être déplacés vers d'autres nœuds, mais que le nœud ne peut pas être drainé correctement après un délai d'inactivité (actuellement de 10 minutes), le nœud est automatiquement arrêté. Le délai de grâce n'est pas configurable pour les clusters GKE. Pour en savoir plus sur le fonctionnement du scaling à la baisse, consultez la documentation sur l'autoscaler de cluster.

La fréquence à laquelle l'autoscaler de cluster inspecte un cluster pour détecter les pods non planifiables dépend en grande partie de la taille du cluster. Dans les petits clusters, l'inspection peut avoir lieu toutes les quelques secondes. Il n'est pas possible de définir un délai exact pour cette inspection.

Si vos nœuds connaissent des manques, car vos pods ont demandé ou défini par défaut des ressources insuffisantes, l'autoscaler de cluster ne corrige pas la situation. Vous pouvez vous assurer que l'autoscaler de cluster fonctionne aussi précisément que possible en effectuant des demandes de ressources explicites pour toutes vos charges de travail.

N'activez pas l'autoscaling Compute Engine pour les groupes d'instances gérés pour les nœuds du cluster. L'autoscaler de cluster de GKE est distinct de l'autoscaling Compute Engine. Une telle opération peut provoquer l'échec du scaling à la hausse ou à la baisse des pools de nœuds, car l'autoscaler Compute Engine entre en conflit avec l'autoscaler de cluster de GKE.

Critères d'exploitation

Lors du redimensionnement d'un pool de nœuds, l'autoscaler de cluster repose sur les hypothèses suivantes :

Tous les pods répliqués peuvent être démarrés sur un autre nœud, provoquant éventuellement une brève interruption.
Les utilisateurs ou les administrateurs ne gèrent pas manuellement les nœuds. L'autoscaling peut remplacer les opérations de gestion manuelle des nœuds que vous effectuez.
Tous les nœuds d'un pool de nœuds unique ont le même ensemble de libellés.
L'autoscaler de cluster prend en compte le coût relatif des types d'instances dans les différents pools, et tente de développer le pool de nœuds le moins coûteux possible. L'autoscaler de cluster tient compte du coût réduit des pools de nœuds contenant des VM Spot, qui sont préemptibles.
L'autoscaler de cluster prend en compte les demandes de conteneur d'initialisation avant de programmer les pods. Les demandes de conteneur d'initialisation peuvent utiliser toutes les ressources non allouées disponibles sur les nœuds, ce qui peut empêcher la planification des pods. L'autoscaler de cluster suit les mêmes règles de calcul des demandes que Kubernetes. Pour en savoir plus, consultez la documentation Kubernetes sur l'utilisation de conteneurs d'initialisation.
Les étiquettes ajoutées manuellement après la création initiale du cluster ou du pool de nœuds ne font l'objet d'aucun suivi. Les nœuds créés par l'autoscaler de cluster se voient attribuer des étiquettes spécifiées avec --node-labels au moment de la création du pool de nœuds.
Dans la version 1.21 ou antérieure de GKE, l'autoscaler de cluster prend en compte les informations de rejet des nœuds existants à partir d'un pool de nœuds pour représenter l'ensemble du pool de nœuds. À partir de la version 1.22 de GKE, l'autoscaler de cluster combine des informations à partir des nœuds existants du cluster et du pool de nœuds. L'autoscaler de cluster détecte également les modifications manuelles que vous apportez au nœud et au pool de nœuds.

Bonne pratique :

N'activez pas l'autoscaler de cluster si vos applications ne tolèrent pas les interruptions.

Équilibrer les zones

Si votre pool de nœuds contient plusieurs groupes d'instances gérées avec le même type d'instance, l'autoscaler de cluster tente d'équilibrer la taille de ces groupes d'instances gérées lors de l'autoscaling. Cela peut contribuer à éviter une répartition inégale des nœuds entre les groupes d'instances gérés dans plusieurs zones d'un pool de nœuds. GKE ne tient pas compte de la règle d'autoscaling lors du scaling à la baisse.

Lors d'un événement de scaling à la hausse, l'autoscaler de cluster ne procède à l'équilibrage qu'au niveau des zones. L'autoscaler effectue un scaling à la baisse des nœuds sous-utilisés, quelle que soit la taille relative des groupes d'instances gérés sous-jacents d'un pool de nœuds, ce qui peut entraîner une répartition inégale des nœuds entre les zones.

Règle d'emplacement

À partir de la version 1.24.1-gke.800 de GKE, vous pouvez modifier la stratégie de localisation de l'autoscaler de cluster. Vous pouvez contrôler la règle de distribution de l'autoscaler de cluster en spécifiant l'option location_policy avec l'une des valeurs suivantes :

BALANCED : l'autoscaler de cluster prend en compte les exigences de pod et la disponibilité des ressources dans chaque zone. Cela ne garantit pas que les groupes de nœuds similaires auront exactement les mêmes tailles, car l'autoscaler prend en compte de nombreux facteurs, y compris la capacité disponible dans une zone et des affinités de zone spécifiques des pods qui ont déclenché un scaling à la hausse.
ANY : l'autoscaler de cluster priorise l'utilisation des réservations inutilisées et tient compte des contraintes actuelles de ressources disponibles.

Bonne pratique :

Utilisez la règle ANY si vous utilisez des VM spot ou si vous souhaitez utiliser des réservations de VM qui ne sont pas égales entre les zones.

Réservations

À partir de la version 1.27 de GKE, l'autoscaler de cluster prend toujours en compte les réservations lors de la prise de décisions de scaling à la hausse. Les pools de nœuds avec des réservations inutilisées correspondantes sont prioritaires sur le choix du pool de nœuds pour le scaling à la hausse, même s'il n'est pas le plus efficace. En outre, les réservations inutilisées sont toujours prioritaires lors de l'équilibrage de scalings à la hausse multizones.

Valeurs par défaut

Pour les pools de nœuds VM spot, la règle de distribution de l'autoscaler de cluster par défaut est ANY. Dans cette règle, les VM spot présentent un risque plus faible de préemption.

Pour les pools de nœuds non préemptifs, la règle de distribution de l'autoscaler de cluster par défaut est BALANCED.

Taille minimale et maximale du pool de nœuds

Lorsque vous créez un pool de nœuds, vous pouvez spécifier la taille minimale et maximale de chaque pool de nœuds de votre cluster. L'autoscaler de cluster prend des décisions de redimensionnement dans le cadre de ces contraintes de scaling. Pour mettre à jour la taille minimale, redimensionnez manuellement le cluster à une taille adaptée aux nouvelles contraintes, après avoir spécifié la nouvelle valeur minimale. L'autoscaler de cluster prend ensuite des décisions de redimensionnement en fonction des nouvelles contraintes.

Taille actuelle du pool de nœuds	Action de l'autoscaler de cluster	Contraintes de scaling
Inférieur au minimum que vous avez spécifié	L'autoscaler de cluster effectue un scaling à la hausse pour provisionner les pods en attente. Le scaling à la baisse est désactivé.	Le pool de nœuds n'évolue pas en dessous de la valeur spécifiée.
Compris entre les tailles minimale et maximale que vous avez spécifiées	L'autoscaler de cluster évolue à la hausse ou à la baisse en fonction de la demande.	Le pool de nœuds reste dans les limites de taille que vous avez spécifiées.
Supérieur à la valeur maximale que vous avez spécifiée	L'autoscaler de cluster effectue un scaling à la baisse uniquement pour les nœuds qui peuvent être supprimés en toute sécurité. Le scaling à la hausse est désactivé.	Le pool de nœuds n'évolue pas au-dessus de la valeur spécifiée.

Sur les clusters Standard, l'autoscaler de cluster ne réduit jamais automatiquement la capacité d'un cluster à zéro nœud. Un ou plusieurs nœuds doivent toujours être disponibles dans le cluster pour exécuter les pods système. De plus, si le nombre de nœuds actuel est égal à zéro en raison de la suppression manuelle des nœuds, l'autoscaler et le provisionnement automatique de nœuds peuvent effectuer un scaling à la hausse sur un cluster ne comptant aucun nœud.

Pour en savoir plus sur les décisions des autoscalers, consultez la section Limites de l'autoscaler de cluster.

Limites de l'autoscaling

Vous pouvez définir le nombre minimal et maximal de nœuds à utiliser par l'autoscaler de cluster lors du scaling d'un pool de nœuds. Utilisez les options --min-nodes et --max-nodes pour définir le nombre minimal et maximal de nœuds par zone.

À partir de la version 1.24 de GKE, vous pouvez utiliser les options --total-min-nodes et --total-max-nodes pour les nouveaux clusters. Ces options définissent le nombre minimal et maximal du nombre total de nœuds dans le pool de nœuds de toutes les zones.

Exemple de nœuds minimal et maximal

La commande suivante crée un cluster multizones d'autoscaling doté de six nœuds répartis sur trois zones, avec un minimum d'un nœud par zone et un maximum de quatre nœuds par zone :

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --zone=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

Dans cet exemple, la taille totale du cluster peut être comprise entre trois et douze nœuds, répartis sur les trois zones. Si l'une des zones échoue, la taille totale du cluster peut être comprise entre deux et huit nœuds.

Exemple de nombre total de nœuds

La commande suivante, disponible dans GKE 1.24 ou version ultérieure, crée initialement un cluster multizones avec autoscaling sur six nœuds répartis sur trois zones, avec un minimum de trois nœuds et un maximum de douze nœuds dans le pool de nœuds dans toutes les zones :

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --zone=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

Dans cet exemple, la taille totale du cluster peut être comprise entre 3 et 12 nœuds, quelle que soit la répartition entre les zones.

Profils d'autoscaling

La décision de supprimer un nœud représente un compromis entre l'optimisation de l'utilisation et la disponibilité des ressources. Supprimer les nœuds sous-exploités améliore l'utilisation des clusters, mais les nouvelles charges de travail peuvent se trouver contraintes d'attendre le provisionnement de nouvelles ressources avant de pouvoir s'exécuter.

Vous pouvez spécifier le profil d'autoscaling à utiliser pour prendre de telles décisions. Les profils disponibles sont les suivants :

balanced : profil par défaut qui donne la priorité à la disponibilité de davantage de ressources pour les pods entrants, réduisant ainsi le temps nécessaire à leur activation pour les clusters standards. Le profil balanced n'est pas disponible pour les clusters Autopilot.
optimize-utilization : donne la priorité à l'optimisation de l'utilisation plutôt qu'à la mise en réserve de ressources dans le cluster. Lorsque vous activez ce profil, l'autoscaler de cluster effectue un scaling à la baisse plus radical du cluster. GKE peut supprimer davantage de nœuds et supprimer les nœuds plus rapidement. GKE préfère planifier les pods dans les nœuds disposant déjà d'une allocation élevée de processeurs, de mémoire ou de GPU. Cependant, d'autres facteurs affectent la planification, tels que la répartition des pods appartenant au même Déploiement, StatefulSet ou Service sur les nœuds.

Le profil d'autoscaling optimize-utilization permet à l'autoscaler de cluster d'identifier et de supprimer les nœuds sous-utilisés. Pour effectuer cette optimisation, GKE définit le nom du programmeur dans la spécification du pod sur gke.io/optimize-utilization-scheduler. Les pods qui spécifient un programmeur personnalisé ne sont pas affectés.

La commande suivante active le profil d'autoscaling optimize-utilization dans un cluster existant :

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

Prendre en compte la planification et l'interruption des pods

Lors de la réduction, l'autoscaler de cluster respecte les règles de planification et d'éviction définies sur les pods. Ces restrictions peuvent empêcher la suppression d'un nœud par l'autoscaler. La suppression d'un nœud peut être empêchée si ce nœud contient un pod remplissant l'une des conditions suivantes :

Les règles d'affinité ou d'anti-affinité du pod empêchent la replanification.
Le pod n'est pas géré par un contrôleur tel que Deployment, StatefulSet, Job ou ReplicaSet.
Le pod dispose d'un stockage en local et la version du plan de contrôle GKE est antérieure à la version 1.22. Dans les clusters GKE avec la version 1.22 ou ultérieure du plan de contrôle, les pods avec stockage local ne bloquent plus le scaling à la baisse.
Le pod comporte l'annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
La suppression du nœud dépasse la valeur PodDisruptionBudget configurée.

Pour en savoir plus sur l'autoscaler de cluster et éviter les interruptions, consultez la section Questions fréquentes sur l'autoscaler de cluster :

Autoscaling des TPU dans GKE

GKE est compatible avec les TPU (Tensor Processing Units) pour accélérer les charges de travail de machine learning. Le pool de nœuds de tranche TPU à hôte unique et le pool de nœuds de tranche TPU multi-hôte sont tous deux compatibles avec l'autoscaling et le provisionnement automatique.

Avec l'option --enable-autoprovisioning sur un cluster GKE, GKE crée ou supprime des pools de nœuds de tranche TPU à hôte unique ou multi-hôte avec une version et une topologie de TPU qui répondent aux exigences des charges de travail en attente.

Lorsque vous utilisez --enable-autoscaling, GKE procède au scaling du pool de nœuds en fonction de son type, comme suit :

Pool de nœuds de tranche TPU à hôte unique : GKE ajoute ou supprime des nœuds TPU dans le pool de nœuds existant. Le pool de nœuds peut contenir un nombre de nœuds TPU compris entre zéro et la taille maximale du pool de nœuds, tel que déterminé par les options --max-nodes et --total-max-nodes. Lorsque le pool de nœuds effectue un scaling, tous les nœuds TPU du pool de nœuds ont le même type de machine et la même topologie. Pour en savoir plus sur la création d'un pool de nœuds de tranche TPU à hôte unique, consultez la section Créer un pool de nœuds.
Pool de nœuds de tranche TPU multi-hôte : GKE effectue un scaling du pool de nœuds de façon atomique, de zéro jusqu'au nombre de nœuds requis pour satisfaire la topologie TPU. Par exemple, pour un pool de nœuds TPU avec un type de machine ct5lp-hightpu-4t et une topologie 16x16, le pool de nœuds contient 64 nœuds. L'autoscaler GKE s'assure que ce pool de nœuds comporte exactement 0 ou 64 nœuds. Lors d'un nouveau scaling à la baisse, GKE supprime tous les pods planifiés et draine l'intégralité du pool de nœuds jusqu'à zéro. Pour en savoir plus sur la création d'un pool de nœuds de tranche TPU multi-hôte, consultez la section Créer un pool de nœuds.

Informations supplémentaires

Vous pouvez trouver plus d'informations sur l'autoscaler de cluster dans la section Questions fréquentes sur l'autoscaling du projet Open Source Kubernetes.

Limites

L'autoscaler de cluster présente les limites suivantes :

Les PersistentVolumes locaux ne sont pas compatibles avec l'autoscaler de cluster.
Dans les versions de plan de contrôle GKE antérieures à 1.24.5-gke.600, lorsque les pods demandent un stockage éphémère, l'autoscaler de cluster ne permet pas de faire évoluer un pool de nœuds sans nœuds qui utilise des disques SSD locaux en tant que stockage éphémère.
Limites de taille des clusters : jusqu'à 15 000 nœuds. Tenez compte des autres limites de cluster et de nos bonnes pratiques concernant l'exécution des clusters de cette taille.
Lorsque vous êtes en phase de scaling à la baisse, l'autoscaler de cluster respecte un délai de grâce de 10 minutes afin de replanifier les pods du nœud sur un autre nœud avant de mettre fin au processus de manière forcée.
Parfois, l'autoscaler de cluster ne peut pas effectuer un scaling à la baisse complet et un nœud supplémentaire demeure après cette opération. Cela peut se produire lorsque les pods système requis sont planifiés sur différents nœuds, car aucun déclencheur ne permet de transférer l'un de ces pods vers un autre nœud. Reportez-vous à la page J'ai quelques nœuds avec une faible utilisation, mais ils ne sont pas réduits. Pourquoi ? Pour contourner cette limitation, vous pouvez configurer un budget d'interruption de pod.
La programmation personnalisée avec des filtres modifiés n'est pas acceptée.
Les nœuds n'évolueront pas si les pods ont une valeur PriorityClass inférieure à -10. Pour en savoir plus, consultez la section Comment l'autoscaler de cluster fonctionne-t-il avec la priorité et la préemption des pods ?
L'autoscaler de cluster ne dispose peut-être pas d'un espace d'adressage IP non attribué suffisant pour ajouter de nouveaux nœuds ou pods, ce qui entraîne des échecs de scaling à la hausse signalés par les événements eventResult avec le motif scale.up.error.ip.space.exhausted. Vous pouvez ajouter d'autres adresses IP destinées aux nœuds en développant le sous-réseau principal ou en ajoutant de nouvelles adresses IP destinées aux pods à l'aide d'un CIDR multipod discontinu. Pour plus d'informations, consultez Espace d'adressage IP insuffisant pour les pods.
L'autoscaler de cluster GKE est différent de l'autoscaler de cluster du projet Open Source Kubernetes. Les paramètres de l'autoscaler de cluster GKE dépendent de la configuration du cluster et sont susceptibles d'être modifiés. Si vous avez besoin de mieux contrôler le comportement de l'autoscaling, désactivez l'autoscaler de cluster GKE et exécutez l'autoscaler de cluster du projet Open Source Kubernetes. Cependant, le projet Open Source Kubernetes n'est pas compatible avec Google Cloud.

Problèmes connus

Dans les versions antérieures à la version 1.22 du plan de contrôle GKE, l'autoscaler de cluster GKE arrête le scaling à la hausse de tous les pools de nœuds sur les clusters vides (zéro nœud). Ce comportement ne se produit pas dans GKE 1.22 et versions ultérieures.

Dépannage

Pour obtenir des conseils de dépannage, consultez les pages suivantes :