Kubecon Europe 2024 on Zwindler's Reflection

Récap du dernier jour de Kubecon Europe 2024 - Vendredi

Fri, 22 Mar 2024 18:00:00 +0200

Cet article fait partie d’une suite de 4 posts :

This is the end

4ème (en comptant les colocated events) et dernier jour de Kubecon. C’était intense !!

La keynote de la journée a été ouverte par Chris Anisczcyk, CTO de la Linux Foundation (CNCF).

Quelques chiffres amusants : c’est la 20ème Kubecon, en juin 2014, Kubernetes a été open sourcé (il aura donc 10 ans cette année).

Chris a fait un petit récap du chemin parcouru depuis cette date :

2015 - Kubernetes devient 1.0
novembre 2015, première Kubecon à San Francisco avec seulement quelque centaines de participants
2016 - création de la CNCF
2019 - Création des événements KCD
2020 - Création des Cloud native community groups

Pour fêter les 10 ans de Kubernetes, la CNCF a créé un site kubertenes.cncf.io.

Dernier point, un nouveau groupe de personnes reconnues dans la communauté a été créé (en plus des ambassadors), les Kubestronauts. Il s’agit des personnes qui ont fait toutes les certications (CKA, CKAD, CKS, KCNA, KCSA).

Keynote: Success Not Guaranteed

La keynote suivante, de Bob Wise, CEO de Heroku, était aussi, d’une certaine manière, un regard dans le rétro, mais plus orienté sur sa propre carrière… Bob Wise a déroulé les choix dans sa carrière qu’il a dû faire pour créer du “cloud native” quand ça n’existait pas encore.

We had built our own orchestration system, everything was working in dev, but not in prod

Lorsqu’il était dans la team Coud Native de Samsung, Bob a parlé des obstacles que lui et son équipe avaient décelé et qui auraient pu freiner l’adoption de Kubernetes.

Le premier était les problématiques de performance (comment dépassér les 100 nodes, supporter plusieurs patterns de déploiements, comme par exemple des clusters multi AZ). Ces challenges ont été traités par le Scaling SIG dont il faisait partie.

Le second était la gouvernance. Bob a estimé que la création de la CNCF et que la standardisation des containers avec OCI plutôt que forker docker avaient été les “bons moves”.

Open source is not enough, you need true community gouvernance

Keynote: A 10-year Detour: The Future of Application Delivery in a Containerized World

À croire que réminiscence était le mot d’ordre de la journée, car c’était ensuite au tour de Solomon Hykes de jeter un coup d’œil dans le rétroviseur. Cependant, lui l’a fait avec de la sensibilité et une touche d’humour qui était très agréable.

Solomon a reparlé de son parcours, notamment au sein de dotCloud puis de Docker, de ce qui a mené à l’adoption de la technologie des containers

Serious people don’t launch serious workloads in the cloud

Après avoir expliqué qu’on ne devait pas céder aux sirènes de la nostalgie en repensant aux PaaS des années 2010 (en mode “winner takes all”), et qu’il ne fallait pas y revenir.

Pour finalement changer complètement de sujet et parler tout à coup d’usine logicielle (“ne pas céder à la tentation de tout faire soi-même”). Difficile de ne pas y voir un clin d’œil à Dagger.io.

Keynote Panel Discussion: Unity in Diversity: A Decade of Inclusive Growth in the Cloud Native Community

Kasper Borg Nissen a animé un panel sur la diversité dans l’écosystème cloud native :

Jinhong Brejnholt, Saxo Bank
Andrea Giardini, Independent
Anastasiia Gubska, BT Group
Stéphane Este-Gracias, ITQ

Au travers des différentes actions des panélistes, nous avons pu nous rendre compte qu’il existe de nombreuses initiatives pour rendre la communauté cloud native plus diverse, plus durable (au sens écologique du terme).

On a parlé du SIG deaf and hard of hearing, des non-code contributions (la documentation), de Kubetrain (l’initiative visant à venir à la kubecon en train sponsorisé), des KCD, …

Le témoignage de Anastasiia Gubska (sourd-muette) était particulièrement fort, touchant, inspirant.

