VM Spot

Cette page explique ce que sont les VM Spot et leur fonctionnement dans Google Kubernetes Engine (GKE). Pour découvrir comment utiliser les VM Spot, consultez la section Utiliser des VM Spot.

Présentation des VM Spot dans GKE

Les VM Spot sont des instances de machines virtuelles (VM) Compute Engine dont le prix est inférieur à celui des VM Compute Engine standards et qui n'offrent aucune garantie de disponibilité. Les VM Spot offrent les mêmes types de machines et les mêmes options que les VM standards.

Vous pouvez utiliser des Spot VM dans vos clusters et pools de nœuds pour exécuter des charges de travail sans état, par lots ou tolérantes aux pannes, qui peuvent tolérer les perturbations causées par la nature éphémère des Spot VM.

Les VM Spot restent disponibles jusqu'à ce que Compute Engine ait besoin des ressources pour les VM standards.

Pour en savoir plus sur les Spot VM, consultez la section Spot VM dans la documentation Compute Engine.

Avantages des VM Spot

Les Spot VM et les VM préemptives présentent de nombreux avantages, en particulier :

Contrairement aux VM préemptives, qui expirent au bout de 24 heures, les Spot VM n'ont aucun délai d'expiration. Les Spot VM ne sont arrêtées que lorsque Compute Engine a besoin des ressources ailleurs.

Fonctionnement des spot VM dans GKE

Lorsque vous créez un cluster ou un pool de nœuds à l'aide de Spot VM, GKE crée des Spot VM Compute Engine sous-jacentes qui se comportent comme un groupe d'instances géré (MIG). Les nœuds qui utilisent des VM Spot se comportent comme des nœuds GKE standards, mais sans garantie de disponibilité. Lorsque les ressources utilisées par les VM Spot sont requises pour exécuter des VM standards, Compute Engine arrête ces VM Spot afin de pouvoir utiliser les ressources ailleurs.

Résiliation et arrêt progressif des spot VM

Lorsque Compute Engine doit récupérer les ressources utilisées par les VM Spot, un avis de préemption est envoyé à GKE. Une fois l'avis de préemption envoyé, Compute Engine envoie un signal ACPI G2 Soft Off pour lancer la période d'arrêt de la VM.

Par défaut, les clusters GKE disposent d'une période d'arrêt progressif de 30 secondes pour les pods après la réception de la notification de préemption. Cette période est divisée en 15 secondes pour l'arrêt de vos pods, après quoi les pods système critiques ont 15 secondes pour s'arrêter.

Vous pouvez éventuellement prolonger la durée de la période d'arrêt progressif à 120 secondes. La configuration de cette durée est en preview. Le plan de contrôle de votre cluster doit exécuter GKE version 1.35.0-gke.1171000 ou ultérieure. Vous pouvez prolonger la durée en personnalisant la configuration du système de nœuds pour définir les valeurs de pools de nœuds standards spécifiques. Pour en savoir plus, consultez Arrêt progressif des VM Spot dans GKE. Cette méthode n'est compatible qu'avec le mode Standard.

Par défaut, les clusters utilisent l'arrêt en douceur des nœuds pendant une période par défaut de 30 secondes entre la notification d'arrêt et l'arrêt. Les pods standards ont 15 secondes pour s'arrêter, après quoi les pods système (avec les priorityClasses system-cluster-critical ou system-node-critical) disposent de 15 secondes pour s'arrêter. Vous pouvez prolonger le délai de grâce à l'aide des champs suivants :

  • shutdownGracePeriodSeconds : prolongez le délai de grâce total des pods à 120 secondes, ou à 0 seconde si vous n'avez pas besoin de temps pour l'arrêt progressif.
  • shutdownGracePeriodCriticalPodsSeconds : prolonge le délai de grâce pour l'arrêt des pods système critiques. Ce champ n'est valide que si vous spécifiez également le champ shutdownGracePeriodSeconds. La valeur de ce champ doit être inférieure à celle du champ shutdownGracePeriodSeconds. Par exemple, si vous spécifiez une valeur de 30 dans le champ shutdownGracePeriodCriticalPodsSeconds et une valeur de 120 dans le champ shutdownGracePeriodSeconds, les pods standards disposent de 90 secondes pour s'arrêter et les pods système de 30 secondes.

