À propos des marges de capacité

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 la capacité de réserve à l'avance, vous pouvez démarrer les charges de travail plus rapidement et 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. Lorsque vous rencontrez des augmentations soudaines du trafic, un tampon actif fournit une capacité préprovisionnée conçue pour un scaling à faible latence. Lorsque vous constatez une augmentation durable du trafic, un tampon de secours permet de planifier les pods à un coût plus abordable que le préprovisionnement.

Les tampons 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 de la capacité plus rapidement que les nouveaux nœuds, à 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 d'autres méthodes de surprovisionnement, telles que la réduction des cibles d'utilisation de l'autoscaler horizontal de pods (AHP), qui peut augmenter la capacité inactive de manière linéaire à mesure que votre cluster se développe.
  • Répondre aux exigences de charge de travail : vous contrôlez entièrement la configuration de votre tampon 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 de la mémoire tampon en fonction de vos besoins.

Nous recommandons les tampons de capacité pour les charges de travail sensibles à la latence qui nécessitent un scaling à la hausse rapide, comme les agents IA, l'inférence d'IA, les applications de vente au détail lors d'événements promotionnels ou les serveurs de jeux pendant les pics d'activité des joueurs.

Fonctionnement des tampons de capacité

Implémentez un tampon de capacité en utilisant 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 que la capacité de réserve est disponible. Si votre cluster ne dispose pas d'une capacité suffisante pour répondre aux requêtes de ressources définies dans le tampon, l'autoscaler de cluster provisionne des nœuds supplémentaires.

Lorsqu'une charge de travail évolue à la hausse, GKE planifie les pods en attente sur la capacité disponible dans l'ordre de priorité suivant :

  1. Nœuds en cours d'exécution dans un tampon actif
  2. Nœuds en cours d'exécution dans un tampon de secours qui n'ont pas encore été suspendus
  3. Nœuds suspendus dans un tampon de secours
  4. Nœuds nouvellement provisionnés

Pour planifier les pods en attente le plus rapidement possible, GKE utilise la capacité de tampon disponible avant de provisionner de nouveaux nœuds. Cette priorité s'applique même si une règle de priorité plus élevée dans une ComputeClass personnalisée provisionnerait un nouveau nœud.

La capacité de la mémoire tampon n'est pas limitée à la charge de travail référencée dans le champ scalableRef. Tout pod en attente dont les contraintes de planification, telles que les sélecteurs de nœuds, les tolérances et les requêtes de ressources, correspondent à la configuration du nœud tampon peut revendiquer cette capacité. Pour réserver un tampon de capacité pour une charge de travail spécifique, configurez la séparation des charges de travail en ajoutant des tolérances et des sélecteurs de nœuds (ou des affinités de nœuds) correspondants à la charge de travail et au tampon de capacité.

Lorsqu'une charge de travail consomme de la capacité d'un tampon actif, l'autoscaler de cluster réapprovisionne le tampon actif en reprenant un nœud d'un tampon de secours compatible s'il en existe un, ou en provisionnant un nouveau nœud. Lorsqu'une charge de travail ou un tampon actif consomme un nœud d'un tampon de secours, l'autoscaler de cluster réapprovisionne le tampon de secours en provisionnant et en suspendant un nouveau nœud. Lorsque votre charge de travail est réduite et que les nœuds sont sous-utilisés, l'autoscaler de cluster supprime les nœuds en cours d'exécution excédentaires après la fenêtre de stabilisation de scaling à la baisse, plutôt que de les suspendre à nouveau dans le tampon de secours. Pour reconstituer le tampon de secours, GKE provisionne et suspend de nouveaux nœuds séparément.

Stratégies de tampon de capacité

Vous pouvez configurer des tampons de capacité en utilisant différentes stratégies de provisionnement en fonction de vos exigences 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'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 la revendication des pods lors d'un événement de scaling à la hausse.

Tampon de secours

Un tampon de secours fournit des nœuds suspendus. La stratégie de secours est plus rentable que la stratégie active, mais elle introduit un court délai pour reprendre le nœud avant qu'il n'accepte les charges de travail.

Coûts et tarification

Les tampons de capacité sont fournis sans frais supplémentaires en plus de vos coûts de calcul standards basés sur les nœuds, qui s'appliquent aux pools de nœuds standards et aux charges de travail Autopilot qui sélectionnent du matériel spécifique. Les tampons de capacité ne sont pas compatibles avec le modèle de facturation basé sur les pods.

