Introduction#
J’ai eu la possibilité, cette année, grâce à mon entreprise SFEIR, d’aller à la KubeCon 2022 à Valence en Espagne pour suivre trois jours de conférence sur place mais aussi voir les stands des partenaires dans l’optique de discuter, découvrir de nouvelles solutions, outils, etc.
Cette conférence est très spécialisée sur la conteneurisation, l’orchestration avec Kubernetes et tout ce qui gravite autour du Cloud Native.
Dans les présentations, les produits présentés sont associés à la Cloud Native Computing Foundation (CNCF).
Le but de cet article est de vous partager les conférences auxquelles j’ai assisté avec une présentation assez succincte des différents concepts abordés.
De plus, j’ai ajouté le lien qui permet de regarder la présentation et de télécharger le contenu au format PDF.
Deux annonces ont été faites durant la première Keynote :
- La KubeCon 2023 sera à Amsterdam ;
- Une certification Prometheus Associate va prochainement être disponible (elle est actuellement en Beta).
Les conférences#
Multi-cluster Failover Using Linkerd par Charles Pretzer (Buoyant, Inc)#
Lien pour visualiser le contenu de la conférence
Cette première conférence présente, dans un premier temps, le produit Linkerd, un service mesh pour Kubernetes développé en Rust, assez simple et rapide à mettre en oeuvre avec notamment la mise en place du mTLS (mutual TLS).
L’objectif de cette présentation était de faire découvrir une installation de Linkerd avec deux clusters (west
et east
) que vous pouvez retrouver ici avec l’ensemble des lignes de commande à exécuter via la documentation pour réaliser ça chez vous.
Il y a un eu aussi l’utilisation du plugin viz pour tout ce qui concerne les métriques avec Prometheus et les tableaux de bord avec Grafana permettant la visualisation de tout ce qui se passe avec Linkerd.
J’ai trouvé le contenu très intéressant pour montrer la facilité d’installation de Linkerd même dans un cas d’utilisation avancée.
Falco to Pluginfinity and Beyond par Leonardo Grasso et Jason Dellaluce (Sysdig)#
Lien pour visualiser le contenu de la conférence
Falco est l’outil de sécurité qui permet de détecter les menaces au sein de Kubernetes que beaucoup découvre avec la certification CKS.
La version de Falco 0.30 est sorti fin septembre, début octobre 2020 avec un nouveau rythme de trois versions majeures par an. Ces mises à jour permettent à l’outil de s’enrichir et de détecter de nouveaux appels système critiques (syscalls).
Cette présentation met en lumière le mode plugin de Falco où il sera possible d’avoir d’autres sources de données que les logs d’un cluster Kubernetes comme par exemple CloudTrail d’AWS. Ces plugins peuvent être développés par la communauté en Go pour le moment.
Vous pouvez retrouver les différents plugins ici. La version 0.31 de Falco est nécessaire pour les utiliser.
Falco devient une solution de plus en plus personnalisable et élargit les sources de données pour détecter les menaces.
Confidential Containers Explained par James Magowan (IBM) et Samuel Ortiz (Apple)#
Lien pour visualiser le contenu de la conférence
Cette présentation explique le but des Confidential Containers pour protéger leur exécution et les données qui leur sont associées.
Le projet est au stade de sandbox côté CNCF.
Le but de cette démarche est que chaque Pod dispose d’une enclave sécurisée où la plupart des paramètres comme la mémoire, les données ou le code sont chiffrés où un service extérieur atteste de la bonne conformité de l’enclave.
Cela permet d’exécuter des charges de travail particulièrement sensibles sur Kubernetes, voire de les migrer sur le Cloud public si ce dernier supporte le confidential computing.
Cette présentation permet de démontrer qu’exécuter des ressources sensibles sur un cluster Kubernetes est totalement possible quel que soit le lieu de déploiement du cluster.
Prow! Leveraging Developer-Centric CI for Your OSS Project! par Nabarun Pal (VMware) et Arsh Sharma (Okteto)#
Lien pour visualiser le contenu de la conférence
Prow est un outil Kubernetes de CI/CD en mode chat-ops qui permet entre autre d’interagir avec une Pull Request de Github (relancer des tests, fusionner automatiquement, etc.).
Prow est utilisé par beaucoup de projets CNCF comme Kubernetes. Le but de cette présentation était de présenter les différents composants de Prow afin d’encourager d’autres projets à l’utiliser.
Comme le montre l’image ci-dessus, Prow se compose de différents composants :
- Plank est un opérateur Kubernetes qui va venir créer des Pod dans un cluster Kubernetes associé à une tâche à exécuter par Prow ;
- Sinker va venir supprimer au fur et à mesure les tâches Prow terminé depuis deux jours ;
- Crier va notifier Github en fonction des différents status des tâches Prow ;
- Horologium exécute les tâches Prow récurrentes ;
- Deck est l’interface utilisateur où il est possible de voir les tâches récentes au sein de Prow.
De plus, tide permet de définir un certain nombre de critères qui permettront à une Pull Request d’être fusionnée ou non sans interaction humaine.
Enfin, pour déployer sa propre instance, il est possible d’utiliser l’outil tackle
comme décrit dans la documentation.
Je trouve cet outil intéressant surtout avec les commandes que l’on peut exécuter dans chaque Pull Request via les commentaires.
Building a Nodeless Kubernetes Platform par William Denniss (Google Cloud)#
Lien pour visualiser le contenu de la conférence
Dans cette présentation, William Denniss explique la mise en place du service GKE autopilot qui est un service GKE sans noeud ni machine virtuelle attitrée, mais qui facture uniquement les objets Kubernetes créés.
Cela inclut quelques limitations quant à l’exécution des Pod ou d’autres objets, c’était aussi l’occasion de les découvrir :
Comme vous pouvez le voir sur la photo du dessus, plusieurs limites peuvent avoir des conséquences sur certaines ressources Kubernetes car on perd l’utilisation de noeuds “personnels”.
L’utilisation de GKE autopilot est, à mon avis, très séduisante surtout grâce à la facturation du service qui est très différente d’un GKE dit “standard”.
Operating Prometheus in a Serverless World par Colin Douch (Cloudflare)#
Lien pour visualiser le contenu de la conférence
Prometheus, l’outil de supervision que l’on ne présente plus est capable aussi de s’intégrer dans un monde serverless où les contraintes sont parfois multiples : peu de temps d’exécution, création et suppression de ressources très fréquente, etc.
Colin Douch explique comment palier à ces contraintes avec l’utilisation de la Gravel Gateway qui permet d’agréger des métriques entre elles.
Cette présentation met en évidence comment éviter les limitations du monde serverless et d’utiliser Prometheus quel que soit le type de ressource. Si vous souhaitez plus d’informations sur la solution, je vous recommande de regarder l’article de blog du même auteur.
How to Migrate 700 Kubernetes Clusters to Cluster API with Zero Downtime par Tobias Giese et Sean Schneeweiss (Mercedes-Benz Tech Innovation)#
Lien pour visualiser le contenu de la conférence
Tobias et Sean présentent un retour d’expérience par rapport à leur migration de clusters Kubernetes au sein de Mercedes en utilisant les Cluster API.
Cela passe par la création de plusieurs composants intermédiaires pour réaliser leur migration. Plusieurs choses sont à prendre en considération lors de ce type de migration :
Ce retour d’expérience était très intéressant et permet de se faire une idée de l’ensemble des étapes à réaliser pour effectuer ce type de migration sur un nombre de clusters aussi large.
Alerting in the Prometheus Ecosystem: The Past, Present and Future par Josue (Josh) Abreu (Grafana Labs)#
Lien pour visualiser le contenu de la conférence
Josue Abreu explique dans cette présentation les différentes étapes des projets qui gravitent autour de Prometheus où la communauté est fortement impliquée pour faire évoluer le produit avec plusieurs ajouts comme par exemple : ne pas être alerté certains jours de la semaine ou avoir plusieurs alertes par graphiques au sein de Grafana.
Enfin, certaines fonctionnalités arriveront plus tard comme par exemple le fait de pouvoir tester la configuration des receivers sans déclencher d’alertes.
Cette présentation, moins technique que les autres, présente un état de l’art du produit et de son évolution à travers le temps grâce à la communauté et le retour des utilisateurs.
Prometheus Sparse High-Resolution Histograms in Action par Ganesh Vernekar (Grafana Labs)#
Lien pour visualiser le contenu de la conférence
Cette présentation permet de se rendre compte du changement qui a été effectué au sein de Prometheus pour stocker les histogrammes où généralement les compartiments contenant les données (buckets) sont prédéfinis et ne peuvent être modifiés.
Il est évidemment possible de faire toute sorte d’opérations arithmétiques avec ce nouveau format. Prometheus utilise récupère les valeurs des histogrammes sur un nouveau point de terminaison en HTTP Proto Buf.
Cela permet de comprendre en profondeur la manipulation des histogrammes au sein de Prometheus et les différentes évolutions qui ont conduit à ce changement.
Show Me Your Labels and I’ll Tell You Who You Are par Sandor Guba (Cisco)#
Lien pour visualiser le contenu de la conférence
Sandor Guba développe ici le sujet des labels au sein d’un cluster Kubernetes en utilisant le Logging Operator en utilisation la fonctionnalité de restreindre les accès via les RBAC et un service account pour authentifier la personne.
Cette solution utilise fluentbit pour récolter les logs, permet de les router et de choisir différentes sorties : S3, ElasticSearch, etc.
Cette présentation a notamment pour but de donner encore plus d’importance aux labels et de les rendre encore plus indispensables.
Conclusion#
Cette KubeCon était très riche en informations que ce soit au niveau des Keynotes ou des présentations. Cela m’a permis de discuter avec différents interlocuteurs et d’échanger sur plusieurs thématiques : sécurité, supervision, gestion des logs, etc.
L’ambiance était aussi au rendez-vous avec une multitude de passionnés venus du monde entier pour apprendre et partager.
J’ai tout de même trouvé que certains sujets étaient abordés de manière trop théorique et qu’une démonstration aurait permis de rendre le contenu plus facile d’accès.
Pour finir, je suis revenu avec l’envie de tester plusieurs outils qui feront sûrement l’objet de prochains articles. :)