Retour sur la KubeCon 2024

Comme toujours dans ce genre d’événement, la journée commence par une série de keynotes, dans l’immense salle “Paris Room” du 3ème étage, Hall 7.

D’emblée, le ton est donné, et tient en 2 lettres: I.A. ou A.I. au choix…

Keynotes du mercredi 20/03 😀

(Guillaume Audic, Julien Rateau, Benoit Touron)

Dans leur talk Accelerating AI Workloads with GPUs in Kubernetes, Kevin et Sanjay (NVIDIA) nous présentent les techniques et les défis à relever pour intégrer des GPU (et donc de l’IA) dans nos workloads sur Kubernetes. On notera par exemple la “DRA” (Dynamic Resource Allocation), sortie en alpha dans Kubernetes 1.27, permettant de gérer différents types de ressources (y compris des GPU) sur un modèle resource/claim (à la manière des PV/PVC qui nous sont déjà familiers). L’optimisation de la consommation des GPU sera possible grâce à une meilleure observabilité, l’optimisation du scheduler de Kubernetes (Bin packing), amélioration des sondes sur les nœuds Kubernetes pour vérifier l’état des GPUs.

Pour la troisième Keynote de la matinée Build an Open Source Platform for AI/ML, Jorge Palma (Microsoft) nous démontre qu’il est possible de “faire de l’IA” uniquement basée sur des composants Open Source, grâce par exemple à l’opérateur KAITO et à des modèles open source. L’enjeu pour la CNCF est de promouvoir un standard de déploiement et d’orchestration des modèles d’IA sur Kubernetes, comme cela a été le cas pour les workloads. La CNCF a donc ouvert un groupe de travail sur l’IA, afin de définir des bonnes pratiques et des patterns qui simplifieront les mises en production de ces modèles.

Ensuite, Leon et Yuzhui (Bloomberg) dans leur talk Platform Building Blocks: How to Build ML Infrastructure With CNCF projects nous présentent leur plateforme qui traite des milliards de données et des millions de documents en temps réel dans le but d’aider à la prise de décision sur les marchés financiers. Ils abordent d'abord le cycle de vie des données de Machine Learning jusqu’à leur mise en production. Puis, ils rentrent dans le vif du sujet avec une présentation de leur infrastructure, comprenant tous les outils utilisés ainsi que le rôle de chacun d’eux. Ils concluent avec une frise chronologique représentant les étapes de mise en place de leur solution, avec l’introduction de différents outils au fur et à mesure de leur avancée. Le très bon équilibre de cette conférence entre la présentation théorique de leur solution de Machine Learning et le niveau de détail de l’infrastructure en fait une de nos préférées.

Ressources

