Les tampons de capacité vous aident à réduire la latence de démarrage des pods pour vos charges de travail Google Kubernetes Engine (GKE). Pour ce faire, ils vous permettent de déclarer de manière proactive des niveaux de tampons de capacité actifs ou en veille dans votre cluster. En déclarant la capacité excédentaire à l'avance, vous pouvez démarrer les charges de travail plus rapidement et de manière économique.
Ce document explique le fonctionnement des marges de capacité. Pour savoir comment activer et utiliser les marges de capacité, consultez Configurer les marges de capacité.
Quand utiliser des marges 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, une mémoire tampon active fournit une capacité préprovisionnée conçue pour une mise à l'échelle à faible latence. Lorsque vous constatez une augmentation soutenue du trafic, une mémoire tampon de secours permet de planifier les pods à un coût plus abordable que le préprovisionnement.
Les marges de capacité offrent les avantages suivants :
- Minimiser la latence de scaling : les tampons actifs fournissent des nœuds en cours d'exécution, ce qui permet de minimiser la latence. Les tampons de secours reprennent rapidement, ce qui permet de disposer plus rapidement de la capacité que les nœuds récents, à un coût inférieur à celui des tampons actifs.
- Surprovisionnement économique : les tampons de capacité vous aident à maintenir un filet de sécurité. Pour les charges de travail à grande échelle, cette approche est souvent plus économique que les autres méthodes de surprovisionnement (par exemple, en abaissant les cibles d'utilisation de l'autoscaler de pods horizontal (AHP)), qui peuvent augmenter la capacité inutilisée de manière linéaire à mesure que votre cluster se développe.
- Répondez aux exigences de charge de travail : vous avez un contrôle total sur la configuration de votre marge de capacité. Vous pouvez, par exemple, intégrer des daemonsets personnalisés pour précharger des images, ajuster le temps de démarrage et contrôler la taille des tampons en fonction de vos besoins.
Nous recommandons des marges de capacité pour les charges de travail sensibles à la latence qui nécessitent une mise à l'échelle rapide, comme 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 marges de capacité
Implémentez une marge de capacité en utilisant une ressource personnalisée Kubernetes CapacityBuffer pour définir une marge 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 de suffisamment de capacité 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 à haute priorité est mise à l'échelle, 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ées dans le tampon, ce qui évite le délai habituel associé au provisionnement des nœuds. Lorsqu'une charge de travail utilise une unité tampon, l'autoscaler de cluster provisionne un nouveau nœud pour remplir le tampon.
Stratégies de marge 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.
Marge active
Un tampon actif fournit des nœuds en cours d'exécution pour la mise à l'échelle à faible latence des charges de travail qui s'inscrivent dans la capacité réservée. Comme les nœuds sont déjà en cours d'exécution, ils offrent une latence minimale pour revendiquer les pods lors d'un événement de scaling à la hausse.
Tampon de secours
Une mémoire tampon de veille fournit des nœuds suspendus. La stratégie de veille est plus économique que la stratégie active, mais elle introduit un court délai pour que le nœud reprenne avant d'accepter les charges de travail.
Coûts et tarification
La facturation des marges de capacité diffère selon le type de marge :
- Tampons actifs : les VM en cours d'exécution que GKE maintient pour servir de capacité de tampon actif vous sont facturées aux tarifs de calcul GKE standards. Sur Autopilot, les tarifs de facturation standards basés sur les pods s'appliquent aux pods en cours d'exécution.
- Tampons de veille : lorsque les instances de VM sont suspendues, vous ne payez pas les coûts de calcul (processeur ou mémoire). Vous devrez payer des frais de stockage mineurs (par exemple, pour les disques de démarrage de VM) et les coûts des ressources associées, telles que les adresses IP externes statiques. Lorsque GKE rétablit les VM de secours pour héberger des charges de travail, les tarifs de facturation standards pour le calcul ou basés sur les pods s'appliquent.
CRD CapacityBuffer
Pour configurer un tampon de capacité, vous devez créer une définition de ressource personnalisée (CRD) CapacityBuffer. Vous pouvez configurer la marge de capacité pour répondre à différents critères :
- Instances répliquées fixes : spécifiez un nombre fixe de pods tampon à créer en fonction des 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 tampon à créer en fonction des demandes de ressources d'un modèle de pod référencé.
- Basée sur un pourcentage : définissez la taille de la mémoire tampon en tant que pourcentage d'un objet évolutif existant qui définit une sous-ressource de scaling (telle qu'un déploiement, un StatefulSet, un ReplicaSet ou un Job). La taille de la mémoire tampon s'ajuste de manière dynamique à 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 mise à l'échelle Kubernetes.
Pour en savoir plus, consultez la documentation de référence sur le CRD CapacityBuffer.
Bonnes pratiques
Pour optimiser le rapport coût/efficacité et la réactivité lors de la configuration des marges de capacité, suivez les recommandations suivantes :
- Utilisez une stratégie de veille en premier lieu et optimisée pour les coûts : privilégiez les tampons de veille si vos charges de travail peuvent tolérer un bref délai de scaling up d'environ 30 secondes. Cette stratégie évite les démarrages à froid des nœuds de nouvelles VM 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 de veille plus grand pour une configuration économique. GKE donne la priorité au remplissage du tampon actif en réactivant les nœuds du tampon de secours (ce qui prend environ 30 secondes), tandis que de nouveaux nœuds sont provisionnés en arrière-plan pour remplir le tampon de secours. Cette configuration absorbe les pics initiaux avec une capacité active et s'adapte à la croissance soutenue à l'aide de la capacité de secours à moindre coût.
- Dimensionner les tampons actifs pour les pics initiaux : définissez la taille de votre tampon actif pour couvrir les pics de répliques soudains initiaux auxquels vous vous attendez, avant que les nœuds de tampon de secours puissent reprendre.
- Dimensionnez les tampons de veille pour une charge soutenue : définissez des tampons de veille suffisamment grands 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. Une mémoire tampon de secours de taille suffisante peut réduire la latence maximale de planification des pods au temps nécessaire pour redémarrer un nœud, soit environ 30 secondes. Lorsque la mémoire tampon de capacité commence à être utilisée et à se remplir, les nouveaux nœuds de mémoire tampon passent à l'é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 mémoire tampon : testez différentes tailles de mémoire tampon active et de 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 tampon GKE Open Source disponible sur 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 marges de capacité sont soumises aux exigences et limites suivantes :
- Les marges de capacité sont disponibles pour les clusters GKE exécutant la version 1.35.2-gke.1842000 ou ultérieure pour les marges actives, et la version 1.36.0-gke.2253000 pour les marges de secours.
- Les marges 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 Standard 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 Standard, 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 dans votre CapacityBuffer. Si vous n'activez pas le provisionnement automatique des nœuds, l'autoscaler de cluster ne fait que mettre à l'échelle les pools de nœuds existants.
- Les tampons de capacité active et de secours sont comptabilisés dans les quotas Compute Engine.
Les tampons de secours présentent les limites supplémentaires suivantes :
- Elles ne sont disponibles que sur les clusters standards avec le provisionnement automatique des nœuds activé.
- Les nœuds avec GPU ou TPU associés ne sont pas compatibles.
- Les SSD locaux ne sont pas compatibles.
- Les clés de chiffrement gérées par le client (CMEK) ne sont pas prises en charge.
- 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-unes des principales limites :
- Les nœuds avec des disques protégés par des clés de chiffrement fournies par le client (CSEK) ne sont pas acceptés.
- Les nœuds disposant de plus de 208 Go de mémoire ne sont pas compatibles.
- Les instances Bare Metal ne sont pas prises en charge.
- L'OS du nœud doit être compatible avec les signaux de veille ACPI S3.
- La durée de la procédure de suspension est proportionnelle à la taille de la mémoire.
- La reprise dépend de la disponibilité des ressources sous-jacentes nécessaires à la reprise.
Étapes suivantes
- Pour savoir comment implémenter une marge de capacité, consultez Configurer des marges de capacité.