OC2-Edge versus k3s + Zarf: the benchmark

This article contains no measurement results. It publishes a protocol.

OC2-Edge will be compared to the k3s + Zarf stack, the reference for Kubernetes deployments in disconnected environments. The chosen method is that of preregistered studies (registered reports): the full protocol is published and frozen before the first measurement [4]. The metrics, the conditions, and the publication rules are therefore settled here, publicly, before anyone knows who wins what.

A protocol published before the measurements

In research, preregistration consists of publicly depositing the hypotheses, the metrics, and the analysis plan before data collection [4]. The goal is to prevent two known biases: selecting favorable metrics after the fact, and rewording hypotheses after the fact so that they fit the results.

A benchmark published by the maker of the system under test is exposed to exactly these two biases. Preregistration is the countermeasure: what we will measure, how, and what we will publish is fixed in this article and versioned in the repository. Any later change to the protocol will be published as a separate, dated addendum with its justification. The results will be the subject of a separate article, once the measurements are judged solid.

Why k3s + Zarf

k3s is a lightweight, certified conformant Kubernetes distribution, designed for edge, IoT (Internet of Things), and resource-constrained environments [1]. Zarf is a delivery tool for disconnected environments: it packages container images, manifests, and dependencies into a self-sufficient archive that can be installed and operated without Internet access [2].

The combination of the two is the reference in this domain. It is the approach adopted by the DoD Platform One ecosystem, the U.S. Department of Defense software platform, whose Big Bang distribution builds on Kubernetes and whose air-gapped deployments use Zarf [2][3]. Comparing OC2-Edge to this stack means comparing it to the state of the art actually deployed, not to a convenient target.

The two systems embody two philosophies. k3s + Zarf assembles generic IT components and adapts them to constrained environments: the path of genericity. OC2-Edge is an integrated node, designed from the start for the tactical post: the path of specialization. The benchmark measures what this design difference changes in practice, if it changes anything.

Six metrics, and why they matter at the tactical edge

The protocol preregisters six metrics. Each corresponds to a real constraint of the tactical post, not to a brochure figure.

1. Disk and RAM footprint at rest. The embedded computer shares its resources with mission workloads: sensor fusion, inference, encryption. Every megabyte consumed by the platform is taken from the mission. Planned measurement: disk usage after full installation, resident memory after stabilization, with no application load, on both systems.

2. Cold start time to operational service. A tactical node restarts after a power cut, in a vehicle, not in a UPS-backed rack. The metric runs from power-on to the first C2 (command and control) service usable by the operator: tactical picture displayable, not a login prompt. Planned measurement: cold start, system electrically off, identical reference service on both sides.

3. Behavior under memory pressure. When memory runs out, the Linux kernel kills processes through the OOM killer (Out Of Memory killer); the order of victims depends on cgroup configuration and declared memory protections [5]. At the tactical edge, degradation must be prioritized: the minimal C2 function survives, comfort telemetry dies first. Planned measurement: controlled memory pressure ramp, observation of the order in which processes are killed and of the survival of the reference C2 service.

4. Behavior under prolonged network partition. A tactical node operates cut off from the network for hours or days: jamming, EMCON, terrain. The metric observes two things: the state of services during the partition, including the node’s ability to remain locally operable, and the behavior on restoration (resynchronization without intervention, without state corruption). This requirement matches the project’s availability doctrine (P8 doctrine, article in French).

5. Preemption and priorities under load. At CPU saturation, priority processing (receiving an alert, updating a friendly position) must preempt background processing. Planned measurement: saturating CPU load, injection of priority events, end-to-end processing latency measured on both systems.

6. Full offline operability. Initial installation, update, rollback: all three operations are executed without any network access, from local media, by an operator following the published documentation. The criterion is binary per operation: the operation succeeds without network or it does not. The number of manual interventions required is recorded.

The planned conditions

The protocol fixes the following conditions, before any measurement.

Same hardware for both systems, same workloads, same disturbance scenarios. The exact bench hardware will be announced with the first results; depending on the progress of the Jetson campaign, the measurements will target the ARM64 emulator and then silicon.
Configurations published in full in the repository, for both systems.
Replayable scripts: every measurement is produced by a versioned script. A third party with equivalent hardware can replay the full protocol and compare their figures to ours.
Good-faith configuration of the compared system: k3s and Zarf are configured according to their official documentation and the published practices of the Platform One ecosystem [1][2][3], not left in an unfavorable default configuration. Any optimization applied to one system is documented, and its equivalent is sought for the other.
Frozen, published versions of both systems at measurement time.

The protocol also states what it does not measure. The comparative security of the two systems (attack surface, hardening posture) is out of scope: it belongs to a dedicated analysis, not to a load bench. Cost of ownership, operator training load, and the availability of qualified personnel are out of scope: these factors weigh in a real-world choice, but they cannot be measured on a bench. Finally, the protocol does not compare application ecosystems: the number of workloads available for Kubernetes is an established fact that does not need to be measured here. Anything not listed in the six metrics is considered not covered by this benchmark.

The pre-committed publication rules

Five rules are committed to here, before the first measurement.

Raw results are published whatever they are, including when they are unfavorable to OC2-Edge.
Unfavorable conditions are part of the protocol and will not be removed from it: the scenarios where the generic stack is expected to do better are measured and published like the others.
No publication of unsound measurements: a measurement that is unstable, not reproducible from one run to the next, is marked as an open point and reworked, not published as a result.
The protocol no longer changes after the first measurement. Any addition or removal of a metric is the subject of a public, dated, justified addendum.
Failures are published like successes: this is a production rule of this blog, already applied to the Jetson campaign log.

The expected conclusion, stated fairly

An honest preregistration also states what the author expects to find. Here are our expectations, formulated before measurement and falsifiable by the measurements.

What the k3s + Zarf stack does well, and what the benchmark should confirm: the richness of the ecosystem (operators, charts, observability tooling), genericity (any standard Kubernetes workload deploys), and the maturity of the disconnected delivery tooling [1][2]. A project that has already invested in Kubernetes will find a well-marked path there.

What the integrated node is designed to do better: footprint (no stacked generic layers), cold start (a single immutable image rather than an orchestration to rebuild), controlled degradation (C2 priorities are in the base, not in bolted-on configuration).

These are design expectations, not results. The measurements will confirm or refute them, metric by metric. If an expectation is refuted, the result will be published with the same visibility as the others, and the gap will be analyzed publicly. The protocol is in the repository; it can be replayed today, without waiting for our results article.

Sources

K3s Project (SUSE), “K3s: Lightweight Kubernetes”, documentation, 2026, https://docs.k3s.io
Zarf Project (OpenSSF), “Zarf: Airgap software delivery”, documentation, 2026, https://docs.zarf.dev
U.S. Department of Defense, “DoD Platform One”, 2026, https://p1.dso.mil
Center for Open Science, “Preregistration”, 2026, https://www.cos.io/initiatives/prereg
The Linux Kernel documentation, “Control Group v2” (memory controller, OOM events), 2026, https://docs.kernel.org/admin-guide/cgroup-v2.html