Three’s a Crowd: How to Achieve 2-Node HA at the Edge and Make Your CFO Smile

Tyler Gillson et Pedro Oliveira de Spectro Cloud (les développeurs principaux de Kairos, une distribution de Kubernetes) nous ont présenté les challenges qui les ont motivés à trouver une solution pour obtenir un cluster Kubernetes en “edge” avec seulement deux machines et non pas trois.

Les problématiques edges sont particulières. On ne peut pas se permettre dans certains cas de ne se reposer que sur un seul node, au risque d’avoir un SPOF. On ne peut pas non plus utiliser de cluster etcd externe ou de compter sur un “witness” (3ème vote, pour un quorum) car on peut avoir une mauvaise connectivité.

Le but était aussi de pas réinventer trop de choses, notamment dans les couches basses.

Il a donc été choisi d’utiliser k3s avec kine (kine is not etcd) avec une base postgres en mode actif passif.

Si le nœud principal tombe en panne ou devient inaccessible, le nœud secondaire est promu, l’instance postgres devient principale et le control plane du node secondaire est redémarré. En théorie, ça fonctionne, sans trop de choses à modifier.

La démo n’a malheureusement pas fonctionné, mais la discussion qui a suivi avec les développeurs du projet était très intéressante.

Trimaran: Load-Aware Scheduling for Power Efficiency and Performance Stability

Asser Tantawi & Chen Wang d’IBM nous ont présenté des plugins pour le scheduler qui permettent de placer de manière plus intelligente les pods sur les nodes, via un calcul de “score” basé sur des données des nodes et de statistiques.

Il en existe pour l’instant trois, mais il est en théorie très facile d’en écrire des similaires en modifiant les paramètres.

À tester.

Récap du deuxième jour de Kubecon Europe 2024 - Jeudi

Fri, 22 Mar 2024 00:00:00 +0200

Cet article fait partie d’une suite de 4 posts :

Keynote: 🇫🇷 Hip, Hip, Beret! No Cap, Just Cloud Native Facts

Dans cette keynote d’ouverture, Taylor Dolezal, Head of Ecosystem de la Cloud Native Computing Foundation nous a présenté quelques statistiques de la CNCF, avec un focus particulier sur les contributions des “end users”.

Sans surprise, Backstage arrive comme d’habitude largement en tête, avec KCL et Argo ensuite.

Pour faciliter les contributions, la CNCF a lancé un programme “from Zero to merge project” pour inciter les personnes qui n’osent pas contribuer à le faire. À voir si c’est vraiment utile, ou non ?

Keynote Panel Discussion: Revolutionizing Cloud Native Architectures with WebAssembly

Le talk suivant était un panel avec :

Ralph Squillace, Principal Product Manager, Microsoft
Michelle Dhanani, Principal Software Engineer, Fermyon Technologies
Kai Walter, Distinguished Architect, ZEISS

Pour faire simple, Michelle Dhanani nous a montré les avantages de lancer des workloads WASI (WebAssembly mais côté serveur, pas dans un navigateur) depuis Kubernetes, avec une mini-démo. Pour en savoir plus, je suis allé voir une session dans l’après midi.

Suite à cette keynote, j’ai écouté d’une oreille la suite (les awards pour les end users) mais pas de quoi en faire un récap.

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

Ce talk avait été fait en français l’an dernier à KCD France. J’en avais eu d’excellents retours, mais je n’avais pas vu le voir puisque j’étais moi même organisateur de l’événement (eh oui, c’est le côté ingrat de l’orga ;-P).

Jérôme Petazzoni et Alexandre Buisine ont fait un REX de l’usage des opérateurs de base de données pour les clients d’Enix, le tout en étant habillés comme des Pirates.

Voici les 6 opérateurs qui ont été comparés :

CNPG, StackGres, postgres-operator (Zalando)
Moco, mariadb-operator, percona operator

Sur une liste de critères (d’opérabilité surtout), Jérôme et Alex ont comparé les différents opérateurs et expliqué pourquoi ils les aimaient / n’aimaient pas, et à la toute fin, lesquels ils utilisent en production.

