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 optimiser votre rentabilité, associez les Spot VM aux bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE.

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 Spot VM, un avis de résiliation est envoyé à GKE. Les VM Spot s'arrêtent 30 secondes après la réception d'une notification d'arrêt.

Sur les clusters exécutant GKE version 1.20 ou ultérieure, la fonctionnalité d'arrêt de nœuds kubelet est activée par défaut. Le kubelet détecte la notification d'arrêt et met fin aux pods en cours d'exécution sur le nœud de façon progressive. Si les pods font partie d'un déploiement, le contrôleur crée et planifie de nouveaux pods pour remplacer les pods arrêtés.

Dans la mesure du possible, le kubelet accorde le délai de grâce suivant en fonction de la version de GKE du pool de nœuds :

  • Versions ultérieures à 1.22.8-gke.200 : 15 secondes pour les pods non système, après quoi les pods système (avec les classes de priorité system-cluster-critical ou system-node-critical) disposent de 15 secondes pour s'arrêter normalement.
  • 1.22.8-gke.200 et versions antérieures : 25 secondes pour les pods non système, après quoi les pods système (avec les classes de priorité system-cluster-critical ou system-node-critical) disposent de cinq secondes pour s'arrêter normalement.

Lors de l'arrêt progressif d'un nœud, le kubelet met à jour l'état des pods, en attribuant la phase Failed et un motif Terminated aux pods arrêtés.

Lorsque le nombre de pods arrêtés atteint un seuil de 1 000 pour les clusters de moins de 100 nœuds ou de 5 000 pour les clusters de 100 nœuds ou plus, la récupération de mémoire nettoie les pods.

Vous pouvez également supprimer manuellement des pods arrêtés à l'aide des commandes suivantes :

  kubectl get pods --all-namespaces | grep -i NodeShutdown | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n
  kubectl get pods --all-namespaces | grep -i Terminated | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n

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 Spot VM. Lorsque vous rejetez des nœuds qui utilisent des Spot VM, 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. Si votre cluster comporte des pods qui ne peuvent pas être placés sur des Spot VM existantes, l'autoscaler de cluster ajoute des nouveaux nœuds qui utilisent des Spot VM.

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 Spot VM 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