À propos du provisionnement automatique des nœuds

Standard

---

Cette page explique le fonctionnement du provisionnement automatique des nœuds dans les clusters Google Kubernetes Engine (GKE) standards. Le provisionnement automatique des nœuds entraîne un scaling automatique des nœuds pour répondre aux exigences de vos charges de travail.

Avec les clusters Autopilot, vous n'avez pas besoin de provisionner manuellement des nœuds ni de gérer des pools de nœuds, car GKE gère automatiquement le scaling et le provisionnement des nœuds.

Pourquoi utiliser le provisionnement automatique des nœuds

Le provisionnement automatique des nœuds gère et fait évoluer automatiquement un ensemble de pools de nœuds pour le compte de l'utilisateur. Sans provisionnement automatique des nœuds, l'autoscaler de cluster GKE ne crée des nœuds qu'à partir de pools de nœuds créés par l'utilisateur. Le provisionnement automatique de nœuds permet à GKE de créer et de supprimer automatiquement des pools de nœuds.

Fonctionnalités non compatibles

Le provisionnement automatique des nœuds ne crée pas de pools de nœuds utilisant l'une des fonctionnalités suivantes. Toutefois, l'autoscaler de cluster procède au scaling des nœuds des pools de nœuds existants utilisant les fonctionnalités suivantes :

• GKE Sandbox.
• Systèmes d'exploitation Windows.
• Le contrôle de l'affinité de réservation.
• Autoscaling des PersistentVolumes locaux.
• Le provisionnement automatique des nœuds avec des disques SSD locaux comme stockage éphémère.
• Le provisionnement automatique via une planification personnalisée utilisant des filtres modifiés
• Configurez le multithread simultané (SMT, simultaneous multi-threading).

Fonctionnement du provisionnement automatique des nœuds

Le provisionnement automatique des nœuds est un mécanisme de l'autoscaler de cluster, qui se limite au scaling des pools de nœuds existants. Lorsque le provisionnement automatique des nœuds est activé, l'autoscaler de cluster peut créer automatiquement les pools de nœuds en fonction des spécifications appliquées aux pods non planifiables.

Remarque : L'autoscaler de cluster est automatiquement activé lors de l'utilisation du provisionnement automatique des nœuds.

Le provisionnement automatique des nœuds crée des pools de nœuds en fonction des informations suivantes :

• Demandes de ressources de processeur, de mémoire et de stockage éphémère.
• Demandes de GPU.
• Affinités de nœuds et sélecteurs de libellés des pods en attente
• Tolérances et rejets de nœuds des pods en attente

Remarque : Pour que le provisionnement automatique des nœuds fonctionne comme prévu, les demandes de ressources de pod doivent être suffisamment volumineuses pour que le pod fonctionne normalement. Si les demandes de ressources sont trop modestes, les nœuds provisionnés automatiquement risquent de manquer de ressources nécessaires au lancement des pods.

Limites de ressources

Le provisionnement automatique des nœuds et l'autoscaler de cluster sont limités aux niveaux suivants :

• Au niveau du pool de nœuds : les pools de nœuds provisionnés automatiquement sont limités à 1000 nœuds.
• Au niveau du cluster :
  • Les limites de provisionnement automatique que vous définissez s'appliquent en fonction des quantités de processeurs et de mémoire utilisées sur tous les pools de nœuds, et pas uniquement sur les pools provisionnés automatiquement.
  • L'autoscaler de cluster ne crée pas de nouveaux nœuds si cela entraîne le dépassement de l'une des limites définies. Si les limites sont déjà dépassées, GKE ne supprime pas les nœuds.

Séparation de la charge de travail

S'il existe des pods avec des tolérances et des affinités de nœuds en attente, le provisionnement automatique de nœuds peut provisionner des nœuds avec les libellés et les rejets correspondants.

Le provisionnement automatique des nœuds peut créer des pools de nœuds avec des libellés et des rejets si toutes les conditions suivantes sont réunies :

• Un pod en attente nécessite un nœud doté d'un libellé avec une clé et une valeur spécifiques.
• Le pod a une tolérance pour les rejets avec la même clé.
• La tolérance concerne l'effet NoSchedule, l'effet NoExecute ou l'ensemble des effets.

