Rust-native Cloud Operating System with an OpenStack-compatible northbound surface.
OpenStack compatibility northbound. O3K Cloud Kernel in the middle. Typed infrastructure execution southbound.
O3K is not a service-for-service Rust rewrite of Nova, Neutron, Keystone, Glance, Placement, and Cinder. OpenStack service names define compatibility surfaces; O3K owns its internal cloud model.
Core principles:
- OpenStack compatibility is northbound. Existing CLI/SDK/Terraform workflows remain valuable contracts.
- O3K owns cloud authority. Public IDs, ownership, desired state, scheduling, operations, and reconciliation are O3K concerns.
- The Cloud Kernel is shared. IAM, authorization, resource ownership, operations, quotas, audit/event identity, and failure semantics are reused by first-class O3K domains.
- Execution is southbound. Host agents/providers perform bounded mutations and report observations.
- Kubernetes is a first-class deployment target. Kubernetes may operate the O3K control plane, but it does not become O3K's VM scheduler, tenant-resource database, or Cloud Kernel.
Current status: alpha. P9 (routed fabric), P10 (native persistent storage — LVM + Ceph RBD), and P11 (multi-hypervisor edge cloud with overlapping tenant CIDRs, Geneve+WireGuard, three-host real evidence) are completed. The small-edge-cloud profile (10–20 hypervisors target) has real-host evidence. Production HA, full OpenStack parity, and broad maximum-scale are not current support claims.
On a clean Ubuntu 24.04 or Debian 12 x86_64 VM:
curl -sfL https://get.o3k.io | sudo sh -get.o3k.io is only a convenience redirect to the official GitHub Release
asset. The canonical direct alpha URL is:
curl -sfL https://github.com/kubedoio/o3k-rust/releases/download/v0.2.0-alpha.2/install.sh | sudo sh -The future stable URL will be
https://github.com/kubedoio/o3k-rust/releases/latest/download/install.sh —
it is not the alpha source and must not be used before a stable release
exists.
The installer is pinned to its own release: it installs the verified
v0.2.0-alpha.2 release bundle, bootstraps the libvirt TestLab (test-vm
ACTIVE, console verified), and writes client credentials to
/etc/o3k/admin-openrc and /etc/o3k/clouds.yaml — the admin password is
never printed.
Supported: Ubuntu 24.04 x86_64, Debian 12 x86_64, libvirt TestLab alpha.
Version pinning and the dev/test overrides (O3K_VERSION,
O3K_RELEASE_BASE), credentials, idempotent re-run, uninstall/purge, and
troubleshooting: docs/INSTALLER.md.
Not claimed: production, HA, Kubernetes HA, PostgreSQL, full OpenStack, native Cinder, ARM/RHEL/etc.
OpenStack clients
|
o3kd
|
SQLite + O3K domain/scheduler/reconciler
|
versioned provider boundary
|
o3k-compute o3k-network o3k-storage
| | |
libvirt Geneve+WG LVM / Ceph RBD
o3kd is the current integrated control-plane composition shell. Host-local
real compute, network, and storage execution cross typed gRPC+mTLS agent
boundaries. Multi-host topology with overlapping tenant CIDRs, Geneve realm
encapsulation over WireGuard host transport, and LVM/RBD storage is proven
on three-host real evidence with 15 simulated scale hosts.
Kubernetes deployability is a main O3K product target, not community packaging added later.
The target architecture is:
OpenStack / O3K clients
|
Gateway / Service
|
+------------- Kubernetes -------------+
| o3kd-1 o3kd-2 o3kd-3 |
| \ | / |
| PostgreSQL |
| probes / rollout / config / metrics |
+----------------+----------------------+
|
versioned mTLS
|
external hypervisor hosts
|
o3k-compute
|
libvirt / QEMU / KVM
The governing rules are deliberately strict:
- Kubernetes operates the control-plane processes; O3K remains the cloud authority.
- Cloud Kernel/domain crates do not depend on Kubernetes APIs.
- PostgreSQL is required before an HA/cloud-native Kubernetes support claim; SQLite remains the single-controller/TestLab store.
- Multiple
o3kdreplicas require durable work ownership and controller fencing. Pod replication alone is not correctness. - Hypervisor/network/storage execution stays host-local by default instead of being forced into privileged pods.
- Kubernetes CRDs may later manage the O3K installation, but do not become the canonical database for servers, networks, volumes, or operations.
- Pod-local state is cache/scratch only for authoritative control-plane data.
- OCI images + Helm are the first packaging target; an Operator is justified only when O3K-specific lifecycle automation needs one.
See ADR-0167 — Kubernetes-native control-plane deployment.
intent
-> authorization
-> durable desired state + operation
-> scheduling
-> provider command
-> infrastructure mutation
-> observation
-> reconciliation / compensation
A timeout is an unknown outcome, not proof of failure. O3K observes before retrying an operation whose side effect may already have happened.
| OpenStack surface | O3K domain |
|---|---|
| Keystone | O3K IAM |
| Glance | O3K Image |
| Nova | O3K Compute |
| Neutron | O3K Network |
| Placement | O3K Capacity / Placement |
| Cinder | O3K Volume compatibility / hosted integration today |
- SQLite: supported default for TestLab and single-controller profiles.
- PostgreSQL: supported production-oriented persistence profile (verified with PostgreSQL 16).
PostgreSQL is a prerequisite for the future HA Kubernetes profile. O3K does not use shared-SQLite or distributed-filesystem workarounds as a shortcut to Kubernetes HA.
O3K has one product architecture and three primary deployment/evidence profiles:
- OpenStack service testbed — host external OpenStack services against O3K IAM/compute/network;
- native O3K TestLab/cloud — single-host, P9/P10 complete (routed fabric, LVM + Ceph RBD persistent storage);
- small edge cloud — P11 complete: multi-host with overlapping CIDRs, Geneve+WireGuard fabric, LVM locality, serial RBD, drain/restart/failure recovery, 3-host evidence with 15 simulated scale hosts (targets ~10–20 hypervisors).
Kubernetes is a deployment substrate target across applicable control-plane profiles, not a separate cloud-authority model.
cargo build
cargo run --bin o3kdFor real libvirt execution use docs/TESTLAB.md.
- Architecture
- Visual summary
- ADR-0165 — Cloud OS / Cloud Kernel
- ADR-0166 — O3K IAM / Keystone compatibility
- ADR-0167 — Kubernetes-native control plane
- Product requirements
- Roadmap
- Normative source map
O3K is a clean-slate Rust implementation owned and developed by Kubedo GmbH. It is based on public OpenStack APIs/specifications, public client behavior, O3K ADRs/specifications/contracts, and independently produced evidence.
Apache-2.0.