🎉 Retour sur la Kubecon 2024

La Kubecon est LA grande messe autour de Kubernetes. Chaque année, il y a une édition en Europe et aux US qui se tient dans une ville différente : Paris a été choisi pour l’édition 2024 qui s’est tenue du 19 au 22 mars et nous avons été 8 à avoir eu le privilège d’y aller.

Cet événement majeur a été un moment enrichissant où nous avons pu échanger avec des experts sur les défis et les opportunités liés à ces technologies. Notre participation nous a offert une vision approfondie et à jour des tendances, des innovations et des meilleures pratiques dans ces domaines passionnants et en constante évolution.

Nous résumons au cours de cet article les différentes conférences qui nous ont le plus marquées, bonne lecture 😉

Keynote

Priyanka Sharma, directrice exécutrice de la Cloud Native Computing Foundation, a ouvert la keynote en présentant le parcours de la CNCF jusqu’à maintenant ainsi que la fierté que la CNCF a de pouvoir rassembler 12000 participants autour de l’opensource et de Kubernetes..

Le buzz du moment est l’intelligence artificielle 🤖 : plusieurs acteurs sont venus évoquer les avancées, les challenges des mises en œuvre applicatives et d’infrastructures pour satisfaire un besoin grandissant de plus en plus gourmand en ressources.

Architecting Resilience: Lessons from Managing 7K+ Kubernetes Clusters at Scale – Kwanghun Choi & Gyutae Bae, Kakao

L’équipe explique l’infrastructure mise en œuvre : un cluster k8s par AZ est déployé avec un load balancer mis en place en frontal de ces 3 clusters. Les équipes de dev choisissent sur quel cluster déployer leurs Deployments / Services / Jobs. La mise à jour de la configuration du load balancer est réalisée par un mécanisme différent des déploiements applicatifs. Un incendie est survenu et a brûlé une partie des serveurs ce qui a provoqué une perte non négligeable de l’état des clusters. Les équipes plateformes ont constaté que notamment les workloads et la configuration du load balancer frontal décrivant le routage des package n’étaient pas déployés sur au moins 2 clusters.

Suite à cet incident, il a été décidé de maintenir un état global des clusters en synchronisant les bases ETCDs directement.
De plus, une mise à jour systématique du load balancer frontal sur tous les services des différents clusters est instauré afin d’assurer la continuité de service en cas de panne.

La question suivante qui a été soulevée est le trafic « cross zone », c’est-à-dire le routage de paquet depuis ce load balancer vers le cluster se trouvant dans la même zone de disponibilité afin de diminuer la latence ainsi que les coûts. La CNI mise en place initialement était cilium avec différentes règles pour assurer la résilience. Différents benchmarks réalisés par l’équipe plateforme ont montré une latence liée à cette mise en œuvre et il a été décidé de faire du routage eBPF directement.

Le talk se termine par la présentation des prochains sujets avec notamment la création d’une CRD afin de piloter la mise à jour du load balancer.

Future of Intelligent Cluster Ops: LLM-Azing Kubernetes Controllers – Rajas Kakodkar, VMware & Amine Hilaly, AWS

Les speakers commencent la présentation en montrant un descripteur Kubernetes mettant en oeuvre une CRD accompagnée d’un opérateur appelant un endpoint Large Language Model afin de décrire en langage naturel le type de ressources à déployer sur le cluster : LLM*Netes.

Le backend utilisé est ChatGPT, d’autres intégrations sont en cours de développement.

Une première démo consistait à faire du « Chaos Engineering » en tuant des ressources au hasard pour vérifier la résilience des applications.
Voici un exemple de descripteur :

apiVersion: llmnetes.dev/v1alpha1
kind: CommandExec
metadata:
  name: command1
spec:
  command: Deploy a cronjob that will delete pod randomly in the cluster every 2hours.

Une autre démo mise en œuvre montrait l’utilisation d’une ressource ClusterAudit afin de vérifier l’état des PersistentVolumeClaims et PersistentVolumes.

La dernière question posée au LLM était Can I upgrade to the next version afin de vérifier si la montée de version du cluster dans une version majeure suivante était possible.
Le speaker rappelle, à juste titre, que les LLM ne savent répondre à des questions qu’avec des probabilités sur des sujets déjà vus. Dans le cas présent, peu de littérature était présente sur la base d’apprentissage et donc la réponse apportée n’était pas déterministe et parfois incorrecte.

