FoundationDB a rendu cette idée célèbre. Au lieu de s'appuyer seulement sur des tests unitaires et des tests end-to-end sur un vrai cluster, le projet exécute des workloads distribués dans un monde simulé, où le temps, les fautes réseau, les pannes de processus et les décisions d'ordonnancement peuvent être explorés puis rejoués à partir d'une seed. TigerBeetle pousse une discipline complémentaire : rendre les invariants explicites dans le code, vérifier en continu la forme de l'état et transformer une corruption silencieuse en panne locale et bruyante.

Chez Clever Cloud, nous appliquons cette direction à des logiciels d'infrastructure en Rust. Moonpool, développé par Pierre Zemb, donne aux systèmes Rust un environnement de simulation déterministe où le temps, le réseau, les tâches, l'aléa et le stockage peuvent être virtualisés derrière des traits de providers. Magnetar est l'application de cette approche à un client Apache Pulsar. C’est d’ailleurs, l’approche que nous prenons au sein de notre reverse proxy Sōzu. 

Magnetar est un driver Apache Pulsar écrit en Rust, depuis zéro. Il repose sur un coeur protocolaire sans-io, un moteur de production Tokio et un moteur Moonpool pour la simulation déterministe. Cette première release publique s'adresse aux ingénieurs qui veulent essayer Magnetar, évaluer son architecture, comparer son comportement avec les clients Pulsar existants et contribuer à structurer un écosystème Pulsar Rust plus solide.

L'objectif n'est pas seulement d'exposer une API Rust autour de Pulsar. L'objectif est de construire un client dont les comportements difficiles peuvent être inspectés, rejoués et forcés à échouer avant que la production ne s'en charge.

Un client Pulsar fait partie du système distribué

On pourrait être tenté de considérer une bibliothèque cliente comme la partie simple d'un système distribué. Le broker porterait la réplication, le stockage, l'ownership et la coordination. Le client se contenterait de se connecter, d'envoyer des messages, d'en recevoir et de les acquitter.

Cette vision ne tient pas face à un vrai client Apache Pulsar.

Un client Pulsar sérieux doit gérer les producers, consumers, readers, topics partitionnés, consumers multi-topics, subscriptions par pattern, transactions, schémas, authentification, routage proxy, lookup broker, failover de cluster, reconnect, backoff, batching, chunking, ack grouping, suivi des messages non acquittés, negative acknowledgements, retry-letter et dead-letter flows, observabilité et une longue liste de Pulsar Improvement Proposals.

Les bugs difficiles ne viennent pas seulement d'une commande mal encodée. Ils viennent souvent du temps et de l'ordre. Un broker tombe pendant qu'un publish est en vol. Une reconnexion arrive alors qu'un consumer a des acknowledgements en attente. Un refresh de token se produit pendant un reset de session. Un lookup via proxy pointe vers un nouveau broker alors que l'ancienne connexion se vide encore. Un topic migre et le client doit reconstruire assez d'état pour continuer sans prétendre que l'ancienne session existe toujours.

Cela signifie qu'un client Pulsar n'est pas seulement un wrapper pratique autour d'une socket. Il fait partie du système distribué. Il possède un état qui doit rester cohérent pendant que le monde autour de lui change.

Si cet état est caché dans des tâches runtime, des files de channels, des horloges implicites et des accidents de timing, alors le client devient plus difficile à raisonner précisément au moment où cette précision compte le plus. Magnetar part de l'hypothèse inverse : rendre l'état protocolaire explicite, le piloter à travers des frontières étroites et garder l'I/O à l'extérieur.

De l'écosystème Pulsar Rust à Magnetar

Magnetar vient d'une expérience concrète avec l'écosystème Pulsar Rust, notamment la maintenance et l'usage de pulsar-rs. Ce travail compte. Il a donné aux utilisateurs Rust un client Apache Pulsar et a créé le contexte pratique dans lequel l'étape suivante pouvait être évaluée.

Magnetar n'est pas une critique de ce qui existait avant lui. C'est une continuation du même écosystème, avec un point de départ architectural différent. Après avoir travaillé sur des usages Pulsar réels, la direction est devenue plus claire : un driver Pulsar Rust doit rendre la frontière protocole/runtime plus nette, rendre les comportements difficiles reproductibles, suivre la parité explicitement et faire de la testabilité une contrainte de conception.

C'est pourquoi Magnetar ne commence pas par le builder public. Il commence par le protocole.

L'API utilisateur compte, et cette première release expose déjà une surface large. Mais pour un client distribué, la question plus profonde est ce qui se passe sous cette API lorsque le broker bouge, que la connexion tombe, que l'horloge avance, qu'un timeout se déclenche, qu'une subscription est reconstruite ou que la même trace est rejouée sous un autre runtime.

Le coeur sans-io

Le coeur de Magnetar est magnetar-proto. C'est une machine d'état protocolaire synchrone. Elle n'a pas de socket. Elle ne dépend pas de Tokio. Elle ne lance pas de tâches. Elle n'utilise pas async. Elle ne lit pas l'horloge hôte sur le chemin chaud du protocole.

Sa forme suit la même idée générale qui a rendu quinn-proto influent dans le monde réseau Rust : injecter des octets, récupérer des octets à transmettre, récupérer des événements sémantiques et demander à la machine d'état quand son prochain timer expire.

Conceptuellement, l'interface ressemble à ceci :

> connection.handle_bytes(now, bytes);

connection.poll_transmit(&mut out);
connection.poll_event();
connection.poll_timeout();

Cette petite forme est un grand choix d'architecture.

handle_bytes permet à un moteur d'injecter les octets du wire dans la machine d'état. poll_transmit draine les frames sortantes. poll_event produit les événements sémantiques auxquels le runtime doit réagir : challenges d'authentification, résultats de lookup, checksum mismatch, signaux de reconnexion ou transitions protocolaire. poll_timeout permet au runtime de savoir quand réveiller la machine d'état.

La machine d'état ne décide pas d'où viennent les octets. Elle ne sait pas si le réseau est un vrai stream TCP, un stream TLS, un pipe d'octets dans un simulateur ou un broker scripté dans un harnais différentiel. Elle ne décide pas non plus ce que "maintenant" veut dire. Le moteur lui passe le temps.

Les traits publics de magnetar-proto suivent la même règle. Ce ne sont pas des services runtime cachés derrière des callbacks async. Ce sont de petits contrats protocolaires, placés aux endroits où la machine d'état a besoin d'une décision ou d'une transformation : AuthProvider produit les octets d'authentification, Schema définit l'encodage, le décodage, les données de schéma et les hooks de schéma résolu par le broker, MessageEncryptor et MessageDecryptor décrivent la crypto de payload sur des octets et de la metadata de message, ServiceUrlProvider expose l'URL de service courante pour le failover, et HealthProbe utilise un contrat de type poll au lieu d'attacher le crate protocolaire à un runtime async. Le motif est volontaire : le coeur protocolaire peut demander des faits, des octets ou un état de readiness, tandis que l'I/O, le cache, le refresh, les probes réseau et le scheduler restent à l'extérieur.

Cette séparation n'est pas seulement une affaire de propreté. C'est ce qui rend le protocole testable sans broker, sans socket et sans runtime async. Un bug protocolaire peut être réduit à une fixture : injecter ces octets à cet instant, récupérer ces sorties, vérifier cet event stream et rejouer la même séquence.

Pour un client Apache Pulsar, cela compte parce que le protocole wire ne se limite pas au chemin heureux. Il comprend la création de producers, la subscription de consumers, les acks, nacks, transactions, erreurs broker, redirects, challenges d'authentification, migrations de topics, markers de replicated subscriptions, metadata de schémas, batching, chunking et chemins de fermeture. Chacun de ces éléments porte de l'état. Chaque transition d'état est plus facile à raisonner lorsqu'elle n'est pas mélangée aux lectures de socket, au scheduling de tâches et aux wakeups spécifiques d'un runtime.

L'interdiction des channels comme contrainte d'architecture

Magnetar fait aussi un choix Rust async peu courant : les primitives de channels sont interdites dans le workspace.

L'architecture directe d'un client réseau ressemble souvent à ceci : future producer vers channel, channel vers driver task, driver task vers channel, channel vers future consumer. Cela peut fonctionner, mais cela disperse l'état entre des files et des tâches. La backpressure devient implicite. Les sémantiques de fermeture dépendent de la bibliothèque de channel. Des futures abandonnées peuvent laisser des messages dans des endroits difficiles à inspecter. La question de debug devient : où est passé ce message ?

Magnetar utilise un autre motif. L'état vit dans la machine d'état protocolaire et dans la connexion partagée détenue par le runtime. Les futures utilisateur enregistrent des wakers dans des slabs indexés par identifiants d'opération. Le driver possède la boucle d'I/O, injecte les octets dans la machine d'état, draine les frames sortantes et réveille les futures correspondantes lorsque les outcomes arrivent.

Ce n'est pas une interdiction esthétique des channels. C'est une manière de garder la propriété de l'état explicite. Lorsque le driver reconstruit des producers après une reconnexion, lorsqu'un consumer attend un message, lorsqu'un ack outcome est livré ou lorsqu'une opération en attente échoue parce qu'une session a disparu, l'état pertinent est dans la machine d'état et peut y être inspecté.

Ce design a des compromis. Il met plus de pression sur la correction de la machine d'état. Il impose un ordre de locks précis. Il demande aux reviewers de comprendre l'enregistrement des wakers et les chemins de réveil. Mais il rend aussi le comportement beaucoup plus facile à simuler, rejouer et comparer entre runtimes.

Deux moteurs, une machine d'état

Magnetar livre deux moteurs qui pilotent le même coeur protocolaire.

Le moteur par défaut est magnetar-runtime-tokio. C'est le chemin d'exécution de production : TCP, TLS via tokio-rustls, tâches driver, temps réel, vraies sockets et surface publique PulsarClient que la plupart des utilisateurs rencontreront en premier.

Le second moteur est magnetar-runtime-moonpool. Il pilote la même machine d'état magnetar-proto::Connection à travers des providers Moonpool. Au lieu d'inscrire le runtime en dur, Moonpool expose des traits de providers pour le réseau, le temps, le spawning de tâches, l'aléa et le stockage. Avec un bundle de providers proche de la production, le moteur peut exécuter de vraies I/O. Avec des providers de simulation, ces mêmes catégories peuvent être virtualisées.

C'est là que la simulation déterministe devient pratique. Le client peut être piloté dans un monde où le temps avance sous contrôle, où les livraisons réseau peuvent être réordonnées ou interrompues, où les tâches s'exécutent sous un scheduler déterministe, où l'aléa est seedé et où les pannes peuvent être rejouées depuis la même seed.

Moonpool n'est pas un mock. Un mock remplace généralement un composant par un comportement simplifié. C'est utile pour beaucoup de tests unitaires, mais ce n'est pas la même chose que d'exercer un vrai client dans des interleavings difficiles.

Moonpool n'est pas non plus un test end-to-end classique. Un e2e exécute le vrai système, ce qui est indispensable, mais il utilise souvent du temps réel, un vrai réseau et des pannes difficiles à reproduire une fois le timing passé.

Moonpool occupe un autre espace. Il garde le code proche du chemin réel d'exécution tout en virtualisant les providers qui rendent le comportement distribué difficile à reproduire. Le but n'est pas d'éviter les e2e. Le but est d'ajouter un régime où les pannes ne sont plus des anecdotes. Elles deviennent des seeds.

Le moteur Moonpool de Magnetar utilise la même machine d'état protocolaire que le moteur Tokio. Le chemin TLS est lui aussi piloté de façon à préserver la frontière de simulation : au lieu de s'appuyer sur tokio-rustls, le moteur Moonpool pilote directement rustls::ClientConnection au-dessus du pipe d'octets. Cela maintient les handshakes TLS sous le même contrôle déterministe que le reste du réseau simulé.

Tests différentiels : faire converger les moteurs

Deux moteurs ne sont utiles que s'ils ne deviennent pas silencieusement deux clients différents.

Magnetar inclut donc un harnais différentiel. Il exécute une trace, par exemple connect, open producer, send, subscribe, receive, ack, seek et close, contre les moteurs Tokio et Moonpool, puis compare les event streams visibles par l'utilisateur.

Cela compte parce que le moteur Moonpool sert à trouver des bugs difficiles à exposer avec du temps réel et de vraies sockets. Pour que cette recherche ait du sens, le moteur simulé doit rester aligné avec le moteur de production à la frontière utilisateur.

Si Tokio et Moonpool divergent, le simulateur devient moins fiable. Si le harnais différentiel les maintient alignés, alors une seed rouge dans le monde simulé pointe beaucoup plus probablement vers une propriété réelle du client, et non vers une implémentation séparée réservée aux tests.

C'est aussi pour cela que la politique de validation de Magnetar est stricte sur la couverture cross-runtime. Les changements comportementaux doivent exercer la couche sans-io, le runtime Tokio, le runtime Moonpool, l'équivalence différentielle et la surface e2e lorsque c'est applicable. C'est plus de travail qu'un seul test unitaire. C'est aussi le coût pour faire de la simulation déterministe un vrai outil d'ingénierie, pas une expérience annexe.

La parité Java comme contrat de crédibilité

La simulation ne remplace pas la largeur fonctionnelle. Elle rend cette largeur moins fragile.

Apache Pulsar possède un client Java mature, et pour beaucoup d'utilisateurs ce client définit ce que signifie "un client Pulsar". Le produce/consume de base ne suffit pas. Un client crédible doit couvrir les comportements sur lesquels les applications s'appuient : batching, compression, transactions, schémas, topics partitionnés, consumers multi-topics et par pattern, retries, dead-letter flows, providers d'authentification, support proxy, failover, opérations admin et PIPs qui structurent les usages modernes de Pulsar.

Magnetar suit la parité avec le client Java comme un contrat public. Le README porte la matrice de parité et le statut moteur par moteur. L'article n'a pas besoin de recopier cette matrice, mais son existence est importante. Elle donne aux utilisateurs un moyen d'évaluer le projet comme client Pulsar, et non comme une expérience étroite autour d'un seul chemin heureux.

C'est pourquoi la première release publique de Magnetar est plus large qu'une démo minimale. Elle inclut la fondation protocolaire, la façade publique, les moteurs runtime, le support admin, les providers d'authentification, la crypto de messages, le travail CLI, les hooks d'observabilité et une liste croissante de surfaces PIP.

La raison de suivre la parité est simple : les utilisateurs ne choisissent pas une bibliothèque cliente uniquement parce que son architecture interne est élégante. Ils la choisissent parce qu'elle peut représenter le système qu'ils exécutent réellement. L'architecture rend cette surface maintenable. La parité la rend utile.

Au-delà de la production et de la consommation

L'expression "client Pulsar" peut masquer une large surface fonctionnelle. Vus de l'extérieur, les premiers exemples paraissent généralement modestes : construire un client, créer un producer, envoyer un payload, souscrire avec un consumer, recevoir un message, l'acquitter. Ces exemples sont utiles parce qu'ils montrent le point d'entrée. Ils ne suffisent pas à évaluer le client.

Les vraies applications Pulsar dépendent de comportements qui n'apparaissent qu'une fois la première démo fonctionnelle. Un producer peut avoir besoin de batching, de compression, de chunking, de modes d'accès, de sequence ids, de timeouts d'envoi, de propriétés par message, de transactions, d'interceptors et de statistiques de latence. Un consumer peut avoir besoin de batch receive, d'acquittements cumulatifs, d'acquittements par index de batch, de nack backoff, de gestion des timeouts d'ack, de retry topics, de dead-letter topics, de seek, de pause/resume, de modes de souscription et de comportements par partition. Les applications avec des schémas stricts ont besoin d'Avro, de JSON, de Protobuf, de Protobuf-native, de KeyValue, de schémas primitifs et de la sémantique de résolution de schéma côté broker. Les déploiements avec des exigences de sécurité ont besoin d'authentification par token, de mTLS, d'OAuth2, de SASL, de Kerberos/GSSAPI, d'Athenz, de choix de provider TLS, et d'un moyen de raisonner sur le comportement de la crypto sans forcer chaque build à embarquer tous les providers.

