L’objectif de cet article n’est pas de critiquer la technologie Kubernetes en elle-même, mais plutôt d’évaluer son usage et sa pertinence en fonction des besoins spécifiques de nos clients. Dans cet article, nous nous concentrerons principalement sur les enjeux liés à l’autoscaler; les autres fonctionnalités de Kubernetes n’étant pas critiques pour nos clients et ne sont pas compatibles avec notre méthodologie, laquelle repose sur 19 ans d’expertise et de travail en commun.
Notre position n’est pas dogmatique, lorsque les besoins de nos clients le justifient nous savons adapter la complexité de nos réponses à leurs exigences. Nous proposons notre propre méthode d’ajustement automatisé des ressources. Il nous arrive même d’utiliser l’autoscaler d’AWS … Il convient toutefois de noter que la grande majorité de nos clients ont un trafic relativement prévisible.
Pour les projets sur lesquels nous avons travaillés, K8S ne constitue pas une solution qui pouvait apporter un gain significatif sur le rapport scalabilité / rentabilité.
Même si l'élasticité du système K8S permet d'aborder directement les problématiques de montée en charge en allouant des ressources dynamiquement, nous recommandons de garder le contrôle sur la prévisibilité et l'optimisation des coûts en optant pour des règles d'infogérance maîtrisées de bout en bout.
K8s ne rend pas automatiquement les applications élastiques / scalables, l'essentiel du travail demeurant applicatif
En effet, sur la partie horizontale, un autoscaler ne gère que l'ajout de CPU/RAM, ce qui revient à une scalabilité horizontale, mais ce n'est qu'un problème que les applications peuvent rencontrer parmi d'autres (contention des IO, surcharges SQL, API tierces, etc ...)
Le redimensionnement des ressources CPU/RAM est le problème le plus trivial sur lequel nous pouvons agir, en changeant les specs d'une VM suite à une alerte : cela ne prend que quelques minutes chez Bearstech.
L'autoscaler ne réagit qu'avec un temps de retard sur une situation déjà dégradée (en général au moins 5 minutes), et sans contrôle, l'autoscaler peut faire les montagnes russes aussi longtemps qu'il le souhaite... Il ne règle donc pas le problème de la continuité de service et de la tenue en charge 24/7 de l'application.
Ce dernier point nécessite une réflexion en amont et une expertise en architecture et performance des infrastructures d'hébergement.
Nous proposons une scalabilité basée sur des métriques, un monitoring spécifique adapté aux applicatifs que nous infogérons
Le monitoring est le coeur de notre métier, chez Bearstech, chaque ressource ajoutée dans l'infra doit être entièrement provisionnée (OS, services, code applicatif, données) et intégrée (monitorée, connectées aux services tiers).
Si l'environnement d'exploitation a besoin de plus de ressources, il faut prévoir également un déploiement d’application automatique en préalable (mais non suffisant), et il faut une intégration intime avec la partie système.
Si un automate est plus rapide qu’un opérateur pour réagir à une surcharge, il n’est par contre pas instantané (un délai de 5min est typique) ni forcément mieux informé qu’un opérateur (il peut y avoir des sur-déclenchements).
Un point important à prendre en compte: si l’application n’est pas limitée par la ressource gérée par l’automate, il ne pourra pas apporter de solution utile . En effet, des seuils sont à définir afin de ne pas risquer des effets d'emballement à cause de modules de développement qui n'ont pas été désactivés, ou d'un système de cache non prévu pour le multi-serveur ...
Mais aussi, toutes les ressources ne sont pas scalables horizontalement (SQL l’est par exemple très difficilement) ;
Malgré ses envies de scalabilité infinie, l'automate doit être paramétré pour avoir un niveau de contrôle sur la consommation des ressources.
Chez Bearstech, ce contrôle a lieu au niveau du service de monitoring qui dépend de notre système de supervision. Chez K8S, ce contrôle se fait via un paramétrage de variables définissant le niveau de QoS (quotas, limits et requests ...). Il nous a donc semblé contre-productif d'empiler plusieurs systèmes de contrôles, voire de les mettre en concurrence.
Notre expertise de l'infogérance de systèmes d'informations nous permet donc de concevoir des architectures qui garantissent l'optimisation constante de la consommation énergétique des infrastructures que nous maintenons en exploitation. Nous considérons qu'il en va de notre responsabilité d'opérateur dans un secteur où l'empreinte carbone doit être aussi limitée que possible.
Nos solutions d'élasticité sont plus transparentes, prévisibles et responsables
Nous avons mis au point des procédures pour industrialiser les méthodes de virtualisation afin de dimensionner des machines qui correspondent pour le mieux aux besoins en ressources des applications qui nous sont confiées.
Ces procédures sont consolidées et déployables en quelques minutes. Elles peuvent ainsi faire l'objet de procédures automatisables, dans la condition que les applications puissent bénéficier d'une architecture adaptée.
1. Déploiement applicatif
Lorsqu’un autoscale décide de rajouter par exemple une VM, c’est lui qui va devoir installer l’application et la connecter aux services dont elle a besoin (SQL, NFS, etc). Il doit donc savoir à chaque instant quelle est la version de l’application en production, et comment la déployer. Bearstech va vous conseiller et vous accompagner pour spécifier les modalités de livraison de l’application en production. Notre workflow devops est particulièrement adapté pour ce type de besoin.
2. Ressources partagées
Nous effectuons un travail d'identification des données que les processus exécutant l’application devront partager à chaque instant, car celles-ci seront gérées par une infrastructure tierce. On y trouve en général :
- les fichiers manipulés par l’application via le filesystem de l’OS
- les fichiers manipulés par l’application via un protocole objet
- une base de données : cluster SQL
- une base de données NoSQL
- des sessions : cluster Redis …
Chacun de ces services peut être déployé et infogéré par Bearstech, et devra lui-même être dimensionné en fonction des dimensions minimales et surtout maximales de l’autoscaler.
Il est important de réaliser que chacune de ces ressources partagées peut être un goulet d’étranglement de l’application et nécessite donc une attention particulière. Le seul fait d’avoir déployé un autoscaler est loin de garantir un succès en production lors du prochain pic de charge sans avoir mis en oeuvre avec nous, les analyses requises.
3. Configuration, test et exploitation
Une application est plus qu’une somme de services reliés entre eux, les interactions peuvent être rapidement complexes.
Notre expérience nous permet de choisir des architectures et dimensions cohérentes et fonctionnelles sans connaître l’application a priori, mais il demeure indispensable d’effectuer un test de charge sur une infrastructure:
- le test permet de configurer l’autoscaler en fonction des performances attendues de l’application
- le test permet d’anticiper comment réagit l’autoscaler et avoir un modèle de référence
- le test permet de vérifier où se trouve le goulet d’étranglement à chaque palier de charge
En exploitation, il est important d’effectuer une analyse régulière du comportement de l'autoscaler, à la fois d’un point de vue fonctionnel (absorbe les pics de charge) et financier (ne se déclenche pas à l’excès).
La surveillance de l’autoscaler est donc intimement liée au suivi des performances de l’application au cours de ses évolutions, et nous pouvons vous fournir l'outillage pour surveiller la qualité de votre code. Là aussi notre workflow devops est doté d'outils qui répondent à ce type de besoin.
Edit :
- Correction de l'affirmation "En effet, un autoscaler ne gère que l'ajout de CPU/RAM" par "En effet, sur la partie horizontale, un autoscaler ne gère que l'ajout de CPU/RAM"
- Correction introduction
