Scale-to-zero
Kers supporte le scale-to-zero : quand un site ou une application ne reçoit aucune requête, tous ses pods peuvent être arrêtés automatiquement. Dès qu’une requête arrive, les pods redémarrent et la traitent — le tout sans aucune intervention manuelle.
Principe
Dans un cluster Kubernetes classique, un déploiement tourne en permanence, même si personne ne visite le site pendant des heures ou des nuits entières. Ces pods consomment du compute et sont facturés en continu.
Le scale-to-zero inverse ce principe :
|
0 requête → 0 pod actif → 0 coût compute. |
Quand l’activité reprend, les pods se relancent automatiquement pour servir le trafic.
Fonctionnement dans Kers
La fonctionnalité repose sur KEDA (Kubernetes Event-driven Autoscaling), un composant open-source déployé sur la plateforme Kers.
KEDA surveille le trafic HTTP entrant :
-
Aucune requête depuis un délai configurable → les pods du déploiement sont scalés à 0.
-
Une requête arrive → KEDA détecte l’événement et relance les pods.
-
Les pods deviennent disponibles en quelques secondes, la requête est traitée.
Ce comportement est entièrement transparent côté infrastructure : votre code, vos images Docker et vos déploiements ne changent pas.
Cas d’usage
Le scale-to-zero est particulièrement adapté aux situations suivantes :
| Contexte | Bénéfice |
|---|---|
Environnements staging / dev |
Ces environnements sont souvent inactifs la nuit et le week-end. Le scale-to-zero supprime leur coût pendant les périodes creuses. |
Sites à faible trafic |
Un site institutionnel ou une landing page peu visitée peut ne pas justifier un pod permanent. |
Batch ou applications ponctuelles |
Des services appelés sporadiquement n’ont pas besoin de tourner en continu. |
Disponibilité actuelle
Le scale-to-zero est disponible aujourd’hui pour les déploiements PHP (Nginx + PHP-FPM) dans Kers.
Trade-offs à prendre en compte
Latence au démarrage à froid
Quand les pods sont à zéro et qu’une première requête arrive, un délai de démarrage (cold start) est inévitable : de l’ordre de quelques secondes, le temps que les pods soient prêts.
Ce délai est généralement acceptable pour les cas d’usage décrits ci-dessus (staging, faible trafic). Pour des applications de production à fort trafic en continu, un minimum de 1 pod est recommandé pour conserver une latence constante.
|
Il est possible de configurer le nombre minimum de pods (0 pour le scale-to-zero complet, ou 1 pour conserver un pod de veille). Le choix dépend du compromis coûts / latence souhaité. |
Désactivation du monitoring et des liveness probes
Pour que le scale-down vers zéro puisse s’opérer, il est nécessaire de désactiver les liveness probes et les sondes de monitoring actif sur les pods concernés.
En effet, ces mécanismes génèrent eux-mêmes du trafic vers les pods à intervalles réguliers : si des probes continuent d’interroger un pod, le système détecte une activité permanente et ne peut jamais conclure que le service est inactif — le scale-down vers zéro n’est alors jamais déclenché.
Waays prend en charge cette configuration lors de l’activation du scale-to-zero sur votre déploiement.
Complémentarité avec l’autoscaling
Scale-to-zero et autoscaling sont deux mécanismes complémentaires dans Kers :
-
Le scale-to-zero réduit la consommation à l’idle (période sans trafic).
-
L'autoscaling des nœuds absorbe les pics de charge au-delà de la capacité installée.
Ensemble, ils permettent de n’utiliser — et de ne payer — que ce dont vous avez effectivement besoin, au moment où vous en avez besoin.