Observability on Zwindler's Reflection

Un nouveau champ `log` pour les network policies Cilium : une idée de use case

Mon, 03 Nov 2025 12:00:00 +0200

TL;DR

Cilium 1.18 a ajouté un champ log aux CiliumNetworkPolicies pour taguer les verdicts de flux (FORWARDED, DROPPED, AUDIT, …) avec des labels personnalisés. Dans l’idée, c’est la fonctionnalité parfaite pour éviter de logger le trafic bloqué que l’on connait dans nos dashboards de monitoring !

Mais il y a un hic, sans rapport avec cette fonctionnalité, qui rend cette idée inutilisable : on ne peut pas l’utiliser avec egressDeny + toFQDNs.

ET, il y a un bug, qui fait que le “log” n’est visible que sur le trafic “autorisé”.

Je vous raconte…

Le problème : monitor all the things (mais pas trop)

Comme toute bonne équipe “ops” qui se respecte, nous monitorons/loggons les flux réseau de notre cluster Kubernetes avec Hubble pour une analyse ultérieure et de l’alerting. Nous (en particulier mon collègue Nicolas Nativel) poussons tous les flux AUDIT et DROPPED vers un dashboard Grafana pour pouvoir rapidement repérer quand quelque chose est bloqué et décider :

C’est légitime ? → On ouvre le flux
C’est suspect ? → On déclenche l’alarme 🚨

Ça fonctionne plutôt bien… jusqu’à ce qu’on commence à bloquer explicitement des choses qu’on sait devoir être bloquées.

Dans notre cas, nous voulions empêcher une application tierce d’envoyer les données de “télémétrie” (ouais, appelons ça comme ça 😏). On parle d’appels HTTPS vers des domaines de tracking externes.

Le problème ? Si on bloque simplement ces flux, ils apparaîtront comme DROPPED dans Hubble, déclencheront notre monitoring, et on se retrouvera avec des alertes pour quelque chose qu’on a intentionnellement bloqué.

C’est du bruit dont on ne veut pas.

Et donc, ce champ log des network policies de Cilium 1.18 ?

Bonne nouvelle ! Cilium 1.18 a introduit exactement ce dont nous avions besoin : la possibilité d’ajouter des champs de log personnalisés aux verdicts sur les network policies.

Cf. l’annonce dans le blogpost officiel.

L’idée est simple : vous ajoutez un champ log.value à votre CiliumNetworkPolicy :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: my-policy
spec:
 endpointSelector:
 matchLabels:
 app: my-app
 egress:
 - toFQDNs:
 - matchName: "example.com"
 log:
 value: "my-custom-log-tag"

Ensuite, quand vous observez les flux dans Hubble, vous pouvez les filtrer en utilisant CEL (Common Expression Language) :

hubble observe \
 --verdict AUDIT \
 --not \
 --cel-expression "(_flow.policy_log.endsWith('my-custom-log-tag'))" \
 --print-raw-filters

Output :

allowlist:
- '{"verdict":["AUDIT"]}'
denylist:
- '{"experimental":{"cel_expression":["(_flow.policy_log.endsWith(''my-custom-log-tag''))"]}}'

Parfait ! Vous savez maintenant taguer les calls que vous avez explicitement bloqués et les exclure de votre monitoring. 🎉

Le plan : bloquer la télémétrie élégamment

À l’aide de cette nouvelle fonctionnalité, nous avons élaboré notre stratégie :

Utiliser egressDeny pour bloquer explicitement les domaines de télémétrie
Ajouter un champ de log personnalisé : app-explicit-traffic-blocked
Configurer Hubble pour filtrer les verdicts de flux avec ce tag
Profit ! 🎉

Voici ce que nous avons essayé :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: app-external-block-policy
 namespace: my-namespace
