Clusters Anthos sur VMware devient Google Distributed Cloud (logiciel uniquement) pour VMware. Pour en savoir plus, consultez la présentation du produit.

Cette page a été traduite par l'API Cloud Translation.

Activer l'autoscaling du cluster

Ce document décrit l'autoscaling pour un cluster d'utilisateur dans Google Distributed Cloud.

L'autoscaling des clusters augmente ou diminue le nombre de nœuds dans un pool de nœuds en fonction des exigences de vos charges de travail.

Avant de commencer

Découvrez les limites de l'autoscaler de cluster.

L'autoscaler de cluster repose sur les hypothèses suivantes:

Tous les pods répliqués peuvent être redémarrés sur un autre nœud, ce qui peut entraîner une brève interruption. Si vos services ne peuvent pas tolérer les interruptions, nous vous déconseillons d'utiliser l'autoscaler de cluster.
Les utilisateurs ou les administrateurs ne gèrent pas manuellement les nœuds. Si l'autoscaling est activé pour un pool de nœuds, vous ne pouvez pas remplacer le champ replicas du pool de nœuds.
Tous les nœuds d'un pool de nœuds unique ont le même ensemble de libellés.

Fonctionnement de l'autoscaling de cluster

L'autoscaler de cluster fonctionne sur une base de pool de nœuds. Lorsque vous activez l'autoscaling pour un pool de nœuds, vous spécifiez un nombre minimal et maximal de nœuds pour le pool.

L'autoscaler de cluster augmente ou diminue automatiquement le nombre de nœuds dans le pool, en fonction des demandes de ressources (plutôt que de l'utilisation réelle des ressources) des pods exécutés sur les nœuds. Il vérifie régulièrement l'état des pods et des nœuds, et prend les mesures suivantes:

Si les pods ne sont pas programmables en raison d'un nombre insuffisant de nœuds dans le pool, l'autoscaler de cluster en ajoute, dans la limite du nombre maximal spécifié.
Si les nœuds sont sous-utilisés et que tous les pods peuvent être planifiés avec moins de nœuds dans le pool, l'autoscaler de cluster supprime des nœuds, jusqu'au minimum spécifié. Si un nœud ne peut pas être drainé correctement, il est arrêté de force, et le disque géré par Kubernetes associé est dissocié en toute sécurité.

Si vos pods ont demandé trop peu de ressources (ou n'ont pas modifié les valeurs par défaut, ce qui peut être insuffisant) et que vos nœuds connaissent des pénuries, l'autoscaler de cluster ne corrige pas cette situation. Vous pouvez vous assurer que l'autoscaler de cluster fonctionne avec précision en effectuant des demandes de ressources explicites pour toutes vos charges de travail.

Pour un pool de nœuds individuel, minReplicas doit être ≥ 1. Toutefois, la somme des nœuds de cluster d'utilisateur non rejetés à un moment donné doit être au moins égale à 3. Cela signifie que la somme des valeurs minReplicas pour tous les pools de nœuds avec autoscaling et des valeurs replicas pour tous les pools de nœuds sans autoscaling doit être au moins égale à 3.

L'autoscaler de cluster prend en compte le coût relatif des types d'instances dans les différents pools de nœuds et tente de développer le pool de nœuds de manière à réduire au maximum le gaspillage.

Créer un cluster d'utilisateur avec autoscaling

Pour créer un cluster d'utilisateur avec l'autoscaling activé pour un pool de nœuds, remplissez la section autoscaling du pool de nœuds dans le fichier de configuration du cluster d'utilisateur. Exemple :

nodePools:
- name: pool‐1
  …
  replicas: 3
  ...
  autoscaling:
    minReplicas: 1
    maxReplicas: 5

La configuration précédente crée un pool de nœuds avec trois instances dupliquées et applique un autoscaling avec une taille minimale de pool de nœuds égale à 1 et une taille maximale de 5.

La valeur minReplicas doit être ≥ 1. Un pool de nœuds ne peut pas effectuer de scaling à la baisse jusqu'à zéro nœud.

Ajouter un pool de nœuds avec autoscaling

Pour ajouter un pool de nœuds avec autoscaling à un cluster existant, procédez comme suit :

Modifiez le fichier de configuration du cluster d'utilisateur pour ajouter un pool de nœuds et incluez une section autoscaling pour le pool. Définissez les valeurs de replicas, minReplicas et maxReplicas selon vos besoins. Exemple :
```
nodePools:
- name: my-new-node-pool
  …
  replicas: 3
  ...
  autoscaling:
    minReplicas: 2
    maxReplicas: 6
```

Mettez à jour le cluster :

gkectl update cluster --config USER_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

Pour activer l'autoscaling pour un pool de nœuds dans un cluster existant, procédez comme suit :

Modifiez un nodePool spécifique dans le fichier de configuration du cluster d'utilisateur et incluez la section autoscaling. Définissez les valeurs de minReplicas et maxReplicas si vous le souhaitez.
```
nodePools:
- name: my-existing-node-pool
  …
  replicas: 3
  ...
  autoscaling:
    minReplicas: 1
    maxReplicas: 5
```

Mettez à jour le cluster :

gkectl update cluster --config USER_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

Pour désactiver l'autoscaling pour un pool de nœuds spécifique, procédez comme suit :

Modifiez le fichier de configuration du cluster d'utilisateur et supprimez la section autoscaling de ce pool de nœuds.
Exécutez gkectl update cluster.

Vérifier le comportement de l'autoscaler de cluster

Vous pouvez déterminer ce que fait l'autoscaler de cluster de plusieurs manières.

Vérifier les journaux de l'autoscaler de cluster

Tout d'abord, recherchez le nom du pod de l'autoscaler de cluster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods -n USER_CLUSTER_NAME | grep cluster-autoscaler

Vérifiez les journaux sur le pod de l'autoscaler de cluster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG logs cluster-autoscaler-POD_NAME --container cluster-autoscaler -n USER_CLUSTER_NAME

Remplacez POD_NAME par le nom du pod de l'autoscaler de cluster.

Vérifier le plan de configuration

L'autoscaler de cluster publie la carte de configuration kube-system/cluster-autoscaler-status.

Pour afficher la carte de configuration:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get configmap cluster-autoscaler-status -n kube-system -o yaml

Vérifiez les événements d'autoscaling du cluster.

Vous pouvez vérifier les événements d'autoscaling de cluster :

Sur les pods (en particulier ceux qui ne peuvent pas être planifiés ou sur des nœuds sous-utilisés)
Sur les nœuds
Sur la carte de configuration kube-system/cluster-autoscaler-status.

Limites

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

Il n'est pas possible de personnaliser la planification avec des filtres modifiés.
Les nœuds n'effectuent pas de scaling à la hausse 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'autoscaling n'est pas disponible pour les pools de nœuds Windows.

Dépannage

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.
Si vous rencontrez des problèmes lors d'un scaling à la baisse du cluster, consultez la page Prendre en compte la planification et l'interruption des pods. Il vous faudra peut-être ajouter un 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.
Lors d'un scaling à la baisse, 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 dispose d'un stockage en local.
- Le pod n'est pas géré par un contrôleur tel qu'un déploiement, un StatefulSet, une tâche ou un ReplicaSet.
- Le pod se trouve dans l'espace de noms kube-system et ne dispose pas d'un PodDisruptionBudget
Le PodDisruptionBudget d'une application peut empêcher l'autoscaling. Si la suppression de nœuds entraîne un dépassement du budget, le cluster n'effectue pas de scaling à la baisse.

En savoir plus

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