Stratégies pour réduire la latence au démarrage

Google Kubernetes Engine (GKE) propose plusieurs stratégies qui vous aident à réduire la latence de démarrage des pods lorsque vos charges de travail évoluent à la hausse. En réduisant les retards dans le provisionnement des nœuds, l'extraction des images de conteneurs et l'initialisation des applications, vous pouvez améliorer la réactivité des services lors des pics de trafic et équilibrer les coûts d'infrastructure.

Utilisez ce document pour comparer les stratégies de réduction de la latence de démarrage de GKE tout au long du cycle de vie de démarrage des pods et choisissez une stratégie unique ou une combinaison en couches qui correspond aux exigences de votre charge de travail.

Comprendre le cycle de vie de démarrage des pods

Lorsqu'une charge de travail évolue à la hausse dans GKE et que les nœuds existants ne disposent pas de suffisamment de capacité allouable pour les nouveaux pods, la latence de démarrage de bout en bout s'étend sur trois étapes séquentielles :

  • Lors de l'étape de provisionnement des nœuds et de planification des pods, l'autoscaler de cluster provisionne une nouvelle VM Compute Engine, initialise le nœud et l'enregistre auprès du plan de contrôle afin que le planificateur Kubernetes puisse placer le pod en attente.
  • Lors de l'étape d'extraction des images de conteneurs, le composant kubelet du nœud télécharge et décompresse les images de conteneurs requises par le pod à partir de votre Container Registry.
  • Lors de l'étape d'initialisation de l'application, l'environnement d'exécution du conteneur démarre le processus de l'application, charge les dépendances ou les pondérations du modèle en mémoire, et transmet les vérifications de démarrage et d'aptitude Kubernetes.

Différentes fonctionnalités de GKE ciblent des étapes spécifiques de ce cycle de vie. Pour savoir quelle étape contribue le plus au temps de démarrage de votre charge de travail, consultez la section Surveiller les métriques de latence de démarrage.

Comparer les stratégies de réduction de la latence de démarrage

Le tableau suivant compare les stratégies de réduction de la latence de démarrage de GKE tout au long du cycle de vie de démarrage des pods :

Stratégie Étape du cycle de vie Profil de la latence Profil de coût et de quota Mode de cluster et compatibilité matérielle Application idéale
Tampons de capacité active (bêta) Provisionnement des nœuds et planification des pods Planification immédiate des pods, car les nœuds sont déjà en cours d'exécution.

Tarifs de calcul standards basés sur les nœuds pour les VM en cours d'exécution.

Utilise les quotas de processeurs virtuels, de mémoire, de disque et d'adresses IP Compute Engine quotas, ainsi que les quotas de ressources Kubernetes dans l'espace de noms.

Clusters standards et clusters Autopilot avec des ComputeClasses personnalisées (facturation basée sur les nœuds).

Compatible avec les processeurs, les GPU et les TPU.

 Absorption des pics de trafic soudains et scaling des charges de travail GPU, TPU ou CPU sensibles à la latence.
Tampons de capacité de secours (bêta) Provisionnement des nœuds et planification des pods Reprise des nœuds suspendus en 30 à 35 secondes environ, ce qui est plus rapide que le provisionnement d'un nouveau nœud.

Aucun frais de calcul de VM pendant la suspension. Entraîne des frais de stockage sur disque persistant pour les disques de démarrage et l'état de la mémoire stockée.

Utilise les quotas de disque et d'adresses IP pendant la suspension, ainsi que les quotas de ressources Kubernetes dans l'espace de noms.

Clusters standards (avec provisionnement automatique des nœuds) et clusters Autopilot avec des ComputeClasses personnalisées.

Compatible uniquement avec les processeurs (pas de GPU, de TPU ni de disques SSD locaux).

 Maintien d'une capacité de bursting rentable pour une croissance soutenue du trafic growth.
Nœuds à démarrage rapide Provisionnement des nœuds et planification des pods Réduit le temps de démarrage des nœuds à froid au mieux de ses capacités en utilisant du matériel pré-initialisé. Fourni sans frais supplémentaires.

Clusters Autopilot et charges de travail Autopilot dans les clusters standards.

Compatible avec les séries de machines à usage général et GPU éligibles sans disques SSD locaux ni VM Spot.

 Accélération du provisionnement des nœuds de référence sans configuration ni coût de capacité inutilisée.