spec:
 endpointSelector:
 matchLabels:
 app.kubernetes.io/name: my-app
 # note: egressDeny prend la précédence sur les règles egress
 # https://docs.cilium.io/en/stable/security/policy/language/#deny-policies
 egressDeny:
 # Bloquer tout le trafic externe et le logger avec un champ de log arbitraire
 # Ceci est utilisé pour empêcher l'app d'envoyer des données de télémétrie à l'extérieur
 # sans déclencher d'alerte AUDIT/DROPPED
 # fonctionnalité ajoutée dans cilium 1.18.0 https://github.com/cilium/cilium/pull/39902
 - toFQDNs:
 - matchPattern: "*.telemetry.example.com"
 toPorts:
 - ports:
 - port: "443"
 protocol: TCP
 - port: "80"
 protocol: TCP
 log:
 value: "app-explicit-traffic-blocked"

Ça devrait fonctionner, non ? On utilise egressDeny (qui prend la précédence sur les autres règles, ce qui est une bonne chose !), et on le tague avec notre log personnalisé.

Retour à la réalité

Et puis… patatra.

En lisant la documentation Cilium sur les deny policies, nous sommes tombés sur cette petite note de rien du tout :

Deny policies do not support:

policy enforcement at L7, i.e., specifically denying an URL

toFQDNs, i.e., specifically denying traffic to a specific domain name.

Attendez, quoi ?

On ne peut pas utiliser toFQDNs avec egressDeny. Tout notre plan vient de s’effondrer 😱.

Pourquoi c’est un problème, déjà ?

Le problème, c’est le modèle de précédence dans Cilium :

Les règles egressDeny prennent la précédence sur les règles egress (by design, et c’est bien !)
Mais si on utilise egressDeny, on ne peut pas utiliser toFQDNs pour cibler intelligemment le domaine incriminé, on doit bloquer par IP ou CIDR
Ces services de télémétrie utilisent probablement des IPs dynamiques pour leurs endpoints (bonne chance pour maintenir une liste…)
Et si on bloque tout le trafic 80/443 dans egressDeny, on ne peut pas faire d’exceptions pour le trafic légitime dans les règles egress car… deny prend la précédence sur allow !

On est coincé entre le marteau et l’enclume :

Utiliser egress avec toFQDNs → ça marche, mais on ne peut pas bloquer, seulement autoriser
Utiliser egressDeny avec des IPs → on va jouer au chat et à la souris avec des plages IP qui changent
Utiliser egressDeny pour bloquer tout le 80/443 → on bloque tout, y compris le trafic légitime

Solutions de contournement potentielles

En attendant que Cilium supporte toFQDNs dans les policies egressDeny, voici quelques approches alternatives que vous pourriez envisager :

Trouver un moyen de désactiver la télémétrie directement dans l’app

C’est la meilleure option, mais malheureusement pas toujours sur la table.

Blocage basé sur le DNS

Configurer le serveur DNS pour retourner NXDOMAIN pour les domaines de télémétrie, comme un serveur pi-hole personnel le ferait avec les pubs. L’application échouera à résoudre le domaine et n’enverra pas de données.

Utiliser egressDeny basé sur les IPs (avec un overhead de maintenance)

Résoudre les FQDNs de télémétrie vers leurs plages IP actuelles et les bloquer avec egressDeny :

egressDeny:
 - toCIDRSet:
 - cidr: 203.0.113.0/24  # Exemple de plage IP de télémétrie
 toPorts:
 - ports:
 - port: "443"

Si la liste n’évolue pas trop souvent, c’est une bonne option.

OK, mais imaginons qu’il n’y ait pas de trafic légitime. Peut-on utiliser la fonctionnalité pour ajouter un log sur le trafic droppé ?

Malheureusement non, pas pour le moment.

Il y a un bug dans cette nouvelle fonctionnalité de Cilium qui ne log le champ policy_log que sur les flux “autorisés”, pas sur les flux audit/dropped.

Policy log does not work for DROPPED/AUDIT flow ouverte par mon collègue Nicolas :

When defining a CiliumNetworkPolicy with the spec.log field configured, I expect the relevant hubble flows to have the policy_log field. It works for allowed flow.

But for denied/audited flow resulting from the rule (implicit or explicit), policy_log is never available.

Note: I observe the same issue with --print-policy-names option of hubble, the k8s:io.cilium.k8s.policy.derived-from label is not set for denied flows (but correctly set for allowed flows).

et une autre issue [Hubble CLI] –print-policy-names flag does not do anything ouverte par quelqu’un d’autre.