Plutôt que de tout paraphraser, voici les slides :

Lien docs.google.com

Kubernetes Controllers in Rust: Fast, Safe, Sane

Le talk que j’ai vu ensuite était une présentation de Matei David, ingénieur chez Buoyant (les développeurs de Linkerd).

Matei nous a expliqué qu’une des raisons (ce n’est pas la seule) pour laquelle la plupart des controllers d’opérateurs Kubernetes sont codés en golang : les libraries client-go et controller-runtime sont les bibliothèques les plus complètes pour interagir avec l’API server.

Cependant, ça ne veut pas dire que rust n’est pas un langage de choix pour coder des operateurs.

Il existe un crate kube-rs, qui est l’équivalent de client-go et qui permet déjà de rédiger du code de qualité pour intéagir avec Kubernetes. Il existe kubert qui ajoute une couche d’abstraction au code rust pour coder des opérateurs.

Matei a ensuite montré des exemples de codes et expliqué pourquoi ils avaient commencé à écrire du code rust pour Linkerd (problématiques complexes de mutex en go et gestion de la mémoire plus safe en rust).

N’était pas très à l’aise en rust, j’ai compris juste assez pour que ce soit intéressant, mais pas assez pour avoir envie de tester. C’était un bon talk.

Leveling up Wasm Support in Kubernetes

Ce talk sur les produits de Fermyon Spin et KubeSpin était relativement intéressant. C’était une version longue de la keynote du matin, avec les mêmes intervenants, et une démo plus longue et live.

Pour faire simple pour ceux qui ne sauraient pas, WASM est un format permettant d’exécuter du code bas niveau sur n’importe quel device et n’importe quel architecture dans un environnement sandboxé et sécurisé.

boring definition: it’s another bytecode format

Pour donner un exemple concret, Figma utilise du code C++ compilé en WASM pour exécuter du code nécessitant des performances importantes depuis un navigateur et importé simplement avec du javascript.

On nous a présenté Spin, un ensemble d’outils pour développeurs permettant de faciliter l’adoption de WASM dans un environnement serverless, puis SpinKube, le framework permettant de faciliter l’intégration de ces stacks dans Kubernetes.

Spin is like “rails”

SpinKube utilise runwasi, un containerd shim écrit en rust (encore du Rust…). La démo (sur 5 RPi) était sympa et donne envie de tester.

Keeping the Bricks Flowing: The LEGO Group’s Approach to Platform Engineering for Manufacturing

Ce talk de Mads Høgstedt Danquah & Jeppe Lund Andersen, de The LEGO Group, était mon petit bonbon.

Comme beaucoup de nerds, je suis un fan de briques Lego depuis mon enfance et travailler là-bas serait un peu un rêve. Je ne suis donc pas du tout objectif dans mon récit de ce talk.

Mads et Jeppe ont commencé par poser le décors. Lego est une entreprise industrielle qui se repose beaucoup sur l’automatisation pour rester compétitive. Il y a donc beaucoup de machines, nécessitant beaucoup de services logiciels et donc beaucoup d’infrastruture.

Ce talk était donc un REX des pratiques que The Lego Group a mis en place pour obtenir une infrastruture agréable à utiliser pour ses 1200 ingénieur⋅es logiciels.

Voici quelques conseils qu’ils ont pu donner au cours de la présentation :

Provide a cloud like experience (self service, API enabled) accessible with IDP

User adoption is not a given, it must be earned. But how do we earn our users trust?

Focus on early value

Private on-prem cloud is way easier than it ever was

Value time over quality

Quality over speed (pick from the landscape)

Words to live by.

Make Your Cluster Fly: Embed a Multi-Node Kubernetes Cluster Inside an Aircraft Using Puppet & Flux

En toute fin de journée, je suis allé voir ce talk de Thalès de Alexis Bonnin & Guillaume Maquinay.

En réalité, j’y suis allé parce que je connais quelqu’un qui a participé en partie à ce projet et j’avais envie de voir ce qu’ils allaient en dire, même si j’étais bien fatigué de la journée…

