Procéder à l'autoscaling d'un cluster

Vous trouverez sur cette page la procédure à suivre pour configurer l'autoscaling de vos clusters Google Kubernetes Engine standards (GKE). Reportez-vous à la section sur l'autoscaler de cluster pour en savoir plus sur son fonctionnement.

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 automatiquement provisionnés et font l'objet d'un scaling automatique pour répondre aux exigences de vos charges de travail.

Utiliser l'autoscaler de cluster

Dans les sections suivantes, nous expliquons comment utiliser l'autoscaler de cluster.

Créer un cluster avec autoscaling

Vous pouvez créer un cluster avec l'autoscaling activé à l'aide de Google Cloud CLI ou de Google Cloud Console.

gcloud container clusters create CLUSTER_NAME \
    --enable-autoscaling \
    --num-nodes NUM_NODES \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --region=COMPUTE_REGION

gcloud container clusters create my-cluster --enable-autoscaling \
    --num-nodes=30 \
    --min-nodes=15 --max-nodes=50 \
    --region=us-central

gcloud container clusters create my-cluster --enable-autoscaling \
    --num-nodes 10 \
    --region us-central1 \
    --total-min-nodes 10  --total-max-nodes 60

Ajouter un pool de nœuds avec autoscaling

Vous pouvez créer un pool de nœuds en activant l'autoscaling à l'aide de gcloud CLI ou de Google Cloud Console.

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --enable-autoscaling \
    --min-nodes=MIN_NODES \
    --max-nodes=MAX_NODES \
    --region=COMPUTE_REGION

gcloud container node-pools create my-node-pool \
    --cluster my-cluster \
    --enable-autoscaling \
    --min-nodes 1 --max-nodes 5 \
    --zone us-central1-c

Activer l'autoscaling pour un pool de nœuds existant

Vous pouvez activer l'autoscaling pour un pool de nœuds existant à l'aide de gcloud CLI ou de Google Cloud Console.

gcloud container clusters update CLUSTER_NAME \
    --enable-autoscaling \
    --node-pool=POOL_NAME \
    --min-nodes=MIN_NODES \
    --max-nodes=MAX_NODES \
    --region=COMPUTE_REGION

Vérifier que l'autoscaling est activé pour le pool de nœuds existant

Vérifiez que votre cluster utilise l'autoscaling avec Google Cloud CLI ou la console Google Cloud.

gcloud container node-pools describe NODE_POOL_NAME --cluster=CLUSTER_NAME |grep autoscaling -A 1

autoscaling:
  enabled: true

Créer un pool de nœuds donnant la priorité à l'utilisation des réservations inutilisées

Vous pouvez utiliser l'option --location_policy=ANY lorsque vous créez un pool de nœuds pour indiquer à l'autoscaler de cluster de donner la priorité à l'utilisation des réservations inutilisées :

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location_policy=ANY

Remplacez les éléments suivants :

• POOL_NAME : nom du nouveau pool de nœuds que vous choisissez.
• CLUSTER_NAME : nom du cluster.

Désactiver l'autoscaling pour un pool de nœuds existant

Vous pouvez désactiver l'autoscaling pour un pool de nœuds existant à l'aide de gcloud CLI ou de Google Cloud Console.

gcloud container clusters update CLUSTER_NAME \
    --no-enable-autoscaling \
    --node-pool=POOL_NAME \
    --region=COMPUTE_REGION

Redimensionner un pool de nœuds

Pour les clusters avec autoscaling activé, l'autoscaler de cluster redimensionne automatiquement les pools de nœuds dans les limites spécifiées par la taille minimale (--min-nodes) et la taille maximale (--max-nodes) ou la taille totale minimale (--total-min-nodes) et la taille totale maximale (--total-max-nodes). Ces options s'excluent mutuellement. Vous ne pouvez pas redimensionner manuellement un pool de nœuds en modifiant ces valeurs.

Si vous souhaitez redimensionner manuellement un pool de nœuds dans votre cluster pour lequel l'autoscaling est activé, procédez comme suit :

1. Désactivez l'autoscaling sur le pool de nœuds.
2. Redimensionnez manuellement le cluster.
3. Réactivez l'autoscaling en spécifiant la taille minimale et la taille maximale du pool de nœuds.

Empêcher la planification des pods sur les nœuds sélectionnés

Vous pouvez utiliser des rejets startup ou status pour empêcher la planification des pods sur des nœuds sélectionnés, en fonction du cas d'utilisation.

Cette fonctionnalité est disponible dans GKE dans la version 1.28 et ultérieure.

Rejets de démarrage

Utilisez des rejets startup lorsqu'une opération doit être terminée avant que des pods puissent s'exécuter sur le nœud. Par exemple, les pods ne doivent pas s'exécuter tant que l'installation des pilotes sur le nœud n'est pas terminée.

L'autoscaler de cluster considère que les nœuds rejetés avec des rejets startup ne sont pas prêts, mais qu'ils seront pris en compte lors de la logique de scaling à la hausse, en supposant qu'ils seront prêts sous peu.

Les rejets de démarrage correspondent à tous les rejets portant le préfixe startup-taint.cluster-autoscaler.kubernetes.io/.

Rejets d'état

Utilisez des rejets status lorsque GKE ne doit pas utiliser un nœud donné pour exécuter des pods.

