Prolonger la durée d'exécution des pods Autopilot

Cette page explique comment demander des durées d'exécution étendues pour les pods avant qu'ils ne soient évincés par Google Kubernetes Engine (GKE).

À propos de l'éviction de pods lancée par GKE

Les évictions de pods font partie intégrante de l'exécution des charges de travail sur Kubernetes. GKE supprime les charges de travail lors des événements planifiés, tels que les mises à jour automatiques des nœuds et le scaling à la baisse de l'autoscaling, pour garantir que vos nœuds sont à jour et optimisés pour une utilisation efficace des ressources. Par défaut, GKE envoie un signal d'arrêt au conteneur dès que l'événement se produit, après quoi le délai de grâce du conteneur s'arrête avant que Kubernetes évince le pod. Pour les mises à niveau automatiques des nœuds, le délai de grâce peut aller jusqu'à une heure. Pour les événements de scaling à la baisse, le délai de grâce peut aller jusqu'à 10 minutes.

Kubernetes dispose de fonctionnalités intégrées que les conteneurs peuvent utiliser pour gérer correctement les évictions, telles que les PodDisruptionBudgets et les délais de grâce. Toutefois, certaines charges de travail, telles que les files d'attente par lot ou les serveurs de jeu multijoueurs, doivent être exécutées plus longtemps avant d'être supprimées. Le délai de grâce par défaut accordé par GKE lors des évictions lancées par GKE peut ne pas être suffisant pour ces charges de travail. Dans ces situations, vous pouvez indiquer à Autopilot d'éviter d'expulser des charges de travail spécifiques pendant sept jours maximum.

Cas d'utilisation

Dans certaines situations, vous pouvez indiquer à GKE d'éviter d'évincer les charges de travail comme suit :

  • Vous exécutez des serveurs de jeu multijoueurs qui suppriment les joueurs de leurs sessions si ceux-ci s'arrêtent plus tôt.
  • Vous exécutez un logiciel audio ou de visioconférence qui peut perturber les réunions en cours si les serveurs s'arrêtent.
  • Vous exécutez des tâches qui nécessitent du temps et l'arrêt anticipé entraîne une perte de travail en cours.
  • Vous exécutez un service avec état moins tolérant aux perturbations et vous souhaitez minimiser la fréquence des interruptions.

Tarifs

Vous pouvez demander des durées d'exécution prolongées pour vos pods sans frais supplémentaires. Toutefois, tenez compte des changements de comportement suivants qui pourraient avoir une incidence sur vos tarifs :

  • Les clusters Autopilot appliquent des valeurs minimales plus élevées pour les demandes de ressources de pods de durée étendue. Les clusters Autopilot vous facturent les demandes de ressources de vos pods en cours d'exécution. La surcharge du système et la capacité des nœuds inutilisés ne vous sont pas facturées.
  • L'utilisation de pods de durée étendue peut augmenter le nombre de nœuds dans votre cluster, ce qui peut affecter l'utilisation des adresses IP et l'évolutivité. Si vous avez des DaemonSets qui s'exécutent sur chaque nœud, le nombre de DaemonSets dans le cluster sera plus élevé.

Pour en savoir plus sur les tarifs, consultez la page Tarifs du mode Autopilot.

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.
  • Assurez-vous de disposer d'un cluster Autopilot exécutant la version 1.27 ou ultérieure.

Limites

  • Vous ne pouvez pas demander de durées d'exécution étendues pour vos pods Spot.
  • Les temps d'extraction d'images sont comptabilisés lors du calcul de la durée d'exécution étendue.
  • Vous pouvez avoir au maximum 50 charges de travail de durée étendue (avec différentes requêtes de processeur) dans chaque cluster. Cela signifie que jusqu'à 50 ensembles de valeurs de requête de processeur différents, après avoir passé les contrôles minimum, ratios et contrôles de taille des ressources Autopilot, peuvent avoir une durée étendue dans chaque cluster.
  • Vous ne pouvez pas utiliser l'affinité inter-pod Kubernetes dans des pods de durée prolongée.
  • Dans la mesure du possible, GKE place chaque pod de durée d'exécution étendue sur son propre nœud. Ce comportement garantit que les nœuds peuvent effectuer un scaling à la baisse s'ils sont sous-utilisés.

Demander une durée d'exécution étendue

Pour demander une durée d'exécution étendue pour un pod, définissez l'annotation cluster-autoscaler.kubernetes.io/safe-to-evict de Kubernetes sur false dans la spécification du pod.

  1. Enregistrez le manifeste suivant sous le nom extended-deployment.yaml :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: extended-pods
  labels:
    duration: extended
spec:
  selector:
    matchLabels:
      duration: extended
  template:
    metadata:
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
      labels:
        duration: extended
    spec:
      containers:
      - name: example-container
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 200m

  2. Créez le déploiement :

    kubectl create -f extended-deployment.yaml

Les pods continuent de s'exécuter pendant au moins sept jours avant qu'un scaling à la baisse ou une mise à niveau automatique des nœuds ne puisse se produire.

Remarques et recommandations

Lorsque vous utilisez cette fonctionnalité, tenez compte des points suivants :

  • Les pods de durée prolongée ne sont pas protégés contre l'éviction basée sur la priorité. Si vous utilisez des classes PriorityClass Kubernetes, envisagez les méthodes suivantes pour minimiser la probabilité d'éviction basée sur la priorité :
    • Assurez-vous que vos pods de durée prolongée utilisent la priorité la plus élevée, afin que les autres pods d'utilisateur n'évincent pas vos pods de durée prolongée.
    • Utilisez la séparation de la charge de travail pour exécuter des pods de durée prolongée séparément des autres pods.
  • Les pods système s'exécutent avec la priorité la plus élevée et peuvent toujours évincer les pods avec une durée prolongée. Pour minimiser cette probabilité, GKE planifie les pods système sur le nœud avant de planifier le pod de durée étendue.
  • Les pods de durée prolongée peuvent toujours être évincés plus tôt dans les cas suivants :
    • Éviction pour libérer de l'espace pour les pods d'utilisateur prioritaires (avec une classe PriorityClass plus élevée)
    • Éviction pour libérer de l'espace pour les composants système Kubernetes
    • Éviction de mémoire insuffisante kubelet si le pod utilise plus de mémoire que ce qui a été demandé (OOMKill)
    • Événements de maintenance de VM Compute Engine. Les types de machines optimisés pour les accélérateurs sont plus susceptibles d'être affectés par ces événements, car ces machines ne sont pas compatibles avec la migration à chaud.
    • Réparation automatique des nœuds
    • Événements déclenchés par l'utilisateur, tels que le drainage d'un nœud
  • Vous pouvez utiliser l'annotation cluster-autoscaler.kubernetes.io/safe-to-evict dans des clusters standards, mais le résultat n'est pas le même. Les pods s'exécutent indéfiniment, même si un événement de scaling à la baisse se produit, empêchant la suppression des nœuds sous-utilisés et entraînant une facturation de ces nœuds. Les pods ne sont pas non plus protégés contre les évictions causées par les mises à niveau automatiques des nœuds.

Étapes suivantes