Fini le surprovisionnement au démarrage : découvrez le CPU startup boost de GKE

Le dilemme : rapidité au démarrage ou gaspillage permanent

Toute équipe qui exécute des workloads lourds et sensibles à la latence sur Kubernetes est contrainte de choisir entre deux compromis frustrants :

Dimensionner pour le démarrage, et payer pour toujours. Fixez la request CPU suffisamment haute pour traverser rapidement l'initialisation, même si l'application n'a besoin que d'un minimum de CPU une fois chaude. Cette request reste là en permanence. C'est elle que le scheduler utilise pour placer le Pod, que l'autoscaler de cluster utilise pour décider d'ajouter des nœuds, et c'est elle qui vous est facturée. Sur quelques centaines de replicas, ce compromis entre démarrage plus rapide et gaspillage permanent s'accumule vite.

Dimensionner pour le régime établi, et souffrir au démarrage. Ajustez la request à l'utilisation réelle en fonctionnement, et acceptez que chaque redémarrage, chaque déploiement progressif, chaque mise à niveau de nœud se traduise par une lente montée vers l'état prêt. Sous throttling CPU, un warm-up de JVM qui devrait prendre 5 secondes peut s'étirer jusqu'à 30 ou plus. Résultat : des rollouts plus lents, un scale-out plus lent lors des événements HPA, et des pics de latence potentiels pour les utilisateurs.

Aucune de ces deux options n'est vraiment acceptable. Le CPU startup boost est conçu pour combler cet écart.

Ce que le CPU startup boost résout concrètement

Le CPU startup boost est une nouvelle fonctionnalité du Vertical Pod Autoscaler (VPA) de GKE, actuellement en Preview. Elle permet d'augmenter temporairement la request CPU d'un conteneur pendant l'initialisation du Pod, puis de la ramener automatiquement à sa valeur de base sans redémarrer le conteneur.

Les runtimes gourmands en ressources (Java, Node.js et Python avec des imports lourds) obtiennent la marge CPU dont ils ont besoin uniquement quand ils en ont besoin, pendant l'initialisation. Votre request de base peut ainsi refléter l'utilisation réelle en régime établi, plutôt qu'un compromis gonflé pour les premières secondes de vie du Pod. Comme le retour du niveau boosté au niveau de base s'appuie sur le redimensionnement de Pod à chaud (IPPR) de Kubernetes plutôt que sur une éviction et une recréation du Pod, le conteneur continue de tourner pendant toute l'opération.

Ce mécanisme fonctionne en complément du rôle habituel du VPA, qui consiste à recommander et appliquer un dimensionnement des ressources sur le long terme. Le startup boost n'est en réalité qu'une surcouche de courte durée appliquée par-dessus la valeur de base que le VPA (ou vous-même) a déjà établie.

Fonctionnement et configuration

Le guide complet est disponible ici : Accelerate application startup with CPU startup boost.

Le CPU startup boost se définit en ajoutant un bloc startupBoost à votre objet VerticalPodAutoscaler. Vous pouvez l'appliquer au niveau du Pod, pour que chaque conteneur reçoive le même boost, ou au niveau du conteneur, pour cibler certains conteneurs ou en exclure d'autres d'un boost appliqué à l'ensemble du Pod.

Il ne se déclenche qu'à la création du Pod. Si un conteneur redémarre plus tard, par exemple après un OOMKill alors que le Pod lui-même reste en vie, le boost n'est pas réappliqué. Le webhook d'admission qui injecte le boost ne s'exécute qu'à l'admission initiale du Pod.

Le type de boost peut être un multiplicateur ou une quantité fixe. type: "Factor" multiplie la request CPU de base par un facteur (factor: 2 la double) ; type: "Quantity" ajoute une quantité fixe de CPU par-dessus la valeur de base.

Il fonctionne avec les modes de mise à jour du VPA, pas à leur place. Utilisez-le avec updateMode: "Off" si vous voulez le comportement de boost et rien d'autre, ou associez-le à updateMode: "InPlaceOrRecreate" si vous souhaitez également que le VPA continue d'ajuster les ressources en fonction de l'utilisation constatée.

Pour configurer un boost au niveau du Pod, utilisez l'une des options suivantes.

Boost au niveau du Pod, sans action du VPA

Utilisez cette option quand vous voulez le boost et rien de plus — le VPA n'appliquera aucune autre recommandation de ressources.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Chaque conteneur du Pod reçoit le double de sa request CPU de base pendant les 10 premières secondes après que le Pod a atteint l'état Ready, après quoi GKE le redimensionne à chaud vers sa valeur de base.

Boost au niveau du Pod, avec gestion continue par le VPA

Utilisez cette option quand vous voulez à la fois le boost au démarrage et un right-sizing continu et à chaud des ressources par la suite.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Même comportement de boost, mais updateMode: "InPlaceOrRecreate" signifie que le VPA continue de recommander et d'appliquer des ajustements de ressources tout au long de la vie du Pod, en tentant d'abord un redimensionnement à chaud avant de recourir à la recréation.

Boost au niveau du conteneur, ciblé sur un seul conteneur

Utile quand un Deployment contient un sidecar ou un conteneur utilitaire qui n'a pas besoin du pic de CPU au démarrage. Vous limitez le boost au seul conteneur qui en a besoin via resourcePolicy.containerPolicies.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

Ici, boosted-container-name reçoit 2 vCPU supplémentaires par-dessus sa request de base pendant le démarrage — une quantité fixe plutôt qu'un multiplicateur.

Exclure un conteneur d'un boost défini au niveau du Pod

Le cas inverse : un boost est défini au niveau du Pod, mais un conteneur ne doit pas être boosté comme les autres.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

Le boost au niveau du Pod applique par défaut un facteur de 2 à l'ensemble des conteneurs, mais la politique de conteneur le ramène à un facteur de 1 pour le conteneur nommé.