À propos de l'autoscaling des clusters GKE

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 obtenir 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.

Avant de lire cette page, assurez-vous de connaître les concepts Kubernetes de base et le fonctionnement des demandes et limites de ressources.

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.

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 sont pas 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. Toutefois, les conditions suivantes s'appliquent à ce comportement de l'autoscaler de cluster :
  • L'autoscaler de cluster tient compte du coût réduit des pools de nœuds contenant des VM Spot, qui sont préemptibles. Toutefois, l'autoscaler de cluster prend également en compte la disponibilité des ressources dans chaque zone et peut choisir la ressource la plus chère, mais disponible.
  • Lorsque plusieurs pools de nœuds utilisent des VM Spot, l'autoscaler de cluster ne sélectionne pas automatiquement l'option la moins chère. Pour optimiser l'utilisation rentable des VM Spot et éviter ce scénario, nous vous recommandons d'utiliser des classes de calcul personnalisées.
• 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.

É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.

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.

Toutefois, l'autoscaler de cluster ne recherche des réservations que dans son propre projet. Par conséquent, si une option de nœud moins chère est disponible dans le projet du cluster, l'autoscaler peut sélectionner cette option au lieu de la réservation partagée. Si vous devez partager des réservations entre des projets, envisagez d'utiliser des classes de calcul personnalisées, qui vous permettent de configurer la priorité utilisée par l'autoscaler de cluster pour mettre à l'échelle les nœuds, y compris les réservations partagées.

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.

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 \
    --location=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 \
    --location=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 :

• Comment fonctionne le scaling à la baisse ?
• L'autoscaler de cluster fonctionne-t-il avec PodDisruptionBudget en phase de scaling à la baisse ?
• Quels types de pods peuvent empêcher l'autoscaler de cluster de supprimer un nœud ?
• Comment régler l'autoscaler de cluster dans GKE ?

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.

Spot VM et autoscaler de clusters

Étant donné que l'autoscaler de cluster préfère développer les pools de nœuds les moins chers, il ajoute des VM Spot lors de l'ajustement à la hausse lorsque vos charges de travail et la disponibilité des ressources le permettent.

Toutefois, même si l'autoscaler de cluster préfère ajouter des VM Spot, cette préférence ne garantit pas que la majorité de vos pods s'exécutera sur ces types de VM. Les VM Spot peuvent être préemptées. En raison de cette préemption, les pods sur les VM Spot sont plus susceptibles d'être évincés. Lorsqu'ils sont évincés, ils ne disposent que de 15 secondes pour s'arrêter.

Par exemple, imaginons que vous disposiez de 10 pods et d'un mélange de VM à la demande et de VM Spot:

• Vous commencez avec 10 pods exécutés sur des VM à la demande, car les VM Spot n'étaient pas disponibles.
• Vous n'avez pas besoin de tous les 10 pods. L'autoscaler de cluster supprime donc deux pods et arrête les VM à la demande supplémentaires.
• Lorsque vous avez à nouveau besoin de 10 pods, l'autoscaler de cluster ajoute des VM Spot (car elles sont moins chères) et planifie deux pods dessus. Les huit autres pods restent sur les VM à la demande.
• Si l'autoscaler de cluster doit à nouveau réduire l'échelle, les VM Spot seront probablement préemptées en premier, laissant la majorité de vos pods s'exécuter sur des VM à la demande.

Pour donner la priorité aux VM Spot et éviter le scénario précédent, nous vous recommandons d'utiliser des classes de calcul personnalisées. Les classes de calcul personnalisées vous permettent de créer des règles de priorité qui favorisent les VM Spot lors de l'ajustement à la hausse en leur attribuant une priorité plus élevée que les nœuds à la demande. Pour maximiser davantage la probabilité que vos pods s'exécutent sur des nœuds compatibles avec des VM Spot, configurez la migration active.

L'exemple suivant montre comment utiliser des classes de calcul personnalisées pour hiérarchiser les VM Spot:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  priorities:
  - machineType: g2-standard-24
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  activeMigration:
    optimizeRulePriority: true

Dans l'exemple précédent, la règle de priorité déclare une préférence pour la création de nœuds avec le type de machine g2-standard-24 et les VM Spot. Si les VM Spot ne sont pas disponibles, GKE utilise des VM à la demande comme option de remplacement. Cette classe de calcul active également activeMigration, ce qui permet à l'autoscaler de cluster de migrer les charges de travail vers des VM Spot lorsque la capacité est disponible.

Si vous ne pouvez pas utiliser de classes de calcul personnalisées, ajoutez une affinité, une altération ou une tolérance de nœud. Par exemple, la règle d'affinité de nœud suivante déclare une préférence pour la planification de pods sur des nœuds qui sont compatibles avec des VM Spot (GKE ajoute automatiquement le libellé cloud.google.com/gke-spot=true à ces types de nœuds):

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
    preference:
      matchExpressions:
      - key: cloud.google.com/gke-spot
        operator: Equal
        values:
        - true