La facturation des nœuds sous-jacents diffère selon le type de tampon :

  • Tampons actifs : les tarifs de calcul standards basés sur les nœuds vous sont facturés pour les VM en cours d'exécution que GKE gère pour servir de capacité de tampon actif.
  • Tampons de secours : lorsque les instances de VM sont suspendues, vous ne payez pas de frais de calcul (processeur ou mémoire). Vous devez payer des frais de stockage mineurs (par exemple, pour les disques de démarrage de VM et l'état de la mémoire stockée) et des coûts pour les ressources associées, telles que les adresses IP externes statiques. Lorsque GKE réactive les VM de secours pour héberger des charges de travail, les tarifs de calcul standards basés sur les nœuds s'appliquent. Pour en savoir plus, consultez Tarifs des instances suspendues.

CRD CapacityBuffer

Pour configurer un tampon de capacité, vous devez créer une ressource CapacityBuffer CustomResourceDefinition (CRD). Vous pouvez configurer le tampon de capacité pour qu'il réponde à différents critères :

  • Instances répliquées fixes : spécifiez un nombre fixe de pods de tampon à créer en fonction des requêtes de ressources d'un modèle de pod référencé. Cette configuration est le moyen le plus simple de créer un tampon d'une 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 objet Deployment, StatefulSet, ReplicaSet ou Job). La taille du 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 scaling Kubernetes.

Vous pouvez combiner ces options, par exemple en définissant à la fois replicas et percentage afin que GKE utilise la valeur la plus élevée comme seuil minimal, et en définissant limits comme limite supérieure.

Pour en savoir plus, consultez la documentation de référence sur la CRD CapacityBuffer.

Bonnes pratiques

Pour optimiser la rentabilité et la réactivité lors de la configuration des tampons de capacité, suivez les recommandations suivantes :

  • Utilisez une stratégie de mise en veille optimale en termes de coûts : donnez la priorité aux tampons de mise en veille si vos charges de travail peuvent tolérer un bref délai de scaling à la hausse d'environ 30 secondes. Cette stratégie évite les démarrages à froid 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 secours plus grand pour une configuration rentable. GKE donne la priorité au remplissage du tampon actif en reprenant 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 la capacité active et s'adapte à une croissance soutenue en utilisant 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 soudains initiaux d'instances répliquées que vous prévoyez de rencontrer, avant que les nœuds de tampon de secours puissent reprendre.
  • Dimensionner les tampons de secours pour une charge soutenue : définissez des tampons de secours 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 de secours 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 est rempli, les nouveaux nœuds de 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 tampon : testez différentes tailles de tampon actif et de tampon de secours 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 taille de la mémoire tampon et atteindre vos objectifs de performances.
  • Réduire la latence de démarrage à froid lors du scaling des charges de travail à partir de zéro : associez les charges de travail qui effectuent un scaling à la hausse et à la baisse à partir de zéro à l'aide de l'autoscaler horizontal de pods (minReplicas: 0) avec des tampons de capacité. Lorsque la demande augmente et que la charge de travail passe de zéro à un nombre supérieur, GKE planifie immédiatement les pods sur les nœuds de tampon préchauffés au lieu d'attendre le provisionnement de nouveaux nœuds de calcul.
  • Envisagez d'utiliser le profil d'autoscaling optimize-utilization sur les clusters standards : étant donné que les tampons de capacité conservent déjà une marge de manœuvre, vous pouvez configurer le profil d'autoscaling optimize-utilization (--autoscaling-profile=optimize-utilization) afin que l'autoscaler de cluster réduise plus rapidement la capacité des nœuds sous-utilisés après une baisse de la demande. Ce profil regroupe également les pods de manière plus dense sur les nœuds. Avant de l'activer, déterminez si un regroupement plus dense répond aux exigences de disponibilité de votre charge de travail.

Calculer la taille de votre mémoire tampon

Lorsque vous combinez un tampon actif avec un tampon de secours, vous pouvez estimer le nombre d'instances répliquées de tampon, ou de pods de tampon simulés, nécessaires pour absorber un pic de trafic. Calculez cette estimation en utilisant votre taux de scaling à la hausse attendu en pods par seconde, la latence de reprise de vos nœuds de secours et la latence de création de vos nœuds à froid. Ces latences varient en fonction de la série de machines de VM et de la configuration des nœuds. Par exemple, la latence de reprise d'un nœud de secours est généralement de 30 à 35 secondes, et la latence de création d'un nœud est généralement de 60 à 120 secondes, selon la série de machines. Pour mesurer les latences réelles de votre cluster, consultez Surveiller les métriques de latence de démarrage.

  1. Calculez la taille de votre tampon actif pour couvrir les pods créés pendant la reprise des nœuds de secours :

    \[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]

  2. Calculez la taille de votre tampon de secours pour couvrir les pods restants créés pendant que les nouveaux nœuds froids terminent leur provisionnement :

    \[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]

