Retour sur la KubeCon 2023 à Amsterdam

Retour sur la KubeCon 2023 à Amsterdam

Trois jours à la KubeCon

J'ai eu l'occasion d'assister pour la deuxième fois à ce grand événement qu'est la KubeCon grâce à mon entreprise SFEIR, qui se déroulait cette fois-ci à Amsterdam pour l'édition 2023.

Cet événement regroupe différentes présentations et stands sur des outils associés à la Cloud Native Computing Foundation (CNCF).

kubecon-2023-entree

Plus de 10 000 personnes étaient attendues pour trois jours bien remplis !

À travers cet article, je vais vous partager les différentes conférences auxquelles j'ai assisté ainsi que les différents produits et outils que j'ai découverts.

L'article sera mis à jour quand les vidéos de rediffusion seront disponibles.

La Keynote

La Keynote de départ marque le démarrage de la KubeCon. Cette année, nous sommes accueillis par Chris Aniszczyk qui occupe le poste de CTO au sein de la CNCF.

Tout d'abord, c'était l'occasion de rappeler plusieurs statistiques :

  • 159 projets
  • 1300 mainteneurs
  • 200 000 contributeurs
  • 24 communautés Kubernetes

kubecon-2023-keynote

Ces différents chiffres ne font que croître année après année ! Cela montre l'implication de la communauté envers les outils open source.

Dans l'objectif de rester informer sur les dernières tendances, bonnes pratiques, mais aussi de nouveaux outils, vous pouvez vous inscrire à la newsletter Wisdom of the Cloud si vous le désirez.

Cette année, le thème principal de cette Keynote était en relation avec l'impact environnemental.

Quelques outils ont ensuite été présentés, c'est le cas du projet Kepler de Red Hat qui permet de mesurer la consommation énergétique des Pods au sein de Kubernetes en exposant différentes métriques au format Prometheus.

C'est aussi le cas du côté de Microsoft, et plus spécifiquement sur Azure avec le Carbon Aware KEDA Operator qui permet de réduire les émissions de gaz carbonique en mettant à l'échelle des différentes charges de travail (nombre de répliques de Pod) en fonction de l'empreinte carbone de la région où le cluster est déployé.

Enfin, celle-ci s'est terminée sur deux annonces intéressantes :

On continue avec les conférences auxquelles j'ai assisté durant ces trois jours.

Les conférences

A CI/CD Platform in the Palm of Your Hand par Claudia Beresford (Weaveworks)

kubecon-2023-cicd

Dans cette première conférence, Claudia nous présente le concept des MicroVMs qui est à la frontière entre les conteneurs et les machines virtuelles. Les MicroVMs sont très rapides, avec un temps de boot de l'ordre de 125 ms et demande très peu de ressources au démarrage.

L'objectif est d'utiliser ce concept avec Flintlock pour gérer le cycle de vie des MicroVMs, Firecracker pour la virtualisation et Cloud Hypervisor comme hyperviseur dans le but de générer des runners éphémères de CI/CD à la volée.

Plusieurs avantages sont à prendre en considération :

  • Performance accrue et temps de démarrage très rapide ;
  • Isolation totale des runners ;
  • Moins de puissance de calcul nécessaire pour déployer les runners, les coûts sont donc, par conséquent, réduits.

Vous pouvez retrouver le lien du support de présentation ici.

Argo CD Core - A Pure GitOps Agent for Kubernetes par Alexander Matyushentsev (Akuity) et Leonardo Luz Almeida (Intuit)

On continue avec une présentation sur ArgoCD core qui permet de déployer uniquement les briques d'ArgoCD qui sont essentielles à son fonctionnement. Je vous ai déjà parlé d'ArgoCD sur ce blog, vous pouvez retrouver mon article

kubecon-2023-argocd-core

Alexander et Leonardo commencent par présenter cet outil qui permet de déployer des applications en suivant l'approche GitOps sur Kubernetes, tout en fournissant un lien pour n'installer que la partie "core".

Même si l'API Server d'ArgoCD n'est pas installée, il est totalement possible de se connecter et d'utiliser le client avec la commande argocd login --core. Ce qui permettra à la commande de dialoguer avec l'API de Kubernetes plutôt que celle d'ArgoCD.

Enfin, il est aussi possible de visualiser ce qui est déployé, même sans avoir installé l'interface web, avec la commande argocd admin dashboard. Cette dernière aura comme effet de rendre accessible le tableau de bord d'ArgoCD en local.

Availability and Storage Autoscaling of Stateful Workloads on Kubernetes par Leila Abdollahi Vayghan (Shopify)

