Containers as a Service: un Pod per container, isolato nella propria microVM Kata, con la sua porta Neutron come unica rete.
Go Pod Kataopenkeel-zun
Il modulo
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.
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.
Configuration: YAML, see config/config.example.yaml (dropped oslo options and why: config/dropped-options.md)
Development environment, database and tests: docs/GETTING-STARTED.md
Database schema, migrations and upgrades: docs/DATABASE.md
Integration with openkeel-nova (one change to its agent): docs/NOVA-INTEGRATION.md
Estratto da openkeel-zun/README.md (in inglese).
API REST
73 operazioni dell'API REST originale (route e azioni nel corpo) e il loro stato in OpenKeel.
Gli scambi registrati dai test API di Zun Python e le sonde dell'applicazione Pecan reale vengono riprodotti sul servizio Go, con vettori di algoritmo e un test del controller su un cluster simulato.
Replay degli scambi registrati
Replay E2E dei test API registrati
I 256 scambi di 221 test API Python restituiscono lo stesso stato e lo stesso corpo, ciascuno su un database popolato come previsto dal test registrato.
Esecuzione
make e2e (test/e2e), report in report.json; make e2e-strict fallisce su qualsiasi differenza non elencata in known-differences.txt.
Ultimo risultato 223 / 256 identici; la modalità strict è superata, con le 35 differenze elencate insieme alla loro motivazione.
Fonte: openkeel-zun/docs/CONFORMANCE.md
Replay degli scambi registrati
Sonde dell'applicazione Pecan reale
Le richieste inviate all'applicazione Python reale, al di fuori dei suoi test unitari, ottengono le stesse risposte dal servizio Go.
Esecuzione
Replay di test/e2e/testdata/zun.probes.json nella suite e2e.
Ultimo risultato 30 / 32; gli altri 2 sono difetti di Python corretti di proposito (trappole T7, T13).
Fonte: openkeel-zun/docs/CONFORMANCE.md
Test unitari e golden test
Vettori di algoritmo ricavati da Python
L'analisi dei nomi delle immagini, le decisioni di pull, la mappatura degli stati Docker, le query a Placement, la policy di riavvio e le regole delle porte corrispondono alle funzioni Python.
Esecuzione
internal/zun/vectors_test.go su _rewrite/vectors_stable-2026.2.json.
Ultimo risultato 8 / 8 famiglie, 307 casi.
Fonte: openkeel-zun/docs/CONFORMANCE.md
Test unitari e golden test
Ciclo di vita dei container su un cluster simulato
Creazione, scheduling, claim, porte Neutron, Pod Kata, arresto ed eliminazione lasciano gli stessi record di Python, porte e allocazioni incluse.
Esecuzione
internal/compute/manager_test.go con simulatori Kubernetes.
Ultimo risultato Superato.
Fonte: openkeel-zun/docs/CONFORMANCE.md
Escluso dal rewrite
Zun mantiene la sua API v1 ma esegue i container come Pod Kubernetes in VM Kata, per cui scompaiono le operazioni specifiche di Docker e lo stack di nodo Docker, CNI e Kuryr.
Gestito dalla piattaforma Cloud Native
Daemon Docker, zun-cni e kuryr-libnetwork
Gestito da Pod Kubernetes, Kata Containers
Perché è stato escluso
I container sono Pod posizionati da Placement e isolati in VM Kata; le porte Neutron si collegano tramite il CNI OVN, e il kubelet scarica le immagini e monta i PVC Cinder.
Perché la soluzione non ne risente
python-zunclient, openstack appcontainer, Skyline e Heat continuano a funzionare con la stessa API; lo stack di nodo è quello del cluster.
Fonte: openkeel-zun/README.md
Gestito dalla piattaforma Cloud Native
Pause, unpause e commit
Gestito da Kubernetes
Perché è stato escluso
Kubernetes non ha API di freeze né di commit; aggiungerle richiederebbe un agente di nodo con accesso root a containerd o ai cgroup, cosa che OpenKeel rifiuta (decisione del 2026-11-02).
Perché la soluzione non ne risente
Queste azioni rispondono 409 container.operation-not-supported. Le immagini si costruiscono in un registry; i container in esecuzione non sono interessati.
Fonte: openkeel-zun/docs/CONFORMANCE.md
Gestito dalla piattaforma Cloud Native
Livello scrivibile conservato dopo stop
Gestito da Kubernetes
Perché è stato escluso
Kubernetes non prevede un Pod arrestato che possa ripartire: stop elimina il Pod e start ne crea uno nuovo.
Perché la soluzione non ne risente
Il filesystem e i log del container vanno persi all'arresto. I dati conservati nei volumi Cinder sopravvivono a stop, start, reboot e rebuild, che è la prassi documentata.
Fonte: openkeel-zun/README.md
Gestito dalla piattaforma Cloud Native
Ricerca di immagini Docker, docker load, reti Docker
Gestito da Kubernetes (kubelet)
Perché è stato escluso
Non c'è alcun daemon per cercare, caricare archivi o creare reti; i kubelet scaricano dai registry e i Pod si collegano direttamente alle porte Neutron.
Perché la soluzione non ne risente
La ricerca di immagini restituisce solo riferimenti esatti, le immagini Glance richiedono un riferimento OCI, e la creazione di una rete registra solo una riga. La rete dei container stessa è compito di Neutron.
Fonte: openkeel-zun/README.md
Gestito dalla piattaforma Cloud Native
Claim DISK_GB in Placement
Gestito da Kubernetes (ephemeral-storage)
Perché è stato escluso
Nessun provider OpenKeel pubblica DISK_GB, essendo i dischi root dei PVC; il claim metterebbe in Error ogni container dotato di disco.
Perché la soluzione non ne risente
Il disco diventa la request e il limit di ephemeral-storage del Pod: il kubelet lo posiziona e lo limita, come faceva storage-opt di Docker. CPU e memoria restano oggetto di claim in Placement.
Fonte: openkeel-zun/docs/CONFORMANCE.md
Meccanismi interni semplificati
RPC RabbitMQ verso zun-compute
Perché è stato escluso
L'API accoda ogni operazione asincrona in una tabella del database che zun-compute acquisisce con compare-and-set; un unico zun-compute attivo detiene un Lease.
Perché la soluzione non ne risente
Zun non richiede RabbitMQ e l'API resta invariata; il task di un worker in crash viene ripreso.
Fonte: openkeel-zun/README.md
Qui è elencato solo ciò che è stato escluso per scelta progettuale; il lavoro non ancora svolto si trova nei Known gaps del docs/CONFORMANCE.md del modulo. Tutti i moduli
Interazioni Zun
Vista del servizio generata dalla skill dei diagrammi a partire dal modello OpenKeel.