Pour obtenir des instructions, consultez la page Configurer la séparation des charges de travail dans GKE.

Suppression de pools de nœuds provisionnés automatiquement

Si un pool de nœuds provisionné automatiquement ne contient aucun nœud, GKE supprime ce pool. GKE ne supprime pas les pools de nœuds qui ne sont pas provisionnés automatiquement.

Types de machines compatibles

Le provisionnement automatique des nœuds examine les exigences de pod dans votre cluster pour déterminer le type de nœud qui conviendrait le mieux à ces pods.

Par défaut, GKE utilise la série de machines E2, sauf si l'une des conditions suivantes s'applique :

• La charge de travail demande une fonctionnalité qui n'est pas disponible dans la série de machines E2. Par exemple, si un GPU est requis par la charge de travail, la série de machines N1 est utilisée pour le nouveau pool de nœuds.
• La charge de travail demande des ressources TPU. Pour en savoir plus sur les TPU, consultez la Présentation des Cloud TPU.
• La charge de travail utilise le libellé machine-family. Pour en savoir plus, consultez la section Utiliser une famille de machines personnalisées.

Si le pod demande des GPU, le provisionnement automatique des nœuds attribue un type de machine suffisamment volumineux pour supporter le nombre de GPU demandé par le pod. Le nombre de GPU limite le processeur et la mémoire dont le nœud peut disposer. Pour en savoir plus, consultez la page Plates-formes de GPU.

Remarque : Sur les versions de GKE antérieures à la version 1.25, le provisionnement automatique des nœuds attribue un type de machine doté du nombre exact de GPU. Un problème connu entraîne le blocage des pods présentant des ratios processeur/GPU ou mémoire/GPU très élevés dans l'état Pending. Nous vous recommandons de mettre à niveau vers la version 1.25 ou ultérieure de GKE.

Images de nœuds compatibles

Le provisionnement automatique des nœuds crée des pools de nœuds en utilisant l'une des images de nœuds suivantes :

• Container-Optimized OS (cos_containerd).
• Ubuntu (ubuntu_containerd).

Accélérateurs de machine learning compatibles

Le provisionnement automatique des nœuds peut créer des pools de nœuds avec des accélérateurs matériels tels que GPU et Cloud TPU. Le provisionnement automatique des nœuds est compatible avec les TPU dans les versions 1.28 et ultérieures de GKE.

GPU

Si le pod demande des GPU, le provisionnement automatique des nœuds attribue un type de machine suffisamment volumineux pour supporter le nombre de GPU demandé par le pod. Le nombre de GPU limite le processeur et la mémoire dont le nœud peut disposer. Pour en savoir plus, consultez la page Plates-formes de GPU.

Remarque : Sur les versions de GKE antérieures à la version 1.25, le provisionnement automatique des nœuds attribue un type de machine doté du nombre exact de GPU. Un problème connu entraîne le blocage des pods présentant des ratios processeur/GPU ou mémoire/GPU très élevés dans l'état "Pending" (en attente). Nous vous recommandons de passer à la version 1.25 ou ultérieure de GKE.

Cloud TPU

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.

Si une tranche de TPU spécifique ne comporte aucun pod en cours d'exécution ou en attente de planification, GKE effectue un scaling à la baisse du pool de nœuds. Le scaling à la baisse des pools de nœuds de tranche de TPU multi-hôte est effectué de manière atomique. Le scaling à la baisse des pools de nœuds de tranche de TPU à hôte unique est effectué en supprimant des tranches de TPU à hôte unique.

Lorsque vous activez le provisionnement automatique des nœuds avec des TPU, GKE décide du scaling en fonction des valeurs définies dans la requête du pod. Le fichier manifeste suivant est un exemple de spécification de déploiement qui génère un pool de nœuds contenant une tranche de TPU v4 avec une topologie 2x2x2 et deux machines ct4p-hightpu-4t :

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: tpu-workload
      labels:
        app: tpu-workload
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx-tpu
      template:
        metadata:
          labels:
            app: nginx-tpu
        spec:
          nodeSelector:
            cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
            cloud.google.com/gke-tpu-topology: 2x2x2
            cloud.google.com/reservation-name: my-reservation
          containers:
          - name: nginx
            image: nginx:1.14.2
            resources:
              requests:
                google.com/tpu: 4
              limits:
               google.com/tpu: 4
            ports:
            - containerPort: 80