Dans ce talk, Leila nous parle des objets StatefulSet et notamment de tout ce qui concerne la mise à l'échelle du stockage lié à ces objets, en illustrant ces propos avec le moteur de recherche Elasticsearch.

En ce qui concerne l'augmentation du stockage des volumes persistants, c'est une fonctionnalité déjà incluse dans Kubernetes avec l'attribut allowVolumeExpansion: true qui est présent dans l'objet StorageClass. En revanche, les choses se compliquent quand on parle réduction du stockage, c'est pourquoi Shopify a créé son propre controller personnalisé afin de répondre à cette problématique.

kubecon-2023-stateful

Vous pouvez retrouver le lien du support de présentation ici.

Operate Multi-Tenancy Service Mesh with ArgoCD in Production par Lin Sun (Solo.io) et Faseela K (Ericsson Software Technology)

Lin et Faseela nous parle de Service Mesh, et plus précisément d'Istio, qui permet de connecter plusieurs applications déployées au sein d'un cluster Kubernetes en ajoutant une couche d'observabilité et de sécurité.

Plusieurs cas de figure sont évoqués, notamment quand différentes équipes collaborent au sein d'un même cluster. Dans le but de restreindre les communications, il est possible d'associer plusieurs mécanismes : l'objet AuthorizationPolicy et l'annotation exportTo.

Dans la situation où on se retrouve avec plusieurs clusters, les choses sont différentes, l'isolation des communications s'effectue avec les discoverySelectors au sein de la ressource IstioOperator tout en activant le paramètre ENABLE_ENHANCED_RESOURCE_SCOPING.

Enfin, un tableau récapitulatif est proposé permettant de visualiser les avantages et inconvénients en fonction des différents types d'installation.

kubecon-2023-servicemesh-recap

Vous pouvez retrouver le lien du support de présentation ici.

Making Sense of Your Vital Signals: The Future of Pod and Containers Monitoring par David Porter (Google) et Peter Hunt (Red Hat)

Dans cette présentation, il est question de supervision d'un cluster Kubernetes, notamment au niveau des Pods et des conteneurs en parlant de cAdvisor qui permet de remonter plusieurs métriques (CPU, mémoire, réseau, etc.) à partir d'un nœud du cluster.

kubecon-2023-pod-monitoring

Quelques limites de cAdvisor sont à noter :

  • Composant monolithique ;
  • Impact non négligeable sur les performances ;
  • Tous les types de conteneur ne sont pas pris en charge (Windows, Kata).

C'est pourquoi, il serait plus intéressant d'associer ces différentes métriques directement au niveau du Container Runtime Interface (CRI) et c'est actuellement en version alpha.

Vous pouvez retrouver le lien du support de présentation ici.

Tips from the Trenches: GitOps at Adobe par Larisa Andreea Danaila et Ionut-Maxim Margelatu (Adobe)

Cette conférence est un retour d'expérience sur le GitOps sur différents points que l'on retrouve souvent quel que soit le projet.

Dans un premier temps, les deux intervenants mettent en lumière la gestion des dépendances d'applications au sein d'Argo CD en utilisant l'annotation argocd.argoproj.io/sync-wave pour orchestrer le déploiement et faire en sorte de synchroniser ces différentes applications dans le bon ordre.

Ensuite, dès lors que l'on modifie le contenu d'une image, cela revient souvent à faire 2 Pull Requests : une sur le fichier de l'image et une autre sur le fichier de déploiement pour mettre à jour le tag de celle-ci.

Larisa et Ionut-Maxim partagent une solution pour éviter cette double validation : utiliser la CI pour créer l'image puis interfacer cette dernière avec Argo Workflows dans le but de promouvoir, par environnement, cette nouvelle image conteneurisée dans le dépôt de code contenant le fichier à déployer sur le cluster Kubernetes.

kubecon-2023-adobe

Enfin, la dernière partie concerne le déploiement d'une application et l'infrastructure nécessaire au bon fonctionnement de celle-ci. Même problème qu'au-dessus, deux processus différents.

Cette fois-ci, c'est Crossplane qui est utilisé pour non seulement déployer l'application, mais aussi l'infrastructure directement via des objets Kubernetes. Ce qui évite d'utiliser un outil d'infrastructure as code en plus comme Terraform par exemple.

Vous pouvez retrouver le lien du support de présentation ici.

Image Signing and Runtime Verification at Scale: Datadog's Journey par Ethan Lowman (Datadog)

Dans cette présentation, Ethan nous parle de vérification de la signature des images conteneurisées qui est souvent effectuée au niveau d'un Admission Webhook. Ce contrôle est effectué par le Control Plane qui va analyser l'authenticité de la signature associée à l'image. Le problème de cette solution est essentiellement lié à la latence engendrée par le fait de récupérer la signature des méta-données à travers un registre distant.

