GKE accélère le démarrage des pods jusqu’à deux fois sans sur-provisionner le CPU
Google lance en preview le CPU startup boost de GKE, qui élève temporairement le CPU d’un conteneur pendant son initialisation puis le ramène à son niveau de croisière sans redémarrage, grâce à l’In-place Pod Resize de Kubernetes. Les services Java, Node.js et Python qui souffrent de cold starts lents y gagnent un démarrage jusqu’à deux fois plus rapide sans payer de marge CPU au repos.
2 octobre 2026. Google annonce le CPU startup boost de GKE en preview, intégré directement au Vertical Pod Autoscaler (VPA). Le principe : élever dynamiquement le CPU alloué à un conteneur pendant son initialisation, puis le ramener au niveau de croisière dès que l’application est prête, sans redémarrer le conteneur. Pourquoi c’est important : les équipes qui dimensionnent le CPU pour la charge de croisière subissent un throttling au démarrage, et celles qui le sur-provisionnent paient de la marge qui dort. Le startup boost coupe le dilemme à la racine.
Le dilemme que tout exploitant connaît
Une application consomme souvent beaucoup plus de CPU au démarrage qu’en régime établi, et ce surcroît est structurel, pas anecdotique. Un service Java — Spring Boot en tête — doit charger ses classes, scanner le classpath, instancier son conteneur d’injection de dépendances et exécuter la compilation JIT. Un serveur Node.js parse les fichiers, construit l’arbre de modules require/import et déclenche les passes d’optimisation du moteur V8. Un microservice Python importe PyTorch, NumPy ou LangChain, compile ses .pyc et initialise ses schémas ORM.
Si vous dimensionnez les requests CPU pour la charge de croisière, ces phases d’initialisation sont throttlées, et la sonde de readiness met plus de temps à passer — voire expire. La parade classique consiste à sur-provisionner les requests, mais dès que l’application se stabilise, ce CPU supplémentaire reste inutilisé et alourdit la facture sans apporter de valeur.
Le CPU startup boost règle le problème en accordant un pic temporaire de vCPU au lancement, puis en le restituant automatiquement une fois l’initialisation terminée. Google annonce une réduction du temps d’initialisation jusqu’à un facteur deux, sans redémarrage de pod.
Sous le capot, l’In-place Pod Resize
La mécanique repose sur une brique de Kubernetes encore méconnue : l’In-place Pod Resize (IPPR). Historiquement, changer les requests ou limits d’un pod exigeait de supprimer puis recréer le pod — un processus destructeur qui déclenchait des redémarrages, invalidait les caches et forçait une rescheduling.
L’IPPR, suivi sous KEP-1287, a changé la donne en permettant la mutation de ressources à chaud : le control plane et le kubelet mettent à jour les requests CPU et mémoire d’un pod en cours d’exécution, sans tuer le processus. Introduit en alpha dans Kubernetes 1.27, passé beta en 1.33, il est GA depuis la 1.35.
GKE s’appuie sur l’IPPR au sein du VPA pour dérouler le startup boost en trois phases. À l’admission, le webhook du VPA intercepte la création du pod, calcule le CPU majoré selon la politique (multiplicateur ou ajout fixe) et l’injecte dans le spec avec des annotations de suivi. Pendant le démarrage, le pod est ordonnancé avec cette allocation majorée et initialise à pleine vitesse. À la détente, dès que la readinessProbe passe — plus un délai durationSeconds de refroidissement — l’updater du VPA émet une demande de resize à chaud qui ramène le CPU au niveau de croisière, le conteneur continuant de tourner sans interruption.
La configuration en pratique
Le startup boost se déclare comme une section startupBoost dans le manifeste du VerticalPodAutoscaler. Premier cas : un boost au niveau du pod avec un niveau de croisière figé (updateMode: "Off"), pour les équipes qui veulent le boost sans laisser le VPA retoucher les requests en régime établi.
apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
name: java-app-startup-boost
namespace: default
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: java-app
updatePolicy:
updateMode: "Off"
startupBoost:
cpu:
type: "Factor"
factor: 2
durationSeconds: 10Ici, GKE double le request CPU du conteneur au lancement et maintient l’allocation majorée dix secondes après le passage de la sonde de readiness, avant de revenir au niveau de base.
Second cas : combiner le boost de démarrage avec un VPA continu qui optimise aussi les ressources de croisière après le démarrage, via updateMode: "InPlaceOrRecreate".
apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
name: nodejs-app-vpa
namespace: default
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: nodejs-service
updatePolicy:
updateMode: "InPlaceOrRecreate"
startupBoost:
cpu:
type: "Factor"
factor: 3
durationSeconds: 15Pour les pods multi-conteneurs, la politique accepte des règles par conteneur, ce qui permet d’exclure les sidecars — agents de logs ou proxies service mesh — qui n’ont pas besoin de CPU supplémentaire au boot.
Conditions d’éligibilité et pièges d’Autopilot
La fonctionnalité est disponible sur GKE Standard et Autopilot, à partir de la version 1.36.0-gke.4447000. Sur Autopilot, le VPA étant actif par défaut, elle est native ; sur Standard, il faut simplement s’assurer que le Vertical Pod Autoscaling est activé. Le startup boost fonctionne avec les contrôleurs usuels, Deployments et StatefulSets.
Un piège mérite d’être noté pour Autopilot : les pods y doivent respecter des ratios CPU/mémoire valides. Une majoration de CPU au démarrage doit donc s’accompagner d’une allocation mémoire de base qui accepte le ratio majoré pendant la phase de boot, faute de quoi le pod peut être rejeté avant même de démarrer. C’est le genre de détail qui transforme un déploiement rapide en incident silencieux.
Google recommande aussi de combiner le startup boost avec l’API capacity buffers pour absorber les pics de trafic : réduire la taxe de démarrage à grande échelle permet d’obtenir une densité de charge plus élevée sur moins de nœuds, et donc d’améliorer l’utilisation globale du cluster.
Mesurer le gain avant de généraliser
Le startup boost se mesure, et c’est une discipline qui sépare un déploiement réussi d’un simple changement de manifeste. Le bon indicateur n’est pas le temps de démarrage brut du pod, mais le temps jusqu’à readiness — l’intervalle entre la création du pod et le passage de la readinessProbe — car c’est lui qui détermine le moment où le trafic peut arriver.
Deux métriques complémentaires méritent d’être suivies. Le cold start d’un pod unique, mesuré sur un échantillon de déploiements représentatifs — de préférence vos services Java ou Python les plus lourds — donne le gain direct du boost. Le scale-out end-to-end, lui, mesure le délai entre le franchissement d’un seuil d’autoscaling et l’absorption effective du trafic : c’est là que le gain se traduit en disponibilité, car un pod qui démarre deux fois plus vite réduit d’autant la fenêtre pendant laquelle les réplicas existants absorbent seuls la charge.
Une précaution s’impose avant de généraliser. Le boost majorant le CPU demandé, il augmente temporairement la pression d’ordonnancement sur les nœuds pendant la phase de démarrage. Sur des clusters déjà saturés, une vague de scale-out simultanée peut provoquer des évictions ou des échecs d’ordonnancement que le boost ne fait qu’amplifier. Testez d’abord sur un service unique, avec un facteur modéré (factor: 2), et montez progressivement avant de l’appliquer à tout le parc.
Verdict
Si vous exploitez des services Java, Node.js ou Python sur GKE dont les cold starts sont lents — readiness qui frôle le timeout, montée en charge paresseuse après un scale-out — activez le CPU startup boost dès maintenant : il est en preview mais sans surcoût, et un manifeste VPA suffit. Si vous voulez figer vos requests de croisière, choisissez updateMode: "Off" pour obtenir le boost sans laisser le VPA retoucher vos définitions. Si vous êtes sur Autopilot, vérifiez les ratios CPU/mémoire avant d’appliquer une majoration, et combinez le boost avec les capacity buffers pour tirer le meilleur de la densité. Le vrai gain n’est pas le simple facteur deux au démarrage : c’est la fin du choix binaire entre throttling au boot et marge CPU payée au repos.