Puisque 2 tickets sont ouverts et que les mainteneurs ont commencé à répondre dessus, on peut espérer que ce soit corrigé un jour.

Conclusion

Dans notre cas d’usage, nous n’avons finalement pas utilisé cette nouvelle fonctionnalité de Cilium. Mais donner la possibilité d’ajouter des détails (et permettre de filtrer dessus également) est toujours une feature sympa.

Un grand merci à mon collègue Nicolas Nativel, qui a fait la majorité du travail autour des CiliumNetworkPolicies, incluant les dashboards, le travail exploratoire sur cette fonctionnalité, et a pris le temps de créer l’issue sur le repo Cilium.

Références

SLO, SLI, Error Budget et Critical User Journey expliqués simplement (et pourquoi ce ne sont pas des SLA !) (en plusieurs prompts)

Tue, 17 Jun 2025 18:00:00 +0200

NOTE IMPORTANTE : cet article a été généré par un LLM. Ceci va à l’encontre de règles que je me suis fixé pour ce blog (cf l’AI Manifesto).

Je pars du principe que si je ne prends pas la peine d’écrire moi-même le contenu de ce blog, vous ne devriez pas prendre la peine de le lire.

Je l’ai fait dans le cadre d’une expérience qui est décrite dans l’article suivant :

Réflexions sur le blogging technique à l’ère des LLMs

Cependant, je ne vous interdit pas de lire cet article ci (les informations qu’il contient sur les SLOs sont correctes), je veux juste que vous le fassiez en connaissance de cause ;-P.

Introduction : quand les devs découvrent le SRE

Suite à plusieurs discussions récentes avec des collègues développeurs, je me suis rendu compte que les concepts SRE comme les SLO, SLI et Error Budget restaient flous pour beaucoup d’entre eux. Pourtant, ces notions sont de plus en plus utilisées dans nos équipes, souvent sans qu’on prenne le temps de bien les expliquer.

C’est donc l’occasion parfaite pour revenir aux fondamentaux et expliquer ces concepts tels qu’ils ont été conçus à l’origine par Google. Car oui, il faut le rappeler : le SRE (Site Reliability Engineering) et tous les concepts associés ont été inventés par Google, plus précisément par Ben Treynor Sloss en 2003, bien avant que DevOps ne devienne populaire !

L’idée de Google était simple : et si on demandait à des ingénieurs logiciel de concevoir une équipe d’exploitation ? De cette approche sont nés des concepts révolutionnaires pour mesurer et gérer la fiabilité des services.

Fun fact : j’avais déjà abordé ces sujets dans mon talk sur le SRE en 2022, mais je me dis qu’un article dédié ne fait pas de mal pour clarifier les choses :-).

SLA vs SLO : ne mélangeons pas tout !

Avant de rentrer dans le vif du sujet, petit aparté important : ne confondez pas SLA et SLO !

Le SLA (Service Level Agreement), c’est un contrat, souvent avec des pénalités financières si pas respecté. Genre “si le service est en panne plus de X heures dans le mois, on vous rembourse Y€”. Le SLO (Service Level Objective), c’est un objectif interne que vous vous fixez pour la fiabilité de votre service.

La différence est importante : les SLA sont souvent moins stricts que les SLO pour avoir une marge de manœuvre. Si votre SLA c’est 99,9% de disponibilité, votre SLO interne sera peut-être à 99,95%.

Bon, maintenant qu’on a éclairci ça, rentrons dans le détail !

Critical User Journey : commencer par ce qui compte vraiment

Est-ce que le client est content d’utiliser le service ?

C’est LA question fondamentale. Et pour y répondre, il faut d’abord identifier les Critical User Journey (CUJ), autrement dit les parcours utilisateurs critiques.

Mais attention, quand on parle d’utilisateur dans le contexte SRE, ce n’est pas forcément l’utilisateur final ! Pour un service backend, l’utilisateur peut être le frontend qui fait les appels API. Pour une plateforme de CI/CD, ce sont les développeurs qui veulent livrer une nouvelle version. Pour une base de données, ce sont les applications qui l’interrogent.

Concrètement, ça veut dire quoi ? Prenons l’exemple d’une plateforme e-commerce. Les CUJ pourraient être : un utilisateur peut rechercher et consulter un produit, il peut ajouter un produit au panier et passer commande, il peut se connecter à son compte.