Pods d'espace réservé de faible priorité Provisionnement des nœuds et planification des pods Planification immédiate des pods après l'éviction des pods d'espace réservé de priorité inférieure.

Tarifs de calcul standards pour les nœuds en cours d'exécution.

Nécessite une gestion manuelle des déploiements et des PriorityClasses.

 Clusters standards et Autopilot. Réservation de capacité de secours sur les clusters qui utilisent la facturation basée sur les pods ou versions antérieures à la version 1.35.
Streaming d'images Extraction d'images de conteneurs Permet aux conteneurs de démarrer sans attendre le téléchargement complet de l'image.

Fourni sans frais supplémentaires.

Nécessite Artifact Registry ou des dépôts Docker Hub éligibles.

 Clusters Autopilot (activé par défaut) et standards. Réduction des temps d'extraction d'images pour les images de conteneurs volumineuses.
Disques de démarrage secondaires Extraction d'images de conteneurs Associe un disque persistant prérempli aux nouveaux nœuds en parallèle avec le provisionnement des nœuds. Facturation du disque persistant associé sur chaque nœud et du stockage des images disque. Clusters standards et Autopilot. Préchargement d'images de conteneurs volumineuses ou d'ensembles de données statiques tels que les pondérations de modèles de machine learning.
Instantanés de pods Initialisation de l'application Restaure les nouvelles instances dupliquées de pods directement à partir d'un point de contrôle enregistré de la mémoire de processus et de l'état du système de fichiers. Facturation du stockage des instantanés dans Cloud Storage.

Clusters standards et Autopilot exécutant des pods dans GKE Sandbox.

Compatible avec les types de machines CPU et GPU éligibles (pas de TPU).

 Contournement de l'initialisation longue pour les modèles d'inférence d'IA et applications avec des routines de démarrage lourdes.
Optimisation du processeur au démarrage (bêta) Initialisation de l'application Augmente temporairement les demandes et les limites de processeur lors du démarrage des pods, et puis les redimensionne sur place. Utilise temporairement une capacité de processeur de nœud supplémentaire pendant la fenêtre de démarrage. Clusters standards et Autopilot avec autoscaling vertical des pods activé. Accélération de l'initialisation liée au processeur pour les environnements d'exécution tels que Java, Python ou Node.js.

Choisir une stratégie par étape de démarrage des pods

Les sections suivantes décrivent les options disponibles pour chaque étape du cycle de vie de démarrage des pods.

Accélérer le provisionnement des nœuds et la planification des pods

Lorsque les pods en attente ne peuvent pas être placés sur les nœuds existants, l'attente du démarrage d'un nouveau nœud est souvent le principal facteur de latence de scaling à la hausse. Vous pouvez réduire ou éliminer ce délai en utilisant les stratégies suivantes :

  • Utilisez des tampons de capacité pour réserver de manière déclarative une capacité de nœud de secours :
    • Configurez un tampon actif (stratégie buffer.x-k8s.io/active-capacity) pour que les nœuds préprovisionnés restent en cours d'exécution et prêts à planifier immédiatement les pods. Les tampons actifs sont compatibles avec les charges de travail CPU, GPU et TPU.
    • Configurez un tampon de secours (stratégie buffer.gke.io/standby-capacity) pour que les nœuds de processeur préprovisionnés restent en état de suspension. Lorsque les charges de travail évoluent à la hausse, GKE reprend les nœuds de secours en 30 à 35 secondes environ, ce qui évite le coût de calcul complet de l'exécution des VM inactives.
  • Utilisez des nœuds à démarrage rapide pour la pré-initialisation matérielle automatique et au mieux de ses capacités sur les charges de travail Autopilot et les séries de machines GPU éligibles. Lorsque GKE provisionne de nouveaux nœuds pour une charge de travail éligible, il utilise automatiquement des nœuds à démarrage rapide. Cela inclut les nœuds créés pour remplir un tampon de capacité sur une ComputeClass personnalisée Autopilot compatible.
  • Déployez des pods d'espace réservé de faible priorité avec des PriorityClasses Kubernetes si vos charges de travail utilisent le modèle de facturation basé sur les pods Autopilot ou s'exécutent sur des versions de GKE antérieures à la version 1.35. Pour les clusters qui utilisent la facturation basée sur les nœuds sur les versions de GKE compatibles, préférez les tampons de capacité déclaratifs, car ils ne nécessitent pas de gérer les déploiements d'espace réservé ni les boucles d'éviction des pods.