Par exemple, si votre charge de travail effectue un scaling à la hausse de deux pods par seconde, que les nœuds de secours mettent 30 secondes à reprendre et que les nouveaux nœuds froids mettent 90 secondes à être provisionnés :

  • Votre tampon actif a besoin de \( 2 \times 30 = 60 \)  instances répliquées pour absorber les 30 premières secondes du pic.
  • Votre tampon de secours a besoin de \( (2 \times 90) - 60 = 120 \)  instances répliquées pour couvrir les 60 secondes restantes pendant que l'autoscaler de cluster provisionne de nouveaux nœuds froids en arrière-plan pour reconstituer vos tampons. Si le pic se poursuit au-delà de 90 secondes au même rythme, ces nœuds réapprovisionnés sont prêts à diffuser les pods entrants sans temps d'attente.

Pour tester ces estimations par rapport aux modèles de scaling de votre charge de travail, exécutez des simulations avec le simulateur de tampons GKE.

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 de secours.
  • 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 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 standards, nous vous recommandons d'activer la création automatique de pools de nœuds. La création automatique de pools de nœuds permet à l'autoscaler de cluster de créer des pools de nœuds en fonction des requêtes de ressources de votre CapacityBuffer. Si vous n'activez pas la création automatique de pools de nœuds, l'autoscaler de cluster n'effectue un scaling à la hausse que pour les pools de nœuds existants.
  • Les tampons de capacité actifs et de secours consomment les quotas différemment :
    • Les nœuds en cours d'exécution dans un tampon actif sont comptabilisés dans vos quotas Compute Engine de vCPU, de mémoire, de disque et d'adresse IP.
    • Les nœuds suspendus d'un tampon de secours ne sont pas comptabilisés dans les quotas de processeurs virtuels ou de mémoire Compute Engine tant qu'ils sont suspendus. Toutefois, elles continuent de consommer des quotas d'adresses IP et des quotas de disque, y compris le quota Persistent disk standard (GB) utilisé pour stocker la mémoire de la VM suspendue.
    • Dans Kubernetes, les unités de tampon de secours actives et suspendues sont comptabilisées dans les quotas de ressources Kubernetes de votre espace de noms, comme si les pods de tampon étaient en cours d'exécution.
  • Si la dépendance de votre configuration CapacityBuffer (par exemple, un PodTemplate) sélectionne une ComputeClass personnalisée, la dépendance doit définir les tolérances, les sélecteurs de nœuds ou les classes d'exécution requis pour la planification sur les nœuds provisionnés (par exemple, les exigences pour GKE Sandbox). Pour obtenir des instructions, consultez la documentation sur les ComputeClass personnalisées.

Les tampons de secours sont soumis aux limites supplémentaires suivantes :

  • Ils sont compatibles avec les clusters standards pour lesquels la création automatique de pools de nœuds est activée.
  • Ils sont compatibles avec les clusters Autopilot exécutant la version 1.36.0-gke.2853000 ou ultérieure.
  • Les nœuds avec des GPU ou des TPU associés ne sont pas compatibles.
  • Les disques SSD locaux ne sont pas compatibles.
  • Bien que les tampons de secours soient compatibles avec les clés de chiffrement gérées par le client (CMEK) pour le stockage du nœud, la mémoire du nœud est chiffrée à l'aide de Google-owned and Google-managed encryption keys pendant la suspension.
  • Les nœuds Google Kubernetes Engine confidentiels ne sont pas compatibles.
  • Les tampons de secours ne sont compatibles qu'avec les images de nœuds Container-Optimized OS et Ubuntu de GKE. Les nœuds Windows Server ne sont pas compatibles. Si vous utilisez un système d'exploitation de nœud personnalisé, vous devez vous assurer qu'il est compatible avec les opérations de suspension et de reprise de Compute Engine.
  • 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 dotés de 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 compatibles.
    • L'OS du nœud doit être compatible avec les signaux de mise en veille ACPI S3.
    • La durée du processus de suspension est proportionnelle à la taille de la mémoire.

Étapes suivantes