On ne va pas définir des SLO pour toutes les fonctionnalités (la page “À propos” de votre site, on s’en fiche un peu), mais se concentrer sur celles qui, si elles tombent en panne, vont vraiment énerver vos utilisateurs.

Et c’est là que ça devient intéressant : définir les CUJ, c’est souvent un exercice qui doit impliquer le business, pas seulement les équipes techniques. C’est eux qui savent ce qui rapporte de l’argent !

SLI : mesurer ce qui compte

Une fois qu’on a identifié nos CUJ, il faut les mesurer. C’est là qu’interviennent les SLI (Service Level Indicators).

Un SLI, c’est simplement une métrique qui indique si votre service fonctionne bien du point de vue de l’utilisateur. Les plus classiques sont la disponibilité (pourcentage de requêtes qui réussissent), la latence (temps de réponse du service), le débit (nombre de requêtes traitées par seconde) et la qualité (pourcentage de réponses correctes, sans erreurs de données).

L’idée clé ici, c’est de mesurer depuis le point de vue de l’utilisateur, pas depuis vos serveurs. Peu importe que votre CPU soit à 10% si l’utilisateur voit des erreurs 500 !

Quelques conseils pour choisir vos SLI

Pour vous aider à concevoir des SLI fiables, vous pouvez vous inspirer des méthodes USE et RED. USE (Utilization, Saturation, Errors) se concentre sur les ressources systèmes, tandis que RED (Rate, Errors, Duration) se concentre sur les requêtes. Ces frameworks vous donnent un bon point de départ pour identifier les métriques qui comptent vraiment.

Mais attention, un microservice ne doit pas avoir trop de SLI ! Trois ou quatre SLI bien choisies et qui ont un sens métier valent mieux qu’une dizaine de métriques que personne ne regarde. D’ailleurs, seuls les membres de l’équipe qui fournissent le service peuvent vraiment savoir quelles sont les métriques pertinentes. On ne peut pas imposer des SLI génériques à toute une entreprise !

Exemple concret pour notre CUJ “recherche de produit” : SLI disponibilité pourrait être (requêtes HTTP 200 sur /search) / (total requêtes sur /search) * 100, et SLI latence 95% des requêtes sur /search répondent en moins de X ms.

SLO : se fixer des objectifs réalistes

Maintenant qu’on sait quoi mesurer, il faut se fixer des objectifs. C’est le rôle des SLO (Service Level Objectives).

Un SLO, c’est tout simplement une valeur cible pour vos SLI sur une période donnée. Par exemple : “99,9% des requêtes de recherche doivent réussir sur une période de 30 jours” ou “95% des pages de recherche doivent s’afficher en moins de 500ms sur une période de 7 jours”.

Quelques conseils pour bien définir vos SLO

Commencez par mesurer l’existant. Inutile de viser 99,99% si votre service actuel est à 98%. Regardez vos métriques historiques et fixez-vous des objectifs atteignables mais ambitieux.

Pensez S.M.A.R.T. : vos SLO doivent être Spécifiques, Mesurables, Atteignables, Réalistes et Temporellement définis. Comme tout bon objectif !

Et n’oubliez pas que 100% c’est mal ! Comme le dit si bien Ben Treynor Sloss (le papa du SRE chez Google) :

100% is the wrong reliability target for basically everything

Plus on veut de “9”, plus ça coûte cher exponentiellement. Et au-delà d’un certain seuil, les utilisateurs ne voient même plus la différence ! Prenez l’exemple d’un site web qui ne charge pas sur un smartphone : au-delà d’un certain niveau de disponibilité, l’utilisateur ne saura pas dire si c’est son smartphone qui a un problème, son navigateur, le réseau 5G ou bien le site web qui rencontre un incident. Si recharger la page une fois de temps en temps suffit et que les utilisateurs ne sont pas plus impactés que ça, inutile d’investir dans plus de fiabilité.

Pour vous aider à calculer ces pourcentages et temps d’indisponibilité, vous pouvez utiliser uptime.is qui fait les conversions pour vous.

Error Budget : retourner le problème