Accélérer l'extraction d'images de conteneurs

Une fois que le planificateur a placé un pod sur un nœud, le nœud doit extraire l'image de conteneur avant de démarrer le conteneur. Vous pouvez réduire la latence d'extraction des images en utilisant les stratégies suivantes :

  • Activez le streaming d'images pour permettre aux conteneurs de démarrer dès que les fichiers requis sont diffusés sur le réseau, tandis que le reste de l'image est téléchargé en arrière-plan. Les clusters Autopilot activent le streaming d'images par défaut pour les images éligibles dans Artifact Registry.
  • Configurez des disques de démarrage secondaires pour précharger de grandes couches de base de conteneurs ou des ensembles de données statiques sur une image de disque personnalisée. Lorsque GKE crée un nœud, il associe un Persistent Disk instancié à partir de votre image disque en parallèle du provisionnement des nœuds.
  • Exécutez un DaemonSet pour précharger les images de conteneurs sur les tampons de secours pendant la fenêtre d'initialisation des nœuds (buffer.gke.io/standby-capacity-init-time annotation). Avant que GKE ne suspende un nœud de secours, le DaemonSet extrait les images de votre charge de travail sur le disque de démarrage du nœud afin que les images soient déjà mises en cache lorsque le nœud reprend.

Accélérer l'initialisation des applications

Même après l'exécution d'un nœud et la présence de l'image de conteneur, le chargement des frameworks, la compilation du code juste-à-temps (JIT) ou le chargement des pondérations du modèle en mémoire peuvent prendre beaucoup de temps. Vous pouvez réduire le temps d'initialisation en utilisant les stratégies suivantes :

  • Configurez des instantanés de pods pour capturer un point de contrôle de la mémoire et de l'état du système de fichiers d'un pod en cours d'exécution dans GKE Sandbox. Lorsque votre charge de travail évolue horizontalement, GKE restaure les nouvelles instances dupliquées à partir de l'instantané dans Cloud Storage afin que le pod reprenne l'exécution à partir du point où l'instantané a été pris au lieu de s'initialiser à partir d'un état vierge.
  • Configurez l'optimisation du processeur au démarrage sur un VerticalPodAutoscaler pour allouer un processeur supplémentaire à un pod lors de l'admission et de l'initialisation. Une fois que le pod atteint l'état Ready et que la durée d'optimisation configurée est terminée, GKE réduit la demande de processeur du pod à son niveau de référence sur place sans redémarrer le conteneur.

Combiner des stratégies pour une optimisation de bout en bout

Étant donné que ces stratégies fonctionnent à différentes étapes du cycle de vie de démarrage des pods, vous pouvez les superposer pour optimiser le temps de scaling à la hausse de bout en bout :

  • Combinez un petit tampon de capacité active avec un tampon de capacité de secours plus important. Lors d'un pic de trafic soudain, le tampon actif absorbe immédiatement le pic initial de pods. Pendant ce temps, GKE reprend les nœuds du tampon de secours en 30 à 35 secondes environ pour remplir le tampon actif et gérer la croissance soutenue. En arrière-plan, l'autoscaler de cluster provisionne et suspend de nouveaux nœuds pour remplir le tampon de secours.
  • Pour les tampons de capacité de secours, activez le streaming d'images ou préchargez les images de conteneurs à l'aide d'un DaemonSet avant la suspension du nœud afin que le nœud ne passe pas de temps à télécharger des images de conteneurs volumineuses lors de sa reprise.
  • Superposez l'optimisation du processeur au démarrage ou les instantanés de pods sur les tampons de capacité ou les nœuds à démarrage rapide afin qu'une fois que GKE a planifié un pod sur un nœud préprovisionné ou pré-initialisé, le pod évite la limitation du processeur au démarrage ou restaure directement à partir d'un instantané enregistré.

Pour mesurer l'effet d'une stratégie unique ou combinée sur vos charges de travail, consultez les graphiques Distribution de la latence de démarrage des pods et Latence de la première aptitude des pods dans Cloud Monitoring, et inspectez les journaux de latence de planification dans Cloud Logging. Pour obtenir des instructions, consultez la section Surveiller les métriques de latence de démarrage.

Étape suivante