Grosso modo, Alexis et Guillaume ont bien présenté les problématiques liées à des avions qui n’ont par définition par toujours du réseau et qu’il faut réussir à mettre à jour de manière automatisée et industrialisée dans des conditions pas habituelles (edge).

Si les technos ne sont pas super sexy (Puppet ☠️☠️☠️), les challenges sont intéressants, car non conventionnels, et nécessite des solutions à base d’operator pour éviter de pull des images quand on a plus de réseau.

Blabla

Honnêtement, j’ai vu tellement de monde aujourd’hui que ça n’a plus vraiment de sens d’en faire une liste. J’ai eu plusieurs conversations super enrichissantes avec Aurélie, Stéphane, Théotime et Eddy sur le stand OVHCloud, au café avec Laetitia, passé un bon moment avec Zed pendant la pause, profité de la team deezer pendant le déjeuner et au food court le soir, revu Thoms (le bouncer) et Christian totalement par hasard dans le métro en rentrant de diner…

Et surtout, j’ai fait une super photo avec la team frenchies sur le rooftop :

Good times.

Récap du premier jour de Kubecon Europe 2024 - Mercredi

Thu, 21 Mar 2024 10:00:00 +0000

Cet article fait partie d’une suite de 4 posts :

Keynotes

Aujourd’hui, c’est mercredi. C’est donc parti pour les premières Keynotes !!

Priyanka a commencé par nous donner quelques chiffres sur l’édition en cours (qui va rassembler 12000 personnes sur site, la plus grosse Kubecon de tous les temps).

Elle a ensuite donné le ton pour les prochaines keynotes (et aussi toute la conférence, en vrai).

AI is everywhere, with irrational exuberance

Même si Kubernetes a maintenant 10 ans, il est probable qu’on en parle encore pendant un moment, puisque ce sont aujourd’hui les technologies “cloud native” (et donc Kubernetes) qui sont la base de cette révolution de l’IA.

Elle a ensuite insisté sur le fait qu’à l’instar de ce qui avait pour standardiser les technologies liées aux containers (OCI par exemple), il allait falloir s’extirper du modèle propriétaire dans le monde de l’IA.

Elle a terminé par une petite démo à base de LLAVA / BAKLLAVA (description d’images) et ollama (model registry service)

github.com/cncf/llm-in-action

Panel

Juste après, elle a accueilli 3 personnes du monde de l’IA

Timothée Lacroix - Mistral
Paige Bailey - Google
Jeffrey Morgan - Ollama

Il y a eu quelques discussions intéressantes dans ce panel :

Ollama est très proche de l’architecture des projets cloud native, tout simplement par ce que son créateur a travaillé dans ces technologies pendant 10 ans
Mistral utilise Kubernetes pour s’abstraire de toutes les problématiques d’infrastructure et se concentrer sur sa valeur ajouté
il y a beaucoup d’Opensource washing en ce moment

Accelerating AI Workloads with GPUs in Kubernetes

La keynote suivante, présentée par Kevin Klues et Sanjay Chatterjee, parlait du travail qu’il reste à faire pour tirer parti au maximum des GPUs dans Kubernetes.

Il y a deux niveaux d’améliorations sur lesquelles il faut travailler :

bas niveau : comment rendre les GPUs mieux “partageable”
haut niveau : comment rendre “topology aware” nos clusters Kubernetes et nos workloads

Sans trop rentrer dans les détails, il reste du travail, mais ça avance.

Quand j’ai regardé la suite des keynotes (AI, AI, AI, AI, …), j’ai laissé tomber et je suis parti faire un petit tour des sponsors…

10 Years of Kubernetes Patterns Evolution

Étant administrateur de cluster Kubernetes en production depuis bientôt 8 ans, je n’ai pas appris grand-chose à cette session. Cependant, ce talk était très agréable.

Les speakers Bilgin Ibryam & Roland Huss sont pédagogues et quand j’ai appris qu’ils étaient en fait les auteurs du livre “Kubernetes patterns”, j’ai voulu le récupérer.

L’idée du livre (et de ce talk, qui en est une version très raccourcie) est de lister des éléments de design réutilisables pour concevoir des applications cloud native.