Et là, c’est le moment où ça devient vraiment malin. Au lieu de raisonner en “disponibilité”, les équipes SRE raisonnent en Error Budget (budget d’erreur).

C’est un simple changement de perspective : service accessible 99,9% = service inaccessible 0,1% du temps. Sur 30 jours, ça fait environ 43 minutes d’indisponibilité “autorisée”.

Cette approche change complètement la donne ! Au lieu de voir les pannes comme des échecs, on les voit comme un budget à dépenser intelligemment.

Comment utiliser son Error Budget ?

Contre-intuitivement… IL FAUT L’UTILISER !

Si votre SLO est respecté (utilisateurs contents), vous pouvez “dépenser” votre error budget pour faire des déploiements plus risqués, tester des nouvelles fonctionnalités en prod, faire du chaos engineering, ou réaliser des maintenances disruptives.

À l’inverse, si vous “cramez” votre error budget (SLO pas atteint), alors là, stop : on arrête tout ce qui n’améliore pas la fiabilité du service !

C’est un formidable outil de priorisation entre les équipes produit (qui veulent des nouvelles features) et les équipes ops (qui veulent de la stabilité). Le fameux mur de la confusion :

Exemple concret : une API de recommendation

Bon, assez de théorie, prenons un exemple concret. Imaginons qu’on ait une API de recommandation de produits.

D’abord, on définit le CUJ : “Un utilisateur doit pouvoir récupérer des recommandations personnalisées en moins de 1 seconde”. Ensuite, on choisit les SLI : disponibilité (réponses HTTP 200) / (total requêtes) * 100 et latence P95 du temps de réponse.

Pour les SLO, on pourrait avoir : “99,5% des requêtes sur l’API de recommandation doivent réussir sur 30 jours” et “95% des requêtes doivent répondre en moins de 800ms sur 7 jours”.

Enfin, on calcule l’Error Budget : 99,5% de disponibilité = 0,5% d’indisponibilité autorisée, soit environ 3,6 heures d’indisponibilité “budgetées” sur 30 jours.

Simple, non ?

Les pièges à éviter

Le premier piège, c’est de vouloir mettre des SLO partout. N’essayez pas ! Commencez par 2-3 SLO sur vos CUJ les plus critiques. Vous pourrez étendre ensuite.

Le deuxième piège, c’est de fixer des SLO trop stricts. Si vous mettez la barre trop haut, vous allez passer votre temps en “SLO violation” et personne ne prendra plus ça au sérieux.

Enfin, le troisième piège, c’est d’oublier l’aspect organisationnel. Les Error Budgets ne marchent que si toute l’organisation (business inclus) adhère au principe. Sinon, vous aurez beau être en SLO violation, on vous demandera quand même de déployer la nouvelle feature…

Comment commencer ?

Si vous n’avez jamais fait de SLO, voici un plan d’action simple.

Identifiez d’abord 1-2 CUJ critiques (avec le business !). Regardez ensuite vos métriques actuelles sur ces parcours. Définissez alors des SLO réalistes mais un peu ambitieux. Mettez en place l’alerting quand vous êtes en train de consommer votre error budget. Et enfin, itérez ! Les SLO ne sont pas gravés dans le marbre.

Conclusion

J’espère que cet article vous aura donné envie de creuser ces concepts ! Les SLO/SLI/Error Budget ne sont pas juste des buzzwords, c’est vraiment un changement de paradigme dans la façon d’appréhender la fiabilité.

Et le plus beau, c’est que ça marche autant pour une startup avec 3 développeurs que pour une GAFAM avec 10000 ingénieurs. L’important, c’est de commencer simple et d’itérer.

Pour aller plus loin, je vous recommande chaudement le SRE Book de Google (gratuit !) et leur guide pratique pour définir des SLO.

Et si vous voulez approfondir le sujet SRE en général, n’hésitez pas à jeter un œil aux slides de mon talk de 2022 ;-).

Bon monitoring !

Récap FOSDEM 2025

Sat, 01 Feb 2025 12:00:00 +0200

Introduction

Si vous me suivez sur les réseaux sociaux, vous avez peut-être vu que j’étais pour la troisième fois au FOSDEM (Free and Open Source Software Developers’ European Meeting).

