Comment survivre à des pics de charge avec son cluster Kubernetes ?
Le brief : tout tourne bien, nos pods sont healthy, reçoivent du traffic, mais tout d'un coup un gros pic de traff sur notre app ! Et là, c'est le drame. 😱
🧵👇
Le brief : tout tourne bien, nos pods sont healthy, reçoivent du traffic, mais tout d'un coup un gros pic de traff sur notre app ! Et là, c'est le drame. 😱
🧵👇
Le HPA (HorizontalPodAutoscaler) réagit bien, il auto-scale notre déploiement en demandant le scheduling de nouveaux pods. Mais là problème... Il n'y a pas assez de noeuds ! #Kubernetes va alors demander de nouveaux noeuds (on part du principe que c'est on-cloud). #k8s #kube
Mais le temps qu'ils arrivent, notre application est au bord de l'explosion, même la p50 latency est au-dessus des 10 secondes, c'est le feu à bord 🔥😱 Les utilisateurs gueulent car tout est pété en prod.
Finalement après 1-3 minutes les noeuds sont là, les nouveaux pods sont schédulés et le traffic commence à être ingéré correctement, la congestion baisse, on retrouve le calme.
Super, mais comment on aurait pu éviter ça ?! 😭
Super, mais comment on aurait pu éviter ça ?! 😭
Une des solutions que j'ai mis en place chez @Voggt_fr c'est l'utilisation de pods placeholder. Ce sont des pods avec une empreinte ultra légère (busybox, no root, sleep infinity, ...) déployé en permanence sur le cluster et avec une PriorityClass très faible.
Dans le cas d'un pic de traff, quand le HPA demande de nouveaux pods, le pod placeholder va être evicted et les nouveaux pods de mon app vont prendre sa place. Ce placeholder va ensuite être reschedule et trigger un nouveau noeud, où il va attendre d'être evicted au besoin.
L'idée est simple mais peut être coûteuse, surtout si vous utilisez des VMs plein tarif. Toutefois elle permet d'overprovisionner très simplement un ou plusieurs noeuds Kubernetes toujours prêts à recevoir rapidement de nouveaux pods en cas de besoin !
Je vous met un exemple de pod placeholder en image. Un pod avec une empreinte ultra light et qui request/limit CPU et/ou RAM et avec une PriorityClass très faible (0 chez nous). Comme ça plus besoin d'attendre des noeuds, il se fait evict et les pods prennent sa place. 
Le code d'exemple d'un pod placeholder : gist.github.com/KrustyHack/a0b…
Notez bien que la PriorityClass du placeholder doit être très faible (chez nous on a mis 0).
Notez bien que la PriorityClass du placeholder doit être très faible (chez nous on a mis 0).
• • •
Missing some Tweet in this thread? You can try to
force a refresh