LLMNEtes is just a vehicle but you should define your own path on the journey of Cloud Native and AI!

Ne pas croire tout ce que les LLM racontent, ils peuvent nous aider mais ne remplacent pas les ingénieurs.

Beyond Default: Harnessing CPU Affinity for Enhanced Performance Across Your Workload Portfolio – Antti Kervinen, Intel & Dixita Narang, Google LLC

Les speakers montrent l’impact de performances sur le déploiement d’un applicatif avec 8 puis 15 conteneurs avec ou sans affinité de CPU. L’affinité de CPU consiste à contraindre le système d’exploitation à toujours placer un processus sur un processeur physique par rapport à sa précédente exécution.

Les benchmarks montrent l’instabilité de la capacité de traitement de la plateforme lorsqu’aucune contrainte n’est définie. Au contraire, en spécifiant une affinité, les performances sont beaucoup plus stables et meilleures. Ce gain de performance est lié à plusieurs facteurs :

• lorsqu’un processus change de coeurs d’exécution, cela engendre, notamment, beaucoup de CACHE MISS : la donnée n’est plus présente dans la mémoire cache processeur L2 imposant d’aller la chercher et provoquant une perte de temps;
• Les processeurs modulent leurs fréquences en fonction de la charge des tâches à exécuter : plus il y a des choses à faire, plus la fréquence sera élevée. Lorsqu’un processus change en permanence de cœur physique, l’augmentation de fréquence n’est pas réalisée de suite car chaque cœur est finalement « peu » utilisé. Sur les processeurs actuels, cette augmentation s’effectue par coeur mais c’est une opération coûteuse et « longue », c’est pour cela qu’il faut attendre un certain temps avant le déclenchement du mode turbo;
• Certains middlewares sont contre performants lorsqu’ils voient de nombreux vCPU alors que finalement ils n’en utilisent qu’un sous ensemble.

L’objectif des conteneurs est d’avoir le moins d’adhérence possible avec la machine hôte, c’est pourquoi la pratique d’associer une ou plusieurs CPU à un processus est peu réalisée. De plus, ce type de configuration requiert l’appel à des outils de type taskset avec des droits root sur l’hôte.

Pour réaliser ce type de configuration, une CRD accompagnée d’un opérateur est à déployer afin de créer notamment une ressource BallonsPolicy documentation indiquant, par exemple, le nombre min et max de CPU allouée(s) à un conteneur ou un groupe de conteneur ainsi que l’association à un coeur donné. Ce paramétrage peut également être pris en compte à chaud sur les conteneurs déjà en cours d’exécution.

Toutes ces ressources s’appuient notamment sur la Node Resource Interface disponible dans containerd en version >= 1.7 et CRI-O>= 1.26.

Même si ce type de paramétrage permet d’avoir un gain en performance, les orateurs rappellent qu’il faut d’abord mesurer avant d’optimiser afin de vérifier les gains réels apportés par les changements.

Heating Pools with Cloud Power: A New Wave in Green Computing – Saiyam Pathak, Civo & Mark Bjornsgaard, Deep Green Technologies

Les serveurs sont d’excellent radiateurs, 97% de l’énergie consommée est transformée en chaleur. Mark indique qu’en Angleterre, de nombreuses piscines publiques ferment à cause notamment du prix de l’électricité pour chauffer l’eau. L’idée sous jacente est de rapprocher physiquement les serveurs des piscines et d’utiliser la chaleur produite afin de chauffer de l’huile minérale puis de la faire passer dans un échangeur thermique dans lequel circule l’eau de la piscine. Ainsi, les serveurs sont refroidis et les calories récupérées sont valorisées. Deep Green commercialise plusieurs solutions de différente puissance énergétique avec une offre de service de type IAAS pour héberger les applicatifs.

D’un autre côté, Civo est un Cloud provider proposant une offre logicielle plus riche de type Kubernetes managé, object storage, bdd managées, GPU en s’exécutant sur les serveurs installés par Deep Green aux abords des piscines. Le souhait de ces 2 acteurs est de réduire l’impact écologique des datacenters.