Contrairement aux années précédentes, cette fois-ci, le trajet et l’hôtel n’étaient pas payés par mon employeur. J’ai décidé d’y aller sur mes fonds propres. Pas de pression (Belgique, pression, bières, vous l’avez ? ok ok j’arrête, pas taper) donc pour faire de la veille techno intense et faire un récap’ professionnel.

Enfin ça, c’était le plan.

Mais je devrais mieux me connaitre que ça pour savoir que finalement, j’ai passé deux jours aussi intenses que les années précédentes (voire plus ?).

Je sirote donc ce qu’il me reste de club maté pour vous écrire ces quelques lignes (ahahah ~13000 signes).

Vendredi soir, FOSDEM before FOSDEM

Preuve qu’on finit toujours par apprendre de ses erreurs, je suis arrivé “tôt” cette année. J’étais au centre de Bruxelles à 18h, ce qui m’a permis de prendre quelques bières avec deux groupes d’amis différents sans pour autant me coucher trop tard.

Car c’est beaucoup ça en fait le FOSDEM, des discussions autour d’une boisson froide (alcoolisée ou pas)

(mais souvent alcoolisée, et d’ailleurs ça me fait beaucoup réfléchir depuis quelques mois)

Samedi

Malgré une heure de coucher raisonnable (minuit et quelques), je n’ai pas réussi à aller voir le premier talk que je souhaitais voir (problématique dont je vais avoir besoin, pour le travail 🫣).

Cache me if you can: P2P Image Sharing in Kubernetes with Spegel

En réalité, j’étais absorbé dans une intense discussion sur l’optimisation de clusters Ceph pendant le petit déjeuner de l’hôtel (vraiment, aller au FOSDEM dans l’idée de ne pas bosser, c’est raté sur toute la ligne xD).

Mais j’irai voir le replay, car j’en ai eu de bons échos.

A new cgroup cpu.max.concurrency controller interface file

En revanche, j’étais à l’heure pour le talk suivant, qui était un lightning talk de Mathieu Desnoyers pour promouvoir une initiative visant à ajouter un nouveau type de cgroup.

L’idée principale est qu’aujourd’hui, surtout sur des machines bare metal pouvant avoir des centaines de cores, restreindre un container à une quantité donnée de cores par seconde n’a plus vraiment de sens, car cela peut correspondre à plein de cores pendant un très court instant ou alors un seul core pendant 1 seconde.

Un peu rude de commencer sur ça, mais le problème et la proposition de résolution était plutôt bien présentée. À suivre !

Slides

Bringing application containers to Incus

Ceux qui me connaissent savent que je suis un fan inconditionnel de LXC (j’ai écrit beaucoup d’articles sur ce sujet). Et même si j’ai peu creusé LXD (forké par la communauté en “Incus” après une décision controversée de Canonical), je suis les évolutions avec attention (j’avais d’ailleurs vu un talk à ce sujet au FOSDEM l’an dernier).

Cette année encore, j’ai aimé ce talk de Stéphane Graber. Il nous a parlé d’ajouter des containers applicatifs (au format OCI) dans Incus.

En effet, un des avantages d’Incus est de pouvoir gérer plusieurs types de workloads, containers LXC ou machines virtuelles plus classiques, mais il n’y avait pas de support explicite des containers au format OCI (“Docker” par abus de langage). L’idée principale derrière cet ajout réside dans le constat qu’aujourd’hui beaucoup d’applications sont livrées dans ce format et que les repackager pour Incus est un travail fastidieux (et inutile), et que faire du nested-Docker n’a pas vraiment de sens.

En soi, il ne devait pas manquer grand-chose puisque LXC supporte déjà les images au format OCI depuis un moment. C’est d’ailleurs le hack que j’utilise dans mon article phare (comment je me la pète ?!) :

Lancer des containers Docker avec Proxmox VE (et LXC)

À tester :)

Tags pour moi-même : umami et skopeo

Writing a kubernetes controller… But in Rust

Pour le troll (mes collègues comprendront) et un peu par curiosité, je suis resté pour le talk d’après vantant les mérites de Rust pour écrire un controller dans Kubernetes plutôt que Golang (ou autre, d’ailleurs).

