OC2-Edge face à k3s + Zarf : le benchmark

Cet article ne contient aucun résultat de mesure. Il publie un protocole.

OC2-Edge sera comparé à l’assemblage k3s + Zarf, la référence des déploiements Kubernetes en environnement déconnecté. La méthode retenue est celle des études pré-enregistrées (registered reports) : le protocole complet est publié et figé avant la première mesure [4]. Les métriques, les conditions, les règles de publication sont donc arrêtées ici, publiquement, avant que quiconque sache qui gagne quoi.

Un protocole publié avant les mesures

En recherche, le pré-enregistrement consiste à déposer publiquement les hypothèses, les métriques et le plan d’analyse avant la collecte des données [4]. L’objectif est d’empêcher deux biais connus : sélectionner après coup les métriques favorables, et reformuler après coup les hypothèses pour qu’elles collent aux résultats.

Un benchmark publié par l’éditeur du système mesuré s’expose exactement à ces deux biais. Le pré-enregistrement est la parade : ce que nous mesurerons, comment, et ce que nous publierons est fixé dans cet article et versionné dans le dépôt. Toute modification ultérieure du protocole sera publiée comme addendum distinct, daté, avec sa justification. Les résultats feront l’objet d’un article séparé, une fois les mesures jugées solides.

Pourquoi k3s + Zarf

k3s est une distribution Kubernetes allégée et certifiée conforme, conçue pour l’edge, l’IoT (Internet of Things) et les environnements à ressources contraintes [1]. Zarf est un outil de livraison en environnement déconnecté : il empaquette images de conteneurs, manifestes et dépendances dans une archive auto-suffisante, installable et opérable sans accès à Internet [2].

L’assemblage des deux est la référence du domaine. C’est l’approche retenue par l’écosystème DoD Platform One, la plateforme logicielle du département de la Défense américain, dont la distribution Big Bang s’appuie sur Kubernetes et dont les déploiements « air-gapped » utilisent Zarf [2][3]. Comparer OC2-Edge à cet assemblage, c’est le comparer à l’état de l’art réellement déployé, pas à une cible commode.

Les deux systèmes incarnent deux philosophies. k3s + Zarf assemble des composants IT génériques et les adapte aux environnements contraints : c’est la voie de la généricité. OC2-Edge est un nœud intégré, conçu dès l’origine pour le poste tactique : c’est la voie de la spécialisation. Le benchmark mesure ce que cette différence de conception change en pratique, si elle change quelque chose.

Six métriques, et pourquoi elles comptent au tactique

Le protocole pré-enregistre six métriques. Chacune correspond à une contrainte réelle du poste tactique, pas à un chiffre de plaquette.

1. Empreinte disque et RAM au repos. Le calculateur embarqué partage ses ressources avec les charges de mission : fusion de capteurs, inférence, chiffrement. Chaque mégaoctet consommé par la plateforme est retiré à la mission. Mesure prévue : occupation disque après installation complète, mémoire résidente après stabilisation, sans charge applicative, sur les deux systèmes.

2. Temps de démarrage à froid jusqu’au service opérationnel. Un nœud tactique redémarre sur coupure d’alimentation, dans un véhicule, pas dans une baie ondulée. La métrique court de la mise sous tension au premier service C2 (commandement et contrôle) utilisable par l’opérateur : image tactique affichable, pas invite de connexion. Mesure prévue : démarrage à froid, système éteint électriquement, service de référence identique des deux côtés.

3. Comportement sous pression mémoire. Quand la mémoire vient à manquer, le noyau Linux tue des processus via l’OOM killer (Out Of Memory killer) ; l’ordre des victimes dépend de la configuration des cgroups et des protections mémoire déclarées [5]. Au tactique, la dégradation doit être hiérarchisée : la fonction C2 minimale survit, la télémétrie de confort meurt en premier. Mesure prévue : montée en pression mémoire contrôlée, observation de l’ordre des processus tués et de la survie du service C2 de référence.

4. Comportement en partition réseau prolongée. Un nœud tactique opère coupé du réseau pendant des heures ou des jours : brouillage, EMCON, terrain. La métrique observe deux choses : l’état des services pendant la partition, dont la capacité du nœud à rester pilotable localement, et le comportement au rétablissement (resynchronisation sans intervention, sans corruption d’état). Cette exigence rejoint la doctrine de disponibilité du projet (doctrine P8).

5. Préemption et priorités sous charge. À saturation CPU, les traitements prioritaires (réception d’une alerte, mise à jour d’une position amie) doivent préempter les traitements de fond. Mesure prévue : charge CPU saturante, injection d’événements prioritaires, mesure de leur latence de traitement de bout en bout sur les deux systèmes.