Ces fonctionnalités ne sont pas des cases à cocher indépendantes. Elles interagissent. Le batching interagit avec la compression et les timeouts d'envoi. Le chunking interagit avec les sequence ids et la redélivrance. Les transactions interagissent avec les acquittements. La reconnexion interagit avec les producers, les consumers, les lookups, le routage proxy et le failover. L'observabilité doit décrire le comportement sans laisser fuiter de secrets ni noyer les opérateurs en période de churn.

C'est pourquoi le travail fonctionnel et le travail d'architecture de Magnetar sont liés. Plus la surface devient complète, plus il est important que l'état protocolaire soit explicite et que la frontière avec le runtime reste étroite. Un client large bâti sur un état accidentel devient plus difficile à maintenir à mesure qu'il devient plus utile. Un client large bâti sur un état rejouable donne aux mainteneurs une meilleure chance d'empêcher la croissance fonctionnelle de se transformer en comportement caché.

La validation comme architecture

La stratégie de test de Magnetar est volontairement stratifiée, parce que chaque couche attrape une classe différente de bugs.

La couche sans-io permet de tester le comportement protocolaire sans sockets ni tâches async. La documentation de test du projet mentionne aujourd'hui plus de 270 tests unitaires dans magnetar-proto. Ces tests exercent directement la machine d'état : octets en entrée, événements en sortie, buffers de transmission en sortie, transitions d'état vérifiées.

Les tests d'intégration runtime exercent la colle que les tests purement protocolaires ne peuvent pas couvrir. Les moteurs Tokio et Moonpool ont chacun leur surface d'intégration, et le projet impose une parité runtime afin qu'un moteur ne prenne pas silencieusement du retard sur l'autre.

Le pack de chaos déterministe cible les ordonnancements de panne qui ont motivé l'architecture : reconnect, failover, timers en horloge virtuelle, ordre des handshakes TLS, publishes en vol, migration de broker et comportements réseau adversariaux. La documentation du moteur Moonpool décrit un sweep Moonpool quotidien avec 128 seeds aléatoires fraîchement générées en parallèle. Le chiffre compte moins que ce qu'il représente : le client est poussé dans des ordonnancements qu'un humain n'écrirait pas à la main.

Les tests d'équivalence différentielle comparent les deux mondes runtime. Ils posent une question directe : si la même trace est exécutée dans Tokio et Moonpool, l'utilisateur observe-t-il le même comportement ?

Les tests end-to-end restent nécessaires. Ils gardent Magnetar honnête face à un vrai broker Apache Pulsar. La simulation rend des pannes reproductibles, mais elle ne remplace pas la compatibilité avec le système que les utilisateurs déploient.

Ensemble, ces couches ne sont pas une cérémonie. Elles font partie de l'architecture. Le but n'est pas d'accumuler de grands nombres de tests. Le but est d'appliquer la pression de validation exactement là où les clients distribués échouent : état protocolaire, frontières runtime, logique de reconnexion, timing, équivalence et comportement face à un vrai broker.

Ce que la reproductibilité change concrètement

La valeur pratique de la simulation déterministe n'est pas seulement de rendre les tests plus sophistiqués. Elle change la boucle de debug.

Lorsqu'un test end-to-end traditionnel échoue à cause du timing, la première question est souvent de savoir si l'échec est reproductible. S'il ne l'est pas, on ajoute des sleeps, des logs, des timeouts plus larges ou des boucles de retry. Certaines de ces modifications sont utiles. Beaucoup ne font que déplacer la panne ailleurs. La panne reste une histoire : "on l'a vue une fois en CI".

Avec une simulation déterministe, la panne doit devenir un artefact. Cet artefact est une seed, une trace et une transition d'état rejouable. La question passe de "peut-on la refaire apparaître ?" à "quel invariant cet ordonnancement a-t-il violé ?"

Cette différence compte pour une bibliothèque cliente. Les bugs de client se trouvent souvent à la frontière entre le code utilisateur et le broker. Ils sont faciles à attribuer au mauvais endroit. Un publish peut échouer parce que le broker a fermé la connexion, parce que le client a perdu un outcome, parce que le chemin de reconnexion a reconstruit le producer trop tard, parce qu'un ack a réveillé le mauvais waiter, parce qu'un timeout a frappé un état de session périmé, ou parce que la tâche runtime est morte après que le protocole a déjà changé d'état.

Si tout ce comportement est dispersé entre des tâches, des channels, des timers et des sockets, un rapport de panne est difficile à réduire. Si la machine d'état protocolaire est explicite, si la frontière runtime est étroite et si la même séquence peut être rejouée avec des providers contrôlés, le rapport devient beaucoup plus petit : cette seed, cette trace, cet ordre d'événements, cet invariant.

C'est pourquoi Magnetar traite la reproductibilité comme une partie du design du client. Le but n'est pas seulement de trouver plus de bugs. Le but est que les bugs trouvés coûtent moins cher à comprendre et soient plus sûrs à corriger.

Cela change aussi la revue de code. Un reviewer peut demander si un comportement est couvert à la bonne couche. Est-ce une transition protocolaire pure ? Alors le test sans-io doit injecter des octets et vérifier des événements. Est-ce de la colle runtime ? Alors Tokio et Moonpool doivent avoir une couverture équivalente. Est-ce un comportement observable partagé par les deux moteurs ? Alors le harnais différentiel doit comparer les event streams. Est-ce de la compatibilité broker ? Alors un e2e doit toucher un vrai broker Pulsar.

Ces questions sont plus précises que "a-t-on ajouté des tests ?" Elles relient le test au modèle de panne.

Par où commencer la lecture

Pour les ingénieurs qui découvrent Magnetar, le meilleur point d'entrée n'est pas un fichier unique. C'est la relation entre les documents et le code.

Le README donne la surface publique : ce que le client expose, quelles fonctionnalités sont implémentées, comment la matrice de parité Java est suivie, quels PIPs sont supportés et comment les deux moteurs sont positionnés. C'est le contrat utilisateur.

Le document d'architecture explique la forme située sous ce contrat. Il montre la topologie de crates, le sens des dépendances, la frontière sans-io, la boucle driver, le modèle d'événements, les chemins producer et consumer, les moteurs runtime, les sites TLS, les schémas, la couverture PIP et la stratégie de validation. C'est la carte du système.

La série d'ADR explique pourquoi le système a cette forme. ADR-0004 documente la séparation sans-io. ADR-0003 documente l'interdiction des channels. ADR-0011 documente l'injection d'horloge. ADR-0010 documente la décision de parité Java. ADR-0019 documente la relation entre le moteur de production Tokio et le moteur Moonpool par rapport à cet objectif de parité. ADR-0024 documente la politique de test cross-runtime.

Cela compte parce que Magnetar n'est volontairement pas seulement un dépôt de code. C'est un ensemble de décisions d'ingénierie avec une trace publique. Si vous n'êtes pas d'accord avec le design, les ADR donnent la bonne surface de discussion. Si vous voulez contribuer une fonctionnalité, la matrice de parité et la politique de validation indiquent ce que "terminé" veut dire. Si vous voulez évaluer le travail de simulation, la documentation du moteur Moonpool et le harnais différentiel montrent comment le même coeur protocolaire est piloté dans plusieurs mondes.

Cette première release doit donc se lire de deux manières. Comme utilisateur Pulsar, regardez la surface cliente et la matrice de parité. Comme ingénieur infrastructure Rust, regardez la frontière de machine d'état et la stratégie de simulation. Ce qui rend Magnetar intéressant, c'est que ces deux lectures sont censées se renforcer.

Ce que donne la première release publique

Cette première release publique est un point d'entrée technique. Elle s'adresse aux ingénieurs qui veulent essayer Magnetar, lire l'architecture, inspecter les ADR, comparer le comportement avec les clients Pulsar existants et contribuer à structurer l'écosystème Pulsar Rust.

L'API cliente de haut niveau commence par une forme attendue :

let client = PulsarClient::builder()
    .service_url("pulsar://localhost:6650")
    .build()
    .await?;

let producer = client
    .producer("persistent://public/default/orders")
    .create()
    .await?;

Cette API est importante, parce que le client doit être utilisable. Mais la release est aussi une invitation à inspecter les couches inférieures. Lire le README pour la matrice fonctionnelle. Lire le document d'architecture pour le design sans-io. Lire les ADR pour les décisions derrière l'interdiction des channels, les moteurs remplaçables, l'injection d'horloge, la parité Java, la parité Moonpool, les choix de providers TLS et la validation cross-runtime. Lire la documentation du moteur Moonpool si la simulation déterministe appliquée à un vrai client réseau vous intéresse.

Le point important pour cet article est la direction : Magnetar est public pour que les ingénieurs puissent évaluer à la fois la surface cliente et le modèle d'ingénierie qui la porte.

Vous pouvez consulter la première release publique de Magnetar v1.0.0, ainsi que la dernière release à ce jour, la version v1.2.0. 

Pourquoi cela dépasse Magnetar

Magnetar est un client Apache Pulsar. C'est aussi un exemple concret de la manière dont nous voulons construire davantage de logiciel d'infrastructure en Rust.

Les systèmes distribués échouent par transitions d'état. Certaines de ces transitions sont évidentes et faciles à tester. Beaucoup ne le sont pas. Elles apparaissent lorsque le temps avance au mauvais endroit, lorsqu'un retry chevauche un chemin de fermeture, lorsqu'un broker coupe une connexion après avoir accepté une partie de la session, lorsqu'un callback est enregistré juste après une notification, ou lorsqu'un chemin de reconnexion reconstruit un handle mais pas un autre.

On peut essayer de traquer ces bugs après coup. C'est parfois inévitable. Mais l'architecture peut rendre cette traque plus facile ou plus difficile.

Un client avec un coeur protocolaire pur, des événements explicites, du temps injecté, une I/O remplaçable, des seeds déterministes et une comparaison cross-runtime donne de meilleurs outils aux ingénieurs. Il permet de réduire une panne à une trace. Il permet de rejouer cette trace. Il permet de demander si une panne simulée correspond au runtime de production. Il permet d'ajouter un invariant là où une dérive silencieuse de l'état pouvait se cacher.

C'est la direction prise par Magnetar. Rendre le protocole explicite. Rendre le runtime remplaçable. Rendre les pannes reproductibles. Faire de la correction quelque chose que le code doit démontrer en continu.

Merci à Pierre Zemb pour Moonpool et pour cette direction de simulation déterministe en Rust, ainsi qu'aux contributeurs et mainteneurs de l'écosystème Pulsar Rust dont le travail a rendu l'étape suivante possible.

Magnetar est open source. Le code, les notes d'architecture, les ADR et la documentation vivent sur github.com/CleverCloud/magnetar.

Références

Magnetar

• Dépôt Magnetar. Dépôt public du client Apache Pulsar Rust. https://github.com/CleverCloud/magnetar
• README Magnetar. Surface publique, matrice de parité Java, PIPs supportés, couverture par moteur et statut. https://github.com/CleverCloud/magnetar/blob/main/README.md
• Architecture Magnetar. Rationale sans-io, topologie de crates, driver loop, machine d'état protocolaire et tests. https://github.com/CleverCloud/magnetar/blob/main/ARCHITECTURE.md
• Index de documentation Magnetar. Moteur Moonpool, testing, CLI, observabilité, logging, features PIP. https://github.com/CleverCloud/magnetar/blob/main/docs/README.md
• Documentation du moteur Moonpool. Moteur de simulation déterministe, chaos pack, harnais différentiel, modèle de providers. https://github.com/CleverCloud/magnetar/blob/main/docs/moonpool-engine.md
• Documentation de test. Catégories de tests et commandes de validation. https://github.com/CleverCloud/magnetar/blob/main/docs/testing.md
• ADR-0004. magnetar-proto sans-io et moteurs d'I/O remplaçables. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0004-sans-io-protocol-core.md
• ADR-0010. Parité complète avec le client Java. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0010-v0-1-full-java-parity.md
• ADR-0024. Politique de tests et couverture cross-runtime. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0024-cross-runtime-test-and-coverage-policy.md

Écosystème

• pulsar-rs. Client Apache Pulsar Rust existant. https://github.com/streamnative/pulsar-rs
• Apache Pulsar. Plateforme distribuée de messaging et streaming. https://pulsar.apache.org/
• Client Java Apache Pulsar. Surface de référence pour de nombreux utilisateurs Pulsar. https://pulsar.apache.org/docs/

Simulation déterministe

• FoundationDB testing. Lignée de la simulation déterministe et de l'injection de fautes. https://apple.github.io/foundationdb/testing.html
• TigerBeetle TigerStyle. Style d'ingénierie centré sur les assertions. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md
• TigerBeetle VOPR. Approche de simulation testing. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/internals/vopr.md
• Dépôt Moonpool. Simulation déterministe pour systèmes Rust, développée par Pierre Zemb. https://github.com/PierreZ/moonpool
• moonpool-sim. Crate du moteur de simulation Moonpool. https://crates.io/crates/moonpool-sim

C'est une fonction distincte de la conteneurisation elle-même, qui consiste à empaqueter une application avec ses dépendances dans un format standard. Les différences entre Docker et Kubernetes reposent précisément sur cette distinction : Docker fabrique et exécute les conteneurs, Kubernetes les orchestre. Aujourd'hui, Kubernetes est l'orchestrateur de référence, mais l'orchestration en tant que concept existe indépendamment de l'outil qui la met en œuvre.

Pourquoi l'orchestration existe ?

Faire tourner trois conteneurs sur un serveur ne demande pas d'orchestration. On démarre, on supervise à l'œil, on redémarre à la main si quelque chose plante. Le problème change de nature à partir du moment où une application devient un système distribué : plusieurs services, plusieurs machines, du trafic variable, des déploiements fréquents. Les questions opérationnelles qui apparaissent alors sont concrètes. Sur quelle machine placer ce nouveau conteneur ? Que faire si un nœud tombe la nuit ? Comment passer de la version 1.4 à la 1.5 sans interruption visible ? Comment un service interne en trouve un autre quand les adresses IP changent à chaque redémarrage ?

Chacune de ces questions a une réponse manuelle possible, scriptable même. L'orchestration consiste à les automatiser de manière cohérente, sous un modèle unique.

Les cinq fonctions principales de l'orchestration

Kubernetes traite ces questions via un modèle déclaratif construit sur des boucles de réconciliation : on décrit l'état souhaité du système, et l'orchestrateur compare en permanence cet état désiré à l'état réel pour les rapprocher. Les cinq fonctions qui suivent sont des instanciations de ce mécanisme général.

Scheduling : placer les conteneurs sur les bonnes machines

Le scheduling répond à une question : quand un nouveau conteneur doit démarrer, sur quelle machine du cluster doit-il s'exécuter ? Sur un cluster de quelques nœuds aux profils homogènes, la décision est triviale. Sur un cluster réel, elle ne l'est pas : certaines machines ont du GPU, d'autres pas, certaines sont déjà chargées, certaines applications doivent être isolées, d'autres doivent au contraire être co-localisées pour des raisons de latence.