Où :

• cloud.google.com/gke-tpu-accelerator : version et type de TPU. Par exemple, TPU v4 avec tpu-v4-podslice ou TPU v5e avec tpu-v5-lite-podslice.
• cloud.google.com/gke-tpu-topology : nombre et disposition physique des puces TPU au sein d'une tranche de TPU. Lorsque vous créez un pool de nœuds et activez le provisionnement automatique des nœuds, vous sélectionnez la topologie TPU. Pour en savoir plus sur les topologies Cloud TPU, consultez la page Configurations TPU.
• limit.google.com/tpu : nombre de puces TPU sur la VM TPU. La plupart des configurations n'ont qu'une seule valeur correcte. Toutefois, pour la configuration de tpu-v5-lite-podslice avec la topologie 2x4 :
  • Si vous spécifiez google.com/tpu = 8, le provisionnement automatique des nœuds effectue un scaling à la hausse du pool de nœuds de tranche TPU à hôte unique en ajoutant une machine ct5lp-hightpu-8t.
  • Si vous spécifiez google.com/tpu = 4, le provisionnement automatique des nœuds crée un pool de nœuds de tranche TPU multi-hôte avec deux machines ct5lp-hightpu-4t.
• cloud.google.com/reservation-name: nom de la réservation utilisée par la charge de travail. Si cette option est omise, la charge de travail n'utilise aucune réservation.

Si vous définissez tpu-v4-podslice, le provisionnement automatique des nœuds prend les décisions suivantes :

Valeurs définies dans le fichier manifeste du pod		Décidées par le provisionnement automatique des nœuds
gke-tpu-topology	limit.google.com/tpu	Type de pool de nœuds	Taille du pool de nœuds	Type de machine
2x2x1	4	Tranche de TPU à hôte unique	Flexible	ct4p-hightpu-4t
{A}x{B}x{C}	4	Tranche de TPU multi-hôte	{A}x{B}x{C}/4	ct4p-hightpu-4t

Le produit de {A}x{B}x{C} définit le nombre de puces dans le pool de nœuds. Par exemple, vous pouvez définir une petite topologie de 64 puces avec des combinaisons telles que 4x4x4. Si vous utilisez des topologies de plus de 64 puces, les valeurs attribuées à {A}, {B} et {C} doivent répondre aux conditions suivantes :

• {A}, {B} et {C} sont tous inférieurs ou égaux à quatre, ou des multiples de quatre.
• La topologie la plus grande compatible est 12x16x16.
• Les valeurs attribuées conservent le modèle A ≤ B ≤ C. Par exemple, 2x2x4 ou 2x4x4 pour les petites topologies.

Si vous définissez tpu-v5-lite-podslice, le provisionnement automatique des nœuds prend les décisions suivantes :

Valeurs définies dans le fichier manifeste du pod		Décidées par le provisionnement automatique des nœuds
gke-tpu-topology	limit.google.com/tpu	Type de pool de nœuds	Taille du pool de nœuds	Type de machine
1x1	1	Tranche de TPU à hôte unique	Flexible	ct5lp-hightpu-1t
2x2	4	Tranche de TPU à hôte unique	Flexible	ct5lp-hightpu-4t
2x4	8	Tranche de TPU à hôte unique	Flexible	ct5lp-hightpu-8t
2x4^1	4	Tranche de TPU multi-hôte	2 (8/4)	ct5lp-hightpu-4t
4x4	4	Tranche de TPU multi-hôte	4 (16/4)	ct5lp-hightpu-4t
4x8	4	Tranche de TPU multi-hôte	8 (32/4)	ct5lp-hightpu-4t
4x8	4	Tranche de TPU multi-hôte	16 (32/4)	ct5lp-hightpu-4t
8x8	4	Tranche de TPU multi-hôte	16 (64/4)	ct5lp-hightpu-4t
8x16	4	Tranche de TPU multi-hôte	32 (128/4)	ct5lp-hightpu-4t
16x16	4	Tranche de TPU multi-hôte	64 (256/4)	ct5lp-hightpu-4t

1. Cas particulier où le type de machine dépend de la valeur que vous avez définie dans le champ google.com/tpu. ↩

