Containers as a Service: ein Pod pro Container, isoliert in einer eigenen Kata-MicroVM, mit seinem Neutron-Port als einzigem Netz.
Go Kata-Podsopenkeel-zun
Das Modul
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
Auszug aus openkeel-zun/README.md (auf Englisch).
REST-API
73 Operationen der Original-REST-API (Routen und Body-Aktionen) und ihr Status in OpenKeel.
Aus den API-Tests von Python-Zun aufgezeichnete Austausche und Sonden der echten Pecan-Anwendung werden gegen den Go-Dienst wiedergegeben, ergänzt durch Algorithmus-Vektoren und einen Controller-Test auf einem Fake-Cluster.
Replay aufgezeichneter Austausche
E2E-Replay der aufgezeichneten API-Tests
Die 256 Austausche aus 221 Python-API-Tests liefern denselben Status und Body, jeweils auf einer Datenbank, die so befüllt ist, wie der aufgezeichnete Test es voraussetzte.
Ausführung
make e2e (test/e2e), Bericht in report.json; make e2e-strict schlägt bei jedem nicht in known-differences.txt aufgeführten Unterschied fehl.
Letztes Ergebnis 223 / 256 identisch; der Strict-Modus besteht, die 35 Unterschiede sind mit ihrer Begründung aufgeführt.
Quelle: openkeel-zun/docs/CONFORMANCE.md
Replay aufgezeichneter Austausche
Sonden der echten Pecan-Anwendung
An die echte Python-Anwendung gesendete Anfragen außerhalb ihrer Unit-Tests erhalten vom Go-Dienst dieselben Antworten.
Ausführung
Replay von test/e2e/testdata/zun.probes.json in der e2e-Suite.
Letztes Ergebnis 30 / 32; die 2 übrigen sind absichtlich behobene Python-Fehler (Fallen T7, T13).
Quelle: openkeel-zun/docs/CONFORMANCE.md
Unit- und Golden Tests
Algorithmus-Vektoren aus Python
Parsing von Image-Namen, Pull-Entscheidungen, Zuordnung der Docker-Zustände, Placement-Abfragen, Neustartrichtlinie und Portregeln entsprechen den Python-Funktionen.
Ausführung
internal/zun/vectors_test.go auf _rewrite/vectors_stable-2026.2.json.
Letztes Ergebnis 8 / 8 Familien, 307 Fälle.
Quelle: openkeel-zun/docs/CONFORMANCE.md
Unit- und Golden Tests
Container-Lebenszyklus auf einem Fake-Cluster
Erstellen, Scheduling, Claim, Neutron-Ports, Kata-Pod, Stoppen und Löschen hinterlassen dieselben Datensätze wie in Python, einschließlich Ports und Allokationen.
Ausführung
internal/compute/manager_test.go mit Kubernetes-Fakes.
Letztes Ergebnis Bestanden.
Quelle: openkeel-zun/docs/CONFORMANCE.md
Im Rewrite ausgelassen
Zun behält seine v1-API, betreibt Container aber als Kubernetes-Pods in Kata-VMs; damit entfallen Docker-spezifische Operationen und der Knoten-Stack aus Docker, CNI und Kuryr.
Von der Cloud-Native-Plattform übernommen
Docker-Daemon, zun-cni und kuryr-libnetwork
Übernommen von Kubernetes-Pods, Kata Containers
Warum es ausgelassen wurde
Container sind Pods, die von Placement platziert und in Kata-VMs isoliert werden; Neutron-Ports werden über das OVN-CNI angebunden, und das kubelet zieht die Images und bindet die Cinder-PVCs ein.
Warum die Lösung nicht beeinträchtigt ist
python-zunclient, openstack appcontainer, Skyline und Heat funktionieren weiterhin mit derselben API; der Knoten-Stack ist der des Clusters.
Quelle: openkeel-zun/README.md
Von der Cloud-Native-Plattform übernommen
Pause, unpause und commit
Übernommen von Kubernetes
Warum es ausgelassen wurde
Kubernetes hat keine Freezer- oder Commit-API; sie hinzuzufügen würde einen Knoten-Agenten mit Root-Zugriff auf containerd oder cgroups erfordern, was OpenKeel ablehnt (Entscheidung vom 2026-11-02).
Warum die Lösung nicht beeinträchtigt ist
Diese Aktionen antworten 409 container.operation-not-supported. Images werden in einer Registry gebaut; laufende Container sind nicht betroffen.
Quelle: openkeel-zun/docs/CONFORMANCE.md
Von der Cloud-Native-Plattform übernommen
Beschreibbare Schicht über stop hinweg erhalten
Übernommen von Kubernetes
Warum es ausgelassen wurde
Kubernetes kennt keinen gestoppten Pod, der wieder starten kann: stop löscht den Pod und start erzeugt einen neuen.
Warum die Lösung nicht beeinträchtigt ist
Dateisystem und Logs des Containers gehen beim Stoppen verloren. In Cinder-Volumes abgelegte Daten überstehen stop, start, reboot und rebuild, was die dokumentierte Praxis ist.
Quelle: openkeel-zun/README.md
Von der Cloud-Native-Plattform übernommen
Docker-Image-Suche, docker load, Docker-Netzwerke
Übernommen von Kubernetes (kubelet)
Warum es ausgelassen wurde
Es gibt keinen Daemon zum Suchen, Laden von Archiven oder Anlegen von Netzwerken; kubelets ziehen aus Registries, und Pods binden Neutron-Ports direkt an.
Warum die Lösung nicht beeinträchtigt ist
Die Image-Suche liefert nur exakte Referenzen, Glance-Images benötigen eine OCI-Referenz, und das Anlegen eines Netzwerks speichert nur eine Zeile. Die Vernetzung der Container selbst übernimmt Neutron.
Quelle: openkeel-zun/README.md
Von der Cloud-Native-Plattform übernommen
DISK_GB-Claim in Placement
Übernommen von Kubernetes (ephemeral-storage)
Warum es ausgelassen wurde
Kein OpenKeel-Provider veröffentlicht DISK_GB, da Root-Disks PVCs sind; der Claim würde jeden Container mit Disk in Error versetzen.
Warum die Lösung nicht beeinträchtigt ist
Die Disk wird zu Request und Limit des ephemeral-storage des Pods: Das kubelet platziert und begrenzt sie, wie es storage-opt bei Docker tat. CPU und Speicher werden weiterhin in Placement beansprucht.
Quelle: openkeel-zun/docs/CONFORMANCE.md
Vereinfachte interne Mechanik
RabbitMQ-RPC zu zun-compute
Warum es ausgelassen wurde
Die API stellt jede asynchrone Operation in eine Datenbanktabelle ein, die zun-compute per Compare-and-Set beansprucht; ein einziges aktives zun-compute hält einen Lease.
Warum die Lösung nicht beeinträchtigt ist
Für Zun ist kein RabbitMQ erforderlich und die API bleibt unverändert; der Task eines abgestürzten Workers wird übernommen.
Quelle: openkeel-zun/README.md
Hier ist nur aufgeführt, was bewusst ausgelassen wurde; noch nicht erledigte Arbeit steht in den Known gaps der docs/CONFORMANCE.md des Moduls. Alle Module
Zun-Interaktionen
Dienstansicht, vom Diagramm-Skill aus dem OpenKeel-Modell generiert.