Le composant kube-scheduler effectue ce choix en deux étapes : filtering, qui élimine les nœuds qui ne peuvent pas accueillir le pod (capacité insuffisante, contraintes d'affinité, taints et tolerations), et scoring, qui note les nœuds restants selon plusieurs critères. Le pod est ensuite assigné au nœud retenu via une opération de binding auprès de l'API server. La qualité de la décision dépend des informations fournies au scheduler. Ce sont les requests de ressources déclarées sur les pods qui déterminent le placement : le scheduler cherche un nœud dont la capacité disponible couvre ces requests. Les limits, elles, ne servent pas au placement mais plafonnent la consommation d'un conteneur une fois qu'il tourne.

Scaling : ajuster la capacité au trafic réel

Le scaling automatise une décision simple à formuler : combien de copies d'un service doivent tourner à un instant donné ? Trop de copies coûte cher. Trop peu provoque des incidents au moindre pic.

Le scaling est une fonction commune à tous les orchestrateurs ; les mécanismes varient selon l'implémentation. Dans Kubernetes, il repose sur trois briques distinctes. Le Horizontal Pod Autoscaler (HPA), inclus dans le cœur de Kubernetes, ajuste le nombre de pods d'un déploiement en fonction d'une métrique. Il s'appuie pour cela sur le Metrics Server, un composant à installer séparément, car la collecte de métriques n'est pas fournie par défaut. Le Vertical Pod Autoscaler (VPA), livré lui aussi comme projet séparé, ajuste les ressources allouées à chaque pod. Le Cluster Autoscaler, enfin, ajoute ou retire des nœuds entiers selon les besoins agrégés. Ces mécanismes supposent des métriques fiables : un HPA piloté sur le CPU, alors que le service est en réalité contraint par les I/O disque, ne produit pas le résultat attendu.

Self-healing : remplacer ce qui tombe

À partir d'un certain nombre de machines, les pannes ne sont plus des événements exceptionnels mais une donnée d'arrière-plan. Un disque défaille, un kernel panic survient, un conteneur fuit de la mémoire et finit OOM-killed. Sans orchestration, chaque panne déclenche une intervention humaine, plus ou moins urgente. Avec orchestration, ces événements sont absorbés sans intervention.

Au sein de Kubernetes, le mécanisme repose sur deux éléments. D'abord, des sondes (liveness, readiness, startup) qui lui  permettent de savoir si un conteneur fonctionne réellement, et pas seulement s'il a démarré. Ensuite, le principe que tout objet géré par un controller (Deployment, StatefulSet, DaemonSet) est en permanence comparé à l'état désiré : si un pod disparaît, le controller en demande un nouveau. La précision des sondes conditionne la qualité du self-healing : des sondes trop strictes provoquent des redémarrages inutiles, des sondes trop laxistes laissent passer des conteneurs cassés.

Service discovery et load balancing interne

Dans un parc de conteneurs en mouvement, où chaque pod a une adresse IP éphémère, deux services qui doivent communiquer ne peuvent pas s'appuyer sur des configurations IP statiques. Le service discovery résout ce problème par une couche d'indirection. Dans Kubernetes, un objet Service regroupe un ensemble de pods (sélectionnés par labels) sous un nom DNS stable et une IP virtuelle. CoreDNS, le serveur DNS interne du cluster, résout ces noms. Le trafic envoyé à l'IP du Service est distribué entre les pods prêts via kube-proxy. Ce principe n'est pas propre à Kubernetes : d'autres orchestrateurs répondent au même besoin autrement. Sur Clever Cloud, par exemple, les services se découvrent via l'injection de configuration entre applications et via les Network Groups, un réseau privé chiffré doté d'une résolution DNS interne.

Plusieurs types de Services existent (ClusterIP pour l'interne, NodePort et LoadBalancer pour l'externe), auxquels s'ajoute la notion d'Ingress pour le routage HTTP au niveau applicatif. Cette couche réseau, simple en apparence, contient une part substantielle de la complexité d'exploitation de Kubernetes : choix du plugin CNI, politiques réseau, observabilité du trafic est-ouest.

Rolling updates et rollbacks

Mettre en production une nouvelle version sans interrompre le service est une opération risquée si elle est faite à la main. Kubernetes la traite comme une transition d'état : on modifie le manifeste du Deployment pour pointer vers la nouvelle version d'image, et le controller applique la stratégie de rollout configurée.

La stratégie RollingUpdate (par défaut) remplace progressivement les anciens pods par des nouveaux, en garantissant qu'un nombre minimal reste disponible à tout moment. La stratégie Recreate arrête tout puis redémarre, utile pour des migrations de schéma incompatibles. En cas d'échec, le rollout ne revient pas seul à l'état antérieur : il s'interrompt, les nouveaux pods qui échouent aux sondes ne remplacent pas les anciens, et c'est un opérateur qui déclenche le retour à la version précédente avec kubectl rollout undo. La condition pour que cela fonctionne est que les versions soient compatibles entre elles pendant la transition, ce qui implique une discipline côté contrats d'API et migrations de base de données.

Au-delà des cinq fonctions de base

L'orchestration de Kubernetes ne se limite pas à ces cinq fonctions. En pratique, un cluster Kubernetes en production gère aussi la configuration applicative (ConfigMaps), les secrets (avec ou sans chiffrement au repos), le stockage persistant via les PersistentVolumeClaims, l'autorisation (RBAC), l'isolation réseau (NetworkPolicies), l'observabilité (logs, métriques, traces), et la gestion du cycle de vie des certificats. Chacune de ces fonctions est elle-même une responsabilité opérationnelle qui s'ajoute au socle.

Sans orchestrateur vs avec Kubernetes : comparaison fonction par fonction

Le tableau ne hiérarchise pas les deux colonnes. Il montre que Kubernetes fournit un modèle unifié pour ces cinq fonctions, là où une approche sans orchestrateur les traite séparément avec des outils différents. Pour un système qui n'a pas besoin de cette unification, la colonne de gauche reste pertinente.

Pratiques fréquentes à connaître

Choisir l'outil en fonction du besoin, pas par défaut. Toutes les applications n'ont pas besoin de scheduling, de scaling automatique ou de service discovery au niveau qu'offre Kubernetes. Un PaaS, un déploiement sur VM, ou un binaire systemd répondent à de nombreux besoins avec un autre modèle d'exploitation.

Penser l'observabilité dès le départ. Un cluster Kubernetes sans logs centralisés, sans métriques agrégées et sans traces devient rapidement difficile à exploiter au-delà de quelques services. L'observabilité fait partie intégrante de l'orchestration, pas d'un ajout optionnel.

Définir requests et limits avant d'activer l'autoscaling. Le HPA et le Cluster Autoscaler s'appuient sur les ressources déclarées des pods pour décider du scaling. Sans déclaration, leurs décisions reposent sur des informations partielles.

Soigner la configuration des sondes. Les liveness et readiness probes conditionnent à la fois le self-healing et l'acheminement du trafic. Une configuration approximative dégrade ces deux fonctions simultanément.

Quand l'orchestration Kubernetes devient pertinente

Aucune des cinq fonctions, prise isolément, ne justifie d'introduire Kubernetes dans un système. Un script de déploiement, un load balancer correctement configuré, un outil de monitoring avec restart automatique peuvent couvrir individuellement chacune d'elles. Ce qui justifie l'adoption d'un orchestrateur, c'est le moment où les cinq fonctions deviennent simultanément nécessaires sur une infrastructure suffisamment distribuée pour rendre les solutions ad hoc coûteuses à maintenir.

Concrètement, cela correspond à des architectures avec une dizaine de services ou plus, déployés sur plusieurs machines, avec des cycles de déploiement fréquents, des variations de charge significatives et des exigences de résilience qui ne tolèrent plus l'intervention manuelle. Pour des contextes plus contraints en ressources (edge, IoT, machines de développement, petits clusters), une distribution Kubernetes allégée comme K3s peut convenir. Un PaaS répond également à ces besoins, comme à bien d'autres profils d'applications (déploiement industrialisé, scaling automatique, résilience, mises à jour), avec un modèle d'exploitation distinct de Kubernetes.

Lorsque Kubernetes devient pertinent, la question suivante porte rarement sur l'installation et plus souvent sur l'exploitation au quotidien : mises à jour du control plane, gestion d'etcd, rotation des certificats, observabilité, sauvegardes. C'est ce constat qui explique l'adoption croissante des services Kubernetes managés. Côté Clever Cloud, Clever Kubernetes Engine répond à ce besoin avec Materia etcd, une implémentation serverless de l'API etcd bâtie sur FoundationDB qui prend le relais de l'etcd standard, devenu un goulot d'étranglement à grande échelle, sur une infrastructure souveraine répartie sur nos trois datacenters parisiens.

L'orchestration de conteneurs en synthèse

L'orchestration de conteneurs automatise plusieurs catégories de décisions opérationnelles, dont cinq grandes classes principales : où placer un conteneur, quand en démarrer plus, que faire quand l'un d'eux tombe, comment ils se trouvent entre eux, comment passer d'une version à la suivante sans interruption. Kubernetes regroupe ces fonctions sous un modèle unifié, ce qui en fait l'outil de référence pour les systèmes distribués qui en ont besoin simultanément. La question utile, face à un projet, n'est pas de savoir si on doit faire de l'orchestration, mais lesquelles de ces fonctions sont réellement nécessaires, et à quel niveau d'automatisation.

FAQ - Kubernetes orchestration

Quelle est la différence entre conteneurisation et orchestration ?

La conteneurisation empaquette une application et ses dépendances dans un format standardisé exécutable de manière identique sur n'importe quel hôte compatible. L'orchestration automatise la gestion d'un parc de conteneurs en production : placement, scaling, self-healing, service discovery, mises à jour. Docker est l'outil de référence pour la première, Kubernetes pour la seconde.

Faut-il forcément Kubernetes pour orchestrer des conteneurs ?

Non. Kubernetes est l'orchestrateur le plus largement adopté, mais d'autres existent : Nomad de HashiCorp, qui orchestre conteneurs, VM et binaires dans un même cluster, ou Docker Swarm, toujours maintenu mais dont l'adoption a reculé. Apache Mesos, longtemps cité comme alternative, a été retiré dans l'Apache Attic en octobre 2025 et n'est plus en développement actif. Par ailleurs, un PaaS comme Clever Cloud assure l'ensemble de ces fonctions d'orchestration (placement, scaling automatique, self-healing, rolling updates, service discovery) avec son propre control plane, indépendant de Kubernetes. C'est ce control plane qui orchestre aussi bien les applications exécutées en VM que les conteneurs du runtime Docker de la plateforme.

L'orchestration de conteneurs est-elle nécessaire pour CI/CD ?

Non, mais elle est souvent utilisée conjointement. Les pipelines CI/CD modernes produisent des images de conteneurs comme artefact final, et l'orchestrateur (Kubernetes ou autre) prend le relais pour déployer et exploiter ces images. CI/CD et orchestration sont deux étapes complémentaires du cycle de vie applicatif.

K3s permet-il l'orchestration en environnement contraint ?

Oui. K3s est une distribution Kubernetes certifiée CNCF, conçue pour les environnements aux ressources limitées (edge, IoT, machines de développement, petits clusters). Elle conserve les API standards de Kubernetes tout en réduisant l'empreinte ressources et la complexité de déploiement.

Un Kubernetes managé change-t-il les fonctions d'orchestration disponibles ?

Non. Un Kubernetes managé fournit le même ensemble de fonctions d'orchestration qu'un cluster auto-hébergé, puisqu'il s'agit du même Kubernetes. La différence porte sur la répartition des responsabilités opérationnelles : le fournisseur prend en charge la gestion du control plane, les mises à jour, la supervision sous-jacente. Les utilisateurs se concentrent alors sur leurs workloads applicatifs.

Quelle est la fonction d'orchestration la plus difficile à maîtriser ?

Le réseau est fréquemment cité comme la plus complexe. Service discovery, load balancing interne, NetworkPolicies, Ingress, plugin CNI, observabilité du trafic est-ouest : la couche réseau de Kubernetes concentre une part significative des sujets opérationnels avancés et reste une source fréquente d'incidents en production.

Cette version marque une étape : la mécanique sous-jacente est désormais prête à accueillir les fonctionnalités produit que nous voulons bâtir au-dessus. Plutôt qu'une liste de correctifs, nous avons regroupé le travail en six thèmes ; pour chacun, nous disons deux choses — ce qui a été livré, et ce que cela rend possible, pour celles et ceux qui font tourner leurs applications sur la plateforme comme pour les opérateurs qui exécutent Sōzu sur leur propre infrastructure.

1. Un multiplexer HTTP/2 réécrit intégralement

La pile HTTP/1 de Sōzu avait déjà été réécrite autour de kawa, notre format pivot : une représentation interne du message HTTP indépendante de sa version, dans le même esprit que le format HTX de HAProxy. Le multiplexer HTTP/2 en est le prolongement naturel — il étend kawa avec la gestion des sessions et le multiplexing des streams.

Il couvre l'intégralité de la matrice des protocoles (H1↔H1, H1↔H2, H2↔H1, H2↔H2), avec un état de stream partagé, la compression HPACK assurée par loona-hpack, le pooling des connexions HTTP/2 vers les backends, la priorisation des streams selon RFC 9218 Extensible Priorities, et la négociation ALPN par listener, afin que chaque connexion TLS aboutisse sur le bon chemin de code. Environ 181 tests end-to-end et deux cibles de fuzzing (cargo-fuzz) maintiennent le parser et le décodeur HPACK dans le droit chemin — dont des garde-fous de régression qui vérifient octet pour octet l'intégrité des réponses volumineuses sur un trajet « backend HTTP/1 → frontend HTTP/2 », précisément la frontière où se cachent les bugs de readiness en mode edge-triggered d'epoll.

Pour les clients Clever Cloud, l'incidence concrète est simple : chaque application servie par la plateforme parle désormais HTTP/2 par défaut, côté frontend — aucun opt-in, aucune modification de code, aucune configuration. L'activation du HTTP/2 jusqu'au backend reste un choix par cluster — un cluster, dans le modèle de Sōzu, étant l'une de vos applications ; activée de bout en bout, elle débloque notamment gRPC sur toute la chaîne. Les pages s'affichent en moins de connexions TCP ; les navigateurs peuvent mutualiser les requêtes entre les hôtes qui partagent un certificat (nous honorons le SAN coalescing décrit dans la RFC 7540 §9.1.1 : lorsque le certificat, l'autorité d'origine et les conditions de connexion s'y prêtent, Firefox et Chrome peuvent réutiliser une seule connexion vers vos cdn.example.com et assets.example.com au lieu d'en ouvrir plusieurs en parallèle). Il s'agit, au meilleur sens du terme, d'une mise à niveau silencieuse de la plateforme.

C'est aussi le prérequis structurel pour la suite — HTTP/3 sur QUIC et des fondations de streaming plus solides à l'edge. La réécriture du multiplexer est la pièce de la roadmap qui devait advenir en premier.

2. La sécurité pour socle, non comme option

La seconde moitié de la réécriture HTTP/2 est celle dont personne ne réclame l'existence tant qu'elle ne fait pas défaut : la résistance aux floods et aux attaques par déni de service. Sōzu 2.0 embarque des mitigations natives pour les vulnérabilités CVE-2023-44487 (Rapid Reset), CVE-2024-27316 (CONTINUATION flood), CVE-2025-8671 (MadeYouReset), ainsi que pour la famille PING / SETTINGS / empty-DATA des CVE-2019-9512/CVE-2019-9515/CVE-2019-9518. Chaque mitigation expose un counter dédié — douze métriques sous h2.flood.violation.* — afin qu'un SIEM puisse mesurer en fenêtre glissante le taux de déclenchement, sans avoir à parser les logs. Dix-sept motifs de rejet HPACK sont exposés selon le même principe ; il s'agit du premier signal observable côté opérateur pour les tentatives de request smuggling contre la pile HTTP/2.

Le reste du travail de sécurité se déploie à travers le proxy : un plafond de connexions par couple (cluster, IP source) assorti d'une réponse 429 Too Many Requests ; une éviction optionnelle des sessions les plus anciennes lorsque l'accept queue sature ; un durcissement du command channel, du parser HTTP/1, du pattern-trie router (fermeture d'un contournement de routing via regex non ancrées) et du wildcard matcher ; un assainissement du pipeline d'audit contre les séquences Trojan-Source et le SIEM column-smuggling ; et une rotation à chaud des certificats TLS qui ne laisse jamais tomber le certificat fonctionnel en cas d'échec, quand bien même le nouveau serait malformé. Quatre security advisories de dépendances purgées au cours de la même fenêtre.

Chaque mutation privilégiée atterrit désormais dans un journal d'audit structuré : chaque action du plan de contrôle est consignée sous la forme d'une ligne Command(verb=…, actor_uid=…, actor_user=…, result=…) — qui a fait quoi, depuis où, et avec quel résultat. Deux sinks dédiés l'exportent : audit_logs_target pour le flux lisible, et audit_logs_json_target pour un objet JSON à schéma stable par ligne, de sorte que la piste se déverse directement dans un SIEM (Wazuh, Elastic, Loki, Splunk) sans parser sur mesure — dans un format pensé pour PCI-DSS 10.5.

Le cadrage produit est limpide : notre métier, c'est d'opérer la plateforme et de protéger vos applications dès que nous le pouvons. Lorsque la prochaine vulnérabilité HTTP/2 de cette classe paraît un vendredi à vingt-et-une heures, elle n'a pas à se traduire par un week-end de correctifs et de redéploiements sur des milliers d'applications : les attaques de cette classe sont largement absorbées ou atténuées au niveau du proxy, un counter s'incrémente sur un dashboard, et les applications continuent de servir leur trafic. Le « trust-by-default » n'est pas un slogan : c'est l'effet cumulé de dizaines de petits correctifs défensifs, livrés à la couche où la frontière de sécurité se joue véritablement.

3. De la visibilité à chaque couche

L'ajout le plus visible pour l'utilisateur en 2.0 est sozu top — une TUI opérateur (derrière le feature flag Cargo tui) qui offre une vue en temps réel, à la manière de btop ou htop, sur sept panes : Overview, Clusters, Backends, Listeners, H2, Certificates, Events. Palette accessible aux personnes daltoniennes, thèmes personnalisables : l'essentiel tient dans un terminal, sans dashboard externe.

Sous la TUI, la surface des métriques elle-même a été refondue. Le multiplexer expose des counters par type de frame et par code d'erreur RFC 9113, la télémétrie des handshakes TLS, des counters HTTP par status code, et de nouvelles gauges de cycle de vie du worker. L'access log gagne les champs TLS et de forwarding (version, cipher, SNI, ALPN, chaîne XFF), la propagation x_request_id de bout en bout, ainsi que les RTT client et serveur — de quoi corréler une requête d'un hop à l'autre.

Une nouvelle commande, SetMetricDetail, permet à un opérateur d'élever à la demande la cardinalité des métriques, via un lease à durée limitée qui expire : la production reste à faible cardinalité par défaut, et l'inspection fine devient une décision ponctuelle plutôt qu'une réécriture de configuration.

Pour Clever Cloud, c'est le socle du prochain chapitre de l'observabilité tournée vers le client — percentiles de latence par application, disponibilité par cluster, décomposition des handshakes TLS, request IDs traçables d'un hop à l'autre. Les métriques existent désormais au niveau du proxy. L'étape suivante consiste à les exposer dans la console Clever Cloud, à leur juste place, aux côtés des vues de build et de déploiement — afin qu'aucun APM externe ne soit nécessaire pour comprendre le trafic que votre application reçoit véritablement.

4. Des policies de trafic enfin actionnables d'un geste

Sōzu 2.0 refond l'intégralité de la surface des policies côté frontend (#1231) : HSTS typé (RFC 6797), configurable par listener et par frontend ; URL rewrite (host, path, port) avec propagation des regex captures depuis le routing trie vers les rewrite templates ; réécriture des headers de requête et de réponse par frontend — ajouter, modifier ou supprimer n'importe quel header (une valeur vide le supprime, parité avec le del-header de HAProxy), avec en complément l'injection de X-Real-IP au niveau listener et l'élision anti-spoofing des valeurs fournies par le client ; redirects HTTP 301 / 302 / 308 au travers d'une enum typée RedirectPolicy ; et l'authentification HTTP Basic par frontend, avec des credentials hashés en SHA-256 et une comparaison constant-time assurée par la crate subtle (le credential boundary est durci contre les side-channels temporels — la code review l'avait identifié).

C'est la partie de la release où l'opportunité produit est la plus saillante. Aujourd'hui, mener une migration de domaine propre sur une plateforme managée requiert typiquement soit un backend sachant rediriger, soit un service de redirection déployé en parallèle ; placer une URL de preview derrière un mot de passe requiert typiquement un add-on d'authentification. Avec Sōzu 2.0, ces usages deviennent des boutons sur le proxy. La plomberie existe ; ce qu'il reste à accomplir, c'est d'exposer ces boutons dans la console Clever Cloud — sous la forme d'une case à cocher sur un domaine, ou d'un toggle à clic unique pour les preview environments. C'est la surface no-code de contrôle du trafic que nous voulons construire ensuite.

5. L'exploitation comme bénéfice pour le client

Une réécriture de cette profondeur ne se livre sereinement que si la flotte demeure en mouvement en dessous. L'exploitation au quotidien a reçu une attention particulière en 2.0.

sozu listener {http,https,tcp} update est un nouveau patch verb field-masked qui ajuste à la volée les paramètres d'un listener modifiables sans recycler les sockets sous-jacents : seuils de flood HTTP/2, SNI binding, préférence ALPN, idle timeouts, HSTS, custom answers. Les mitigations CVE peuvent désormais être resserrées sous attaque sans recycler les sockets d'écoute. Les health checks actifs des backends s'exécutent à l'intérieur de la loop d'événements mio existante (aucun scheduler async, aucun thread supplémentaire), avec des sondes HTTP/1.1 et HTTP/2, des intervalles dotés d'un léger jitter, et un fail-open path qui achemine à travers les backends au statut Normal dont la retry policy l'autorise. L'intégration systemd (qui clôt #228) effectue enfin ce qu'il convient : des units Type=notify, un READY=1 envoyé seulement après la création des workers initiaux et le replay de l'état sauvegardé, un STOPPING=1 lors du graceful shutdown, un MAINPID=<nouveau> lors des hot upgrades.

Les releases elles-mêmes ont changé de forme. Pousser un tag produit désormais dix tarballs pré-compilés (trois cibles Linux croisées avec jusqu'à quatre crypto providers), signés keyless via sigstore (cosign + GitHub OIDC), accompagnés d'une attestation SLSA build provenance et d'un pointeur SOURCE.txt vers le code source correspondant satisfaisant l'AGPL §6 et la LGPL §4 — refermant ainsi l'écart noté dans #1089. Les fichiers fullchain.pem ACME se chargent à présent proprement, y compris lorsque le client a émis le leaf en tête de chaîne (Certbot, lego, acme.sh) ; une race condition vieille de six ans sur l'auto-restart des workers (#515) est corrigée par pinning de l'inode original au moyen de /proc/self/fd. Le verbe IPC LoadState demeure forward-compatible avec les clients sozu-command-lib 1.1.1, de sorte que l'écosystème d'intégrations ne se brise pas lors de l'upgrade.

À l'échelle de Clever Cloud, le coût d'un incident d'exploitation ne se mesure pas en tickets — il s'agit d'une latence qui s'accumule sur des milliers d'applications, et du temps d'ingénierie que nous devons à la construction de l'étape suivante. Sōzu 2.0 est le proxy qui se laisse exploiter en silence, et cette tranquillité est ce que les clients vivent comme de l'uptime. C'est également ce qui rend Sōzu crédible comme outil que l'on peut exécuter sur sa propre infrastructure : binaires signés, hot reloads, particularités ACME absorbées, intégration systemd menée correctement.

6. Une crypto prête pour demain

La pile TLS a reçu une refonte plus discrète, mais d'égale importance (#1191). Sōzu prend désormais en charge quatre crypto providers pluggables pour rustls : crypto-ring (par défaut), crypto-aws-lc-rs, crypto-openssl, et fips (qui implique aws-lc-rs en mode FIPS). Les quatre sont exercés par la CI, et la precedence chain fips > ring > aws-lc-rs > openssl résout le provider actif de manière déterministe lorsque plusieurs features sont activées simultanément.

Ce dont nous sommes le plus satisfaits, en revanche, est le groups_list par défaut : X25519MLKEM768 est désormais le groupe d'échange de clés en première préférence lorsque le provider le prend en charge. Il s'agit de l'hybride post-quantique en cours de normalisation à l'IETF (draft-ietf-tls-ecdhe-mlkem), déjà enregistré dans le registre TLS de l'IANA ; en pratique, cela signifie qu'un client uniquement compatible X25519 et un client post-quantum négocient l'un comme l'autre l'échange le plus robuste mutuellement pris en charge, sans aucune action de l'opérateur.

Lorsque la transition post-quantique deviendra une exigence réglementaire — selon un calendrier dont l'industrie débat encore — les fondations seront déjà en place sur Clever Cloud : tout client TLS 1.3 qui propose l'hybride le négocie dès aujourd'hui, sans action de l'opérateur. Nous avons effectué ce choix en silence, et nous l'avons inscrit par défaut.

Du reverse proxy à l'edge programmable

Sōzu a toujours été un load balancer d'infrastructure : bien au-delà du HTTP, il équilibre aussi du TCP brut, avec un chemin de forwarding zéro-copie via splice(2) sous Linux pour les listeners TCP. Avec la 2.0, il se rapproche d'une API gateway et devient le substrat d'un edge programmable — et « programmable » est le mot qui compte. Chaque capacité décrite ci-dessus (HTTP/2 par défaut, contrôles anti-abus, observabilité, policies de trafic, crypto agility, calme opérationnel) est un bouton. L'année qui vient de la roadmap Clever Cloud consiste à exposer ces boutons sous la forme de features produit : à travers la console, à travers l'API, à travers les workflows que vous utilisez déjà pour déployer vos applications.

Voilà ce que nous voulons dire lorsque nous affirmons que Sōzu 2.0 est un premier pas vers quelque chose de plus grand. La 2.0 n'est pas la destination — c'est la plateforme sur laquelle nous bâtissons désormais. Le HTTP/2 managé, partout, en constitue la première brique. La deuxième : une console permettant d'activer HSTS, de protéger par mot de passe un preview environment, ou de rediriger un domaine migré. L'aboutissement — un edge entièrement programmable, doté de policy primitives que vous composez — est ce vers quoi nous bâtissons au fil du prochain release cycle.

Deux chantiers sont déjà sur l'établi. D'abord, un volet load balancing UDP — dans l'esprit d'IPVS, mais avec le rechargement à chaud propre à Sōzu — assorti de health checks TCP pour valider la disponibilité des backends UDP ; de quoi ancrer un peu plus le rôle de load balancer d'infrastructure. Ensuite, des backends joignables en HTTPS, qui consolident la connectivité amont et ouvrent la voie à l'API gateway.

Sōzu est un projet open source publié sous AGPL-3.0 (la command library est diffusée sous LGPL-3.0). Les binaires de la version 2.0 sont signés via sigstore et embarquent une attestation SLSA ; si vous opérez votre propre edge, cette version vous appartient : à utiliser, à auditer, à étendre. Le code, l'issue tracker, et les conversations vivent à l'adresse github.com/sozu-proxy/sozu.

Nous remercions les contributeurs qui ont rendu cette release possible — ainsi que toutes celles et ceux qui exécutent Sōzu en production, dont les retours guident la suite.

Références

Standards et spécifications

• RFC 6797 — HTTP Strict Transport Security (HSTS). https://datatracker.ietf.org/doc/html/rfc6797
• RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2). Désormais obsolétée par la RFC 9113, mais le §9.1.1 sur le connection coalescing demeure la citation reprise par la RFC 9113. https://datatracker.ietf.org/doc/html/rfc7540
• RFC 9113 — HTTP/2 (en vigueur). §5 streams, §6 frames, §6.8 GOAWAY, §7 codes d'erreur, §8.1 sémantique HTTP. https://datatracker.ietf.org/doc/html/rfc9113
• RFC 9218 — Extensible Prioritization Scheme for HTTP. https://datatracker.ietf.org/doc/html/rfc9218
• draft-ietf-tls-ecdhe-mlkem — Hybrid key exchange in TLS 1.3 : X25519MLKEM768 (Internet-Draft IETF, enregistré à l'IANA ; l'hybride post-quantique que Sōzu privilégie par défaut). https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem

CVE

• CVE-2019-9512 — HTTP/2 Ping Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9512
• CVE-2019-9515 — HTTP/2 Settings Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9515
• CVE-2019-9518 — HTTP/2 Empty Frames Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9518
• CVE-2021-42574 — Trojan Source (bidirectional override). https://nvd.nist.gov/vuln/detail/CVE-2021-42574
• CVE-2023-44487 — HTTP/2 Rapid Reset. https://nvd.nist.gov/vuln/detail/CVE-2023-44487
• CVE-2024-27316 — HTTP/2 CONTINUATION Flood. https://nvd.nist.gov/vuln/detail/CVE-2024-27316
• CVE-2025-8671 — MadeYouReset (HTTP/2). https://nvd.nist.gov/vuln/detail/CVE-2025-8671

Pour aller plus loin

• Cloudflare — HTTP/2 Rapid Reset: deconstructing the record-breaking attack. Le compte rendu canonique de la divulgation coordonnée d'octobre 2023, incluant la mécanique de l'attaque ainsi que le pic de 398 millions de rps capturé en direct. https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• HAProxy Technologies — HAProxy is Not Affected by the HTTP/2 Rapid Reset Attack (CVE-2023-44487). L'argument structurel de HAProxy quant à la raison pour laquelle son cycle de vie de stream absorbe naturellement le Rapid Reset ; un contraste utile face à l'approche par counters de flood retenue par Sōzu. https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
• Cloudflare blog — série Post-quantum. Couverture pluriannuelle assurée par Bas Westerbaan et ses collaborateurs sur l'échange de clés post-quantique et les groupes hybrides ; filiation de l'hybride X25519MLKEM768 que Sōzu négocie désormais par défaut. https://blog.cloudflare.com/tag/post-quantum/
• Cloudflare Learning Center — What is HSTS?. Primer accessible sur HSTS, la sémantique max-age / includeSubDomains / preload, et la politique de la HSTS preload list.

En résumé : K3s est une distribution Kubernetes certifiée CNCF, optimisée pour les environnements contraints (edge, IoT, labs). K8s désigne le projet Kubernetes originel, conçu pour des clusters de production à grande échelle. Le choix dépend de vos ressources disponibles, de votre contexte de déploiement et de votre charge opérationnelle.

K8s : le Kubernetes standard entreprise

K8s est l'abréviation de Kubernetes, le « 8 » représentant les huit lettres entre le « K » et le « s ». Il s'agit du projet open source original, maintenu par la Cloud Native Computing Foundation (CNCF) et initialement développé par Google.

Kubernetes est conçu pour des environnements de production à grande échelle : clusters multi-nœuds, haute disponibilité, intégration avec les clouds publics (AWS, GCP, Azure) ou des datacenters on-premises. Son plan de contrôle comprend plusieurs composants distincts : API server, scheduler, controller manager, etcd, déployés séparément, ce qui offre une flexibilité maximale mais requiert une expertise opérationnelle significative.

Prérequis typiques pour un nœud control plane en production : 2 vCPU et 2 Go de RAM au minimum pour les composants Kubernetes seuls, sans compter etcd ni les charges applicatives.

K3s : une distribution Kubernetes certifiée CNCF, pas un fork

K3s est une distribution certifiée de Kubernetes, pas une version allégée non officielle ni un fork. Créé par Rancher Labs, il a été donné à la CNCF en juin 2020 et passe les mêmes tests de conformité Sonobuoy que toutes les distributions certifiées. Tout manifeste Kubernetes valide fonctionne sur K3s.

Son objectif principal : réduire drastiquement les ressources nécessaires pour faire tourner Kubernetes sur des environnements contraints (edge, IoT, CI/CD, labs)  sans renoncer à la compatibilité API.

Ce que K3s change par rapport à K8s

• Binary unique de moins de 70 Mo (x86, ARM64, ARMv7 et S390X supportés), incluant le runtime containerd, le CNI Flannel, un Ingress Traefik et un load balancer Klipper.
• SQLite comme datastore par défaut en single-node, au lieu d'etcd. En configuration haute disponibilité (3 nœuds serveur minimum), K3s peut utiliser etcd embarqué ou un datastore externe (MySQL, PostgreSQL, etcd externe).
• Composants alpha/beta retirés pour réduire la surface d'attaque et l'empreinte mémoire.

Point important : K3s ne supprime pas etcd ; il le rend optionnel. En single-node, SQLite suffit. En haute disponibilité, etcd embarqué ou externe est supporté - mais ce dernier n'est pas officiellement pris en charge par l'équipe K3s.

Empreinte ressources

K3s fonctionne à partir de 512 Mo de RAM sur un nœud agent. Un server node (control plane) requiert 2 Go de RAM et 2 cœurs CPU selon la documentation officielle (mise à jour mai 2026), hors charge applicative. Un profil mesuré à la charge est disponible dans le guide de resource profiling K3s. À noter : en test sur du matériel avec 1 Go de RAM total, les distributions K3s, k0s et MicroK8s ont montré des instabilités lors du déploiement de charges applicatives réelles (un seul cluster Kubernetes, même léger, consomme des ressources de contrôle non négligeables).

Différences techniques clés

Datastore

Runtime et packaging

K8s ne fournit pas de runtime par défaut depuis la suppression de dockershim (v1.24, 2022). À partir de Kubernetes 1.24, vous devez installer un runtime CRI-compatible (containerd ou CRI-O). K3s embarque containerd directement dans son binaire.

Architecture du plan de contrôle

Dans K8s, les composants du plan de contrôle (API server, scheduler, controller manager) sont des processus séparés. Dans K3s, ils sont fusionnés en un seul binaire, ce qui réduit l'overhead mais limite certaines configurations avancées d'isolation.

Scalabilité

K3s est adapté à des clusters de taille modérée. En configuration haute disponibilité (3 server nodes, 4 vCPU / 8 Go de RAM), la documentation officielle indique une capacité d'environ 1 200 agents. Pour des clusters de très grande taille (plusieurs milliers de nœuds), K8s  reste la référence.

Tableau comparatif K3s vs K8s

Cas d'usage : lequel choisir ?

Choisissez K3s si :

• Vous déployez sur du matériel contraint (Raspberry Pi, appliances industrielles, serveurs edge avec peu de RAM).
• Vous gérez des clusters IoT ou edge distants, potentiellement en mode déconnecté.
• Vous avez besoin d'un cluster de développement ou de CI démarrant rapidement, y compris sur matériel modeste.
• Vous souhaitez un cluster opérationnel avec un minimum de configuration initiale.

Choisissez K8s (ou une distribution enterprise) si :

• Vous orchestrez des centaines ou milliers de nœuds en production.
• Vos workloads requièrent des intégrations cloud-natives avancées (stockage, load balancers, IAM) fournies par les hyperscalers.
• Vous avez besoin de composants API en alpha/beta non disponibles dans K3s.
• Votre organisation dispose d'une équipe SRE dédiée à l'exploitation de clusters.

Cas hybrides : K3s et K8s ensemble

K3s et K8s ne sont pas mutuellement exclusifs. Plusieurs architectures hybrides sont documentées en production :

Fleet management avec Rancher

Des clusters K3s edge sont pilotés depuis un plan de contrôle central tournant sur K8s ou RKE2. The Home Depot (grande distribution américaine, plus de 2 300 magasins) gère ainsi ses sites avec K3s supervisé depuis Rancher.

Clusters de dev et staging K3s, prod K8s

La compatibilité API garantit que les manifests et charts Helm testés sur K3s fonctionnent en production sur un cluster enterprise. Cette parité réduit les surprises en promotion d'environnements.

CI/CD

Des pipelines de test tournent sur K3s (faible coût, démarrage rapide) pendant que les environnements de production utilisent un cluster K8s managé.

Kubernetes managé : une troisième voie

Ni K3s ni K8s ne résolvent la question de l'opération quotidienne : mises à jour, certificats, surveillance du plan de contrôle, gestion des défaillances. C'est précisément ce que couvrent les solutions de Kubernetes managé.

Les hyperscalers (EKS, GKE, AKS) proposent cette gestion dans leurs propres clouds. Mais des solutions managées existent aussi en dehors de ces écosystèmes, notamment pour des organisations qui souhaitent conserver la maîtrise de leurs données et opter pour un Kubernetes souverain, voire un Kubernetes français.

Clever Kubernetes Engine (CKE) est le service Kubernetes managé de Clever Cloud, conçu pour des équipes qui utilisent déjà Kubernetes et souhaitent déléguer la gestion du plan de contrôle (updates, haute disponibilité, monitoring) sans être contraints dans un seul hyperscaler. CKE s'adresse explicitement aux équipes que le modèle PaaS traditionnel ne couvre pas (cas multi-runtime, workloads non-twelve-factor, ou besoin de contrôle granulaire sur les ressources).

FAQ

K3s est-il un fork de Kubernetes ?

Non. K3s est une distribution certifiée CNCF de Kubernetes. Il passe les tests de conformité Sonobuoy et respecte les mêmes APIs que K8s Il n'est pas maintenu en parallèle de Kubernetes : il suit les releases du projet originel.

Peut-on utiliser K3s en production ?

Oui, avec des nuances. K3s est documenté pour des charges de production dans des environnements contraints (edge, IoT). Pour des clusters à grande échelle ou des workloads critiques avec des exigences de SLA élevées, le K8s  (ou une distribution enterprise comme RKE2) est plus adapté.

K3s supporte-t-il Helm ?

Oui. K3s inclut un contrôleur Helm intégré et est compatible avec toute chart Helm valide.

Quelle est la différence entre K3s et K3d ?

K3d est un outil qui fait tourner K3s dans des conteneurs Docker. Il simplifie encore davantage la création de clusters K3s locaux pour le développement, mais n'est pas destiné à la production.

K3s fonctionne-t-il sur ARM ?

Oui. ARM64 et ARMv7 sont nativement supportés, ce qui explique sa popularité sur Raspberry Pi et les appliances industrielles.

Kubernetes managé vs K3s auto-hébergé : quoi choisir ?

K3s auto-hébergé vous donne un contrôle total mais vous rend responsable des opérations (updates, sécurité, haute disponibilité). Un Kubernetes managé délègue cette responsabilité à un opérateur, au prix d'une dépendance envers ce fournisseur. Le choix dépend de vos ressources opérationnelles et de vos exigences de contrôle.

Plusieurs vulnérabilités récentes du noyau Linux ont nécessité une réponse rapide de la part des opérateurs d'infrastructure. Parmi elles, Copy Fail et Dirty Frag ont attiré l'attention car elles concernent des scénarios d'élévation locale de privilèges.

Copy Fail est suivie sous la CVE-2026-31431.

Dirty Frag regroupe deux vulnérabilités distinctes, la CVE-2026-43284 et la CVE-2026-43500, liées à des composants du noyau Linux.

Chez Clever Cloud, nous avons traité ces vulnérabilités comme des sujets d'infrastructure critiques.

Notre objectif était double : réduire rapidement la fenêtre d'exposition, puis améliorer durablement notre processus de sélection et de déploiement des kernels.

Cet article revient sur notre approche, les décisions prises et les changements apportés à notre chaîne d'exploitation.

Pourquoi ces vulnérabilités demandaient une réaction rapide

Copy Fail et Dirty Frag appartiennent à la famille des vulnérabilités d'élévation locale de privilèges. Dans ce type de scénario, un attaquant doit déjà pouvoir exécuter du code localement, mais peut ensuite tenter d'obtenir des privilèges plus élevés sur la machine concernée.

Dirty Frag repose sur deux failles du noyau Linux.

Elles affectent notamment des modules liés à ESP, utilisé par IPsec, et à RxRPC. Dans une plateforme cloud, ce type de vulnérabilité impose une analyse rapide. Le risque ne se limite pas à la machine isolée. Il faut aussi évaluer les scénarios liés aux environnements mutualisés, aux workloads containerisés et aux mécanismes d'isolation.

Ce que nous avons vérifié

Nous avons analysé l'impact potentiel de ces vulnérabilités sur nos environnements.

Cette étape ne consiste pas seulement à lire les avis de sécurité.

Elle consiste aussi à vérifier si un scénario théorique peut devenir pertinent dans notre contexte d'exploitation.

Dans le cas de CopyFail, la faille venait sous embargo avec son correctif. Nous avons publié une nouvelle image système avec le correctif appliqué dans les jours qui ont suivi.

Les applications de nos clients ont été redéployées dans la foulée.

Dans le cas de Dirty Frag, nos analyses internes ont confirmé que ces vulnérabilités devaient être traitées sérieusement. En effet, les modules ESP sont activés dans nos noyaux pour répondre à certains besoins client spécifiques.

Heureusement, les modules liés à RxRPC ne sont pas présents chez nous car inutile dans notre usage. Nous ne détaillons pas ici les étapes techniques de l'exploitation, car l'objectif de cet article est d'informer nos clients, pas de publier une procédure reproductible.

Cette validation a confirmé la décision opérationnelle : traiter le sujet immédiatement, réduire la surface exposée, puis forcer les redéploiements nécessaires.

Notre réponse opérationnelle

Déployer des mesures immédiates

Nous avons d'abord appliqué des mesures rapides sur les kernels concernés. Dans le cas de Dirty Frag, les mesures publiques recommandées portent notamment sur les composants kernel concernés par ESP et RxRPC.

Côté Clever Cloud, l'objectif était clair : réduire les surfaces exposées identifiées et réduire la fenêtre d'exposition avant d'attendre un cycle classique de maintenance

Redéployer les workloads concernés

Une mise à jour kernel n'est utile que si les systèmes concernés redémarrent effectivement sur un environnement corrigé. Nous avons donc lancé un redéploiement progressif des applications, puis traité les cas qui bloquaient ce redéploiement.

Cette phase est importante. Dans une plateforme managée, la correction ne se limite pas à produire une image ou à compiler un kernel. Il faut aussi s'assurer que la chaîne d'exécution utilise réellement la version attendue.

Améliorer le processus au passage

Nous avons aussi profité de cette séquence pour remplacer un mécanisme temporaire par une intégration plus propre dans notre chaîne d'orchestration.

Concrètement, le choix du kernel est désormais transmis plus explicitement dans notre chaîne interne, jusqu'à Supernova, notre agent d'hyperviseur. Cette évolution remplace le contournement plus rigide mis en place dans l'urgence.

C'est le point central de cette intervention : corriger vite, puis rendre la correction plus fiable pour les prochaines opérations.

Ce que cela change pour les clients de Clever Cloud

Pour les clients, l'effet attendu est simple : réduire l'exposition sans action manuelle de leur part lorsque la plateforme peut prendre en charge le redéploiement.

Clever Cloud exploite une architecture qui repose notamment sur l'isolation par virtualisation. Cette approche est documentée dans nos pages sécurité et dans nos contenus techniques sur l'exécution de conteneurs dans des machines virtuelles.

Elle ne supprime pas tous les risques, mais elle limite certains scénarios de mouvement latéral par rapport à des modèles où plusieurs workloads partagent directement le même environnement d'exécution.

Nous évitons toutefois de présenter cette isolation comme une garantie absolue. Une vulnérabilité kernel doit toujours être traitée sérieusement. C'est pourquoi nous avons combiné mitigation, redéploiement et amélioration de notre chaîne d'exploitation.

Ce que nous retenons

Cette séquence confirme trois principes.

D'abord, une vulnérabilité kernel doit être analysée dans son contexte réel d'exploitation. Une alerte publique ne suffit pas.

Il faut comprendre si les conditions nécessaires à l'exploitation peuvent exister sur la plateforme.

Ensuite, la vitesse de réaction compte. Les vulnérabilités Copy Fail et Dirty Frag ont été divulguées publiquement à quelques jours d'intervalle, avec des analyses publiées par plusieurs acteurs de l'écosystème Linux et cloud.

Enfin, une réponse sécurité utile ne doit pas seulement corriger le problème du moment. Elle doit aussi améliorer le système qui permettra de répondre au prochain incident.

C'est ce que nous avons fait ici : traiter les vulnérabilités, réduire la fenêtre d'exposition et renforcer notre processus de gestion des kernels.

FAQ

Qu'est-ce qu'une vulnérabilité kernel locale ?

Une vulnérabilité kernel locale est une faille qui nécessite déjà une capacité d'exécution sur la machine concernée. Elle peut ensuite permettre d'obtenir des privilèges plus élevés, par exemple root, si le noyau est vulnérable.

Pourquoi ces failles concernent-elles les plateformes cloud ?

Les plateformes cloud exécutent de nombreux workloads avec des mécanismes d'isolation. Une faille kernel peut devenir critique si elle permet de franchir certaines barrières entre processus, conteneurs ou environnements d'exécution.

Dirty Frag et Copy Fail sont-elles la même vulnérabilité ?

Non. Copy Fail est suivie sous la CVE-2026-31431. Dirty Frag regroupe la CVE-2026-43284 et la CVE-2026-43500. Ces vulnérabilités sont proches par leur impact, mais elles sont distinctes.

Quelle action est demandée aux clients Clever Cloud ?

Aucune action générale n'est demandée aux clients pour les environnements pris en charge par la plateforme. L'automatisation apportée par Clever Cloud a permis de tout mettre à jour sans action nécessaire. Les cas spécifiques font l'objet d'un suivi dédié.

En une décennie, K8S s'est imposé comme la base technique sur laquelle s'exécute une part majoritaire des applications cloud modernes.

Comment fonctionne Kubernetes : un orchestrateur déclaratif

La plupart des descriptions de Kubernetes énumèrent ses composants, pods, deployments, services, sans expliquer le mécanisme central. Or le concept fondamental est ailleurs : Kubernetes est avant tout un orchestrateur, et son moteur central repose sur des boucles de réconciliation.

Vous ne dites pas à Kubernetes quoi faire. Vous lui dites à quoi vous voulez que votre système ressemble. Cette distinction, déclaratif contre impératif, change tout.

Concrètement, vous décrivez l'état désiré dans des fichiers manifestes, généralement au format YAML : « je veux 3 répliques de cette image, exposées sur le port 80, avec ces variables d'environnement ». Vous envoyez ce manifeste à l'API Kubernetes via kubectl. À partir de là, Kubernetes compare en permanence l'état réel du cluster (ce qui tourne effectivement) à l'état désiré (ce que vous avez déclaré), et agit pour les rapprocher. Si un nœud meurt, ses pods sont reprogrammés ailleurs. Si vous passez de 3 à 10 répliques dans le manifeste, Kubernetes en démarre 7 de plus. Si un conteneur plante, il est redémarré.

Cette boucle de réconciliation est le cœur de tout ce que fait Kubernetes : auto-réparation, scaling, déploiements progressifs (rolling updates), retours arrière. Pour creuser ce mécanisme et les autres fonctions qu'il rend possibles, découvrez en détail à quoi sert l'orchestration de conteneurs.

Architecture en bref : control plane, nodes, pods

Un cluster Kubernetes se divise en deux ensembles. Le control plane est le cerveau : il prend les décisions globales, accepte les requêtes API, planifie les charges de travail, et surveille l'état du cluster. Il s'appuie sur quelques composants clés comme le serveur API (kube-apiserver), le planificateur (kube-scheduler) et le gestionnaire de contrôleurs (kube-controller-manager), ainsi que sur un magasin de données distribué qui mémorise tout l'état du cluster, traditionnellement etcd.

Les nodes sont les machines qui exécutent réellement les charges de travail. Sur chacune, un agent appelé kubelet reçoit ses instructions du control plane et lance les conteneurs via un moteur d'exécution (containerd, CRI-O, etc.). La plus petite unité déployable n'est pas un conteneur isolé mais un pod : un ou plusieurs conteneurs qui partagent un réseau et un stockage. Au-dessus, des objets de plus haut niveau (Deployment, Service, Ingress, ConfigMap, Secret) décrivent comment les pods doivent être gérés, exposés et configurés.

Cette architecture est aussi la source d'une confusion fréquente avec Docker, dont les rôles sont en réalité complémentaires de ceux de Kubernetes plutôt que concurrents.

Pourquoi K8S est devenu le standard de l'orchestration

Selon le CNCF Annual Cloud Native Survey 2025, publié en janvier 2026, 98 % des organisations interrogées ont adopté des techniques cloud native, et 82 % des utilisateurs de conteneurs déploient Kubernetes en production, contre 66 % en 2023. La domination est massive. Mais l'expliquer uniquement par des qualités techniques serait incomplet, c'est aussi une histoire d'écosystème et d'alignement d'intérêts.

Sur le plan technique, trois propriétés expliquent l'adoption. D'abord, le modèle déclaratif décrit plus haut : il rend les déploiements reproductibles, versionnables dans Git, et résistants aux pannes. Ensuite, la portabilité : un même manifeste fonctionne sur une machine de développement (Minikube, kind, k3d), sur un cluster on-premise et sur n'importe quel cloud. Enfin, l'extensibilité : l'API de Kubernetes accepte des objets personnalisés (Custom Resource Definitions) et des contrôleurs personnalisés (Operators), ce qui en a fait une plateforme pour étendre la plateforme. Cet effet a déclenché une dynamique d'écosystème massive.

Sur le plan stratégique, l'histoire est moins racontée. En 2014, Google avait plus d'une décennie d'expérience dans la gestion de conteneurs à grande échelle avec ses systèmes internes Borg et Omega, dont les principes ont été partagés publiquement via des papiers de recherche académiques (Omega en 2013, Borg en 2015). Plutôt que d'open-sourcer Borg lui-même, qui restait étroitement couplé à l'infrastructure Google, l'équipe a créé Kubernetes comme un nouveau projet inspiré de cette expérience, avec une implémentation distincte conçue dès le départ pour une adoption externe. Le projet a été publié en open source en juin 2014 puis donné à la Cloud Native Computing Foundation en 2015. Cette neutralité, un projet hébergé par une fondation Linux et non par un cloud, a été déterminante. Aucun concurrent ne pouvait se permettre de ne pas l'adopter sous peine d'être marginalisé hors de l'écosystème cloud-native naissant. AWS, qui poussait initialement sa propre solution propriétaire (ECS), a annoncé EKS fin 2017 et l'a lancé en disponibilité générale en juin 2018. À ce moment-là, le standard était scellé.

Sur le plan de l'écosystème, l'effet réseau a fait le reste : Helm pour empaqueter les applications, Prometheus pour la supervision, Istio et Linkerd pour le service mesh, ArgoCD et Flux pour le GitOps, Trivy et Falco pour la sécurité. Chaque outil supplémentaire renforce la valeur du standard. Côté ressources humaines, les compétences Kubernetes sont devenues massivement demandées sur les offres DevOps et SRE, ce qui crée un cercle vertueux : plus d'ingénieurs formés, plus d'entreprises qui adoptent, plus d'ingénieurs qui se forment.

Dans le rapport CNCF 2025, la communauté qualifie aujourd'hui Kubernetes de « boring », au sens noble du terme : un outil mature, prévisible, dont les API ne se cassent plus à chaque release. C'est précisément ce qu'on attend d'une infrastructure standard.

Quand utiliser Kubernetes, et quand privilégier le PaaS ?

Le fait que K8S soit le standard ne signifie pas qu'il soit la bonne réponse à tous les problèmes. Choisir Kubernetes, un PaaS, ou une combinaison des deux dépend du contexte technique et organisationnel ; chez Clever Cloud, beaucoup d'équipes utilisent les deux en parallèle pour des workloads différents.

Kubernetes apporte une vraie valeur dans plusieurs contextes :

• portabilité forte attendue : multi-cloud, hybride, on-premise associé à du cloud, où le manifeste Kubernetes devient un dénominateur commun ;
• architectures distribuées qui appliquent les principes du 12-factor app et l'approche « cattle » (instances interchangeables, sans état) avec des besoins d'orchestration sophistiqués ;
• alignement stratégique sur l'écosystème CNCF (Helm, Operators, ArgoCD, Istio…) ou prérequis client / partenaire qui imposent ce standard ;
• besoin d'une plateforme commune pour des équipes nombreuses, avec une équipe plateforme dédiée ou la volonté d'externaliser cette responsabilité à un service managé.

À l'inverse, dans d'autres contextes, un PaaS comme Clever Cloud répond directement aux mêmes besoins que Kubernetes (déploiements industrialisés, autoscaling, résilience) sans la complexité opérationnelle de l'orchestrateur. C'est notamment vrai pour les architectures applicatives classiques (web + backend + base de données) où l'effort de configuration et d'opération de Kubernetes ne se traduit pas en valeur ajoutée concrète.

Et pour les charges intermédiaires (IoT, edge, environnements de développement, petits clusters), les différences entre K3S et K8S méritent d'être pesées avant de trancher : la distribution allégée est souvent plus adaptée. Le standard de facto n'est pas une obligation morale. C'est un outil puissant et coûteux à opérer, dont l'usage doit être choisi en fonction des problèmes qu'il résout, souvent en complément des autres approches plutôt qu'en remplacement.

Les limites du standard : la dette opérationnelle

Faire tourner Kubernetes en production n'est pas trivial. C'est l'une des raisons pour lesquelles beaucoup d'entreprises qui adoptent K8S optent pour un service managé plutôt qu'une installation auto-gérée.

Les sources de complexité sont multiples : configurer correctement le contrôle d'accès (RBAC), choisir et opérer un plugin réseau (CNI), brancher du stockage persistant (CSI), mettre en place une observabilité, gérer les certificats, faire les mises à jour mineures et majeures sans interruption, durcir la sécurité, gérer les sauvegardes du control plane. Chacun de ces sujets est un métier en soi. Le rapport CNCF 2025 montre d'ailleurs que les défis se sont déplacés du purement technique vers l'organisationnel : 47 % des organisations citent désormais les « changements culturels avec l'équipe de développement » comme principal obstacle, devant la complexité technique brute.

Au cœur de cette dette se trouve un composant moins discuté : etcd. C'est la base de données clé-valeur distribuée qui stocke l'état complet du cluster. etcd est solide pour les clusters de taille modérée, mais devient un goulot d'étranglement à l'échelle. Ce n'est pas un hasard si Google a annoncé fin 2024 le remplacement d'etcd par Spanner pour son offre GKE, en conservant uniquement la compatibilité API. AWS, de son côté, a réécrit une « nouvelle génération » de son architecture etcd pour soutenir l'échelle. K3S, conçu pour les environnements légers, a poussé la logique plus loin en proposant plusieurs alternatives à etcd, dont SQLite par défaut. Quand un composant central doit être reconçu pour soutenir l'usage en production, c'est un indice révélateur.

C'est ce constat qui nous a poussés, chez Clever Cloud, à reconsidérer cette pièce. Notre Clever Kubernetes Engine remplace l'etcd standard par Materia etcd, notre réimplémentation du protocole etcd construite sur  Materia KV, et FoundationDB, répliquée  sur trois datacenters parisiens. Cette approche, c'est aussi ce qui rend Clever Cloud unique : un control plane multi-tenant qui scale horizontalement sans dégrader les performances, hérite de la simulation continue de pannes de FoundationDB, et libère les équipes de la gestion de milliers d'instances etcd fragiles.

Mais que vous choisissiez CKE ou un autre service, le principe vaut : si vous voulez Kubernetes en production sans bâtir une équipe plateforme dédiée, un Kubernetes managé est presque toujours la bonne décision.

En résumé

Kubernetes s'est imposé comme standard pour de bonnes raisons techniques, mais aussi grâce à un alignement d'intérêts qui a fait converger l'industrie autour d'un projet neutre porté par la CNCF. Le mécanisme central, la boucle de réconciliation et le modèle déclaratif, explique sa robustesse. L'écosystème qui s'est construit autour explique sa pérennité.

Cela ne signifie pas qu'il faut l'adopter pour tout. Pour beaucoup de contextes, un PaaS ou une autre approche est mieux adaptée, et bien souvent, les deux cohabitent dans une même architecture, chacun là où il apporte le plus de valeur. Pour des architectures distribuées sérieuses, il reste l'outil de référence, à condition de mesurer la dette opérationnelle qu'il introduit, et de choisir entre l'opérer soi-même ou s'appuyer sur un service managé.C'est précisément la promesse que Clever Kubernetes Engine, notre Kubernetes managé, cherche à tenir : Kubernetes standard, opéré en France sur une infrastructure souveraine, avec un control plane reconçu pour éliminer la friction d'etcd à l'échelle. Et pour les équipes qui n'ont pas besoin de Kubernetes, notre PaaS reste la voie la plus directe vers la mise en production.

FAQ

K8S et Kubernetes, c'est la même chose ?

Oui. K8S est une abréviation : la lettre K, les huit lettres d'« ubernete » condensées en 8, et la lettre S finale. Les deux désignent le même système d'orchestration de conteneurs.

Quelle est la différence entre Docker et Kubernetes ?

Docker est un moteur de conteneurisation : il empaquette une application avec ses dépendances dans une image qui s'exécute comme un conteneur. Kubernetes est un orchestrateur : il déploie, supervise et fait évoluer ces conteneurs sur un parc de serveurs. Cette distinction est l'une des plus mal comprises de l'écosystème, alors queles deux outils répondent en réalité à des besoins différents et complémentaires.

Kubernetes est-il gratuit ?

Le logiciel est open source et gratuit, sous licence Apache 2.0. Mais l'infrastructure sur laquelle il tourne, le temps d'ingénierie pour le maintenir et les outils complémentaires (supervision, sauvegardes, sécurité) ont un coût réel. C'est pourquoi de nombreuses entreprises optent pour un Kubernetes managé.

Faut-il toujours Kubernetes pour déployer en production ?

Non. Kubernetes apporte une orchestration sophistiquée, particulièrement adaptée aux architectures distribuées exigeant portabilité, écosystème CNCF, ou orchestration avancée. Pour beaucoup d'autres contextes, un PaaS répond aux mêmes objectifs (déploiement industrialisé, autoscaling, résilience) sans la complexité opérationnelle. Et dans la pratique, les deux approches cohabitent souvent dans une même architecture.

Quelle différence entre K3S et K8S ?

K3S est une distribution Kubernetes certifiée par la CNCF (donc pas un fork), allégée et conçue pour les environnements aux ressources limitées : edge, IoT, machines de développement, petits clusters. Elle remplace certains composants par des alternatives plus légères et tient dans un binaire unique. Les différences entre K3S et K8S tiennent à plusieurs choix d'architecture précis qu'il faut peser avant de choisir.

Comment commencer avec Kubernetes ?

Le plus rapide est de monter un cluster local avec Minikube, kind ou k3d, puis de déployer une application simple via un manifeste YAML. Pour passer en production, le choix raisonnable pour la majorité des équipes est un Kubernetes managé.

Cela représente une étape importante, issue de trois années de préparation, et s’inscrit dans une stratégie plus large visant à conserver un contrôle complet sur l’infrastructure réseau de notre région Paris.

Pourquoi ce changement

Aux débuts de Clever Cloud, nous avons délégué la gestion du réseau à des partenaires. Ce choix était logique : il nous permettait d’accélérer le développement, de nous concentrer sur les services cloud, et d’éviter d’investir immédiatement dans une expertise que nous ne maîtrisions pas encore.

Mais à mesure que notre infrastructure a grandi, les limites de cette dépendance sont devenues évidentes. Nous n’avions aucun contrôle sur des décisions stratégiques : la manière dont le trafic était routé sur Internet, les chemins empruntés par nos paquets, ou la rapidité avec laquelle nous pouvions réagir aux incidents. Chaque modification, chaque incident nécessitait l’intervention d’un tiers.

Nous avons donc décidé de reprendre cette responsabilité. Cela nous a permis d’obtenir plusieurs avantages concrets. Nous optimisons les coûts grâce à la gestion directe de nos relations de transit et de peering. Nous définissons notre propre politique de routage au lieu de subir les contraintes d’un intermédiaire. Nous résolvons les incidents nous-mêmes, sans dépendre de fournisseurs externes. Et nous obtenons un contrôle complet de notre stack réseau — dans la continuité du contrôle que nous avons progressivement acquis sur nos serveurs et nos datacenters au cours des dernières années.

Mais cette transition ne concerne pas uniquement notre indépendance opérationnelle. Elle apporte des bénéfices immédiats et concrets pour nos utilisateurs. Le plus important est la résilience. Auparavant, l’ensemble du trafic passait par un seul fournisseur. Tout incident de leur côté impactait l’ensemble des services. Nous disposons désormais de quatre fournisseurs upstream répartis sur trois datacenters en région parisienne. Lorsqu’un lien tombe — ce qui s’est produit au cours de l’année passée — le trafic bascule automatiquement vers les alternatives disponibles, sans interruption pour les utilisateurs. Nous pouvons même absorber la perte simultanée de plusieurs liens de transit.

Au-delà de la redondance, nous gagnons le contrôle du routage lui-même. Nous décidons désormais comment le trafic atteint sa destination. Cela nous permet d’optimiser les chemins pour réduire la latence et améliorer les performances, et d’ajuster ces décisions en fonction des besoins spécifiques et de la topologie réseau. Nous réagissons en temps réel à la congestion, aux variations du réseau et aux contraintes opérationnelles.

Enfin, la responsabilité opérationnelle change. Les incidents réseau ne nécessitent plus d’attendre qu’un fournisseur externe les prenne en charge. Les défaillances du réseau public relèvent directement de notre responsabilité : nous les détectons, les analysons et les corrigeons. Cela réduit directement le temps entre l’apparition d’un problème et sa résolution, ce qui améliore la disponibilité et la fiabilité pour nos utilisateurs.

Exploiter son propre réseau sur Internet

Pour opérer un réseau indépendant sur Internet, une organisation doit travailler avec un registre Internet régional (RIR). Les RIR sont responsables de l’attribution et de la gestion des adresses IP et des numéros d’AS dans des zones géographiques spécifiques.

Il existe cinq RIR dans le monde :

• RIPE NCC — Europe, Asie centrale et Moyen-Orient
• ARIN — Amérique du Nord (États-Unis, Canada, Caraïbes)
• LACNIC — Amérique latine et Caraïbes
• APNIC — région Asie-Pacifique
• AFRINIC — Afrique

Pour Clever Cloud, dont l’infrastructure est principalement en Europe, nous travaillons avec le RIPE NCC (Réseaux IP Européens).

Espace d’adressage alloué

En tant que membre d’un RIR, une organisation reçoit des allocations d’adresses IPv4 et IPv6. Pour les membres du RIPE NCC, cela correspond généralement à un bloc IPv4 en /24 (selon disponibilité) et un bloc IPv6 en /29. Ces ressources sont associées à l’organisation et peuvent être utilisées pour opérer un réseau à l’échelle globale.

Création de notre système autonome

Les bases de cette transition ont été posées plusieurs années auparavant. En 2019, nous avons créé notre compte RIPE NCC afin de devenir LIR (Local Internet Registry). Cela nous a permis d’obtenir un bloc IPv4 /24 (91.208.207.0/24) et un bloc IPv6 /29 (2a0f:d0c0::/29).

Puis, en 2022, nous avons enregistré notre numéro de système autonome (ASN) auprès du registre régional. Notre numéro d’AS est AS213394.

> whois AS213394

aut-num:        AS213394
as-name:        CleverCloud
org:            ORG-CCS42-RIPE
import:         from AS29075 accept ANY
import:         from AS3257 accept ANY
import:         from AS3356 accept ANY
import:         from AS43424 accept ANY
export:         to AS29075 announce AS213394:AS-CLVRCLD
export:         to AS3257 announce AS213394:AS-CLVRCLD
export:         to AS3356 announce AS213394:AS-CLVRCLD
export:         to AS43424 announce AS213394:AS-CLVRCLD
admin-c:        QA171-RIPE
tech-c:         QA171-RIPE
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         mnt-fr-clvrcldnet-1
created:        2022-11-28T08:24:23Z
last-modified:  2025-02-25T16:36:15Z
source:         RIPE

Un ASN (Autonomous System Number) est un identifiant unique attribué à un réseau sur Internet. Il est nécessaire pour annoncer des routes via BGP, le protocole qui permet le routage entre réseaux.

Maintenant que nous disposons d’un ASN, nous pouvons annoncer nos préfixes aux autres réseaux via le protocole BGP.

Le rôle de la base de données RIPE

Le RIPE NCC maintient une base de données publique d’objets de routage (comme l’objet aut-num présenté précédemment). Parmi ces objets figurent les objets de type route, qui indiquent quel système autonome (AS) est autorisé à annoncer un préfixe IP donné.

En pratique, ces entrées sont principalement utilisées par les opérateurs réseau et les fournisseurs de transit pour construire leurs politiques de routage et leurs mécanismes de filtrage (filtrage basé sur l’IRR). Ces filtres permettent d’accepter ou de rejeter les annonces reçues de leurs pairs. Il s’agit d’un des mécanismes utilisés pour tenter de prévenir les détournements BGP (BGP hijacks).

En appliquant ces filtres aux routes reçues de leurs pairs, les opérateurs peuvent limiter la propagation d’un préfixe annoncé par un ASN non autorisé.

Prenons un exemple : imaginons que l’organisation A possède le préfixe 192.0.2.0/24 et l’annonce à un fournisseur de transit X. Le fournisseur X applique un filtre sur les routes reçues de l’organisation A afin de n’accepter que les préfixes IP enregistrés dans la base RIR de cette organisation.

Dans ce cas, si l’organisation A commence à annoncer un préfixe qui ne lui appartient pas (par exemple notre préfixe public 91.208.207.0/24), le fournisseur X est censé rejeter cette annonce. Cela permet d’éviter qu’une route incorrecte soit propagée sur Internet et que le trafic soit redirigé vers une entité non légitime.

Le protocole BGP : comment Internet route le trafic

Pour comprendre comment nous annonçons nos préfixes sur Internet, il est essentiel de comprendre BGP — le Border Gateway Protocol. BGP est le protocole de routage de référence sur Internet. Il permet aux réseaux (systèmes autonomes) d’échanger des informations sur les préfixes IP qu’ils possèdent et sur la manière de les atteindre.

BGP fonctionne dans les deux sens. Lorsque nous annonçons à nos pairs et à nos fournisseurs de transit « nous possédons 91.208.207.0/24 », cette annonce se propage sur Internet de réseau en réseau. Chaque réseau qui relaie cette annonce ajoute son propre numéro d’AS dans le AS_PATH — une liste qui représente la séquence de réseaux qu’un paquet doit traverser pour nous atteindre.

Par exemple, OVHcloud (AS16276) voit le chemin [AS29075, AS213394] : le trafic passe par l’un de nos fournisseurs de transit (AS29075), puis arrive jusqu’à nous (AS213394). Chaque réseau qui relaie l’annonce la met à jour de cette manière, construisant progressivement un chemin complet.

Voici un exemple obtenu via le service Looking Glass d’OVHcloud :

> show route for 91.208.207.0/24 all

91.208.207.0/24    via 172.18.16.0 on eno1 [lil1_rbx1_bagg1_8k 2025-12-25] * (100/0) [AS213394i]
    Type: BGP unicast univ
    BGP.origin: IGP
    BGP.as_path: 29075 213394
    BGP.next_hop: 172.18.16.0
    BGP.med: 161
    BGP.local_pref: 40
    BGP.community: (0,0) (29075,18000) (65535,65281)
    BGP.23 [t]: 00 00 b8 6e
                   via 172.18.16.64 on eno1 [lil1_rbx8_bagg1_8k 2025-12-25] (100/0) [AS213394i]

Dans le même temps, nous recevons des annonces provenant d’autres réseaux concernant leurs propres préfixes et les chemins permettant de les atteindre. Cela construit la vue inverse : lorsque nous devons envoyer du trafic sortant, nous savons quel chemin emprunter pour atteindre une destination donnée.

Voici un exemple avec un préfixe d’OVHcloud :

> /routing/route/print detail where dst-address=5.39.0.0/17 and active

Ab   afi=ip4 contribution=active dst-address=5.39.0.0/17 routing-table=main pref-src=185.133.116.2 gateway=213.242.111.201 immediate-gw=213.242.111.201%sfp28-6 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-213.242.111.201"

      bgp.as-path="3356,16276" bgp.communities=3356:2,3356:2066,3356:22,16276:40001,3356:100,65002:7018,3356:123,3356:901,65002:701,65000:64990,65000:64995,65000:64996,3356:502 .med=0 .atomic-aggregate=no .origin=igp

Dans cet exemple, le chemin réseau utilisé par OVHcloud pour nous atteindre est différent de celui que nous utilisons pour les atteindre.

Le processus de migration

os préfixes IP étaient entièrement gérés par notre fournisseur historique. Bien que nous en soyons propriétaires, nous lui avions délégué leur annonce sur Internet.

Cela impliquait que son ASN (AS43424) apparaissait comme origine dans les tables de routage, et que l’ensemble du trafic transitait par son infrastructure.

Clever Cloud Services
   |
   | all inbound/outbound traffic
   v
Historical Provider (AS43424)
   |
   | originates: 91.208.207.0/24 (origin AS43424)
   v
Internet

Nous voulions que notre ASN devienne l’origine des annonces. Pour cela, nous avons planifié une migration en trois étapes, sans interruption pour les utilisateurs.

Migration d’un préfixe entre AS

Pour migrer un préfixe d’un AS vers un autre, nous devions modifier son objet route dans la base de données RIPE. La procédure était relativement simple, mais nécessitait un timing précis.

Nous avons d’abord créé un second objet route dans la base RIPE pour notre préfixe 91.208.207.0/24. Désormais, les deux ASN étaient enregistrés comme autorisés à annoncer ce même préfixe — à la fois l’AS de notre fournisseur historique et notre propre AS (213394).

Ces objets de routage sont interrogeables publiquement via la commande whois ou via l’interface web du RIPE. Par exemple, la commande suivante permet d’obtenir les deux objets enregistrés :

❯ whois -h whois.ripe.net -T route 91.208.207.0/24
% Information related to '91.208.207.0/24AS213394'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
descr:          CleverCloud subnet
origin:         AS213394
created:        2025-01-15T10:29:14Z
last-modified:  2025-01-15T10:29:14Z
source:         RIPE

% Information related to '91.208.207.0/24AS43424'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
mnt-by:         MAGICRETAIL-MNT
descr:          CleverCloud subnet
origin:         AS43424
created:        2020-02-13T09:06:33Z
last-modified:  2020-02-13T09:06:48Z
source:         RIPE

Une fois ce second objet route enregistré et propagé sur Internet (c’est-à-dire une fois que les opérateurs réseau ont récupéré une version à jour de la base RIPE pour construire leurs filtres de routage), nos nouveaux fournisseurs de transit pouvaient constater que notre ASN était autorisé à annoncer ce préfixe. À partir de ce moment-là, nous pouvions commencer à annoncer ce préfixe via notre propre infrastructure.

Si nous n’avions pas créé cet objet route, nos annonces auraient pu être rejetées et nous aurions pu être considérés comme des acteurs malveillants réalisant un détournement BGP (BGP hijack).

Annonce via notre fournisseur historique

Une fois le second objet route propagé, nous avons réalisé la première étape dans la nuit du 16 janvier 2025 : nous avons commencé à annoncer nous-mêmes le préfixe via BGP à notre fournisseur historique.

Le trafic continuait d’emprunter le même chemin de transit, mais cette fois avec Clever Cloud (AS213394) comme origine des annonces, au lieu de notre fournisseur historique. Ce dernier continuait à relayer le préfixe, mais le recevait désormais de notre part au lieu de l’annoncer directement.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   v
Historical Provider (AS43424)
   |
   | re-announces: 91.208.207.0/24 (origin AS213394)
   v
Internet

Cette première phase a servi de validation : en cas de problème, nous pouvions revenir rapidement en arrière sans impacter les autres chemins de transit.

Annonce via nos propres transits

Quelques jours plus tard, dans la nuit du 21 janvier 2025, nous avons franchi l’étape finale : nous avons commencé à annoncer le préfixe via nos propres connexions de transit dédiées.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   |
   +---+---+---+
   |   |   |   |
   v   v   v   v
  T1  T2  T3  HP
(Transit providers + historical provider)
   |   |   |   |
   +---+---+---+
   |
   v
Internet

Nous annonçons désormais nos préfixes directement à quatre fournisseurs upstream (trois fournisseurs de transit, T1/T2/T3, ainsi que notre fournisseur historique HP). Le trafic circule à travers l’ensemble de ces chemins, et nous disposons d’un contrôle complet sur les décisions de routage ainsi que sur la redondance.

Tout au long de ces deux phases, nous n’avons observé aucune interruption ayant un impact pour les utilisateurs. La redondance intrinsèque du protocole BGP, combinée à la nature progressive de la transition, a permis d’assurer un écoulement du trafic sans interruption, quel que soit le chemin privilégié à un instant donné.

Visibilité complète du routage Internet

Dans le cadre de la phase 2, nos trois principaux fournisseurs de transit ont commencé à nous fournir une « full view » de la table de routage Internet. Il s’agit de l’ensemble complet des préfixes IPv4 et IPv6 publiquement annoncés — soit environ 1 million de routes IPv4 et 220 000 routes IPv6.

Disposer d’une full view nous offre une visibilité inédite sur la structure d’Internet et nous permet de prendre des décisions de routage avancées. Au lieu de dépendre de la vision d’un seul fournisseur, nous avons désormais accès à l’ensemble des chemins disponibles pour atteindre n’importe quelle destination.

Avec ces informations, nous sommes en mesure de choisir les chemins optimaux pour notre trafic sortant en fonction de notre topologie réseau et de nos préférences, de mettre en œuvre du traffic engineering pour diriger les flux via des fournisseurs de transit spécifiques, de réagir dynamiquement aux conditions réseau et à la congestion, et d’équilibrer la charge entre nos quatre connexions de transit en nous appuyant sur des données de routage en temps réel.

Ce niveau de contrôle fin sur notre politique de routage est une conséquence directe de l’exploitation de notre propre système autonome et de la gestion de nos propres annonces — exactement le niveau d’indépendance opérationnelle que nous recherchions au début de cette transition.

Un an plus tard

Près d’un an après le début de l’exploitation de nos propres annonces réseau, la transition s’est révélée concluante. Nous n’avons rencontré aucun incident majeur et notre infrastructure a démontré sa résilience. Lorsque des incidents mineurs se sont produits — comme des pertes de paquets sur un fournisseur de transit spécifique ou la perte temporaire d’un lien — le trafic s’est automatiquement rééquilibré sur les connexions restantes.

Nous avons pu détecter et corriger ces problèmes directement, sans dépendre d’un fournisseur tiers. Nos utilisateurs n’ont subi aucune interruption ayant un impact. Cette capacité à assumer la responsabilité de notre réseau et à résoudre rapidement les problèmes est sans doute le principal bénéfice de cette transition.

Et ensuite

Cette transition est loin d’être terminée. Plusieurs évolutions sont prévues :

• augmentation de la capacité réseau pour absorber la croissance du trafic
• mise en place de peering BGP avec d’autres réseaux pour optimiser le trafic local sans recourir au transit
• déploiement de ROA (Route Origin Authorization) pour signer cryptographiquement nos annonces et prévenir les détournements de préfixes
• validation RPKI (Resource Public Key Infrastructure) pour vérifier la légitimité des annonces reçues et renforcer la sécurité du routage
• extension d’IPv6, en entrée (réception de trafic IPv6) comme en sortie (émission de trafic IPv6), déployée progressivement

Conclusion

Début 2025, Clever Cloud a finalisé sa transition vers une exploitation entièrement autonome de son réseau. Nous annonçons désormais nos propres préfixes IP via quatre fournisseurs upstream, ce qui nous donne un contrôle complet sur la manière dont le trafic entre et sort de notre infrastructure.

Pour nos utilisateurs, cela se traduit par une meilleure fiabilité et des temps de résolution plus courts dans notre région Paris. Lorsqu’un incident réseau survient, nous le traitons directement, et notre redondance multi-fournisseurs garantit la continuité du trafic.

Cette étape marque le début d’une nouvelle phase. Nous travaillons déjà sur le peering BGP pour optimiser le trafic local, sur le déploiement de ROA et la validation RPKI pour renforcer la sécurité du routage, ainsi que sur l’extension d’IPv6 pour généraliser le dual-stack. Nous construisons un réseau aussi robuste et autonome que le reste de notre infrastructure.

Nous avons donc construit notre propre orchestrateur. Il repose sur des micro-VMs et nous donne une frontière kernel propre entre les workloads, sans partage de noyau entre tenants. C'est ce qui fait tourner aujourd'hui des dizaines de milliers d'applications en production sur notre PaaS, et c'est encore, pour la plupart des projets, le chemin le plus court entre un commit et de la production.

Quand Docker est arrivé, certains workloads se prêtaient mieux à une image conteneurisée qu'à nos runtimes natifs. Nous avons donc ajouté un runtime Docker à la plateforme, là où ça avait du sens. Pas pour remplacer notre approche, mais pour l'élargir.

Puis Kubernetes s'est imposé comme le standard de fait de l'orchestration de conteneurs. Son écosystème (Helm, opérateurs, GitOps…) est devenu incontournable pour de nombreuses équipes.

Nous aurions pu continuer à répondre que, dans beaucoup de cas, Kubernetes n'est pas le meilleur chemin vers la production. C'est toujours vrai.

Mais ça ne suffisait plus.

C'est pour ça que nous lançons CKE, notre Clever Kubernetes Engine, aujourd'hui disponible en bêta publique.

Comme beaucoup le savent, pendant des années, nous avons résisté à l'idée de proposer Kubernetes comme une case à cocher de plus dans la Console. Non pas parce que Kubernetes ne sert à rien, mais parce qu'il est trop souvent devenu une réponse par défaut à des problèmes que le PaaS résout plus simplement : déployer une application, la scaler, la superviser, l'isoler, lui connecter une base de données, gérer ses variables d'environnement, ses logs et son cycle de vie. Et nous le pensons toujours.

Mais Kubernetes est devenu le langage commun d'une grande partie de l'écosystème cloud-native. Helm, les opérateurs, GitOps, les workloads déjà conteneurisés, les plateformes internes et les chaînes d'outillage existantes font partie de la réalité quotidienne de nombreuses équipes. Et notre raison d'être est de faciliter la vie des équipes techniques.

La question n'était donc plus "faut-il faire du Kubernetes ?", mais "peut-on faire du Kubernetes sans renier ce qui fait Clever Cloud ?"

Pas un Kubernetes empaqueté à la va-vite

Le chemin le plus rapide pour proposer du Kubernetes managé, c'est d'empaqueter une distribution upstream derrière une console d’administration, d'ajouter une API de provisioning, et de facturer le cluster à l'heure.

C'est une stratégie valide pour sortir vite.

Ce n'est pas celle que nous voulions.

Pour CKE, nous avions trois exigences qui ne se résolvent pas en ajoutant simplement Kubernetes à côté du reste de la plateforme.

La première, c'est la souveraineté. CKE est opéré en Europe, sur notre infrastructure et celle de nos partenaires, et peut aussi être déployé sur les infrastructures on-premises de nos clients qui en ont besoin. Pas de dépendance aux hyperscalers américains, pas de zones grises sur la juridiction des données, pas de promesse floue sur la localisation réelle de l'infrastructure.

La deuxième, c'est l'intégration avec le reste de Clever Cloud. Nous ne voulions pas créer un silo Kubernetes à côté du PaaS, des bases de données managées, du stockage objet et du réseau privé. Nous voulions un Kubernetes qui s'inscrive dans la même plateforme, avec la même Console, le même outillage, la même facturation, les mêmes règles de gouvernance et les mêmes services managés.

La troisième, c'est la prévisibilité opérationnelle. Kubernetes est un système distribué complexe, et son comportement sous charge dépend beaucoup de ses fondations. Nous ne voulions pas opérer un produit dont la couche basse resterait une boîte noire ou une limite acceptée par défaut.

C'est ce qui nous a amenés à travailler à un endroit que peu de fournisseurs touchent : la couche de cohérence interne de Kubernetes.

Sous le capot : Materia etcd sur FoundationDB

Dans Kubernetes, etcd est le composant qui stocke l'état du cluster : les manifests, les ressources, les secrets, l'état des nœuds. C'est la source de vérité de tout l'orchestrateur.

C'est aussi l'un des composants les plus sensibles du système.

etcd fonctionne très bien dans le cadre pour lequel il a été conçu. Mais ses limites à grande échelle sont connues : taille du store, latences sous forte charge en écriture, comportement en cas de partition réseau, opérations de sauvegarde et restauration, besoin de compaction et de surveillance fine. Quand Kubernetes devient une fondation critique, etcd devient un sujet d'exploitation à part entière.

Nous ne voulions pas construire CKE sur une brique que nous considérerions ensuite comme une boîte noire fragile.

Nous avons donc repris le problème à sa racine : conserver le contrat attendu par Kubernetes, mais remplacer la couche de cohérence interne par une implémentation adossée à FoundationDB. C'est ce que nous appelons Materia etcd.

FoundationDB nous apporte des transactions ACID distribuées, un modèle de cohérence robuste, et une approche de testing par simulation déterministe qui correspond très bien à notre manière de construire de l'infrastructure critique.

Pour l'utilisateur final, ce travail est invisible. C'est précisément le but. Sous le capot, cette fondation nous permet de construire CKE avec l'auto-scaling, l'auto-healing et la prévisibilité opérationnelle que nous attendons d'un service Clever Cloud.

Nous reviendrons bientôt plus en détail sur Materia etcd, parce que le sujet mérite un article dédié.

Du Kubernetes standard côté développeur

Tout ce travail sur la couche basse a un objectif simple : côté utilisateur, CKE doit être du Kubernetes standard.

Vos manifests fonctionnent sans modification. Vos charts Helm s'installent normalement. Votre Argo CD ou votre Flux se branche comme sur n'importe quel cluster. Vos opérateurs Kubernetes tournent sans surprise.

CKE ne cherche pas à réinventer l'interface développeur de Kubernetes. Ce serait contre-productif. Si vous avez déjà une chaîne de déploiement Kubernetes, l'objectif est qu'elle puisse fonctionner sur CKE avec le moins de friction possible.

La différence se joue ailleurs : dans la manière dont ce Kubernetes s'intègre au reste de la plateforme Clever Cloud.

Kubernetes quand vous en avez besoin, le PaaS quand il suffit

CKE ne remplace pas notre PaaS. Il le complète.

Pour beaucoup d'applications, le PaaS reste le meilleur choix : moins d'exploitation, moins de configuration, moins de YAML, moins de surface de maintenance. Si votre application rentre naturellement dans un runtime Clever Cloud, le PaaS reste souvent le chemin le plus simple et le plus robuste.

Mais il y a des cas où Kubernetes est le bon outil.

Vous avez peut-être besoin :

• D'installer un opérateur ;
• De reprendre des manifests existants ;
• De standardiser une chaîne GitOps ;
• De déployer un workload déjà distribué sous forme de chart Helm ;
• De faire tourner une plateforme interne construite autour de l'API Kubernetes ;
• Ou simplement de répondre aux habitudes d'une équipe qui travaille déjà avec Kubernetes au quotidien.

Dans ces cas-là, le problème n'est pas Kubernetes en soi. Le problème, c'est Kubernetes isolé du reste de votre système.

C'est là que CKE change les choses. Vous pouvez garder une API Node.js sur le PaaS, un frontend statique sur Cellar, une base PostgreSQL managée, et faire tourner sur CKE uniquement le composant, l'opérateur ou le workload qui a réellement besoin de Kubernetes.

Le tout dans le même environnement Clever Cloud.

Une intégration native avec l'écosystème Clever Cloud

CKE a été conçu pour s'intégrer avec les services que vous utilisez déjà sur Clever Cloud.

• Cellar, notre stockage objet compatible S3, peut être utilisé depuis vos workloads Kubernetes.
• Les bases de données managées (PostgreSQL, MySQL, MongoDB, Redis, Materia) s'attachent à votre cluster comme aux autres applications Clever Cloud.
• IAM as a Service permet de gérer l'authentification et les permissions sur le cluster et sur les équipes qui y accèdent.
• Network Groups permet de relier votre cluster CKE à vos applications PaaS Clever Cloud existantes, dans le même réseau privé.

L’intégration avec Network Groups est probablement celle qui change le plus le quotidien.

Kubernetes est souvent introduit dans les organisations comme une nouvelle île : nouvelle console, nouveau réseau, nouveaux secrets, nouvelles règles d'accès, nouvelle facturation, nouvelle façon de connecter les services entre eux.

Avec CKE, l'objectif est inverse. Kubernetes devient une brique de plus dans l'architecture Clever Cloud, pas un monde parallèle.

Vous pouvez donc construire une architecture hybride sans bricolage : une partie sur le PaaS, une partie sur CKE, des bases de données managées, du stockage objet, du réseau privé, et une gouvernance commune.

Activer CKE et déployer une première application

Pour cette démo, on va rester sur le minimum vital : activer la fonctionnalité, créer un cluster, récupérer un kubeconfig, ajouter un node group et déployer une première application avec un service de type LoadBalancer.

Côté prérequis, il faut avoir Clever Tools en version 4.3 ou supérieure, et kubectl installé sur votre poste.

Depuis l'ouverture de la bêta publique le 27 avril, la fonctionnalité Kubernetes peut être activée par tous les clients Clever Cloud, en une commande :

clever features enable k8s

On peut alors créer un cluster. Donnez-lui un nom, précisez votre organisation, et l'option --watch permet de suivre l'avancement du déploiement :

clever k8s create my-cluster --org <your-org-id> --watch

La création prend environ une minute. À tout moment, on peut lister les clusters de l'organisation avec clever k8s list.

Une fois le cluster prêt, on récupère son kubeconfig et on l'écrit directement comme configuration locale par défaut :

clever k8s get-kubeconfig my-cluster --org <your-org-id> > ~/.kube/config

À partir de là, c'est du Kubernetes standard. kubectl parle au cluster, et tout votre outillage habituel suit. On peut commencer par vérifier que tout est en place :

kubectl get nodes

À ce stade, la liste est vide : le cluster est créé mais sans capacité de calcul. C'est l'occasion d'introduire la première spécificité de CKE côté API : le NodeGroup. Un node group est un ensemble de nœuds Kubernetes de même profil (même flavor, même région), gérés comme un tout. Vous le décrivez comme n'importe quelle ressource Kubernetes, dans un fichier YAML :

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
  name: example-nodegroup
spec:
  flavor: M
  nodeCount: 2

Et vous l'appliquez avec kubectl :

kubectl create -f example-nodegroup.yaml

Soixante à quatre-vingt-dix secondes plus tard, les nœuds rejoignent le cluster :

kubectl get nodegroups
NAME                DESIREDNODECOUNT   CURRENTNODECOUNT   FLAVOR   STATUS   AGE
example-nodegroup   2                  2                  M        Synced   2m

kubectl get nodes
NAME                      STATUS   ROLES    AGE   VERSION
example-nodegroup-node0   Ready       2m    v1.35.0
example-nodegroup-node1   Ready       2m    v1.35.0

Pour ajuster la taille du node group, on reste dans l'API Kubernetes :

kubectl scale nodegroup example-nodegroup --replicas=4

Avec un cluster qui dispose maintenant de capacité de calcul, on peut déployer une première application. Pour faire simple, un nginx exposé via un service de type LoadBalancer, ce qui provisionnera automatiquement un load balancer côté Clever Cloud :

kubectl create deployment nginx --image=nginx:alpine --replicas=2 
kubectl expose deployment/nginx --type=LoadBalancer --port 80 
kubectl get service nginx

Quelques secondes plus tard, le service expose une adresse publique. C'est exactement le comportement réactif évoqué plus haut sur la phase de test privé : provisionner un node group, le scaler ou exposer un service ne demande ni attente ni configuration manuelle.

À partir d'ici, c'est du Kubernetes comme partout ailleurs. Vous pouvez ajouter du persistent storage via le CSI Clever Cloud, installer le Clever Kubernetes Operator pour provisionner depuis vos manifests une base de données managée, ou brancher votre chaîne GitOps habituelle. Le cluster supporte les versions Kubernetes 1.34, 1.35 et 1.36, avec 1.35 par défaut. Tout est détaillé dans la documentation CKE.

Ce qu'on a vu en test privé et à Devoxx, et la suite

CKE est désormais en bêta publique, mais certains de nos clients y ont accès en test privé depuis plusieurs mois. Cette phase a été très utile pour confronter le produit à des usages réels avant de l'ouvrir plus largement.

Les retours sont très positifs. Le cluster se comporte comme attendu, et les opérations qui touchent souvent au quotidien d'une équipe Kubernetes, comme l'ajout d'un nœud ou la mise en place d'un load balancer, sont rapides et prévisibles. C'est précisément le comportement que nous visions en investissant autant de temps sur la couche de cohérence interne.

À Devoxx France, nous avons présenté CKE sur le stand Clever Cloud pendant trois jours. Les discussions ont confirmé deux choses que nous observions déjà.

D'abord, les équipes ne cherchent pas seulement un cluster Kubernetes. Elles cherchent un Kubernetes qui s'intègre proprement à leur plateforme, à leur réseau, à leurs bases de données, à leurs contraintes de sécurité et à leurs pratiques existantes.

Ensuite, et c'est sans doute le retour le plus marquant, les développeurs ne cherchent pas à tout mettre sur Kubernetes. Beaucoup veulent garder leurs applications classiques sur notre PaaS, là où il est le plus efficace, et déployer sur Kubernetes uniquement les composants qui le méritent vraiment, par leur complexité, par leur architecture distribuée ou par les contraintes de l'écosystème dans lequel ils s'inscrivent.

C’est exactement le genre d’architecture hybride que CKE est conçu pour permettre.

C’est aussi pour ça que nous avions construit, en amont du lancement, le Clever Kubernetes Operator. Il permet à un workload qui tourne dans un cluster Kubernetes, qu’il soit hébergé chez nous ou ailleurs, de provisionner et de consommer nos services managés directement depuis l’API Kubernetes : PostgreSQL, MySQL, MongoDB, Redis, Cellar ou Materia.

Pour vos équipes, c’est du kubectl apply qui crée une base de données managée. Pour CKE, c’est l’outil naturel pour faire le pont entre les workloads Kubernetes et le reste de la plateforme Clever Cloud.

La bêta est ouverte à tous les clients Clever Cloud. Vous pouvez l'activer dès maintenant, déployer vos premiers workloads, et nous faire remonter ce qui vous manque, ce qui vous surprend ou ce que vous aimeriez voir arriver ensuite.

La discussion est ouverte sur notre communauté GitHub, et la documentation est disponible ici.

CKE ne remplace pas notre PaaS. Il le complète.

Pour beaucoup d'applications, le PaaS reste le chemin le plus simple entre un commit et de la production. Mais quand vous avez besoin de Kubernetes, pour un opérateur, un chart Helm, une chaîne GitOps, un workload déjà standardisé ou une plateforme interne, vous pouvez maintenant le faire dans l'environnement Clever Cloud, avec nos choix d'infrastructure, notre réseau, nos services managés et nos exigences de souveraineté.

C'est ce Kubernetes-là que nous voulions construire.

Dans ce contexte, la question n'est plus de savoir s'il faut migrer, mais comment structurer ce qui existe, maîtriser les opérations au quotidien et conserver le contrôle sur ses environnements et ses données.

Le mardi 28 avril à 11 h 30, Clever Cloud et Cycloid organisent un webinaire pour aborder ces enjeux.

Deux regards croisés sur un problème commun

Nous vous proposons un échange croisé pour apporter un éclairage concret sur ces sujets.

Cycloid traite la structuration et la gouvernance des environnements au travers d'un portail et d'une plateforme de développement interne unifiés. Clever Cloud aborde l’exploitation managée, le maintien en condition opérationnelle (MCO) et la souveraineté opérationnelle.

Rejoignez Florent Perreux (Chief Sales Officer @ Clever Cloud), Steven Le Roux (CTO @ Clever Cloud), Alexandre Blin (Business Director SEMEA @ Cycloid) et Olivier de Turckheim (Solution Architect @ Cycloid) pour comprendre comment articuler gouvernance et exploitation sans ajouter de complexité.

Au programme

🔹 Pourquoi la modernisation cloud ne se limite plus à une migration ;

🔹 Les enjeux de structuration et de gouvernance dans des environnements multi-cloud ;

🔹 Les défis opérationnels liés à l’exploitation et au MCO ;

🔹 Comment articuler gouvernance et exploitation sans multiplier la complexité ;

🔹 Une session Q&A pour poser vos questions en direct.

Pourquoi participer ?

✅ Comprendre les causes réelles de la complexité dans les projets cloud ;

✅ Identifier les leviers pour structurer vos usages et limiter la dépendance fournisseur ;

✅ Mieux appréhender les enjeux d’exploitation et de souveraineté ;

✅ Bénéficier de retours d’expérience concrets ;

✅ Échanger directement avec des experts.

Inscrivez-vous dès maintenant

🗓️ Mardi 28 avril 2026

⏰ 11h30 - 12h00

💻 Webinaire en ligne sur Livestorm

Vous êtes confronté à ces enjeux, rejoignez-nous le 28 avril prochain !

Nantes, France — Clever Cloud, fournisseur européen de solutions cloud, annonce l'ouverture en bêta publique de Clever Kubernetes Engine (CKE) le 27 avril 2026 dans l’après-midi. Le produit sera présenté en avant-première au Devoxx à partir du 22 avril, où les participants pourront le tester directement sur le stand Clever Cloud.

Conçu pour la production et la scalabilité

Kubernetes est devenu le standard de l'orchestration de conteneurs. Clever Cloud a travaillé pendant deux ans pour proposer une version managée et souveraine, conçue pour s'intégrer naturellement dans l'écosystème Clever Cloud et s'opérer avec la même simplicité que les autres services de la plateforme. CKE est pensé pour accompagner des charges de production réelles, avec une scalabilité élevée et un comportement prévisible à grande échelle.

Pour y parvenir, Clever Cloud a notamment développé Materia etcd, une réimplémentation de la couche de cohérence interne de Kubernetes construite sur FoundationDB. C'est ce travail de fond, invisible pour l'utilisateur final, qui garantit à CKE sa robustesse et sa stabilité en production, notamment grâce à de l’auto-scalabilité et de “l'auto-healingde façon native.

CKE s'intègre nativement aux services Clever Cloud existants — stockage objet Cellar (compatible S3), bases de données managées, IAM as a Service, Network Groups — et reste accessible via les outils standard du marché : kubectl, Helm ou GitOps.

Souverain par conception

Hébergé et opéré en Europe par Clever Cloud sur son cloud public, CKE offre aux organisations une alternative concrète aux offres Kubernetes des grandes plateformes américaines, sans compromis sur les performances ni sur la maîtrise juridique des données. CKE peut aussi être déployé sur les infrastructures on-premises du client. 

Modalités d'accès

La bêta publique est ouverte à tous les clients de Clever Cloud à partir du 27 avril 2026, via l'activation de fonctionnalités à réaliser par l’utilisateur. À noter : certains clients bénéficient d'un accès en test privé depuis plus de six mois déjà, ce qui a permis d'affiner le produit avant cette ouverture générale.

"Clever Cloud a longtemps développé des alternatives à Kubernetes. Nos clients nous ont exprimé un besoin clair pour cette technologie, et nous avons décidé de la construire à leurs côtés, avec le niveau d'exigence technique et de souveraineté qui définit notre plateforme." Quentin Adam, CEO de Clever Cloud

En savoir plus