J’ai trouvé le discours de Danil un peu confus et j’ai eu du mal à suivre, car j’étais très loin et les exemples de codes étaient en darkmode… L’exemple ci-dessous n’est même pas le pire, certains bouts de code dans les slides suivantes, en rouge sur noir, étaient illisibles, même en zoomant :

Note aux aspirants/aspirantes speakers, dans un amphi éclairé, le dark mode, c’est illisible.

State of Checkpoint/Restore in Kubernetes

Un des talks que je VOULAIS voir, et au final, j’ai été un peu déçu (pas par le speaker, vous allez comprendre). Là encore, c’était la suite d’un sujet de talk que j’avais vu ailleurs.

Pour celles et ceux qui ne voient pas trop de quoi on parle, il s’agit de mettre en place le tooling nécessaire pour être capable de migrer des containers à chaud d’une machine à une autre.

Ça nécessite d’abord de pouvoir prendre une “photo” de l’état du container (le checkpoint) avant migration (aussi bien les metadatas que les données du container), puis de savoir restaurer cet état à l’identique sur une autre machine (restore).

Ça peut aussi servir à sauvegarder des containers, ou à faire du forensic dessus en cas d’attaque par exemple.

TL;DR : ça n’a quasiment pas avancé.

Et Adrian Reber nous a expliqué pourquoi. Une grande partie de la communauté Kubernetes considère (à tort à mon avis) que les containers qui tournent dans Kubernetes sont stateless et si un hôte meurt et qu’on doit redémarrer tout ses containers, ce n’est pas grave.

Or, il y a de très nombreux contre-exemples à cette affirmation. C’est faux pour les bases de données ou les bus de messages (même si on peut contourner le problème avec du clustering), les containers stateless mais qui ont des longues connexions qui se font trancher en cas de kill, ou même les traitements de machine learning qui peuvent durer des heures.

Pour tous ces usages, tuer le container pour le redémarrer ailleurs est potentiellement pénible / disruptif pour l’utilisateur (pas forcément final). Et je suis un peu chagrin qu’on en soit qu’à passer en Beta (2024) et qu’il n’y ait pas encore de support dans kubectl de cette techno réclamée depuis 2015 !!!

Immutable All the Way Down - using System Extensions to ship Kubernetes

Ce talk de Thilo Fromm n’était pas du tout ce à quoi je m’attendais. À vrai dire, je ne savais pas à quoi m’attendre (je n’avais pas lu l’abstract, je ponçais juste ma chaise d’amphi).

J’ai découvert les SysExt (petit nom des System Extensions), un outil permettant de créer des systèmes d’exploitation immutables et composables, compatible avec tous les OS du moment qu’on a systemd (le speaker a utilisé Flatcar et Kubernetes).

C’était assez inattendu et intéressant. Et malgré quelques glitchs pendant les diverses démos, le speaker a bien su montrer les intérêts de l’outil, à savoir la composabilité du système, la possibilité de décorréler OS sous-jacent et application (separation of concerns), les mises à jour à chaud.

Je ne suis pas sûr d’avoir un use case intéressant en tête, mais c’était une bonne découverte.

Tag pour moi-même : kured

14 years of systemd

La tête bien farcie de talks (certains ont été omis, car je n’ai pas grand-chose à dire dessus), grande pause.

Puis, probablement LE talk de la journée.

Dans le plus grand amphi du FOSDEM et une salle comble, Lennart Poettering, le créateur de systemd, a fait un petit retour sur la création et les perspectives pour le futur d’un des outils les plus controversés dans Linux.

Let’s have a look back at the tumultuous beginnings, how we became what we are now, and let’s talk a bit the perspective for the future, what systemd is supposed to be in the eyes of its developers – and what it shouldn’t be.

C’était un talk intéressant même si on n’est pas toujours d’accord avec cette personnalité clivante. Il permettait de remettre un peu de contexte et d’avoir le point de vue de Lennart lui-même, en opposition aux seuls discours pas toujours très objectifs à l’encontre de systemd, mais qui sont les seuls qu’on entend sur les réseaux sociaux.

Seul bémol, je n’ai pas pu aller voir le talk sur metal-stack.io et je n’ai pas eu le courage d’aller voir autre chose après ça.

