Containers as a Service: un Pod por contenedor, aislado en su propia microVM Kata, con su puerto Neutron como única red.
Go Pods Kataopenkeel-zun
El módulo
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
Extracto de openkeel-zun/README.md (en inglés).
API REST
73 operaciones de la API REST original (rutas y acciones de cuerpo) y su estado en OpenKeel.
Los intercambios grabados de los tests de API de Zun en Python y las sondas de la aplicación Pecan real se reproducen contra el servicio Go, con vectores de algoritmo y un test del controlador en un clúster simulado.
Replay de los intercambios grabados
Replay E2E de los tests de API grabados
Los 256 intercambios de 221 tests de API de Python dan el mismo estado y el mismo cuerpo, cada uno sobre una base de datos poblada según lo que implicaba el test grabado.
Ejecución
make e2e (test/e2e), informe en report.json; make e2e-strict falla ante cualquier diferencia no enumerada en known-differences.txt.
Último resultado 223 / 256 idénticos; el modo estricto se supera, con las 35 diferencias enumeradas junto con su motivo.
Fuente: openkeel-zun/docs/CONFORMANCE.md
Replay de los intercambios grabados
Sondas de la aplicación Pecan real
Las peticiones enviadas a la aplicación Python real, fuera de sus tests unitarios, obtienen las mismas respuestas del servicio Go.
Ejecución
Replay de test/e2e/testdata/zun.probes.json en la suite e2e.
Último resultado 30 / 32; los 2 restantes son defectos de Python corregidos a propósito (trampas T7, T13).
Fuente: openkeel-zun/docs/CONFORMANCE.md
Tests unitarios y golden tests
Vectores de algoritmo procedentes de Python
El análisis de nombres de imagen, las decisiones de pull, la correspondencia de estados de Docker, las consultas a Placement, la política de reinicio y las reglas de puertos coinciden con las funciones de Python.
Ejecución
internal/zun/vectors_test.go sobre _rewrite/vectors_stable-2026.2.json.
Último resultado 8 / 8 familias, 307 casos.
Fuente: openkeel-zun/docs/CONFORMANCE.md
Tests unitarios y golden tests
Ciclo de vida de contenedores en un clúster simulado
La creación, la planificación, la reserva, los puertos de Neutron, el Pod Kata, la parada y la eliminación dejan los mismos registros que en Python, puertos y asignaciones incluidos.
Ejecución
internal/compute/manager_test.go con simulaciones de Kubernetes.
Último resultado Superado.
Fuente: openkeel-zun/docs/CONFORMANCE.md
Excluido del rewrite
Zun conserva su API v1 pero ejecuta los contenedores como Pods de Kubernetes en VM de Kata, por lo que desaparecen las operaciones específicas de Docker y la pila de nodo de Docker, CNI y Kuryr.
Asumido por la plataforma Cloud Native
Demonio Docker, zun-cni y kuryr-libnetwork
Asumido por Pods de Kubernetes, Kata Containers
Por qué se excluyó
Los contenedores son Pods ubicados por Placement y aislados en VM de Kata; los puertos de Neutron se conectan mediante el CNI de OVN, y el kubelet descarga las imágenes y monta los PVC de Cinder.
Por qué la solución no se ve afectada
python-zunclient, openstack appcontainer, Skyline y Heat siguen funcionando con la misma API; la pila de nodo es la del propio clúster.
Fuente: openkeel-zun/README.md
Asumido por la plataforma Cloud Native
Pause, unpause y commit
Asumido por Kubernetes
Por qué se excluyó
Kubernetes no tiene API de congelación ni de commit; añadirlas exigiría un agente de nodo con acceso root a containerd o a los cgroups, lo que OpenKeel rechaza (decisión del 2026-11-02).
Por qué la solución no se ve afectada
Estas acciones responden 409 container.operation-not-supported. Las imágenes se construyen en un registro; los contenedores en ejecución no se ven afectados.
Fuente: openkeel-zun/docs/CONFORMANCE.md
Asumido por la plataforma Cloud Native
Capa de escritura conservada tras stop
Asumido por Kubernetes
Por qué se excluyó
Kubernetes no tiene un Pod detenido que pueda volver a arrancar: stop elimina el Pod y start crea uno nuevo.
Por qué la solución no se ve afectada
El sistema de archivos y los logs del contenedor se pierden al detenerlo. Los datos guardados en volúmenes Cinder sobreviven a stop, start, reboot y rebuild, que es la práctica documentada.
Fuente: openkeel-zun/README.md
Asumido por la plataforma Cloud Native
Búsqueda de imágenes Docker, docker load, redes Docker
Asumido por Kubernetes (kubelet)
Por qué se excluyó
No hay ningún demonio que busque, cargue archivos o cree redes; los kubelets descargan desde registros y los Pods se conectan directamente a puertos de Neutron.
Por qué la solución no se ve afectada
La búsqueda de imágenes solo devuelve referencias exactas, las imágenes de Glance requieren una referencia OCI, y la creación de redes solo registra una fila. La red de los contenedores en sí corresponde a Neutron.
Fuente: openkeel-zun/README.md
Asumido por la plataforma Cloud Native
Reserva de DISK_GB en Placement
Asumido por Kubernetes (ephemeral-storage)
Por qué se excluyó
Ningún provider de OpenKeel publica DISK_GB, ya que los discos raíz son PVC; la reserva pondría en Error todo contenedor con disco.
Por qué la solución no se ve afectada
El disco pasa a ser la request y el limit de ephemeral-storage del Pod: el kubelet lo ubica y lo limita, como hacía storage-opt de Docker. CPU y memoria se siguen reservando en Placement.
Fuente: openkeel-zun/docs/CONFORMANCE.md
Mecánica interna simplificada
RPC de RabbitMQ hacia zun-compute
Por qué se excluyó
La API encola cada operación asíncrona en una tabla de base de datos que zun-compute reserva mediante compare-and-set; un único zun-compute activo mantiene un Lease.
Por qué la solución no se ve afectada
Zun no necesita RabbitMQ y la API no cambia; la tarea de un worker caído se retoma.
Fuente: openkeel-zun/README.md
Aquí solo figura lo que se excluyó por diseño; el trabajo aún no realizado está en los Known gaps del docs/CONFORMANCE.md del módulo. Todos los módulos
Interacciones Zun
Vista de servicio generada por la skill de diagramas a partir del modelo de OpenKeel.