Saiyam présente ensuite une CRD et un opérateur nommé kube-green permettant de d’éteindre les Pods et de les rallumer en fonction de l’heure de la journée. En ne démarrant les ressources que lors des heures ouvrées pour les environnements hors prod, il est possible d’économiser 60% de la facture.

Le descripteur est de la forme suivante :

Keeping the Bricks Flowing: The LEGO Group’s Approach to Platform Engineering for Manufacturing – Mads Høgstedt Danquah & Jeppe Lund Andersen, The LEGO Group

Les deux speakers Mads et Jeppe ont commencé par présenter Lego : entreprise industrielle reposant beaucoup sur l’automatisation de tous les processus que ce soit sur la fabrication des Legos que sur le déploiement de la gestion des data centers de l’entreprise . Il y a donc beaucoup de machines, nécessitant beaucoup de services logiciels et donc beaucoup d’infrastructures.

Le  talk était donc un REX des pratiques que The Lego Group a mis en place pour fournir une infrastructure robuste , sécurisée et maintenable 

Voici les différentes stratégies présenté lors du talk : 

• Fournir  une expérience comparable à celle d’un cloud car la majorité des infrastructures sont On Premise.
• Tous les services sont sous forme d’API et accessibles à travers le  portail de développement interne  Backstage. 
• Pratiquement tous les services sont sous forme Kubernetes et déployé via ArgoCD avec une stratégie GitOps. 
• L’adoption par les utilisateurs n’est pas un fait acquis, elle doit être méritée. 
• En automatisant tous les déploiements de services , ils peuvent fournir les même services , outils , applications  de la même manière partout dans le monde 

Pour s’assurer que tous les services sont opérationnels une équipe dédiée au chaos engineering  est chargée  de mettre en place et d’appliquer des stratégies de test en lien avec les utilisateurs finaux et les Product Owner afin de s’assurer que le fonctionnement attendu est conforme . 

Kubernetes Security Blind Spot: Misconfigured System Pods – Shaul Ben Hai, Palo Alto Networks

Shaul Ben Hai de Palo Alto Networks aborde le rôle critique et les risques inhérents aux pods système dans les clusters Kubernetes. Les pods système, qui nécessitent des privilèges pour la manipulation des ressources et les paramètres réseau, sont des cibles attrayantes pour les attaquants en raison de leur surface d’attaque accrue et des données ou composants sensibles qu’ils gèrent.
Ben Hai met en évidence deux mauvaises configurations qui peuvent conduire à des vulnérabilités de sécurité.
L’une impliquant Fluent Bit, un collecteur de données pour Kubernetes, qui monte un volume contenant le jeton de compte de service de chaque pod dans le nœud,
L ‘autre liée au démon Container Network Interface (CNI), qui conserve des privilèges élevés après l’installation. Les attaquants peuvent exploiter ces mauvaises configurations pour accéder aux tokens de compte de service et élever les privilèges, en opérant potentiellement en tant qu’administrateurs de clusters.

Il souligne l’importance de sécuriser les pods système par le principe du moindre privilège, en limitant l’accès au réseau et en procédant à une surveillance et à une journalisation proactives. Il mentionne également une vulnérabilité dans Kubernetes où un attaquant peut localiser et utiliser un token appartenant à l’installateur CNI pour escalader les privilèges et obtenir un accès d’administrateur de cluster. La vulnérabilité a été traitée par GKE avec des réductions de permission et un renforcement de la configuration de Fluent Bit.

How KubeVirt Improves Performance with CI-Driven Benchmarking, and You Can Too – Ryan Hallisey & Alay Patel, Nvidia

Les ingénieurs de Nvidia Ryan Hesy et Al Patel discutent de leur utilisation de KubeVirt, une machine virtuelle fonctionnant à l’intérieur d’un conteneur, et de l’importance de l’analyse comparative basée sur l’intégration continue (CI) pour mesurer l’échelle et la performance.
Ils expliquent que KubeVirt étend l’API de Kubernetes pour permettre une interaction native avec les machines virtuelles et que Nvidia s’appuie fortement sur lui et sur d’autres outils de l’écosystème comme Oven, Gatekeeper, Prometheus, Grafana et Fluentd pour leurs services cloud.

