Kubernetes

Ces derniers mois, j'ai étudié Kubernetes pour voir s'il pouvait dépasser le domaine des micro-services utilisés ces dernières années ce qui a permis son essor.

A 5 ans d'âge, sur le point de devenir un standard dans le cloud, les trois leaders ( Google, AWS, Microsoft ) en déclinant une version "prête" à l'usage, mais aussi déployable en on-premise, il est temps de se poser la question du passage du stateless au stateful et de quitter le monde des containers appelant des services cloud en mode API.

J'ai donc exploré le monde Kubernetes du stateful et j'ai été agréablement surpris par le foisonnement autour de ce sujet qui va bien au-delà des PV ( physical volume ) et des PVC ( physical volume claim ). Le nombre de startups qui se développe autour du concept de cloud native storage en symbolise l'attrait et préfigure une montée en puissance d'applications plus conséquentes dans ce cluster d'applications qu'est Kubernetes.

Pour ma part, j'ai étudié la solution développée par Portworx et dans une optique d'un regroupement de clusters data dans un cluster Kubernetes, l'idée de séparation de la couche traitement et de la couche storage est séduisante. Ils ont plusieurs projets en production ou pas loin et leur site contient de nombreux exemples d'implémentation pour découvrir le produit.

Pour vous faire une idée de la richesse de l'écosystème Kubernetes, je vous invite à explorer cette map.

D'autre part, si on envisage un produit comme Anthos ou équivalent, on dispose alors d'une première approche pour pouvoir piloter des applications en on-premise ou sur le cloud avec peut-être la perspective d'éviter le fameux vendor lock-in de l'IT. L'histoire est longue dans ce sens, IBM, Oracle, cloudeurs et j'en oublie quelques-uns ...

Pour apprendre Kubernetes, j'ai suivi les deux modules de Cloud Academy, Introduction to Kubernetes et Building, Deploying and Running Containers in Production, ils sont très bien conçus pour appréhender les concepts Kubernetes et réaliser quelques TP d'apprentissage. En mode gratuit, n'hésitez pas à explorer You Tube, on y trouve de très bonnes présentations pour s'initier.

Ma playlist Kubernetes.

Pour pratiquer, vous pouvez installer MiniKube sur une VM et si vous pouvez disposer d'un portable avec 32 GB de RAM, vous pouvez créer un véritable cluster sur un hyperviseur. Pour ma part, j'apprécie l'hyperviseur de Vmware et j'ai donc monté un cluster à 3 noeuds ( un master, deux workers ) en m'appuyant sur le mode d'emploi fourni par Nakivo, excellent !

Ce tutoriel m'a permis de monter un cluster Cassandra et un cluster Elasticsearch ainsi que d'autres bricoles et de vérifier la solidité de la dernière version de Kubernetes, les noeuds étant des VM Ubuntu 20.04.

Durant cette étude, j'ai aussi découvert une startup qui propose des outils pour faciliter la prise en main de Kubernetes , d2iq. Auparavant, elle opérait sur Mesos, d'où un vrai savoir-faire dans le domaine des clusters d'applications.

Et pour les geeks, tentez de développer un opérateur en go !

Présentation de Spanner

Une étude sur Google Spanner

Les sujets abordés:
- Architecture
- ACID
- Conception de BDD
- Bonnes pratiques SQL
- Demo ( chargement par dataflow, LMD non partitionné ou non, plan d'exécution, ... )
- Limites de Spanner

Une infrastructure de clusters elk

Ces derniers mois, j'ai mis en oeuvre une infrastructure de clusters elk ( Elasticsearch, Logstash, Kibana ) sur gcp ( Google Cloud Platform ) en mode IAAS.

Pour ce faire, j'ai utilisé le shell, gcloud, ansible et terraform. Le pilotage de l'infrastructure peut se faire en mode manuel via une VM distante ou de manière automatisée sur Jenkins en mode conteneur ou sur Airflow. un ordonnanceur ( basique ).

En terme d'architecture, elle est virtualisée via des VM et repose sur des groupes d'instance pour la résilience et l'auto-scalabilité. Entre chaque groupe d'instance, des LB de niveau 4 permettent de gérer l'élasticité de l'infrastructure.

Elle est en mode streaming et non en mode batch, elle s'appuie sur un groupe d'instances logstash, chaque filtre de chaque instance effectuant des pull sur une queue pubsub en amont où les logs arrivent, l'objectif  de cette architecture étant de mettre en place un puit de logs à moyen terme.

Le coeur de l'architecture multi-environnment est un cluster elasticsearch, un groupe d'instance pour les master nodes et un groupe d'instance pour les data nodes. Par précaution, les data nodes ne sont pas auto-scalables, l'ajout ou la suppression des noeuds automatisés nécessitant une décision préliminaire. Contrairement à la partie cliente scalable classiquement sur la CPU ( logstash, kibana ), la partie data est délicate à scaler ( métrique, performance disque et réseau, gestion de la taille des data pour la suppression, ... ).

Les groupes d'instances sont régionaux. Ainsi, pour le groupe d'instances des data nodes, ils sont répartis au mieux sur trois zones ( = datacenters ) dans un périmètre acceptable pour la latence réseau, pour ma part, vu le client, on a opté pour la Belgique. Cette configuration permet d'assurer une HA de qualité.

En terme de disponibilité, si vous avez une VM qui plante suite par exemple à un problème kernel, oui, cela peut arriver, elle est immédiatement relancée.

Les datas sont visualisables via une ferme de VM Kibana. Elles sont disponibles au réseau extérieur de Google via un reverse proxy.

Par rapport à l'on-premise, on change de monde. Plus de machines à acheter et à attendre, plus de compétences réparties sur n équipes fonctionnant en mode silo, plus besoin de tailler les infras sur des pics, plus besoin de régler les pbs en envoyant un ticket d'incident à n équipes ... et je ne vous parle pas de la mise en production !

Reste la problématique du prix. Sur ce plan, on joue sur la taille des clusters. En dev, on a des clusters minimaux et non pas des mono-noeuds ( groupe d'instance à une VM et à deux pour les master nodes ) ce qui permet d'avoir de l'élasticité en fonction des besoins. On a aussi des environnements éphémères, merci au cloud car désormais, supprimer et recréer un cluster est automatisable ( pour ma part, c'est fait à 90%, mais on pourrait aller plus loin ).

Et puis, avis personnel, si on comptait enfin tous les coûts cachés d'une infra on-premise ... Suivant les usages, les contraintes, la confidentialité des données, ... cela prendra du temps mais on va droit vers un environnement hybride. La voie est tracée !

Pour être complet, un plugin gcp permet de gérer les snapshots sur un bucket, un agent stackdriver permet de monitorer les VM et il est possible de le compléter avec un agent applicatif pour le suivi du cluster elasticsearch. La brique Stackdriver permet aussi de créer des dashboards, un système d'alerte ...

Pour ceux qui souhaitent approfondir le sujet, voilà un bon point d'entrée: construction d'une infra elk via Terraform