OpenStack gives Kubernetes everything it needs and none of it pre-wired. This is the component list you end up owning, where each piece breaks, the three provisioning routes and what they cost after the first cluster works. If you would rather not own any of it, that layer already exists: edgeContinuum delivers managed Kubernetes on the OpenStack you already run.
The two projects are complementary, not competing. OpenStack is the infrastructure layer: Nova hands out compute, Neutron hands out networks, Cinder hands out block volumes, Keystone hands out identity. Kubernetes is the workload layer above it, and it expects a cloud underneath that can create disks and load balancers on demand.
So "Kubernetes on OpenStack" is not a product you install. It is an integration: worker nodes are Nova instances, PersistentVolumes are Cinder volumes, Service type=LoadBalancer becomes an Octavia load balancer, and something has to translate between the two APIs. That translator is the OpenStack cloud controller manager, and getting it, the CSI driver and the CNI to agree is most of the work.
Nearly every team gets the first cluster working by hand in a week and then discovers the second one costs the same week again. Almost all the engineering in this space is about making cluster number twenty cost nothing, which is why the provisioning route in section 6 matters far more than the component list in section 2.
A production cluster on OpenStack needs the following pieces, most of them from the upstream cloud-provider-openstack project, each versioned and upgraded independently of the others:
LoadBalancer support.kuryr-kubernetes, the plugin that put pods directly on Neutron ports, is retired upstream, so an overlay is the answer for new clusters.ReadWriteMany, which Cinder cannot give you.The version matrix is the part that bites. The CCM and the Cinder CSI driver track the Kubernetes minor they were built for, so an upgrade is not one bump but a coordinated set. Older interfaces disappear on the way: cloud-provider-openstack dropped the legacy neutron-lbaas path years ago and speaks only to Octavia now, and the in-tree cloud provider is gone entirely, so any runbook that predates the out-of-tree CCM is misleading.
Every component on this list is already assembled, version-matched and kept current inside edgeContinuum. Your teams request a cluster from a console or an API and get a kubeconfig; nobody on your side owns the CCM, the CSI driver, the CNI wiring or the upgrade sequencing. See managed Kubernetes on your OpenStack, or start a free trial and provision one against a lab deployment.
Cinder CSI is the well-trodden path and behaves predictably once three decisions are made deliberately:
WaitForFirstConsumer in any multi-AZ deployment. The default binds the volume before the scheduler picks a node, and in a zoned cloud that produces pods that cannot start because their volume lives elsewhere.VolumeSnapshotClass was never created.Cinder gives block volumes, so a volume attaches to one node at a time. Workloads that genuinely need a shared filesystem need Manila and the Manila CSI driver, and that is a second storage integration with its own failure modes, not a flag on the first one.
Pod networking runs as an overlay on top of Neutron. That is one encapsulation inside another, so MTU is the first thing to get right: set the CNI MTU below the Neutron network MTU and the class of intermittent failures where small requests work and large responses hang never appears.
Load balancing is where the cost model surprises people. Every Service type=LoadBalancer asks the CCM for an Octavia load balancer, and each one is real infrastructure with its own amphora, its own VIP and its own lifecycle. Forty microservices exposed that way means forty load balancers. The pattern that scales is a single ingress controller behind one Octavia VIP, with HTTP routing done inside the cluster, and Services of type LoadBalancer reserved for things that genuinely need their own layer-4 entry point.
Octavia is also the slowest thing in a cluster build. Amphora provisioning is measured in minutes, so a cluster that creates several load balancers as part of its bootstrap will spend most of its creation time waiting on Neutron and Octavia rather than on Kubernetes.
Kubernetes has no user database. On OpenStack you have two upstream options, and teams usually pick the first and regret it later.
The first is client certificates, generated per person, distributed by hand, revoked by rebuilding trust. It works for three platform engineers and collapses at thirty developers across eight teams.
The second is the Keystone webhook authenticator, which lets Kubernetes ask Keystone who a bearer token belongs to and which roles it carries, then maps those onto RBAC. Access follows OpenStack project membership, so a developer removed from a project loses cluster access without anyone touching a kubeconfig. The cost is that Keystone becomes part of every cluster's control path and its availability becomes a cluster concern.
A managed platform can also take the question off the cluster entirely. edgeContinuum issues an administrative kubeconfig per cluster, and downloading it is gated by the platform's own roles: whoever holds the permission in the organization that owns the cluster can fetch it from the console or the API, and nobody else can. The Keystone webhook is not part of that path, so Keystone never sits in a cluster's control path, and in-cluster RBAC for the teams working inside the cluster stays yours to define with standard Kubernetes objects.
Either way, an OpenStack project is not a tenant boundary for Kubernetes on its own. Projects carry compute, network and volume quotas, so they bound how much infrastructure a team can consume, but nothing in a project stops a team from creating clusters at the wrong version, in the wrong topology, without backups. That gap is the subject of the OpenStack self-service platform architecture guide. The users, projects and quotas guide covers the Keystone and quota model in its own right.
Every team running Kubernetes on OpenStack has chosen one of these three, whether or not the choice was explicit.
Terraform or Ansible creates the instances, kubeadm bootstraps the cluster, your playbooks install the CCM, the CSI driver and the CNI. It is the fastest route to one working cluster and the most honest teacher: you learn exactly which pieces exist. What stays yours forever is certificate rotation, etcd care, control plane load balancers, node replacement, and every upgrade, once per cluster, by hand.
Magnum is OpenStack's own container infrastructure service, so cluster creation lives in the same API and CLI as the rest of the cloud, which is genuinely attractive when the people creating clusters are the people operating OpenStack. Two things limit it in practice. It tends to trail upstream Kubernetes, so the version you need may not be the version your Magnum release supports. And it was designed as an infrastructure service, so day-two work, upgrades in particular, stays close to the operators rather than becoming something a development team can do for itself. edgeContinuum does not use Magnum, for exactly those two reasons.
CAPO makes clusters declarative Kubernetes objects: a manifest describes the cluster and controllers reconcile reality towards it, so creation, scaling and upgrades become state rather than scripts. It is the strongest technical foundation available, and it is what edgeContinuum builds on underneath.
It is also a framework rather than a finished service, and the list of things it does not decide for you is the real cost: someone owns the management cluster and its availability, the cluster templates and their drift, the Glance image pipeline, the CNI and storage-class defaults, the upgrade sequencing across a fleet, and the diagnosis when a reconcile loop wedges. That someone is a platform team, and staffing it is the decision, not adopting CAPO.
| Route | First cluster | Twentieth cluster | Who creates clusters |
|---|---|---|---|
| kubeadm plus automation | Days | Same effort as the first, per cluster | The platform or infrastructure team |
| Magnum | Hours, once Magnum itself is deployed | Cheap to create, day-two stays with operators | OpenStack operators |
| Cluster API (CAPO) | Weeks, counting the management cluster | Marginal, if the templates are maintained | Whoever can apply a manifest, which is rarely a developer |
| Managed platform on top | Minutes | Marginal | The team that wants the cluster, inside a quota |
Day-one is a demo. Day-two is the product, and it is four recurring jobs.
One decision shapes the density of everything above: does each cluster get its own control plane nodes, or do control planes run as workloads on a management cluster? Three dedicated control plane VMs per cluster means sixty VMs before a single workload runs on a twenty-cluster estate, while hosted control planes consolidate that into pods at a fraction of the footprint, with a different failure domain and different isolation properties. The trade-offs are worked through in hosted vs dedicated Kubernetes control planes.
Tenancy sits alongside it. Multiple teams on one OpenStack need cluster-level isolation, not just namespaces, and quotas that hold at the layer where clusters are requested. Neither Kubernetes nor OpenStack provides that on its own: Kubernetes has no concept of your organizations, and OpenStack projects bound raw infrastructure rather than managed services.
Everything above is buildable, and plenty of good teams have built it. The question worth asking before starting is whether running Kubernetes is a capability your organization wants to own, or a dependency it wants handled.
edgeContinuum is the second answer. It uses Cluster API with the OpenStack provider underneath, and adds the layer that turns it into a service: clusters requested from a console or API inside a quota, CNCF-conformant and version-pinned, with the CCM, Cinder CSI and CNI already wired; in-place upgrades sequenced across a fleet; autoscaling and self-healing driven by desired state; hosted or dedicated control planes as a choice at creation time; and organizations, projects, roles and quotas above it so a development team can serve itself without an operator in the loop. The OpenStack underneath stays yours, operated with your existing tooling, and the same platform runs from SaaS to fully air-gapped.
Because the clusters are conformant, nothing about the workloads changes: existing charts, operators, manifests and CRDs are redeployed unmodified. See the managed Kubernetes on OpenStack page for what the service does, or OpenShift vs CNCF Kubernetes on OpenStack if the alternative on your table is a per-core distribution.
Where to start: request a free trial and provision a managed cluster against a lab OpenStack, which takes minutes and costs you nothing to find out. If you would rather have the design reviewed first, book the call below and bring your component choices.
Start a free trial and provision a managed, CNCF-conformant cluster on your OpenStack in minutes, with the CCM, Cinder CSI, CNI and upgrades already handled. Or bring your release, your storage choices and your cluster count to a call, and our engineers will work the design against your estate.