Exécuter des charges de travail tolérantes aux pannes à moindre coût avec des pods Spot

Cette page explique comment exécuter des charges de travail tolérantes aux pannes à moindre coût avec des pods Spot dans des clusters Google Kubernetes Engine (GKE) Autopilot.

Aperçu

Dans les clusters GKE Autopilot, les pods Spot sont des pods qui s'exécutent sur des nœuds sauvegardés par des VM Spot Compute Engine. Les pods Spot sont facturés moins chers que les pods Autopilot standards, mais peuvent être supprimés par GKE chaque fois que des ressources de calcul sont nécessaires pour exécuter des pods standards.

Les pods Spot sont parfaits pour exécuter des charges de travail sans état, par lots ou tolérantes aux pannes, à des coûts inférieurs à ceux des charges de travail standards. Pour utiliser des pods Spot dans des clusters Autopilot, modifiez le fichier manifeste avec la spécification de pod pour demander des pods Spot.

Vous pouvez exécuter des pods Spot sur la classe de calcul Autopilot à usage général par défaut, ainsi que sur des classes de calcul spécialisées qui répondent à des exigences matérielles spécifiques. Pour en savoir plus sur ces classes de calcul, consultez la page Classes de calcul dans Autopilot.

Pour en savoir plus sur la tarification des pods Spot dans les clusters Autopilot, consultez la page Tarifs de Google Kubernetes Engine.

Avantages

L'utilisation de pods Spot dans vos clusters Autopilot offre les avantages suivants :

  • Tarifs plus bas que l'exécution des mêmes charges de travail sur les pods Autopilot standards.
  • GKE gère automatiquement l'autoscaling et la planification.
  • GKE rejette automatiquement les nœuds qui exécutent des pods Spot afin de s'assurer que les pods standards, tels que vos charges de travail critiques, ne sont pas programmés sur ces nœuds. Les déploiements qui utilisent les pods Spot sont automatiquement mis à jour avec la tolérance correspondante.

Conditions requises et limites

  • Nécessite la version 1.21.4 de GKE ou une version ultérieure.
  • Les pods Spot sont exclus du contrat de niveau de service Autopilot.
  • GKE ne peut pas programmer de pods Spot sur des clusters exécutant des versions de GKE antérieures à 1.21.4.

  • Les clusters Autopilot acceptent les requêtes pour les pods préemptifs dans les clusters exécutant la version 1.21.4 de GKE ou une version ultérieure, à l'aide du sélecteur cloud.google.com/gke-preemptible. Les pods qui utilisent ce sélecteur sont automatiquement migrés vers les pods Spot, et le sélecteur passe à cloud.google.com/gke-spot.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Demander des pods Spot dans vos charges de travail Autopilot

Pour demander que vos pods s'exécutent en tant que pods Spot, utilisez le libellé cloud.google.com/gke-spot=true dans un nodeSelector ou une affinité de nœud dans la spécification des pods. GKE provisionne automatiquement les nœuds pouvant exécuter des pods Spot.

Les pods Spot peuvent être évincés et arrêtés à tout moment, par exemple si des ressources de calcul sont nécessaires ailleurs dans Google Cloud. En cas d'arrêt, les pods Spot du nœud d'arrêt peuvent demander un délai de grâce d'une durée maximale de 25 secondes avant l'arrêt, ce qui est accordé de la manière la plus optimale possible, en spécifiant le champ terminationGracePeriodSeconds.

Le délai de grâce maximal accordé aux pods Spot lors de la préemption est de 25 secondes. Le fait de demander plus de 25 secondes dans l'opération terminationGracePeriodSeconds n'accorde pas plus de 25 secondes lors de la préemption. En cas d'éviction, votre pod reçoit le signal SIGTERM et doit prendre les mesures nécessaires pour s'arrêter pendant le délai de grâce.

Pour Autopilot, GKE rejette également automatiquement les nœuds créés pour exécuter les pods Spot et modifie ces charges de travail avec la tolérance correspondante. Le rejet empêche la planification des pods standards sur les nœuds qui exécutent des pods Spot.

Utiliser un nodeSelector pour exiger des pods Spot

Vous pouvez utiliser un nodeSelector pour exiger des pods Spot dans un déploiement. Ajoutez le libellé cloud.google.com/gke-spot=true à votre déploiement, comme dans l'exemple suivant :

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      labels:
        app: pi
    spec:
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      terminationGracePeriodSeconds: 25
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Utiliser l'affinité de nœuds pour demander des pods Spot

Vous pouvez également utiliser l'affinité de nœuds pour demander des pods Spot. L'affinité de nœuds vous permet de sélectionner plus facilement des nœuds pour exécuter vos charges de travail. Par exemple, vous pouvez combiner plusieurs critères de sélection afin de contrôler plus précisément l'emplacement d'exécution de vos pods. Lorsque vous utilisez l'affinité de nœuds pour demander des pods Spot, vous pouvez spécifier le type d'affinité de nœuds à utiliser comme suit :

  • requiredDuringSchedulingIgnoredDuringExecution : doit utiliser des pods Spot.
  • preferredDuringSchedulingIgnoredDuringExecution : utiliser les pods Spot de la manière la plus optimale possible.

Pour utiliser l'affinité de nœuds pour exiger des pods Spot dans un déploiement, ajoutez la règle nodeAffinity suivante à votre fichier manifeste de déploiement :

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      labels:
        app: pi
    spec:
      terminationGracePeriodSeconds: 25
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-spot
                operator: In
                values:
                - "true"
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Demander des pods Spot de la manière la plus optimale possible

Pour utiliser l'affinité de nœuds afin de demander les pods Spot de la manière la plus optimale possible, utilisez preferredDuringSchedulingIgnoredDuringExecution. Lorsque vous demandez des pods Spot de manière préférée, GKE planifie vos pods en fonction de l'ordre suivant :

  1. Nœuds existants pouvant exécuter des pods Spot qui disposent d'une capacité pouvant être allouée
  2. Nœuds standards existants qui disposent d'une capacité pouvant être allouée
  3. Nouveaux nœuds pouvant exécuter des pods Spot, si les ressources de calcul sont disponibles
  4. Nouveaux nœuds standards

GKE choisit de préférence les nœuds standards existants disposant d'une capacité pouvant être allouée plutôt que la création de nœuds pour des pods Spot. Par conséquent, il se peut que vous ayez plus de pods qui s'exécutent en tant que pods standards qu'en tant que pods Spot, ce qui vous empêche de tirer pleinement parti des coûts réduits des pods Spot.

Rechercher et supprimer des pods arrêtés

Lors de l'arrêt optimal des pods, le kubelet attribue un état Failed et un motif Shutdown aux pods arrêtés. Lorsque le nombre de pods arrêtés atteint un seuil de 1 000, la récupération de mémoire nettoie les pods. Vous pouvez également supprimer manuellement des pods d'arrêt à l'aide de la commande suivante :

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

Étape suivante