OpenKeel: the sovereign French Cloud solution of the inherent group, with a European reach Discover inherent
Components · Compute and capacity
Containers as a Service: one Pod per container, isolated in its own Kata microVM, with its Neutron port as its only network.
OpenKeel implementation in Go of OpenStack Zun (containers service), generated from the reverse-specification of branch stable/2026.2 (reverse-spec-zun/) by the generate-go-from-spec skill. The Zun v1 API (microversions 1.1 to 1.40) is kept byte-compatible, so python-zunclient, openstack appcontainer, Skyline, Heat and gophercloud keep working unchanged. The node side is replaced: containers run as Kubernetes Pods, isolated in Kata Containers VMs by default, on the node that Placement chose, as openkeel-nova runs VMs on KubeVirt.
What is reproduced and what differs is in docs/CONFORMANCE.md and in § Compatibility gaps below; the security checklist is docs/SECURITY.md.
github.com/openkeel/openkeel-zun| Executable | Kubernetes object | Role | Python process it replaces |
|---|---|---|---|
zun-api | Deployment (port 9517, admin 9090) | REST API, scheduling through Placement, synchronous Kubernetes calls (logs, exec, top, stats, archives) | zun-api |
zun-compute | Deployment, one active replica (Lease) | runs the queued operations: Neutron ports, Cinder attachments, Pods; state sync | the container work of zun-compute |
zun-compute-agent | DaemonSet | zun-compute service heartbeat, compute_node row, Placement inventory of its node | the inventory and service parts of zun-compute |
zun-wsproxy | Deployment (port 6784) | attach and interactive exec WebSockets | zun-wsproxy |
zun-cni, zun-cni-daemon, Docker, containerd CRI and kuryr-libnetwork are gone. There is no RabbitMQ: the API queues each asynchronous operation in the openkeel_task table, which zun-compute claims by compare-and-set.
Excerpt from openkeel-zun/README.md (in English).
73 operations of the original REST API (routes and body actions), and their state in OpenKeel.
Exchanges recorded from Python Zun's API tests and probes of the real Pecan application are replayed against the Go service, with algorithm vectors and a controller test on a fake cluster.
The 256 exchanges of 221 Python API tests give the same status and body, each on a database seeded as the recorded test implied.
make e2e (test/e2e), report in report.json; make e2e-strict fails on any difference not listed in known-differences.txt.
Latest result 223 / 256 identical; strict mode passes, the 35 differences listed with their reason.
Source: openkeel-zun/docs/CONFORMANCE.md
Requests sent to the real Python application, outside its unit tests, get the same answers from the Go service.
Replay of test/e2e/testdata/zun.probes.json in the e2e suite.
Latest result 30 / 32; the 2 others are Python defects fixed on purpose (traps T7, T13).
Source: openkeel-zun/docs/CONFORMANCE.md
Image name parsing, pull decisions, Docker state mapping, Placement queries, restart policy and port rules match the Python functions.
internal/zun/vectors_test.go on _rewrite/vectors_stable-2026.2.json.
Latest result 8 / 8 families, 307 cases.
Source: openkeel-zun/docs/CONFORMANCE.md
Create, schedule, claim, Neutron ports, Kata Pod, stop and delete leave the same records as Python, ports and allocations included.
internal/compute/manager_test.go with Kubernetes fakes.
Latest result Pass.
Source: openkeel-zun/docs/CONFORMANCE.md
Zun keeps its v1 API but runs containers as Kubernetes Pods in Kata VMs, so Docker-specific operations and the Docker, CNI and Kuryr node stack are gone.
Taken over by Kubernetes Pods, Kata Containers
Containers are Pods placed by Placement and isolated in Kata VMs; Neutron ports attach through the OVN CNI, and the kubelet pulls images and mounts Cinder PVCs.
python-zunclient, openstack appcontainer, Skyline and Heat keep working against the same API; the node stack is the cluster's own.
Source: openkeel-zun/README.md
Taken over by Kubernetes
Kubernetes has no freezer or commit API; adding them would need a node agent with root access to containerd or cgroups, which OpenKeel refuses (decision 2026-11-02).
These actions answer 409 container.operation-not-supported. Images are built in a registry; running containers are unaffected.
Source: openkeel-zun/docs/CONFORMANCE.md
Taken over by Kubernetes
Kubernetes has no stopped Pod that can start again: stop deletes the Pod and start creates a new one.
The container filesystem and logs are lost on stop. Data kept in Cinder volumes survives stop, start, reboot and rebuild, which is the documented practice.
Source: openkeel-zun/README.md
Taken over by Kubernetes (kubelet)
There is no daemon to search, load archives or create networks; kubelets pull from registries and Pods attach Neutron ports directly.
Image search returns only exact references, Glance images need an OCI reference, and network create only records a row. Container networking itself is Neutron's.
Source: openkeel-zun/README.md
Taken over by Kubernetes (ephemeral-storage)
No OpenKeel provider publishes DISK_GB, root disks being PVCs; the claim would put every container with a disk in Error.
The disk becomes the Pod's ephemeral-storage request and limit: the kubelet places and caps it, as Docker's storage-opt did. CPU and memory are still claimed in Placement.
Source: openkeel-zun/docs/CONFORMANCE.md
The API queues each asynchronous operation in a database table that zun-compute claims by compare-and-set; one active zun-compute holds a Lease.
No RabbitMQ is needed for Zun and the API is unchanged; a crashed worker's task is taken over.
Source: openkeel-zun/README.md
Only what was left out by design is listed here; the work not done yet is in the Known gaps of the module's docs/CONFORMANCE.md. Every module
Service view generated by the diagram skill from the OpenKeel model.
Full screen| From | To | Protocol | What |
|---|---|---|---|
| Zun API | Placement | REST API | allocation candidates, claims |
| Zun API | Kubernetes API server | Kubernetes API | logs, exec, top, resize, metrics |
| Zun compute | Neutron server | REST API | ports bound to host (compute:zun) |
| Zun compute | Cinder API | REST API | attachments → kubernetes_pvc |
| Zun compute | Kubernetes API server | Kubernetes API | Pods (Kata RuntimeClass), NADs, Secrets |
| Zun compute agent | Placement | REST API | inventory (Node UID provider) |
| Zun compute agent | Kubernetes API server | Kubernetes API | Node allocatable, Pods |
| Zun wsproxy | Kubernetes API server | Kubernetes API | attach, exec (WebSockets) |
Branch stable-2026.2 · 8 files
Read the reverse-specResource inventories and allocations; the first component rewritten in Go.
Instances run as KubeVirt VirtualMachines; conductor with the scheduler in process, one agent per node.
Instance high availability; node health from Node Healthcheck and Self Node Remediation.
Bare metal: stays upstream Python, packaged in an OpenKeel chart; too many hardware configurations to test.