Note : l’idée de ce livre est inspirée d’autres livres plus anciens, comme “A Pattern Language”, un livre d’architecture, et “Design patterns” (principes logiciels orienté objet)

Les auteurs ont présenté les patterns suivants :

Health probes
Structual patterns (avec l’exemple du sidecar)
Behavioural patterns (avec l’exemple du singleton)
Configuration patterns
Security patterns
Advanced patterns

Je suis allé récupérer le livre juste après ;-)

Impossible de rentrer dans les salles

Je suis vraiment en colère.

Je n’ai pas pu rentrer ni dans I’ll Let Myself In: Kubernetes Privilege Escalation Tactics (pourtant au même niveau dans le bâtiment), ni dans Crossplane Intro and Deep Dive - the Cloud Native Control Plane Framework.

Les files interminables pour rentrer dans les salles semblent être la norme cette année (encore). A quoi bon faire venir 12 000 personnes sur site si c’est pour que la moitié d’entre elles se retrouvent obligés de regarder les talks en replay trois semaines plus tard ?

Podcast et Brussels Beer Project

Pour ne rien arranger, et après une petite photo avec la team KCD France, j’ai dû partir tôt, car j’avais l’enregistrement d’un podcast qui était prévue de longue date.

Je n’ai donc pas pu tenter ma chance dans une autre session, mais j’ai cru comprendre que c’était à peu près pareil.

L’après midi n’était pas perdue pour autant puisque après le podcast, j’ai pu prendre un verre avec mes collègues parisiens que je ne vois pas si souvent que ça.

Networking, again

J’ai eu la chance de pouvoir parler un long moment avec mon ex-binôme et ses collègues de BackMarket. La discussion était productive ;-).

J’ai aussi croisé Mathieu, Philippe, James, Nicolas, Remy, Zineb et par un hasard à peine croyable, Paul.

Récap du premier jour de Kubecon Europe 2024 - Mardi - colocated events

Tue, 19 Mar 2024 20:00:00 +0000

Cet article fait partie d’une suite de 4 posts :

Mardi

Cette année, pas de DevoxxFR pour moi (c’est pendant les vacances scolaires de Bordeaux). En revanche, je participe à la Kubecon Europe 2024, qui se déroule cette année à Paris !

Les deux précédentes Kubecon que j’ai faites en présentielles (2018 et 2022), je n’avais pu participer qu’au 3 jours (““seulement”” mdr) de conférences, pas les “colocated events” qui se déroulent un jour avant. Cette année, je teste donc l’expérience complète (qui a même commencé lundi, avec la “Kubetrain party” où j’ai été gentiment invité :-D).

Platform Engineering day

En première partie de journée, j’ai décidé de choisir de regarder les talks de la track “Platform Engineering Day”.

Ce colocated event se concentre sur les problématiques de “developer experience”, c’est-à-dire, comment améliorer l’expérience qu’ont les développeurs pour que le temps entre l’écriture du code et le moment où il est en production soit le plus court possible.

Ça nécessite évidemment un changement de mentalité (on parle de shift-left), car plus d’autonomie nécessite également plus de responsabilités.

Sometimes lipstick is just what a pig need

J’ai vraiment adoré ce talk, qui est une très bonne introduction aux problématiques de la dev experience. Le talk est très bien présenté, plein d’énergie positive, avec la juste dose d’humour.

C’était aussi très malin de le mettre en tout début de journée.

Le pitch du talk était de démontrer que dans certains cas, les différents types d’interfaces versus les fonctionnalités qu’elles ont sont parfois peu pratiques, mais il est difficile de mettre le doigt sur LA raison pour laquelle, c’est le cas.

Abby Bangser et Whitney Lee ont fait tourner deux “roues” aléatoires pour faire des paires interface/capabilities :

Pour chaque paire, elles ont essayé de trouver des interfaces existantes, puis elles se sont demandés quels problèmes pouvaient avoir ces interfaces. Et à chaque exemple, nous avons exploré un axe de réflexion pour ces paires :

Autonomy

L’échelle de l’autonomie qu’on souhaite donner à notre application et sa fonctionnalité.