De plus, ils s’assurent que leur stack Kubernetes évolue bien en cas de charge élevée en se concentrant sur l’environnement, les seuils de scalability et les extensions.

L’équipe a rencontré un problème de performance sur des clusters Kubernetes à grande échelle où un grand nombre de Secrets a fait en sorte que le serveur API ne réponde plus à de multiples appels en simultanés. Ils ont souligné l’importance de surveiller la charge que les extensions et les autres clients créent sur le serveur API.

Leurs équipes utilisent plusieurs outils pour surveiller et comparer les temps de création et d’exécution de l’interface de la machine virtuelle (VMI) dans KubeVirt. Ils exécutent quotidiennement des tests de bout en bout par le biais de CI et utilisent des graphiques pour identifier les améliorations ou les régressions de performance. Ils expliquent également la différence entre les benchmarks de performance et d’évolutivité et démontrent comment benchmarker un opérateur en utilisant des outils tels que Kube-Burner et Cluster Loader.

Les mesures peuvent être analysées à l’aide de Prometheus ou de Thanos, et des règles d’alerte peuvent être mises en place pour les notifications de dégradation des performances.

We Tested and Compared 6 Database Operators. The Results are In! – Jérôme Petazzoni, Tiny Shell Script LLC & Alexandre Buisine, Enix

La gestion des bases de données dans un cluster Kubernetes suscite de nombreuses interrogations et appréhensions. Heureusement, les opérateurs de bases de données simplifient cette tâche en masquant toute la complexité liée à la gestion d’une base de données dans un cluster Kubernetes.
Comme pour tous les composants de l’ingénierie logicielle, il existe plusieurs alternatives, chacune avec ses spécificités. C’est dans ce contexte que les intervenants (Alexandre Buisine et Jérôme Petazzoni) ont réalisé une comparaison de six opérateurs de bases de données :

Pour PostgreSQL :

• CNPG
• StackGres
• postgres-operator de Zalando

Pour MySQL :

• Moco
• Mariadb-operator
• Percona Operator for MySQL

Cette comparaison s’est appuyée sur plusieurs critères, dont les résultats sont consignés dans le tableau suivant :

Is Your Image Really Distroless? – Laurent Goderre, Docker

Dans cette conférence, Laurent Goderee définit ce qu’est une image Distroless, ce qui nous amène à nous interroger sur la nature réelle de nos images.

Le terme « Distro » est une abréviation de « Linux Distribution », qui comprend un Kernel, un système d’initialisation (systemd, etc…), des librairies et outils GNU, ainsi que d’autres composants.

Selon cette définition, une image « Distroless » est une image qui contient uniquement une liste minimale de composants logiciels et partage le Kernel avec le système hôte. Elle ne comprend pas de gestionnaire de paquets, pas de shell, ni de clients web tels que curl ou wget.

Il est fréquent de constater que plusieurs images se disant « Distroless » contiennent néanmoins un shell ou d’autres composants Linux, ce qui va à l’encontre du concept de « Distroless ». Cela s’explique par le fait que moins une image contient de composants Linux (ce qui réduit la surface d’attaque), moins elle est utilisable : c’est un dilemme entre la sécurité et l’utilisabilité.

Par exemple, de nombreuses applications conteneurisées nécessitent souvent l’exécution de scripts d’initialisation qui dépendent de la présence du shell.

Pour construire de véritables images « Distroless », on peut utiliser des outils tels que BuildKit ou le mécanisme de construction Multi-Stage.

Conclusion

Cette édition fut très riche avec pas moins de 12 tracks en parallèle en permanence, un très grand nombres de sponsors et beaucoup d’animations.

C’est avec plein d’étoiles dans les yeux que nous sommes rentrés de ces 3 jours excitants. Cette expérience nous a offert une vision approfondie et à jour des tendances, des innovations et des meilleures pratiques dans ces domaines passionnants et en constante évolution.

Les slides et les enregistrements vidéos de toutes les conférences sont en lignes via le site du programme ou accessible via la chaine Youtube de la CNCF.

Cette prose a été co-écrite avec Kevin Nzuguem et Eric Morvan 💪.