L'autoscaler de cluster considère que les nœuds rejetés avec des rejets status sont prêts, mais les ignore lors de la logique de scaling à la hausse. Même si le nœud rejeté est prêt, aucun pod ne doit s'exécuter. Si les pods ont besoin de davantage de ressources, GKE effectue un scaling à la hausse du cluster et ignore les nœuds rejetés.

Les rejets d'état correspondent à tous les rejets portant le préfixe status-taint.cluster-autoscaler.kubernetes.io/.

Ignorer les rejets

Les rejets à ignorer sont définis comme étant tous les rejets portant le préfixe ignore-taint.cluster-autoscaler.kubernetes.io/.

Dépannage

Vérifiez si le problème que vous rencontrez est dû à l'une des limites de l'autoscaler de cluster. Sinon, consultez les informations de dépannage suivantes concernant l'autoscaler de cluster :

Le cluster n'effectue pas de scaling à la baisse

Lorsque le cluster a correctement effectué un scaling à la hausse, puis qu'il tente d'effectuer un scaling à la baisse, les nœuds sous-utilisés restent activés et empêchent le cluster d'effectuer le scaling. Cette erreur se produit pour l'une des raisons suivantes :

• Des restrictions peuvent empêcher la suppression d'un nœud par l'autoscaler. GKE peut empêcher la suppression d'un nœud si celui-ci contient un pod remplissant l'une des conditions suivantes :

  • Les règles d'affinité ou d'anti-affinité du pod empêchent la replanification.
  • Dans les versions 1.21 et antérieures de GKE, le pod dispose d'un stockage local.
  • Le pod n'est pas géré par un contrôleur tel que Deployment, StatefulSet, Job ou ReplicaSet.

  Pour résoudre ce problème, configurez les règles de planification et d'éviction de l'autoscaler de cluster sur vos pods. Pour en savoir plus, consultez la section Prendre en compte la planification et l'interruption des pods.

• Les pods système s'exécutent sur un nœud. Pour vérifier que vos nœuds exécutent des pods kube-system, procédez comme suit :

  1. Accédez à l'explorateur de journaux dans la console Google Cloud.

     Accéder à l'explorateur de journaux

  2. Cliquez sur Générateur de requêtes.

  3. Utilisez la requête suivante pour rechercher tous les enregistrements du journal des règles de réseau :

       - resource.labels.location="CLUSTER_LOCATION"
       resource.labels.cluster_name="CLUSTER_NAME"
       logName="projects/PROJECT_ID/logs/container.googleapis.com/cluster-autoscaler-visibility"
       jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"
     

     Remplacez les éléments suivants :

     • CLUSTER_LOCATION : la région dans laquelle se trouve le cluster
     • CLUSTER_NAME : le nom du cluster
     • PROJECT_ID : ID du projet dans lequel le cluster est créé.

     • NODE_POOL_NAME : le nom de votre pool de nœuds

       S'il y a des pods kube-system en cours d'exécution sur votre pool de nœuds, le résultat inclut les éléments suivants :

       "no.scale.down.node.pod.kube.system.unmovable"
       

  Pour résoudre ce problème, vous devez effectuer l'une des opérations suivantes :

  • Ajoutez un budget PodDisruptionBudget pour les pods kube-system. Pour en savoir plus sur l'ajout manuel d'un PodDisruptionBudget pour les pods kube-system, consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes.
  • Utilisez une combinaison de rejets et de tolérances de pools de nœuds pour séparer les pods kube-system des pods de votre application. Pour en savoir plus, consultez la section Provisionnement automatique des nœuds dans GKE.

Incohérence sur la taille du pool de nœuds

Le problème suivant survient lorsque vous configurez la taille du pool de nœuds :

• La taille d'un pool de nœuds existant est inférieure au nombre minimal de nœuds que vous avez spécifié pour le cluster.

La liste suivante décrit les causes les plus courantes de ce comportement :

• Vous avez spécifié un nouveau nombre minimal de nœuds alors que le nombre de nœuds existants est plus élevé.
• Vous avez réduit manuellement le pool de nœuds ou le groupe d'instances géré sous-jacent. Cette opération manuelle a spécifié un nombre de nœuds inférieur au nombre minimal de nœuds.
• Vous avez déployé des VM Spot préemptées dans le pool de nœuds.
• 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".

  Pour connaître les étapes de dépannage supplémentaires lors des événements de scaling à la baisse, consultez la page Impossible d'effectuer un scaling à la baisse du cluster.

• Durant la phase de réduction de la capacité, l'autoscaler de cluster respecte le délai de grâce pour l'arrêt des pods, jusqu'à 10 minutes. Passé ce délai, les pods sont interrompus de force.

• Vous pouvez constater une taille de pool de nœuds inférieure au nombre minimal de nœuds que vous avez spécifié pour le cluster. Ce comportement est dû au fait que l'autoscaler n'utilise le paramètre de nombre minimal de nœuds que lorsqu'il doit déterminer un scaling à la baisse. Voici la liste des causes possibles de ce comportement.

Pour résoudre ce problème, augmentez manuellement la taille du pool de nœuds à une valeur correspondant au moins au nombre minimal de nœuds. Pour en savoir plus, consultez la section Redimensionner manuellement un cluster.

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

• 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 ?

Étapes suivantes

• En savoir plus sur l'autoscaler de cluster
• Afficher les événements de l'autoscaler de cluster