Exemple : si un développeur veut déployer un service ou une brique d’infrastructure :

Est-ce qu’on veut donner un portail (exemple Backstage) aux développeurs pour qu’ils puissent déployer des objets eux même en prod ?
Est-ce qu’on veut juste ouvrir un ticket pour demander de l’aide à un administrateur.

Contextual distance

Est-ce qu’on reste sur le même outil (un plugin d’IDE), ou est-ce qu’on change d’outil ?

Capability skill

Est-ce que l’outil nécessite une connaissance approfondie pour être utilisé (un CLI), ou est-ce que l’outil cache la complexité totalement (un sidecar) ?

Interface skill

Est-ce que l’outil est simple/intuitif à utiliser ou non ?

Pour cette catégorie, les speakers ont eu une réflexion intéressante : les templates (de code) ne sont PAS des interfaces simples à utiliser. Dès qu’on veut changer quelque chose qui n’est pas le comportement par défaut, il faut modifier du code (pire, du code “de quelqu’un d’autre”).

Le “takeaway” principal de ce talk est qu’il n’y a pas de réponse universelle et que lorsqu’on crée ou met en place un nouvel outil, il faut se poser ces questions, en fonction du contexte.

Beyond Platform Thinking at Ritchie Brothers - Build Things No One Expects, in a Place No One Expect

Ce talk de Bryan Oliver était un REX de l’implémentation de la philosophie Platform Engineering au sein d’une société globale d’enchères d’engins de chantiers.

Parmi les quelques retours intéressant que j’ai bien aimés, Bryan a notamment rappelé qu’il fallait :

voir la plateforme comme un produit
qu’il s’agit avant tout d’un projet logiciel, pas un projet d’infrastructure
que le but premier est avant tout de supprimer toute friction pour le développeur

Après quelques chiffres rapides pour la mise en contexte, Bryan a ensuite donné quelques exemples de ce qui pouvait être fait pour atteindre cet objectif.

Ça a donné quelques exemples assez “drôles”, comme le fait qu’un admission controller ait été créé pour attendre la validation d’un JIRA pour mise en prod finale, ou alors l’usage intensif d’opérateur (concepts assez lourds, mais qui peuvent être indispensables pour aller au bout de la démarche d’autonomisation des devs quand aucune alternative sur étagère n’existe).

L’important est de séparer le travail pour rendre ce qui est livré “compliant” (qu’on peut “shift-left”) du fait de vérifier que le travail compliant a été fait (qu’on garde côté “ops”).

Building a Platform Engineering API Layer with kcp

Je suis arrivé alors que le talk avait déjà commencé, mais je pense avoir saisi la majorité du talk. Globalement, il s’agissait d’une présentation sur kcp, un outil open source permettant de segmenter un cluster Kubernetes en un ensemble de sous-clusters en forme d’arbre (via des workspaces).

On peut restreindre l’accès aux objets via héritage entre les branches de l’arbre et faciliter la création de plateformes par l’ajout d’API custom via des APIExports et des APIBindings.

Ce n’est pas totalement clair pour moi puisqu’il me manque un bout du talk mais j’imagine qu’un petit test sera le plus simple pour bien comprendre l’intérêt de l’outil dans la pratique.

Hands-on lab Sysdig

Après une pause bien méritée sur le rooftop avec mes collègues…

… Il était grand temps de se diriger vers le Courtyard by Marriot pour un “hands on lab” avec Sysdig, plein à craquer :

Avant de commencer le lab, un intervenant dont je n’ai pas enregistré le nom nous a fait un talk assez bien construit sur tout ce qu’il faut sécuriser quand on est sur le cloud

There is no “perimeter” in the cloud

You have to combine open source tools to get proper security in the cloud

Le problème le plus problématique étant que dans la majorité des cas, les incidents de sécurité dans le cloud sont dus à des erreurs humaines (permissions trop grandes, secrets leakés, …), il faut une combinaison de plusieurs outils pour s’en sortir.

Après un tour d’horizon de plusieurs solutions couvrant une partie du scope (snyk, notary, wolfi, …), l’intervenant a ensuite introduit Falco (développé par sysdig), l’un de ces outils.