C'est pourquoi, Ethan indique qu'il est préférable d'intégrer la vérification directement dans containerd qui sera déléguée au niveau des nœuds du cluster. Cette fonctionnalité sera disponible dans la version 2.0 et viendra afficher une erreur lors du pull si celle-ci n'est pas correctement signée.

kubecon-2023-sign-containerd

Vous pouvez retrouver le lien du support de présentation ici.

In-Toto: Attestations and More for Software Supply Chain Security par Aditya Sirish A Yelgundhalli (New York University)

Aditya nous propose une présentation de In-toto qui est un framework permettant de se protéger des attaques qui visent les chaînes d'intégration et de déploiement à travers Witness qui est son implémentation par la communauté open-source.

Il utilise un moteur de stratégie en Rego et se base sur l'attribution d'attestations pour vérifier plusieurs éléments :

  • Vérifier la phase de création d'application (build), ainsi que les outils qui ont été utilisés ;
  • Détecter des activités malveillantes ;
  • S'assurer que seuls les utilisateurs et machines autorisés peuvent intervenir dans les étapes de la chaine CI/CD.

Pour finir, In-toto est utilisé dans plusieurs outils, au sein de Jenkins ou DataDog par exemple.

Future of Istio - Sidecar, Sidecarless or Both? par Neeraj Poddar (Solo.io)

Neeraj a tout d'abord évoqué la forte croissance du nombre de Service Mesh en 2022. Tout en rappelant qu'Istio est devenu membre du CNCF depuis le mois de septembre 2022 en tant que membre au statut incubating.

Dans la suite de la présentation, il est revenu sur différents points d'attention sur l'utilisation des sidecars :

  • Complexité opérationnelle : chaque Pod contient un conteneur ;
  • Le coût : le CPU et la RAM utilisés par chaque conteneur sidecar ;
  • Les perfomances : la latence ajoutée notamment à cause du proxy.

Ces différents points peuvent être résolus par l'utilisation de Istio Ambient Mesh qui permet de déployer sur chacun des nœuds, un agent contenant un zero-trust tunnel ou ztunnel le tout dans un objet Kubernetes de type DaemonSet.

kubecon-2023-servicemesh-istio-ambient

Cela permet d'éviter d'injecter des conteneurs sidecar dans chacun des Pods. Néanmoins, l'agent ne permet pas de faire des analyses sur la couche 7 du modèle OSI.

C'est pourquoi, il est nécessaire d'installer des waypoint proxy par application pour avoir de l'observabilité ainsi que d'autres fonctionnalités sur la couche 7. Ces proxys sont de simples Pods qu'il est possible de mettre à l'échelle.

En complément, Istio Ambient Mesh continue d'utiliser iptables et est aussi sécurisé que la version avec les sidecars.

Pour finir, Neeraj indique qu'il est possible, pour des besoins spécifiques, de mélanger les deux modes : avec sidecar ou sans en fonction des besoins.

Containerd: Project Update and Deep Dive par Maksym Pavlenko (Apple) et Samuel Karp (Google)

Cette conférence avait pour but de faire un récapitulatif des évolutions de containerd et de son adoption au sein de l'éco-système Kubernetes.

Plusieurs types de version sont disponibles :

  • Active : correction de bugs et de sécurité (1 an) ;
  • Étendu : contient uniquement de mises à jour de sécurité (pas de temps défini) ;
  • LTS (stabilité longue durée) : correction de tous types (3 ans).

D'ailleurs la version 1.6 est la première LTS qui sera supportée jusque février 2025.

En ce qui concerne la version 1.7, celle-ci apporte deux nouvelles fonctionnalités :

  • L'API Sandbox : permettant de garantir une isolation au niveau du CRI (Container Runtime Interface) ;
  • Le service Transfer permettant de réaliser des actions comme pull, push, import, export, etc.

kubecon-2023-containerd

La version 2.0 va permettre de stabiliser les différentes fonctionnalités et API existantes, tout en supprimant des fonctionnalités qui sont dépréciées, notamment la version 1 de l'API runtime.

On retrouve, dans cette version, la volonté d'avoir des versions prêtes pour la production que ce soit au niveau de l'API sandbox ou le service Transfer. De plus, plusieurs mises à jour seront effectués au niveau du CRI et NRI (Node Resource Interface).

Enfin, il faut savoir que la plupart des services managés comme EKS, AKS ou GKE utilisent containerd par défaut. C'est aussi le cas de Kubeadm et K3S que j'ai déjà mentionnés à travers quelques articles sur mon blog.