Accelerating AI Workloads with GPUs in Kubernetes : https://sched.co/1YhHx
Pour en savoir plus sur le DRA, regarder le talk DRAcon: Demystifying Dynamic Resource Allocation - from Myths to Facts (https://youtu.be/u7CktFEJbS8?si=ayKMR0tyR6hxRIBg)
How to Build ML Infrastructure with CNCF Project : https://sched.co/1YhJe
Platform Building Blocks: How to Build ML Infrastructure With CNCF projects https://sched.co/1YhIv

CoreDNS Plugins: A Deep Dive 😀

(Benoit Touron)

Nous connaissons tous CoreDNS, le serveur DNS interne de nos clusters. Mais saviez-vous qu'il peut être utilisé en dehors d'un cluster Kubernetes ? Et encore mieux, qu'il est possible d'étendre ses fonctionnalités ?
En prenant comme exemple le contrôle des requêtes DNS entre les namespaces, John et Yong Tang nous expliquent comment ajouter de nouvelles fonctionnalités à CoreDNS. Attention cependant, car cela nécessite de recompiler CoreDNS. On ne peut donc pas vraiment parler de "plugin", à mon avis… Cela dit, ce talk était très intéressant et bien mené.

https://sched.co/1YhfH

OpenTelemetry: project updates and next steps 🫤

(Laurent Al Hossri)

Conférence pour tenir au courant des évolutions de la solution, avec notamment le passage en GA (General Availability) de la solution core, ainsi que l'évolution des conventions sémantiques (HTTP passe en stable). Pas de passage en GA pour la partie Community, et un besoin constant d'aide pour faire évoluer la solution.

https://sched.co/1Yhf8

Self-Hosted LLMs on Kubernetes: A Practical Guide🤩

(Benoit Touron)

Hema et Aakanksha (Red Hat) nous expliquent concrètement comment déployer la puissance des LLMs sur votre propre cluster. Et non, on n'est pas obligés de recourir au cloud ou à des API propriétaires fermées !

Sélectionnez votre modèle Open Source (sur la plateforme hugging face https://huggingface.co/ proposant environ 400 000 modèles), transformez le en conteneur et utilisez Fast API https://github.com/tiangolo/fastapi pour l’opérer sur votre cluster, démo à l’appui.

https://sched.co/1YeMP

Crossplane Intro and Deep Dive - The Cloud Native Control Plane Framework 🤩

(Julien Rateau)

Créer une infrastructure sans utiliser de code directement depuis un cluster Kubernetes ? C'est la promesse que Jared et Philippe nous font et nous démontrent durant cette présentation. Les ressources managées sont exposées via une API depuis l'API Server de Kubernetes et la création de l'objet se base sur des fichiers YAML, comme toutes autres ressources Kubernetes.

https://sched.co/1Yhfi

Distributed AI: Using NATS.Io to Seamlessly Connect AI Applications from Cloud to Edge 🧡

(Benoit Touron)

Tomasz et Jeremy (Synadia) nous présentent NATS (https://nats.io/), qui permet de connecter ensemble tous les composants d’une solution (cluster dans le cloud, on prem ou équipements en Edge Computing). Principalement, NATS est un message broker complètement distribué, auquel on peut ajouter une couche de persistance grâce à JetStream (https://docs.nats.io/nats-concepts/jetstream).

Pour être dans le thème de l’IA, les speakers proposent une démo convaincante mettant en œuvre de la reconnaissance faciale, mélangeant du Cloud et du soft fonctionnant sur un PC directement sur la scène, illustrant une des applications possibles de NATS.

https://sched.co/1YhgF

Comparing Sidecar-Less Service Mesh from Cilium and Istio 😀🤔

(Benoit Touron)

J'ai apprécié l'introduction qui rappelle les concepts de base d'un service mesh, son utilité et ce qu'il apporte. Par la suite, Christian présente le concept de sidecar container et sa mise en œuvre dans l'implémentation d'un service mesh. Si vous souhaitez découvrir ces notions, c'est une très bonne introduction. La suite devient plus complexe, avec une comparaison en profondeur de deux service mesh : Cilium et Istio, utilisant tous deux eBPF pour fonctionner sans sidecar. Cette seconde partie est plutôt réservée aux spécialistes.

https://sched.co/1YeRx

Keynotes du jeudi 21/03 😀

(Benoit Touron)

Parmi les keynote de ce second jour, j’ai retenu Revolutionizing Cloud Native Architectures with WebAssembly. Cette technologie, déjà mise en avant lors de la précédente Kubecon à Amsterdam (https://youtu.be/bBZf23f_sVg) promet portabilité, performances exceptionnelles et empreinte mémoire réduite. La nouveauté ici, c’est l’utilisation de SpinKube (https://www.spinkube.dev/)pour déployer des workloads en WebAssembly sur votre cluster.

https://sched.co/1YhJM

We Tested and Compared 6 Database Operators. The Results are In! 🧡🧡🧡

(Guillaume Audic, Benoit Touron)

🚀Notre coup de cœur sur cette conf !🚀

Dès le début, Jérôme et Alexandre arrivent sur scène en costume de pirate. Le spectacle commence par une bataille au sabre et met en œuvre divers instruments, tels qu'une longue-vue…
Mais au-delà du spectacle, le fond est réellement intéressant. Il s'agit de comparer six opérateurs permettant de déployer des bases de données sur un cluster (trois pour MySQL ou MariaDB, trois pour PostgreSQL). Leurs forces et faiblesses sont analysées en détail : facilité d'installation et d'utilisation, backup/restore… Le tout basé sur leur expérience réelle de production, et noté à l'aide d'icônes Banane (cool), Tête de mort (moins cool) ou un mélange des deux (en amélioration par rapport aux versions précédentes). Si vous devez choisir une solution de base de données pour vos clusters, nous vous invitons vivement à regarder attentivement le talk. Nous regrettons peut-être que l'aspect performances n'ait pas été abordé.

https://sched.co/1YeO5

Stop Leaking Kubernetes Service Information via DNS! 🤩

(Benoit Touron)

🚀Super talk sur la sécurité !🚀

On ne sait pas toujours que le DNS de Kubernetes peut fournir des informations précieuses pour un attaquant, Jon et Yong Tan nous le prouvent, et la procédure est assez simple. En gros, on scanne les adresses IP internes du cluster (le DNS nous fournit gracieusement le CIDR), puis sur ces IP, on retrouve facilement les ports (le DNS nous les fournit également via les enregistrements de type SRV). Il ne reste plus qu’à trouver la bonne porte…
Une des solutions consiste à sécuriser le DNS via un plugin CoreDNS, dans la lignée du précédent talk CoreDNS Plugins: A Deep Dive.

https://sched.co/1YeOU

Misconfigurations in Helm Charts: How Far Are We from Automated Detection and Mitigation? 🤩

(Benoit Touron)

Ce talk de Francesco et Agathe, portant sur la vérification de nos charts Helm, s'est révélé très intéressant. Ils ont présenté plusieurs outils permettant de vérifier la conformité des charts Helm, dont Checkov, Datree, KICS, Kubelinter, Kubeaudit, Kubescape et Terrascan. Ces outils examinent si vos charts respectent les bonnes pratiques de sécurité, entre autres aspects.

Cependant, lorsque l'un de ces outils identifie une mauvaise pratique, comme un conteneur disposant de privilèges excessifs, comment procéder à la correction sans provoquer de dommages collatéraux ? Agathe a proposé une méthodologie pour automatiser les phases d'analyse, de test et de correction dans un processus d'intégration continue (CI).

https://sched.co/1YeOu

Why Barricade the Door if the Window Is Open? Making Sense of Kubernetes Initial Access Vectors 😀

(Benoit Touron)

Pensez-vous être parfaitement protégé derrière votre RBAC ? Il se pourrait que ce ne soit pas entièrement le cas, et Shay nous en apporte la preuve en examinant les failles de sécurité les plus répandues : fuites de vos kubeconfig, accès non autorisé à l’API Kubelet, images malveillantes… Ce sujet a déjà été abordé lors de la KubeCon 2023, dans le cadre du talk Hacking and Defending Kubernetes Clusters: We'll Do It LIVE!!!. Si vous trouvez ce sujet intéressant (et vous devriez !), ces deux présentations se complètent bien.

Ressources

Vidéo (Kubecon 2023): https://youtu.be/J3pS-XBdNpU?si=j9dl07b3RvH6vFnh
https://sched.co/1YePj

Building a Tool to Debug Minimal Container Images in Kubernetes, Docker and ContainerD 🫤

(Benoit Touron)

🚀Attention : voici du contenu technique avancé ! 🚀

La tendance actuelle est aux images « distroless ». D'un point de vue sécurité et empreinte disque, c'est avantageux. Cependant, le débogage de ce type d'images peut s'avérer complexe…
Kyle et Saiyam nous proposent une solution quelque peu "hacky" pour surmonter ces difficultés. En bonus, découvrez un lien vers une vidéo similaire issue de la précédente KubeCon.

https://sched.co/1YeS7

Ressources

Vidéo (Kubecon 2023): https://kccnceu2023.sched.com/event/1HycC

GitOps Continuous Delivery at Scale with Flux 🤩

(Guillaume Audic)

En février dernier, après avoir appris que la société Weaveworks (principal contributeur) fermait ses portes, je me suis beaucoup interrogé sur l’avenir du produit FluxCD, un outil que j’apprécie particulièrement.

Ce talk m’a rassuré quant à l’avenir de Flux. La feuille de route est claire, de nombreuses APIs passeront en GA (General Availability) en 2024, et de nouvelles fonctionnalités sont annoncées, telles que la vérification des signatures des artefacts avec Notary et le support des OCI repositories pour les Helm Release par Flux 2.3. Il est à noter que le projet FluxCD a trouvé du soutien auprès d’entreprises telles que ControlPlane, Orange, Microsoft, etc., assurant ainsi une longue vie à FluxCD. https://www.cncf.io/announcements/2024/03/19/cloud-native-computing-foundations-fluxcd-project-gains-new-corporate-support/

Cela dit, je vous ai parlé des éléments qui m’ont rassuré, mais ce n’était pas le cœur du talk. Stefan Prodan a évoqué différentes stratégies pour déployer Flux à grande échelle, en présentant plusieurs modes d’optimisation. Voici les points clés, à implémenter dans cet ordre pour éviter une complexité inutile :

Optimisations des sources et ajustement fin des contrôleurs :
- Migrer vos Helm Releases vers des OCI repositories pour améliorer les performances, car le stockage de nombreuses versions dans vos dépôts Helm HTTP/S peut les affecter.
- Utiliser un dépôt Git dédié pour éviter de récupérer tout l’historique du dépôt applicatif.
- Segmenter vos ressources Kubernetes en plusieurs Kustomizations Flux pour bénéficier de réconciliations concurrentes.
Mise à l'échelle verticale :
- Augmenter les limites CPU & mémoire de vos controllers
- Augmenter les réconciliations concurrentes sur les controllers
- Monitorer votre API Kubernetes, car augmenter vos réconciliations peut engendrer des erreurs dues au rate-limit de l’API.
Mise à l'échelle horizontale :
- À utiliser en dernier recours car cela complexifie votre architecture Flux.
- L'idée est de réaliser du sharding et de déployer les contrôleurs à plusieurs reprises. Chaque instance aura un sélecteur d'étiquettes unique utilisé comme clé de sharding.

Je vous laisserais aussi consulter le benchmark https://github.com/fluxcd/flux-benchmark/blob/main/RESULTS.md qui a été réalisé sur le temps de réconciliation suivant le type de ressources utilisées. Les performances sont au rendez-vous.

https://sched.co/1YhhG

Container Image Workflows at Scale with Buildpacks 😀

(Julien Rateau)

Dans ce talk, Juan Bustamante (Broadcom) et Aidan Delaney (Bloomberg) se sont donnés pour objectif de nous présenter les Buildpacks, un outil permettant de construire des images Docker sans Dockerfile. Ils débutent par une présentation théorique de l'outil et de la structure d'un projet utilisant les Buildpacks. Ils expliquent que l'outil exécute plusieurs phases avant de créer l'image :

Analyzer : lit les métadonnées de l'image précédente et assure l'accès au registre.
Detector : sélectionne les buildpacks (via /bin/detect) et produit un plan de build.
Restorer : restaure les métadonnées des couches de l'image précédente et du cache, ainsi que les couches mises en cache.
Builder : exécute les buildpacks (via /bin/build).
Exporter : crée une image et met en cache les couches.

Une information particulièrement intéressante est que les Buildpacks sont capables, dès la phase de build, de lancer la commande d'installation des dépendances en scannant le répertoire approprié et en récupérant le contenu du fichier les listant (comme le requirements.txt en Python) sans qu'il soit nécessaire de le spécifier explicitement. Une fonctionnalité remarquable de l'outil est sa capacité à supprimer rapidement et de manière transparente un layer présentant une CVE, de toutes les images le contenant, ce que j'ai trouvé à la fois remarquable et très utile.

La présentation s'est poursuivie avec une démonstration où ils ont construit la même image pour deux architectures différentes (arm64 et amd64).

En conclusion, une allusion a été faite à kpack, une extension sur Kubernetes permettant de construire des images OCI directement depuis un cluster.

https://sched.co/1Yhj6

Keynotes du vendredi 22/03🫤

(Benoit Touron)

Pour cette dernière série de Keynotes, j’ai bien apprécié la présentation de Solomon Hykes (le créateur de Docker): A 10-year Detour: The Future of Application Delivery in a Containerized World, dans laquelle il nous raconte son histoire.

https://sched.co/1YhKQ

Building Container Images the Modern Way 🤩

(Benoit Touron)

La construction d'images de conteneurs ne se fait plus aujourd'hui comme elle se faisait hier. Ce talk fascinant présente plusieurs outils et techniques pour optimiser la création de nos images.
Nous partons d'un Dockerfile traditionnel, tel qu'on aurait pu l'écrire il y a dix ans, pour passer ensuite à une première optimisation avec une version multi-étapes, comme on l'aurait faite il y a cinq ans.

Adrian nous introduit alors à une série d'outils destinés à optimiser et automatiser la construction de nos images. Parmi eux, KO Build, Bazel build, Apko, et NixOS se distinguent (quatre méthodes différentes, toutes aussi complexes les unes que les autres), sans oublier la combinaison de BuildKit et Dagger, entre autres. Pour une exploration complète de ces outils et techniques, je vous recommande de regarder la vidéo !

https://sched.co/1YeRB

What's New with Kubectl and Kustomize … and How You Can Help! 😀

(Damien Morellet)

Lors du dernier créneau de cette KubeCon 2024, j'ai assisté à la conférence de deux responsables techniques du SIG (Special Interest Group) des projets CLI de Kubernetes. Ils ont dressé un bilan des mises à jour passées et à venir de ces outils, partageant quelques anecdotes sur les choix effectués à l'époque concernant l'ergonomie de l'emblématique interface de commande kubectl, et expliquant la complexité de la mise à jour de ces outils.

Il est fascinant de voir comment ces outils évoluent, du point de vue de leurs créateurs.

Découvrez notre article de la KubeCon 2023 juste ici : https://www.sfeir.dev/cloud/les-5-choses-a-retenir-de-la-kubecon-cloudnativecon-europe-2023/

Retrouvez tous les résumés officiels, vidéos et slides sur https://kccnceu2024.sched.com/.

À noter qu'ils proposent ce type de présentation à chaque KubeCon !