Je connaissais l’outil donc je n’ai pas appris grand-chose (falco ne fait que détecter des comportements suspects, falcosidekick se charge des notifications, on doit ensuite agir via des outils tiers), mais la présentation était très bien faite et l’intervenant agréable à écouter. J’ai passé un très bon moment.

Le lab, en revanche était trop orienté super débutants et a eu un ou deux petits glitchs (429 sur les pulls, navigateurs figés…). Dommage

Quelques citations :

It takes 207 days for a company to realize there was a breach, 70 days to contain it In reality, you have 10 minutes to fix the problem

“I enjoy writing rego. Said no one ever”

Paas Forward

Pour terminer la journée, j’ai ensuite filé vers l’événement conjoint OVHCloud + Rancher (et Enix, AMD, Netapp, NVidia), Paas Forward.

Après un peu de networking, nous avons eu droit à des conférences pour présenter les nouveaux produits sortis conjointement par OVHCloud et Rancher (pour faire court, un Rancher managé). Le tout animé par Alex Williams, le fondateur de The New Stack.

On a fini la soirée par du networking à nouveau et un concert de Kungs. C’était sympa :) (mais trop fort x-o).

Chit-chat

Comme d’habitude, les conférences sont aussi un endroit parfait pour se retrouver, se rencontrer et discuter.

Entre hier soir et aujourd’hui, j’étais super content de pouvoir revoir ou rencontrer en vrai pour la première fois (après des échanges sur le net) Katia, Stéphane, Andrea, Aurèl, Jérôme, Réda, Smaine, Kévin, Olivier, Christian, Quentin, JC, Rachid, Jérôme (bis), Alan, Thomas, Olivier (bis), Thierry, Aurélie, Stéphane, la team frenchies sur Telegram, Alex, Sébastien, Fanny, Laurent, Boris, Rémi, Thomas (Bis) et tous les gens que j’oublie ou qu’on m’a présentés, car il est tard (bien trop pour écrire un article).

À demain pour le “vrai premier” jour !

Kubecon Europe 2024 on Zwindler's Reflection

Récap du dernier jour de Kubecon Europe 2024 - Vendredi

This is the end

Keynote: Success Not Guaranteed

Keynote: A 10-year Detour: The Future of Application Delivery in a Containerized World

Keynote Panel Discussion: Unity in Diversity: A Decade of Inclusive Growth in the Cloud Native Community

Three’s a Crowd: How to Achieve 2-Node HA at the Edge and Make Your CFO Smile

Trimaran: Load-Aware Scheduling for Power Efficiency and Performance Stability

Sponsors

Récap du deuxième jour de Kubecon Europe 2024 - Jeudi

Keynote: 🇫🇷 Hip, Hip, Beret! No Cap, Just Cloud Native Facts

Keynote Panel Discussion: Revolutionizing Cloud Native Architectures with WebAssembly

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

Kubernetes Controllers in Rust: Fast, Safe, Sane

Leveling up Wasm Support in Kubernetes

Keeping the Bricks Flowing: The LEGO Group’s Approach to Platform Engineering for Manufacturing

Make Your Cluster Fly: Embed a Multi-Node Kubernetes Cluster Inside an Aircraft Using Puppet & Flux

Blabla

Récap du premier jour de Kubecon Europe 2024 - Mercredi

Keynotes

Panel

Accelerating AI Workloads with GPUs in Kubernetes

10 Years of Kubernetes Patterns Evolution

Impossible de rentrer dans les salles

Podcast et Brussels Beer Project

Networking, again

Récap du premier jour de Kubecon Europe 2024 - Mardi - colocated events

Mardi

Platform Engineering day

Sometimes lipstick is just what a pig need

Beyond Platform Thinking at Ritchie Brothers - Build Things No One Expects, in a Place No One Expect

Sponsored Keynote: Crossplane - The Best Kept Secret in Platform Engineering - Bassam Tabbara, Upbound

Building a Platform Engineering API Layer with kcp

Hands-on lab Sysdig

Paas Forward

Chit-chat