6. Opérabilité hors ligne complète. Installation initiale, mise à jour, retour arrière : les trois opérations sont exécutées sans aucun accès réseau, depuis un support local, par un opérateur suivant la documentation publiée. Le critère est binaire par opération : l’opération aboutit sans réseau ou elle n’aboutit pas. Le nombre d’interventions manuelles requises est consigné.

Les conditions prévues

Le protocole fixe les conditions suivantes, avant toute mesure.

• Même matériel pour les deux systèmes, mêmes charges de travail, mêmes scénarios de perturbation. Le matériel exact du banc sera annoncé avec les premiers résultats ; selon l’avancement de la campagne Jetson, les mesures viseront l’émulateur ARM64 puis le silicium.
• Configurations publiées intégralement dans le dépôt, pour les deux systèmes.
• Scripts rejouables : chaque mesure est produite par un script versionné. Un tiers disposant du matériel équivalent peut rejouer le protocole complet et confronter ses chiffres aux nôtres.
• Configuration de bonne foi du système comparé : k3s et Zarf sont configurés selon leur documentation officielle et les pratiques publiées de l’écosystème Platform One [1][2][3], pas laissés dans une configuration par défaut défavorable. Toute optimisation appliquée à un système est documentée, et son équivalent est recherché pour l’autre.
• Versions figées et publiées des deux systèmes au moment de la mesure.

Le protocole énonce aussi ce qu’il ne mesure pas. La sécurité comparée des deux systèmes (surface d’attaque, posture de durcissement) est hors périmètre : elle relève d’une analyse dédiée, pas d’un banc de charge. Le coût de possession, la charge de formation des opérateurs et la disponibilité de personnel qualifié sont hors périmètre : ces facteurs pèsent dans un choix réel, mais ils ne se mesurent pas sur un banc. Enfin, le protocole ne compare pas les écosystèmes applicatifs : le nombre de charges disponibles pour Kubernetes est un fait établi qui n’a pas besoin d’être mesuré ici. Ce qui n’est pas listé dans les six métriques est réputé non couvert par ce benchmark.

Les règles de publication pré-engagées

Cinq règles sont engagées ici, avant la première mesure.

1. Les résultats bruts sont publiés quels qu’ils soient, y compris lorsqu’ils sont défavorables à OC2-Edge.
2. Les conditions défavorables font partie du protocole et n’en seront pas retirées : les scénarios où l’assemblage générique est attendu meilleur sont mesurés et publiés comme les autres.
3. Aucune publication de mesures non solides : une mesure instable, non reproductible d’une exécution à l’autre, est marquée comme point ouvert et retravaillée, pas publiée comme résultat.
4. Le protocole ne change plus après la première mesure. Tout ajout ou retrait de métrique fait l’objet d’un addendum public daté et justifié.
5. Les échecs sont publiés comme les succès : c’est une règle de production de ce blog, déjà appliquée au journal de campagne Jetson.

La conclusion attendue, loyalement

Un pré-enregistrement honnête énonce aussi ce que l’auteur s’attend à trouver. Voici nos attentes, formulées avant mesure et falsifiables par les mesures.

Ce que l’assemblage k3s + Zarf fait bien, et que le benchmark devrait confirmer : la richesse de l’écosystème (opérateurs, charts, outillage d’observabilité), la généricité (toute charge Kubernetes standard se déploie), la maturité de l’outillage de livraison déconnectée [1][2]. Un projet qui a déjà investi dans Kubernetes y trouvera un chemin balisé.

Ce que le nœud intégré est conçu pour faire mieux : l’empreinte (pas de couches génériques empilées), le démarrage à froid (une image immuable unique plutôt qu’une orchestration à reconstruire), la dégradation contrôlée (les priorités C2 sont dans le socle, pas dans une configuration rapportée).

Ce sont des attentes de conception, pas des résultats. Les mesures les confirmeront ou les infirmeront, métrique par métrique. Si une attente est infirmée, le résultat sera publié avec la même visibilité que les autres, et l’écart sera analysé publiquement. Le protocole est dans le dépôt ; il est rejouable dès aujourd’hui, sans attendre notre article de résultats.

Sources

1. K3s Project (SUSE), « K3s : Lightweight Kubernetes », documentation, 2026, https://docs.k3s.io
2. Zarf Project (OpenSSF), « Zarf : Airgap software delivery », documentation, 2026, https://docs.zarf.dev
3. U.S. Department of Defense, « DoD Platform One », 2026, https://p1.dso.mil
4. Center for Open Science, « Preregistration », 2026, https://www.cos.io/initiatives/prereg
5. The Linux Kernel documentation, « Control Group v2 » (contrôleur mémoire, événements OOM), 2026, https://docs.kernel.org/admin-guide/cgroup-v2.html