Vous pouvez retrouver le lien du support de présentation ici.

1M Lines of YAML: Wrangling Kubernetes Configuration for Hundreds of Teams par Katrina Verey (Shopify)

Au sein de cette présentation, Katrina nous a parlé du système utilisé par Shopify pour templater et déployer un large nombre d'objets sur un cluster Kubernetes.

Dans un premier temps, un moteur de template à base de Ruby et de fichiers .erb a été utilisé. Ce qui a notamment posé plusieurs problèmes : complexité pour faire évoluer le moteur, mais aussi pour visualiser les changements lors d'une revue de code.

Il est donc très difficile d'avoir une visualisation claire des objets générés avec le moteur de templating.

Finalement, la solution adoptée par Shopify est d'utiliser un moteur de templating en YAML tout en stockant les fichiers générés dans un endroit dissocié permettant d'installer ce contenu sur un cluster, mais aussi de conserver l'ensemble des versions dans le cas où un retour en arrière est nécessaire.

Vous pouvez retrouver le lien du support de présentation ici.

Malicious Compliance: Reflections on Trusting Container Scanners par Ian Coldwater, Duffie Cooley (Isovalent), Brad Geesaman (Ghost Security) et Rory McCune (Datadog)

kubecon-2023-trusting-scanner

Ce talk était l'occasion d'évoquer les différents types d'outil qui permettent de scanner les images conteneurisées et de comparer leurs relevés de sécurité.

Dans les outils, on retrouve Trivy, Grype, Docker scan (actuellement déprécié) et Docker scout.

À travers une image qui contient plusieurs failles de sécurité, les différents outils mentionnés plus haut, affichent des résultats différents les uns des autres. Que ce soit sur le système d'exploitation, les paquets installés, les dépendances d'application voire les méta-données associées aux binaires.

L'objectif de cette présentation est de montrer qu'être conforme en matière de sécurité n'est pas forcément signe que l'application est sécurisée en tant que telle.

Notamment via différentes manipulations au sein du Dockerfile pour éviter que le scan de sécurité remonte ces différentes failles :

  • Modifier le nom du système d'exploitation avec un OS inconnu ;
  • Modifier le nom des binaires et faire des liens symboliques ;
  • Écraser les méta-données des binaires ;

Un dernier point d'attention est lié au multi-stage build qui peut parfois offusquer certains résultats. C'est pourquoi, il est important aussi de scanner l'ensemble des images utilisées.

Évidemment, ce type de manipulation est extrême, mais cela met en évidence qu'il est possible de "tromper" les scans de sécurité sans corriger aucune faille.

Un dernier point d'attention est aussi le Software Bill of Materials (SBOM) qui, en fonction des produits, ne remonte pas les mêmes informations à cause de l'absence de standard pour le moment.

Des outils à découvrir ou redécouvrir...

En plus des conférences ci-dessus, j'ai eu l'occasion de découvrir quelques outils sur les stands des exposants.

Voici ceux que je souhaitais vous partager :

  • Les images sécurisées et durcies de Chainguard. Idéal pour réduire les risques de sécurité avec une taille totale d'image réduite ;

  • Apko de Chainguard qui permet de créer des images de conteneurs en se basant sur des paquets apk avec le strict minimum à partir d'un fichier YAML ;

  • Cilium Service Mesh (Isovalent) sans conteneur sidecar qui utilise la technologie eBPF pour la gestion des communications, la sécurité mais aussi l'observabilité. Le but étant de réduire la latence avec ce mode d'installation ;

  • Tracee d'Aquasec. Cet outil détecte les comportements suspects, par exemple des appels système malveillants, en utilisant la technologie eBPF grâce à un ensemble de règles prédéfinies ;

  • vcluster qui génère des clusters Kubernetes virtuels au sein d'un cluster parent. L'avantage de cette solution est de pouvoir tester différentes fonctionnalités sans avoir à recréer un cluster différent. En outre, cela permet d'avoir un coût au global réduit sans perdre du côté de l'isolation des différentes charges de travail.

Conclusion

Tout comme l'année dernière, la KubeCon est un moment riche en partage et en informations. Cette année, beaucoup de sujets sur le Service Mesh, la sécurité des conteneurs et la supervision.

J'ai essayé d'alterner entre les conférences et les stands afin de découvrir de nouveaux produits voire outils. Le timing étant parfois très serré, il n'est pas forcément facile de jongler entre les deux.

Néanmoins, je ressors de cet événement avec une liste d'outils à tester et d'autres à redécouvrir. Quelques articles de blog arriveront prochainement sur ces différents sujets !

Rendez-vous l'année prochaine à Paris :-)