Lors de l'arrêt progressif, si les pods font partie d'une charge de travail gérée, comme un déploiement, le contrôleur crée et planifie de nouveaux pods pour remplacer les pods arrêtés. Si vous spécifiez une valeur supérieure à la période d'arrêt progressif définie dans le champ terminationGracePeriodSeconds du fichier manifeste de votre pod, la période d'arrêt progressif n'est pas prolongée. Le délai de grâce total maximal qu'un pod peut obtenir est de 120 secondes.

Planifier des charges de travail sur des Spot VM

GKE ajoute automatiquement les libellés cloud.google.com/gke-spot=true et cloud.google.com/gke-provisioning=spot (pour les nœuds exécutant la version 1.25.5-gke.2500 de GKE ou une version ultérieure) aux nœuds qui utilisent des VM Spot. Vous pouvez planifier des pods spécifiques sur des nœuds qui utilisent des VM Spot à l'aide du champ nodeSelector dans la spécification de pod. Les exemples suivants utilisent le libellé cloud.google.com/gke-spot :

apiVersion: v1
kind: Pod
spec:
  nodeSelector:
    cloud.google.com/gke-spot: "true"

Vous pouvez également utiliser l'affinité de nœuds pour indiquer à GKE de planifier des pods sur des VM Spot, comme dans l'exemple suivant :

apiVersion: v1
kind: Pod
spec:
...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/gke-spot
            operator: In
            values:
            - "true"
...

Vous pouvez également utiliser nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution pour préférez que GKE place les pods sur des nœuds qui utilisent des Spot VM. Il n'est pas recommandé de privilégier les VM Spot, car GKE peut planifier les pods sur des nœuds viables existants qui utilisent des VM standards.

Utiliser des rejets et des tolérances pour la planification

Pour éviter toute interruption, utilisez un rejet de nœud pour vous assurer que GKE ne planifie pas les charges de travail critiques sur les VM Spot. Lorsque vous rejetez des nœuds qui utilisent des VM Spot, GKE ne programme que les pods dont la tolérance correspond à ces nœuds.

Si vous utilisez des rejets de nœuds, assurez-vous que votre cluster comporte également au moins un pool de nœuds qui utilise des VM Compute Engine standards. Les pools de nœuds qui utilisent des VM standards constituent un emplacement fiable pour GKE pour planifier des composants système critiques tels que DNS.

Pour en savoir plus sur l'utilisation d'un rejet de nœud pour les Spot VM, consultez la page Utiliser des rejets et des tolérances pour les Spot VM.

Utiliser des spot VM avec des pools de nœuds GPU

Les Spot VM sont compatibles avec l'utilisation des GPU. Lorsque vous créez un pool de nœuds GPU, GKE ajoute automatiquement le rejet nvidia.com/gpu=present:NoSchedule aux nouveaux nœuds. Seuls les pods avec la tolérance correspondante peuvent s'exécuter sur ces nœuds. GKE ajoute automatiquement cette tolérance aux pods qui demandent des GPU.

Votre cluster doit disposer d'au moins un pool de nœuds non GPU utilisant des VM standards avant de créer un pool de nœuds GPU utilisant des VM Spot. Si votre cluster ne dispose que d'un pool de nœuds GPU avec des Spot VM, GKE n'ajoute pas le rejet nvidia.com/gpu=present:NoSchedule à ces nœuds. Par conséquent, GKE peut planifier des charges de travail du système sur les pools de nœuds GPU avec des Spot VM, ce qui peut entraîner des perturbations en raison des Spot VM et peut augmenter votre consommation de ressources, car les nœuds GPU sont plus chers que nœuds non GPU.

Autoscaler de cluster et provisionnement automatique des nœuds

Vous pouvez utiliser l'autoscaler de cluster et le provisionnement automatique des nœuds pour effectuer un scaling automatique de vos clusters et pools de nœuds en fonction des exigences de vos charges de travail. L'autoscaler de cluster et le provisionnement automatique des nœuds sont compatibles avec l'utilisation de Spot VM.

Spot VM et provisionnement automatique des nœuds

Le provisionnement automatique des nœuds crée et supprime automatiquement les pools de nœuds de votre cluster pour répondre aux exigences de vos charges de travail. Lorsque vous programmez des charges de travail nécessitant des VM Spot à l'aide d'un nodeSelector ou de l'affinité de nœud, le provisionnement automatique des nœuds crée de nouveaux pools de nœuds pour gérer les pods des charges de travail. GKE ajoute automatiquement le rejet cloud.google.com/gke-spot=true:NoSchedule aux nœuds des nouveaux pools de nœuds. Seuls les pods avec la tolérance correspondante peuvent s'exécuter sur les nœuds de ces pools de nœuds. Vous devez ajouter la tolérance correspondante à vos déploiements pour autoriser GKE à placer les pods sur des VM Spot.

   tolerations:
   - key: cloud.google.com/gke-spot
     operator: Equal
     value: "true"
     effect: NoSchedule

