1. Introduction
Le 7 mars 2023, s’est tenue au centre Pompidou, la première édition du Kubernetes Community Days France. Il s’agit d’une journée dédiée aux conférences sur le thème des technologies cloud native et au DevOps. Bien évidemment, dès l’annonce de cet événement, nous avons décidé chez Cockpit io d’y participer. Et la file d’attente impressionnante dès huit heures du matin montrait que l’événement était attendu et suscitait une vraie émulation au sein de la communauté cloud en France.
Dans cet article, nous allons faire le tour d’horizon des nombreuses conférences auxquelles nous avons assisté.
2. Keynote d’ouverture
Pour cette première édition, qui de mieux pour lancer la keynote d’ouverture que Solomon Hykes, créateur de Docker et Jérôme Petazzoni, un des premiers à rejoindre l’aventure Docker, où il est resté 7 ans et qui est référence dans le monde de la conteneurisation et de Kubernetes. La symbolique était forte. Et pour de nombreuses personnes, Solomon a révolutionné le monde de l’informatique et a changé le cours de leurs vies professionnelles.
Le mot de départ a été donné par Jérôme, qui nous a partagé son ressenti sur la communauté Kubernetes qu’il trouve inclusive. Il nous a également présenté l’événement et son organisation.
Ensuite, Solomon l’a rejoint, et il nous a fait un bref historique sur Docker et son avis sur l’avenir de Kubernetes. Il nous a parlé aussi des tendances du moment qu’il voyait : l’intelligence artificielle de manière générale.
Solomon a conclu son intervention par une présentation de Dagger. Dagger est un outil de CI/CD portable, qui permet de lancer et de tester ses pipelines dès le poste de développement. Cela fait quelque temps que nous le suivions de près. Au départ, l’un des reproches que nous lui faisions, c’était l’obligation de passer par Cue, un langage de configuration, qui rendait le ticket d’entrée un peu élevé. Cependant, aujourd’hui, plusieurs SDK permettent d’utiliser un autre langage pour définir ses pipelines (Go, Python, TypeScript, JavaScript et GraphQL). Cette barrière étant tombée, l’outil gagne encore plus en intérêt.
Par la suite, plusieurs sponsors se sont succédé. Parmi eux, le ministère de l’Éducation nationale qui nous a présenté un retour d’expérience sur son utilisation de Kubernetes. Montrant que les acteurs du secteur public, ne sont pas en reste en ce qui concerne les technologies cloud native.
3. Construire des images Docker sur Kubernetes : un long voyage !
Cette conférence a été présentée par Laurent Bernaille et Mayeul Blanzat de chez Datadog. Elle portait sur un sujet ô combien important : La construction d’images Docker dans les pipelines de CI/CD (sur un cluster Kubernetes) et la sécurité.
Il est fréquent de construire des images Docker dans un pipeline de CI/CD en utilisant le pattern Docker in Docker. Ce pattern nécessite le mode priviliged qui est connu pour représenter un risque de sécurité.
L’approche qui a été présentée par les deux intervenants consistait en l’utilisation de rootless containers, avec buildkitd. Cette approche permet, grâce aux User namespaces (désactivés par défaut par Docker), d’obtenir une isolation des utilisateurs système à l’intérieur des conteneurs. Autrement dit, nous pouvons faire en sorte que les utilisateurs à l’intérieur d’un conteneur, et notamment l’utilisateur root, soient différents des utilisateurs de la machine hôte. Ce qui n’est pas le cas par défaut. Cette approche permet donc de sécuriser la construction des images Docker.
Même si le retour d’expérience des intervenants est globalement positif, ils nous ont tout de même fait part de quelques problèmes rencontrés. Parmi ces problèmes, on retrouve des problèmes très bas niveau. Par exemple, ils ont rencontré un problème de timeout après une simple commande dpkg. Pire, sur le build suivant le timeout, ils ont rencontré une erreur indiquant qu’un port est déjà en cours d’utilisation. Après avoir creusé, ils ont fini par trouver que le /proc, pour des raisons de sécurité, n’est pas monté de façon intégrale dans les conteneurs. Une partie du /proc est soit en read only, soit masquée. Il se trouve que la commande dpkg lançait un daemon. Une solution de contournement qu’ils nous ont présenté était tout simplement de faire en sorte qu’aucun daemon ne soit lancé, et si c’est le cas, le stopper. Néanmoins, ils ont ouvert une issue sur GitHub afin de remonter et de résoudre le problème à l’avenir.
Il y a eu également d’autres soucis présentés : des problèmes liés à SELinux et d’autres liés à des dysfonctionnements au niveau de Overlayfs qui produisaient des comportements étranges après deux simples git clone. À chaque problème, ils nous ont présenté des solutions de contournement, ainsi que les issues sur GitHub ouvertes à ce sujet.
Pour notre part, nous avons exploré et mis en place une solution permettant de faire du Docker in Docker tout en évitant de mettre le mode privileged avec l’outil Sysbox. Cette approche basée sur buildkitd est très clairement une piste alternative très intéressante pour nous.
Merci aux intervenants pour cette conférence !
4. Rendre hautement disponible des milliers d’ingresses sur des clusters Kubernetes indépendants
Ce retour d’expérience partagé par Solvik Blum et Laurent Marchaud de Numberly n’était initialement pas prévu. Mais ce talk fut une bonne surprise et nous l’avons trouvé très intéressant. Solvik et Laurent nous ont d’abord parlé de leur infrastructure : architecture en multiclusters Kubernetes, situés dans des zones géographiques différentes. Ces clusters sont redondés en actif-actif, avec une IP anycast, qui redirige le flux de manière efficiente.
Dans leur contexte, le besoin est le suivant : Comment load-balancer les ingresses dans cette architecture en mutliclusters pour assurer une haute disponibilité des services ? Pour répondre à ce besoin, ils ont opté pour Yggdrasil, projet open source qui répond à beaucoup de leurs attentes.
Yggdrasil est un control plan qui permet de disposer d’un cluster Envoy qui agit comme un load balancer multiclusters pour Kubernetes. Permettant de rendre hautement disponible les applications même en cas de perte d’un cluster entier.
Comment cela fonctionne-t-il ? Yggdrasil va surveiller tous les Ingresses sur chaque cluster Kubernetes qu’on lui aura renseigné via les Kubeconfig flag. Et chaque Ingress détecté va avoir un listener. Dans le cas où il y a plusieurs clusters Kubernetes, chacun se verra attribuer une adresse.
Point intéressant, Numberly a fait le choix de contacter directement le maintainer du projet afin de lui proposer de contribuer à ce projet très intéressant et qui répondait à leurs besoins en grande partie. C’est un bel exemple d’une entreprise qui profite d’un projet open source et qui rend à la communauté en contribuant pour développer de nouvelles fonctionnalités ou pour améliorer l’existant.
Merci aux intervenants pour cette conférence !
5. Révolution eBPF : Un noyau Linux dynamique
Salle comble pour cette conférence donnée par Raphaël Pinson qui nous a parlé d’eBPF, sujet extrêmement intéressant et qui a le vent en poupe depuis quelques années.
Raphaël nous a d’abord présenté eBPF (pour Extended Berkeley Packet Filter), technologie qui nous permet d’étendre les fonctionnalités du noyau, de manière efficace et sécurisée, en se basant sur les événements sans devoir modifier son code source. Réseau, observabilité et sécurité sont autant de domaines qui peuvent en bénéficier.
Lors de ce talk, il nous a présenté des exemples d’utilisation : nous y apprenons, par exemple, qu’eBPF est utilisé sur les téléphones Android pour suivre l’utilisation réseau ou mémoire. Ou dans le domaine réseau où eBPF peut servir pour se prémunir des attaques DDOS, en dropant les paquets sur la carte réseau directement. Il est également possible d’utiliser eBPF pour tuer les process dès le déclenchement et avant même leur exécution.
Nous avons également eu plusieurs exemples d’outils basés sur eBPF :
- Cilium : CNI Kubernetes
- Tetragon : Composant Cilium d’observabilité et de sécurité
- Hubble : Composant d’observabilité
eBPF est désormais proposé en option par les principaux fournisseurs cloud.
Il est difficile de résumer ce talk très riche, mais une chose est certaine, la conférence est excellente et le sujet vaut le coup d’être creusé, pour celles et ceux qui hésitent. Un grand bravo à l’orateur !
6. Sécurisez votre software supply chain avec SLSA, Sigstore et Kyverno
Nous avons assisté à une autre conférence sur le thème de la sécurisation de la supply chain, présentée par Mohamed Abdennebi de la société Sfeir.
Mohamed a commencé par nous montrer que les attaques sur les supply chain ont considérablement augmentées depuis quelques années. Il cite des attaques de type dependency confusion ou encore de type typosquatting. Un des moyens de s’en prémunir est de vérifier la provenance des packages. Pour y parvenir, il nous a présenté SLSA (Security Levels for Software Artifacts), projet de l’OpenSSF (Open Source Security Foundation), permettant de garantir l’intégrité de la supply chain.
Il nous a présenté, d’une part, les attestations permettant d’indiquer la provenance d’un package (incluant le moteur de CI ayant buildé le package). D’autre part, les règles de sécurité (il a insisté sur le fait que les règles sont progressives, ce qui permet de les adopter plus facilement et de les renforcer au fil de l’eau).
La présentation théorique a laissé place à une démonstration durant laquelle nous avons pu voir l’outil Sigstore, dont le fonctionnement est très inspiré de Let’s Encrypt, mais pour les packages.
L’objectif est de permettre de signer des packages, afin que leurs provenances puissent être vérifiées par les utilisateurs. Nous avons également pu voir d’autres outils :
- Cosign, qui permet de signer facilement un package,
- Fulcio, qui est une CA permettant de délivrer des certificats
- Rekor, qui permet de faire du Transparency Log sur les certificats.
La signature se fait de façon keyless, avec notamment une clef privée temporaire et un certificat d’une durée de vie très réduite, permettant ainsi de ne pas gérer la révocation des certificats.
Lors de la démonstration, il a commencé par construire et signer une image Docker localement. Il a ensuite construit et signé une image Docker dans un pipeline de CI/CD. Il nous a également exposé la possibilité d’utiliser Kyverno dans un cluster Kubernetes pour n’autoriser que les images signées,
Pour notre part, nous trouvons l’approche intéressante pour un problème commun. Nous pensons tout de même qu’il faut prendre en compte le coût de la mise en place d’une telle approche. Le fait de pouvoir mettre des règles de façon progressive est très bénéfique pour permettre une adoption progressive.
Quoi qu’il en soit, merci pour la présentation !
7. L’enfer des DB SQL sur Kubernetes face à la promesse des opérateurs
La salle “Bleu” était pleine pour assister à la présentation, sous le thème des pirates (mention spéciale aux costumes), de David Donchez et Alexandre Buisine de la société Enix. Lors de ce talk, ils nous ont partagé leurs retours d’expérience concernant les opérateurs de bases de données Kubernetes avec un comparatif selon plusieurs critères comme l’installation ou le monitoring.
David et Alexandre ont d’abord comparé les opérateurs sur l’installation : un des critères de comparaison et de sélection est la possibilité de personnaliser l’installation et la configuration. Il est important de pouvoir le faire pour éviter que les ops ne se connectent aux bases de données pour le faire. D’autres opérateurs possèdent une interface graphique ou encore un plugin kubectl comme c’est le cas de Moco
Sur le point de la haute disponibilité, le défi de pouvoir remplacer des instances de bases de données en toute sécurité de façon automatique ou manuelle. Sur ce point, les grands gagnants sont ceux basés sur Patroni et ceux ayant nativement des fonctionnalités de switchover comme CNPG ou Moco.
Du point de vue monitoring, les critères de qualité qu’ont choisi les équipes d’Enix sont l’intégration avec Prometheus, les métriques de haut niveau et les statuts. Encore une fois, ce sont les mêmes opérateurs qui remportent la manche.
Le dernier point vital dans l’exploitation des bases de données, est bien évidemment la gestion des sauvegardes et des restaurations. Ici, nous apprenons que certains opérateurs permettent l’archivage sur S3 ou sur un PVC et le Point-in-time recovery. Sur cette dernière fonctionnalité, il faut néanmoins se méfier de la durée de rétention des sauvegardes qui, lorsqu’elle est trop grande, peut rapidement saturer le stockage. Il faut dont faire attention aux paramètres par défaut. Ensuite, les stratégies de restauration sont diverses et vont surtout dépendre de l’urgence et du niveau de granularité souhaité (restaurer une table ou une base de données entière …).
Enfin, les équipes d’Enix nous ont exposé les gains obtenus grâce aux opérateurs SQL qui sont le fait d’éviter les erreurs de configuration, l’automatisation, les gains de productivité dans la gestion des Ops et l’autonomie des utilisateurs.
Une conférence très intéressante qui a levé en partie les craintes que peuvent avoir certaines personnes sur le déploiement de bases de données SQL sur un cluster Kubernetes.
Merci aux pirates pour cette présentation !
8. RIK, un orchestrateur de conteneurs en Rust
Cette conférence, présentée par Hugo Amalric chez NetExplorer et Thomas Gouveia chez IoTerop, portait sur un projet d’étude durant leur cursus : l’implémentation, en équipe, d’un orchestrateur de conteneurs en Rust, nommé RIK (Rust in Kubernetes).
Ils nous ont présenté l’architecture, contenant une CLI pour manipuler le cluster. Cette CLI communiquait initialement avec les master nodes en HTTP. Ensuite, ils ont opté pour le protocole gRPC pour la communication entre les composants internes.
Comme pour Kubernetes, leur orchestrateur dispose d’un scheduler, permettant de positionner les workloads dans les différents nœuds worker. Ils ont implémenté un agent, qu’ils ont nommé RIKLET (comme Kubelet) dans les nœuds worker permettant de répondre aux demandes du nœud master. Ils n’ont toutefois pas implémenté de composant pour la partie network (à l’instar de kube-proxy). Ils s’appuient également sur des solutions existantes pour le runtime des conteneurs. Cette présentation théorique a fait place à une démonstration de RIK, en déployant notamment une image Docker.
La suite de la conférence a porté sur les difficultés qu’ils ont rencontrées pendant le projet : difficultés liées au langage Rust, challenges au niveau de la gestion projet, et de la coordination des équipes. Enfin, ils nous ont partagé leur prise de conscience sur l’importance de la documentation et des tests.
La fin de la présentation a porté sur les axes d’amélioration possibles de cet orchestrateur. Ils ont été clairs, ils ne souhaitent pas concurrencer Kubernetes. Néanmoins, ce projet étant enrichissant pour eux, ils souhaitent y apporter des améliorations et les partager. Si le projet vous intéresse, le repository Github est ici. Quoi qu’il en soit, bravo à eux pour leur travail et merci pour la présentation !
9. Kubernetes the not so hard Veepee way
Pour cette conférence, Loïc Blot et Michaël Todorovic de chez Veepee nous parle de la naissance de leur projet Starfish : un projet Container as a Service dont l’objectif est d’améliorer l’expérience des équipes de développement et de réduire le Time to Market. Ce retour d’expérience ne pouvait qu’être intéressant dans ce contexte à très forte volumétrie au sein de cette entreprise qui doit gérer des services à très fort trafic et dont le nombre d’applications dépassent les 500.
Le talk commence par rappeler la genèse du projet : Une vente exceptionnelle de billets en 2019 pour un concert de Céline DION. À ce moment-là, plusieurs orchestrateurs étaient utilisés : Nomad, Docker Swarm, Rancher 1 et 2, Kubernetes legacy… Autant dire, que l’infrastructure était très hétérogène dans un contexte on premise.
La première étape était la mise en place d’un namespace controller qui permettait de relier l’Account ID et le namespace. Ce fut là la naissance du Kubernetes Namespace as a Service (KNaaS).
S’ensuivit une phase durant laquelle ils ont construit un ensemble de briques au-dessus de Kubernetes. Ce fut là l’évolution du modèle KNaaS vers le modèle CaaS (Container as a Service).
Les objectifs du CaaS dans le contexte technique de Veepee sont :
- Minimiser le Time to Market
- Fournir aux équipes de développement une meilleure expérience
- Standardiser les usages et les outils
- Abstraire les API Kubernetes pour les équipes de développement.
Ils nous ont ensuite parlé des deux solutions envisagées d’abord pour déployer les Helm Charts :
- Construire un PaaS : Manque de flexibilité et demande beaucoup de ressources pour maintenir cette solution.
- Déployer depuis les pipelines de CI/CD : solution compliquée à maintenir et risquée, car cela veut dire que des identifiants Kubernetes doivent trainer sur GitLab.
C’est deux options présentent plusieurs limitations d’après eux :
- Limite le type de déploiement à un seul
- Ne gère pas le monorepository
- Rend l’onboarding difficile
Parmi les améliorations qu’ils nous ont présentées :
- Adoption du GitOps, notamment avec l’utilisation d’Argo CD
- Un contrôleur de namespaces pour faire le lien entre Argo et le namespace
- Vault web hook pour les secrets
- Exporter pour savoir quand les certificats SSL vont expirer dans Kubernetes
Suite à cela, un autre objectif a émergé : comment abstraire Kubernetes chez les équipes de développement ? Pour répondre à ce besoin, ils ont construit le projet Starfish, qui est un projet développé en Go qui fournit de la documentation et des workflows par défaut aux équipes.
Parmi les autres outils utilisés cités :
- [Gatekeeper] (https://github.com/open-policy-agent/gatekeeper)
- [Kube-router] (https://www.kube-router.io/)
Bravo à eux pour cette excellente présentation !
10. OpenTelemetry, JavaScript et tracing distribué : Un jour, j’irai vivre en Théorie, car en Théorie tout se passe bien
Présenté par Sonia Seddiki, ce retour d’expérience revient sur la mise en place du tracing avec le standard OpenTelemetry chez Pitchy.
Tout part d’une mise en production de modification cosmétique du code qui, contre toute attente, entraine une indisponibilité des services. En cause, une saturation de disque et surtout un processus qui crashe sans être repéré. Processus non essentiel au fonctionnement de l’application, mais essentiel à son déploiement. La question se pose alors de trouver un moyen d’avoir une visibilité sur tous les événements qui se produisent. La réponse à ce besoin est le tracing.
Le standard OpenTelemetry permet l’export de traces, métriques et logs et offre des fonctionnalités de corrélation entre ces informations. Dans le cas de Pitchy, le premier objectif est déjà de faire fonctionner le tracing en instrumentant le code. L’équipe se heurte à plusieurs problèmes dans ce processus :
- La configuration par défaut qui manque de flexibilité pour pouvoir l’adapter à l’application
- La complexité de la généralisation du tracing surtout sur du code legacy
- Les limites d’utilisation des décorateurs TypeScript
Malgré tout, ils ont obtenu des résultats déjà intéressants qui permettent de repérer des dysfonctionnements ou des bottlenecks dans le fonctionnement de l’application. L’aventure continue donc, en attendant d’intégrer de nouvelles fonctionnalités comme OpenTelemetry Collector.
Pour notre part, nous avons constaté sur nos différents projets que le tracing est devenu un bloc incontournable dans les architectures microservices et qu’il faut surtout le penser en amont. La démarche DevOps s’illustre ici d’autant plus que la réussite de la mise en place d’une stack de tracing dépend fortement de la collaboration Dev et Ops.
Merci pour ce retour d’expérience édifiant !
11. Voyage dans le monde du Chaos Engineering : immunisez votre infrastructure par l’injection de défaillances
Pour ce dernier talk de la journée, nous avons suivi Si Li de chez Carrefour pour un voyage dans le monde du chaos engineering.
Le début du talk était d’abord un rappel théorique de ce domaine de l’informatique. Elle a fait une analogie avec les vaccins pour expliquer que l’injection de défaillances dans les infrastructures permet de les rendre plus résilientes face aux pannes. S’ensuivit un retour d’expérience de la mise en pratique chez Carrefour.
Nous avons pu voir comment, dans le contexte Carrefour, le chaos engineering est pratiqué sur leurs clusters Kubernetes avec une présentation détaillée du workflow. Elle nous a notamment présenté de vrais incidents qui se sont produits, avec les apprentissages et les améliorations qui ont en résultés.
Elle nous a parlé notamment de deux outils utilisés :
Bravo et merci Si pour cette excellente présentation !
12. Conclusion
De notre point de vue, l’événement était une belle réussite ! Un grand bravo aux organisatrices et aux organisateurs : Les sujets étaient très intéressants et il y avait un bel équilibre entre les conférences et les retours d’expérience. Peu importe le niveau d’expertise des participant·es, il y avait des choses à apprendre et à découvrir lors de cette édition.
Mention spéciale également pour les efforts pour améliorer l’inclusion et la diversité des speakers : l’équipe a réellement été proactive concernant ce sujet.
En conclusion, vivement les Kubernetes Community Days 2024 !