Pour en savoir plus sur l'utilisation des affinités de nœud, des rejets et des tolérances pour planifier des VM Spot, consultez l'article de blog Exécuter une application GKE sur des nœuds Spot avec des nœuds à la demande en tant que remplacement.

CRD ProvisioningRequest

Une ProvisioningRequest est une ressource personnalisée avec un espace de noms qui permet aux utilisateurs de demander de la capacité pour un groupe de pods à l'autoscaler de cluster. Cela est particulièrement utile pour les applications avec des pods interconnectés qui doivent être planifiés ensemble en tant qu'unité unique.

Classes de provisionnement compatibles

Il existe trois ProvisioningClasses compatibles:

• queued-provisioning.gke.io: cette classe spécifique à GKE s'intègre au planificateur de charges de travail dynamique. Elle vous permet de mettre en file d'attente des requêtes et de les traiter lorsque des ressources sont disponibles. Cette solution est idéale pour les tâches par lots ou les charges de travail tolérantes aux retards. Consultez Déployer des GPU pour les charges de travail par lot et d'IA avec le planificateur de charges de travail dynamique pour découvrir comment utiliser le provisionnement en file d'attente dans GKE. Compatible à partir de la version 1.28.3-gke.1098000 de GKE dans les clusters Standard et à partir de la version 1.30.3-gke.1451000 de GKE dans les clusters Autopilot.

• check-capacity.autoscaling.x-k8s.io: cette classe Open Source vérifie la disponibilité des ressources avant de tenter de planifier des pods. Compatible à partir de la version 1.30.2-gke.1468000 de GKE.

• best-effort-atomic.autoscaling.x-k8s.io: cette classe Open Source tente de provisionner les ressources de tous les pods de la requête. Si il est impossible de provisionner suffisamment de ressources pour tous les pods, aucune ressource ne sera provisionnée et l'ensemble de la requête échouera. Compatible à partir de la version 1.31.27 de GKE.

Pour en savoir plus sur les classes CheckCapacity et BestEffortAtomicScaleUp, consultez la documentation Open Source.

Limites à l'utilisation de ProvisioningRequest

• L'autoscaler de cluster GKE n'accepte qu'un seul PodTemplate par ProvisioningRequest.
• L'autoscaler de cluster GKE ne peut augmenter la capacité que d'un seul pool de nœuds à la fois. Si votre ProvisioningRequest nécessite des ressources de plusieurs pools de nœuds, vous devez créer des ProvisioningRequests distinctes pour chaque pool de nœuds.

Bonnes pratiques lors de l'utilisation de ProvisioningRequest

• Utilisez total-max-nodes: au lieu de limiter le nombre maximal de nœuds (--max nodes), utilisez --total-max-nodes pour limiter les ressources totales consommées par votre application.
• Utiliser location-policy=ANY: ce paramètre permet de planifier vos pods dans n'importe quel emplacement disponible, ce qui peut accélérer le provisionnement et optimiser l'utilisation des ressources.
• (Facultatif) Intégration à Kueue: Kueue peut automatiser la création de ProvisioningRequests, ce qui simplifie votre workflow. Pour en savoir plus, consultez la documentation Kueue.

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 .
• Lorsque vous supprimez un pool de nœuds GKE pour lequel l'autoscaling est activé, le flag NoSchedule est défini sur les nœuds, et tous les pods sur ces nœuds sont immédiatement expulsés. Pour atténuer la diminution soudaine des ressources disponibles, l'autoscaler du pool de nœuds peut provisionner de nouveaux nœuds dans le même pool. Ces nœuds nouvellement créés peuvent être planifiés, et les pods évincés sont de nouveau planifiés dessus. À terme, l'ensemble du pool de nœuds, y compris les nœuds nouvellement provisionnés et leurs pods, est supprimé, ce qui peut entraîner des interruptions de service. Pour contourner le problème et empêcher l'autoscaler de provisionner de nouveaux nœuds lors de la suppression, désactivez l'autoscaling sur le pool de nœuds avant de lancer la suppression.

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 :

• Résoudre les problèmes liés à l'autoscaler de cluster qui n'effectue pas de scaling à la baisse.
• Résoudre les problèmes liés à l'autoscaler de cluster qui n'effectue pas de scaling à la hausse.

Étape suivante

• Apprenez à procéder à l'autoscaling de vos nœuds.
• Apprenez à mettre à niveau automatiquement vos nœuds.
• Apprenez à réparer automatiquement vos nœuds.
• Découvrez comment réduire les temps d'extraction des images sur les nouveaux nœuds.