Si vous définissez le type d'accélérateur sur tpu-v5-lite-device, le provisionnement automatique des nœuds prend les décisions suivantes :

Valeurs définies dans le fichier manifeste du pod		Décidées par le provisionnement automatique des nœuds
gke-tpu-topology	limit.google.com/tpu	Type de pool de nœuds	Taille du pool de nœuds	Type de machine
1x1	1	Tranche de TPU à hôte unique	Flexible	ct5l-hightpu-1t
2x2	4	Tranche de TPU à hôte unique	Flexible	ct5l-hightpu-4t
2x4	8	Tranche de TPU à hôte unique	Flexible	ct5l-hightpu-8t

Pour savoir comment configurer le provisionnement automatique des nœuds, consultez la page Configurer des TPU.

Compatibilité avec les VM Spot

Le provisionnement automatique des nœuds accepte la création de pools de nœuds basés sur des VM Spot.

La création de pools de nœuds basés sur des VM Spot n'est envisagée que si des pods non programmables ayant une tolérance pour le rejet cloud.google.com/gke-spot="true":NoSchedule existent. Le rejet est automatiquement appliqué aux nœuds des pools de nœuds provisionnés automatiquement qui sont basés sur des VM Spot.

Vous pouvez combiner la tolérance avec un nodeSelector ou une règle d'affinité de nœud pour les libellés de nœud cloud.google.com/gke-spot="true" ou cloud.google.com/gke-provisioning=spot (pour les nœuds exécutant la version 1.25.5-gke.2500 ou ultérieure de GKE), afin de vous assurer que vos charges de travail ne s'exécutent que sur des pools de nœuds basés sur des VM Spot.

Remarque : Le provisionnement automatique des nœuds accepte également la création de pools de nœuds basés sur des VM préemptives à l'aide du rejet cloud.google.com/gke-preemptible="true":NoSchedule et la tolérance correspondante. Toutefois, il est fortement recommandé d'utiliser les VM Spot.

Remarque : La création de pools de nœuds basés sur des VM Spot n'est possible que dans la version 1.21 de GKE et les versions ultérieures. Les VM préemptives peuvent être utilisées dans les versions antérieures de GKE. Si un pod a une tolérance pour le libellé cloud.google.com/gke-spot="true" dans GKE version 1.20 ou antérieure, le provisionnement automatique des nœuds crée un pool de nœuds portant ce libellé, mais le pool de nœuds n'utilise pas réellement de VM spot.

Compatibilité avec les pods demandant un stockage éphémère

Le provisionnement automatique des nœuds permet de créer des pools de nœuds lorsque les pods demandent un stockage éphémère. La taille du disque de démarrage provisionné dans les pools de nœuds est constante pour tous les nouveaux pools de nœuds provisionnés automatiquement. Cette taille de disque de démarrage peut être personnalisée.

La valeur par défaut est de 100 Gio. Le stockage éphémère sauvegardé par les disques SSD locaux n'est pas compatible.

Le provisionnement automatique des nœuds ne provisionnera un pool de nœuds que si le stockage éphémère pouvant être alloué d'un nœud avec un disque de démarrage spécifié est supérieur ou égal à la demande de stockage éphémère d'un pod en attente. Si la demande de stockage éphémère est supérieure à ce qui peut être alloué, le provisionnement automatique des nœuds ne provisionne pas un pool de nœuds. Les tailles de disque des nœuds ne sont pas configurées de manière dynamique en fonction des demandes de stockage éphémère des pods en attente.

Limites d'évolutivité

Le provisionnement automatique des nœuds présente les mêmes limites que l'autoscaler de cluster, ainsi que les limites supplémentaires suivantes :

Limite du nombre de charges de travail distinctes

Le provisionnement automatique des nœuds accepte un maximum de 100 charges de travail distinctes.

Limite du nombre de pools de nœuds

Le provisionnement automatique des nœuds est prioritaire sur la création de pools de nœuds lorsque le nombre de pools du cluster approche 100. La création de plus de 100 pools de nœuds est possible, mais prise en compte lorsque la création d'un pool de nœuds est la seule option permettant de planifier un pod en attente.

Étapes suivantes

• Découvrez comment activer le provisionnement automatique des nœuds.
• Apprenez-en davantage sur l'autoscaler de cluster