Build & DeployTools-in-Action30min
Dimensionnez correctement vos déploiements Kubernetes
Déployer des applications sur Kubernetes nécessite des ressources "requests" et "limits". Ce résumé explique comment choisir les bonnes valeurs pour éviter les problèmes de mémoire ou de performances. Deux outils utiles sont présentés, Krr et Goldilocks, avec des démonstrations et des conseils basés sur l'expérience de l'auteur.
Rémi VerchèreAccenture
talkDetail.whenAndWhere
Wednesday, April 17, 17:50-18:20
Paris 141
Lorsqu'on doit déployer une application sur un cluster Kubernetes, une bonne pratique est de définir des ressources "requests" et "limits" pour garantir le bon fonctionnement de celle-ci tout en garantissant la bonne santé du cluster qui l'accueille.
OK, mais quelles valeurs de "requests" et "limits" doit-on spécifier ? Pas assez de RAM et l'application sera "OOMKilled" ? Trop de CPU, mais cela bloquera les autres déploiements ?
Après un rapide rappel des concepts et tour d'horizon des différentes options pour paramétrer ces ressources, je vous présenterai deux outils simples mais efficaces pour vous aider à définir des valeurs pragmatiques : Krr d'une part, Goldilocks et l'utilisation automatique des Vertical Pod Autoscaler d'autre part. Je vous montrerai enfin comment intégrer au mieux ces informations dans vos tableaux de bord.
Pour chaque outil, une démonstration sera faite sur des applications "live", avec mes propres avis et retour d'expérience.
OK, mais quelles valeurs de "requests" et "limits" doit-on spécifier ? Pas assez de RAM et l'application sera "OOMKilled" ? Trop de CPU, mais cela bloquera les autres déploiements ?
Après un rapide rappel des concepts et tour d'horizon des différentes options pour paramétrer ces ressources, je vous présenterai deux outils simples mais efficaces pour vous aider à définir des valeurs pragmatiques : Krr d'une part, Goldilocks et l'utilisation automatique des Vertical Pod Autoscaler d'autre part. Je vous montrerai enfin comment intégrer au mieux ces informations dans vos tableaux de bord.
Pour chaque outil, une démonstration sera faite sur des applications "live", avec mes propres avis et retour d'expérience.
Rémi Verchère
D'abord chez les Devs sur des solutions embarquées, j'ai au fur et à mesure de mes postes basculé chez les Ops sur des solutions d'infrastructure diverses et variées.
Pendant plus de 10 ans j'ai donc bossé avec les Devs et les Ops, affichant une volonté de proposer des choix autour des solutions Open Source.
Je suis maintenant consultant depuis plusieurs années, et apporte aux entreprises mon savoir-faire sur des sujets d'automatisation, observabilité et cloud native infrastructure, en tant qu'Ops au service des Devs.
Pendant plus de 10 ans j'ai donc bossé avec les Devs et les Ops, affichant une volonté de proposer des choix autour des solutions Open Source.
Je suis maintenant consultant depuis plusieurs années, et apporte aux entreprises mon savoir-faire sur des sujets d'automatisation, observabilité et cloud native infrastructure, en tant qu'Ops au service des Devs.
comments.speakerNotEnabledComments