On prem Kubernetes at scale with metal-stack.io

Fin de journée autour de quelques gaufres et boissons.

Dimanche

Réveil prévu un peu plus tôt dimanche, de manière à arriver à l’heure pour les premiers talks en “room observability” :

Discovering the Magic Behind OpenTelemetry Instrumentation

Spoiler alert: je n’ai quand même pas réussi à arriver à l’heure xD, donc j’en ai profité pour aller faire un tour de loot stickers/goodies.

Prometheus Version 3

J’ai réellement commencé la journée avec un talk que je n’étais pas spécialement pressé de voir, parce que j’étais persuadé (vu le changelog) qu’il n’y avait rien de bien foufou (et donc rien à apprendre) dans cette version majeure de Prometheus.

Et finalement, c’était plutôt intéressant, mais plus par curiosité que par le niveau technique.

De ce que je comprends après ce talk, cette v3 (majeure donc) était surtout l’occasion de faire passer tous les “breaking changes” accumulé au fil des ans, ainsi que toutes les améliorations cachées derrière des features flags qui auraient pu être activée par défaut, mais ne l’étaient pas par souci de rétro compatibilité. Ca dit quelque chose de la gouvernance du projet.

À revoir, si vous dans l’écosystème Prom.

The performance impact of auto-instrumentation

Mon talk préféré de la (courte) journée. A l’aide de “benchs” (même s’il refuse de parler de ces tests empiriques de cette façon), James Belchamber nous a montré les ordres de grandeurs qu’on peut espérer voir à propos de l’impact de l’instrumentation manuelle et automatique sur divers types de codes.

Le talk était vraiment très agréable et le speaker n’a malheureusement pas pu finir (trop de contenu).

Les take aways :

Zero code distributed traces for any programming langage

Le talk au résultat inattendu du jour, pour moi, c’était celui-ci. Le titre était prometteur : pourquoi faire de l’observabilité auto-instrumentée pour tous les langages sans efforts, je signe tout de suite (au travail…).

Ce talk était une présentation de Beyla, un outil de Grafana Labs, dont le but est d’auto-instrumenter tout type de code à l’aide d’eBPF.

On sent la hype venir et malheureusement, ça n’est au final que ça : de la hype.

J’ai aimé le côté candide du talk, les difficultés rencontrées ont été expliquées sans tabous, les limitations (nombreuses) explicitement listées.

Mais clairement, ça ne me donne pas envie de tester l’outil, et encore moins d’y participer.

L’ultime blague étant justement que les speakers ont lourdement insisté sur le fait qu’il fallait qu’on vienne contribuer, ET qu’ils voulaient refiler le bébé à la CNCF.

Comme un grand singe a dit :

Je ne dirais pas que c’est un échec, je dirais que ça n’a pas marché.

This is the end

Après ça, j’ai décidé d’aller manger des frites bien méritées et la pause est passée très vite. Tellement vite qu’il était finalement temps de récupérer ma valise et d’aller à la gare pour le retour.

Pas de chance, j’aurais aimé voir quelques autres talks, mais pour pouvoir rentrer à une heure raisonnable sur Nantes (car, j’enchaine avec un déplacement pro), c’était impossible.

Mastering Observability with SigNoz -> Open-Source Alternative for Metrics, Logs, and Traces
The Art of Fleet-Wide Kubernetes Observability: 3 Core Strategies

Cette édition, j’ai l’impression d’avoir beaucoup plus profité des gens (des amis de longue date, des anciens collègues, des personnes qui connaissent mon blog, des amis/amies speakers, des bénévoles sur les stands, ou même des inconnus qui m’ont abordés au hasard des couloirs)

Notamment parce que :

je suis arrivé “tôt” la veille
je suis venu “de ma poche”, et pas pour le travail (mais si ça y ressemble beaucoup)

Je pense que ces deux points sont importants et à retenir. Je réalise que j’ai de la chance de pouvoir me payer ce genre de week-end sans trop y penser (tout le monde n’a pas cette chance), et que je devrais en profiter.

Pour finir, je vous laisse sur quelques photos en vrac de ce week-end (une fois de plus) mémorable.