Les tampons de capacité vous aident à réduire la latence de démarrage des pods pour vos charges de travail Google Kubernetes Engine (GKE) en vous permettant de déclarer de manière proactive des niveaux de tampons de capacité actifs ou en veille dans votre cluster. En déclarant une capacité de réserve à l'avance, vous pouvez accélérer le démarrage des charges de travail de manière rentable.
Ce document explique le fonctionnement des tampons de capacité. Pour savoir comment activer et utiliser les tampons de capacité, consultez Configurer des tampons de capacité.
Quand utiliser des tampons de capacité ?
Utilisez des tampons de capacité pour les applications sensibles à la latence de démarrage et qui doivent évoluer rapidement. En cas d'augmentation soudaine du trafic, un tampon actif fournit une capacité préprovisionnée conçue pour un scaling à faible latence. En cas d'augmentation soutenue du trafic, un tampon en veille permet de planifier les pods à un coût plus abordable que le préprovisionnement.
Les tampons de capacité offrent les avantages suivants :
- Réduire la latence de scaling : les tampons actifs fournissent des nœuds en cours d'exécution, ce qui permet de réduire la latence. Les tampons en veille reprennent rapidement, ce qui permet de disposer d'une capacité plus rapidement que les nouveaux nœuds à un coût inférieur à celui des tampons actifs.
- Surprovisionnement rentable : les tampons de capacité vous aident à maintenir un filet de sécurité. Pour les charges de travail à grande échelle, cette approche est souvent plus rentable que d'autres méthodes de surprovisionnement (par exemple, en abaissant les cibles d'utilisation de l'autoscaler horizontal des pods), ce qui peut augmenter la capacité inactive de manière linéaire à mesure que votre cluster se développe.
- Répondre aux exigences des charges de travail : vous contrôlez entièrement la configuration de votre tampon de capacité. Vous pouvez, entre autres, intégrer des daemonsets personnalisés pour précharger des images, régler le temps de démarrage et contrôler la taille des tampons en fonction de vos besoins.
Nous recommandons les tampons de capacité pour les charges de travail sensibles à la latence qui nécessitent un scaling rapide, telles que les agents d'IA, l'inférence d'IA, les applications de vente au détail lors d'événements commerciaux ou les serveurs de jeux lors des pics d'activité des joueurs.
Fonctionnement des tampons de capacité
Implémentez un tampon de capacité à l'aide d'une ressource personnalisée Kubernetes CapacityBuffer pour définir un tampon de capacité de réserve. L'autoscaler de cluster GKE surveille les ressources CapacityBuffer et les traite comme une demande en attente pour s'assurer qu'une capacité de réserve est disponible. Si votre cluster ne dispose pas d'une capacité suffisante pour répondre aux demandes de ressources définies dans le tampon, l'autoscaler de cluster provisionne des nœuds supplémentaires.
Lorsqu'une charge de travail de haute priorité augmente, GKE la planifie immédiatement sur la capacité disponible dans le tampon. Cette planification immédiate s'applique au nombre de répliques ou à la quantité de ressources réservée dans le tampon, ce qui évite le délai habituel associé au provisionnement des nœuds. Lorsqu'une charge de travail utilise une unité de tampon, l'autoscaler de cluster provisionne un nouveau nœud pour remplir le tampon.
Stratégies de tampon de capacité
Vous pouvez configurer des tampons de capacité à l'aide de différentes stratégies de provisionnement en fonction de vos exigences en termes de latence et de coût.
Tampon actif
Un tampon actif fournit des nœuds en cours d'exécution pour un scaling à faible latence des charges de travail qui s'intègrent dans la capacité réservée. Comme les nœuds sont déjà en cours d'exécution, ils offrent une latence minimale pour la revendication des pods lors d'un événement de scaling.
Tampon en veille
Un tampon en veille fournit des nœuds suspendus. La stratégie en veille est plus rentable que la stratégie active, mais elle introduit un court délai pour la reprise du nœud avant qu'il n'accepte les charges de travail.
Coût et tarification
La facturation des tampons de capacité varie en fonction du type de tampon :
- Tampons actifs : vous êtes facturé aux tarifs de calcul GKE standards pour les VM en cours d'exécution que GKE gère pour servir de capacité de tampon actif. Sur Autopilot, les tarifs de facturation standards basés sur les pods s'appliquent aux pods en cours d'exécution.
- Tampons en veille : lorsque les instances de VM sont suspendues, vous ne payez pas de frais de calcul (processeur ou mémoire). Vous encourez des frais de stockage mineurs (par exemple, pour les disques de démarrage de VM) et des coûts pour les ressources associées, telles que les adresses IP externes statiques. Lorsque GKE reprend les VM en veille pour héberger des charges de travail, les tarifs de facturation standards basés sur le calcul ou les pods s'appliquent.
CapacityBuffer CRD
Pour configurer un tampon de capacité, vous devez créer une définition de ressource personnalisée (CRD) CapacityBuffer. Vous pouvez configurer le tampon de capacité pour répondre à différents critères :
- Répliques fixes : spécifiez un nombre fixe de pods de tampon à créer en fonction de s demandes de ressources d'un modèle de pod référencé. Cette configuration est le moyen le plus simple de créer un tampon de taille connue.
- Limites de ressources : spécifiez la quantité totale de processeur et de mémoire que le tampon doit réserver. Le contrôleur calcule le nombre de pods de tampon à créer en fonction des demandes de ressources d'un modèle de pod référencé.
- Basé sur un pourcentage : définissez la taille de la mémoire tampon en pourcentage d'un objet évolutif existant qui définit une sous-ressource de scaling (telle qu'un déploiement, un StatefulSet, un ReplicaSet ou une tâche). La taille de la mémoire tampon s'ajuste dynamiquement à mesure que la charge de travail de référence évolue. Les tampons de capacité basés sur un pourcentage ne sont compatibles qu'avec les objets qui implémentent la sous-ressource de scaling Kubernetes.
Pour en savoir plus, consultez la documentation de référence CapacityBuffer CRD.
Bonnes pratiques
Pour optimiser le rapport coût/efficacité et la réactivité lors de la configuration des tampons de capacité, suivez les recommandations ci-dessous :
- Utilisez une stratégie de veille d'abord, optimale en termes de coûts : privilégiez les tampons en veille si vos charges de travail peuvent tolérer un bref délai de scaling d'environ 30 secondes. Cette stratégie évite les démarrages à froid de nœuds de VM récents sans avoir à supporter le coût total des VM actives.
- Utilisez des tampons actifs pour les charges de travail sensibles à la latence : utilisez des tampons actifs pour les charges de travail qui ne peuvent pas tolérer les temps de reprise des nœuds lorsque le temps de planification des pods doit être aussi faible que possible.
- Utilisez une stratégie hybride pour équilibrer les performances et les coûts : combinez un petit tampon actif avec un tampon en veille plus grand pour une configuration rentable. GKE donne la priorité au remplissage du tampon actif en reprenant les nœuds du tampon en veille (environ 30 secondes), tandis que de nouveaux nœuds sont provisionnés en arrière-plan pour remplir le tampon en veille. Cette configuration absorbe les pics initiaux avec une capacité active et s'adapte à une croissance soutenue grâce à la capacité en veille à moindre coût.
- Dimensionnez les tampons actifs pour les pics initiaux : définissez la taille de votre tampon actif pour couvrir les pics initiaux soudains de répliques que vous prévoyez de rencontrer, avant que les nœuds du tampon en veille ne puissent reprendre.
- Dimensionnez les tampons en veille pour une charge soutenue : définissez des tampons en veille qui sont suffisants pour couvrir la charge étendue que vous prévoyez de rencontrer, afin que les tampons puissent se remplir en arrière-plan à partir d'un démarrage à froid. Un tampon en veille de taille suffisante peut réduire la latence maximale de planification des pods au temps nécessaire pour reprendre un nœud, soit environ 30 secondes. Lorsque le tampon de capacité commence à être utilisé et à être rempli, les nouveaux nœuds de tampon passent à un état actif avant d'être suspendus. Cette stratégie permet d'augmenter la capacité active lors d'une charge prolongée.
- Utilisez le simulateur de tampon : testez différentes tailles de tampon actif et en veille pour obtenir le meilleur résultat pour votre charge de travail spécifique. Exécutez des simulations du comportement de scaling des charges de travail à l'aide du simulateur de tampons GKE Open Source disponible à l'adresse https://github.com/gke-labs/buffers-simulator pour affiner vos règles de dimensionnement des tampons et atteindre vos objectifs de performances.
Conditions requises et limites
Les tampons de capacité sont soumis aux exigences et limites suivantes :
- Les tampons de capacité sont disponibles pour les clusters GKE exécutant la version 1.35.2-gke.1842000 ou ultérieure pour les tampons actifs, et la version 1.36.0-gke.2253000 pour les tampons en veille.
- Les tampons de capacité ne sont compatibles qu'avec les charges de travail qui utilisent un modèle de facturation basé sur les nœuds pour les pools de nœuds standards et les pools de nœuds Autopilot qui sélectionnent du matériel spécifique. Les tampons de capacité ne sont pas compatibles avec les charges de travail qui utilisent le modèle de facturation basé sur les pods.
- Sur les clusters standards, nous vous recommandons d'activer le provisionnement automatique des nœuds. Le provisionnement automatique des nœuds permet à l'autoscaler de cluster de créer des pools de nœuds en fonction des demandes de ressources de votre CapacityBuffer. Si vous n'activez pas le provisionnement automatique des nœuds, l'autoscaler de cluster ne fait évoluer que les pools de nœuds existants.
- Les tampons de capacité actifs et en veille sont pris en compte dans les quotas Compute Engine.
- Si la dépendance de configuration de votre CapacityBuffer (par exemple, un PodTemplate) sélectionne une ComputeClass personnalisée, la dépendance doit définir toutes les tolérances, tous les sélecteurs de nœuds ou toutes les classes d'exécution requises pour la planification sur les nœuds provisionnés (par exemple, les exigences concernant GKE Sandbox). Pour obtenir des instructions, consultez la documentation sur les ComputeClass personnalisées.
Les tampons en veille présentent les limites supplémentaires suivantes :
- Ils sont compatibles avec les clusters standards pour lesquels le provisionnement automatique des nœuds est activé.
- Ils sont compatibles avec les clusters Autopilot exécutant la version 1.36.0-gke.2853000 ou ultérieure.
- Les nœuds auxquels sont associés des GPU ou des TPU ne sont pas compatibles.
- Les disques SSD locaux ne sont pas compatibles.
- Les nœuds Google Kubernetes Engine confidentiels ne sont pas compatibles.
- Vous devez connaître les limites liées aux opérations de suspension et de reprise de Compute Engine.
Voici quelques limites clés :
- Les nœuds avec des disques protégés par des clés de chiffrement fournies par le client ne sont pas compatibles.
- Les nœuds avec plus de 208 Go de mémoire ne sont pas compatibles.
- Les instances Bare Metal ne sont pas compatibles.
- Le système d'exploitation du nœud doit être compatible avec les signaux de veille ACPI S3.
- La durée du processus de suspension est proportionnelle à la taille de la mémoire.
- La reprise dépend de la disponibilité des ressources sous-jacentes requises pour la reprise.
Étape suivante
- Pour savoir comment implémenter un tampon de capacité, consultez Configurer des tampons de capacité.