Vous pouvez vous assurer que GKE ne programme que vos pods sur des Spot VM en utilisant à la fois une tolérance et une règle d'affinité nodeSelector ou de nœud pour filtrer. pour les Spot VM.

Si vous programmez une charge de travail en utilisant seulement une tolérance, GKE peut planifier les pods sur des VM Spot ou sur des VM standards existantes disposant d'une capacité suffisante. Si vous devez programmer une charge de travail sur des VM Spot, utilisez une affinité de nœud (nodeSelector) en plus d'une tolérance. Pour en savoir plus, consultez la section Planifier des charges de travail sur des VM spot.

Spot VM et autoscaler de clusters

L'autoscaler de cluster ajoute et supprime automatiquement les nœuds de vos pools de nœuds en fonction de la demande. Vous pouvez configurer l'autoscaler de cluster pour qu'il ajoute de nouveaux nœuds en privilégiant les Spot VM. Pour en savoir plus, consultez Spot VM et autoscaler de clusters.

Règle par défaut

À partir de la version 1.24.1-gke.800 de GKE, vous pouvez définir la stratégie de localisation de l'autoscaler. L'autoscaler de cluster tente de provisionner les pools de nœuds des VM Spot lorsque des ressources sont disponibles et que la stratégie de localisation par défaut est définie sur ANY. Avec cette règle, les VM Spot présentent un risque plus faible de préemption. Pour les autres types de VM, la règle de distribution de l'autoscaler de cluster par défaut est BALANCED.

Mettre à niveau des pools de nœuds Standard à l'aide de VM Spot

Si vos pools de nœuds de cluster Standard utilisant des VM Spot sont configurés pour utiliser les mises à niveau de la surutilisation, GKE crée des nœuds de surutilisation avec des VM Spot. Cependant, GKE n'attend pas que les VM Spot soient prêtes avant de délimiter le périmètre et de drainer les nœuds existants, car les VM Spot n'offrent aucune garantie de disponibilité. Pour en savoir plus, consultez la page Mises à niveau de la surutilisation.

Modifications du comportement de Kubernetes

L'utilisation de VM Spot sur GKE modifie certaines garanties et contraintes fournies par Kubernetes, telles que les suivantes :

  • La récupération des VM Spot est involontaire et n'est pas couverte par les garanties de PodDisruptionBudgets. Vous risquez de rencontrer une indisponibilité supérieure à la valeur PodDisruptionBudget configurée.

Bonnes pratiques pour les VM Spot

Lorsque vous concevez un système utilisant des VM Spot, vous pouvez éviter les interruptions majeures en appliquant les consignes suivantes :

  • Les Spot VM n'offrent aucune garantie de disponibilité. Concevez vos systèmes en partant du principe que GKE pourrait récupérer tout ou partie de vos Spot VM à tout moment, sans aucune garantie quant au moment où de nouvelles instances deviendront disponibles.
  • Pour garantir que vos charges de travail et tâches sont traitées même lorsqu'aucune VM Spot n'est disponible, assurez-vous que vos clusters comportent un mélange de pools de nœuds utilisant des VM Spot et de pools de nœuds utilisant des VM Compute Engine standards.
  • Assurez-vous que votre cluster comporte au moins un pool de nœuds non GPU utilisant des VM standards avant d'ajouter un pool de nœuds GPU utilisant des VM Spot.
  • Bien que les noms des nœuds ne changent généralement pas lors de la recréation des nœuds, les adresses IP internes et externes utilisées par les Spot VM peuvent changer après la recréation.
  • Utilisez des tolérances et des rejets de nœuds pour vous assurer que les pods critiques ne sont pas programmés sur des pools de nœuds qui utilisent des Spot VM.
  • Pour exécuter des charges de travail avec état sur des VM Spot, effectuez des tests pour vous assurer que les charges de travail peuvent s'arrêter normalement dans les 25 secondes suivant l'arrêt afin de minimiser le risque de corruption des données du volume persistant.
  • Suivez les bonnes pratiques d'arrêt des pods Kubernetes.

Étape suivante