CNCF-conformant clusters on the infrastructure you already run: pick a region, a control plane model and node pools, and the platform provisions everything and hands back a kubeconfig. Upgrades, scaling and healing run continuously from there.
Running Kubernetes on OpenStack by hand means gluing provisioners, cloud providers and upgrade tooling into a stack someone has to babysit; every cluster is a snowflake and every version bump is a risk. edgeContinuum ships that layer as a product: on-premises managed Kubernetes, declared through a console or API, kept in its desired state by the platform. Your team asks for a cluster; nobody builds one.
Almost every team evaluating this has already run Kubernetes on OpenStack in some form, usually kubeadm or Cluster API with a provisioning pipeline around it. It works. The question is what it costs to keep working, across a fleet, through upgrades, for years. The pipeline is yours to maintain as OpenStack and Kubernetes both move; cluster creation stays a request into the team that owns it; every version bump is planned work made harder by drift; and anything air-gapped means rebuilding the pipeline again. If you are still mapping that work, OpenShift vs CNCF Kubernetes on OpenStack covers the per-core alternative and the OpenStack self-service platform architecture guide covers the layer above the clusters.
The honest version: if you have one or two long-lived clusters and an engineer who enjoys this work, building it is defensible. The economics change with the third cluster, the second site, and the first upgrade nobody wants to own.
Pick a region, a control plane model and node pools; the platform provisions the cluster on your OpenStack and hands back a kubeconfig. Download it and use kubectl in seconds, from the console, the API or Terraform. Every cluster lives inside a project, so quotas and roles apply automatically, and downloading that kubeconfig is its own permission: an operations team can scale a node pool without ever holding cluster credentials. See identity and access. To compare topology tradeoffs, read our architectural guide on hosted vs dedicated control planes.
Cluster information
Network information
Every dedicated control plane costs you VMs before the first workload runs. With hosted control planes, cluster control planes run pooled on shared infrastructure while worker nodes stay in each team’s project: more clusters per rack, same isolation for workloads. Choose per cluster; both models live side by side.
There are three well-established ways to get clusters onto OpenStack, and they solve genuinely different amounts of the problem. Knowing where each one stops is most of the decision.
kubeadm is the baseline: it bootstraps a conformant cluster and does it well. What it does not do is anything after that. Node images, load balancers for the API server, the OpenStack cloud provider and Cinder CSI wiring, certificate rotation, etcd care, and every upgrade are yours, per cluster, forever. Teams often start here, prove it works, and then find the second cluster costs as much effort as the first.
Cluster API with the OpenStack provider (CAPO) is the serious answer to that, and it is what we build on ourselves. It makes clusters declarative objects, so creation, scaling and upgrades become reconciled state rather than scripts. The catch is that CAPO is a framework rather than a product: something has to own the management cluster, the templates, the image pipeline, the CNI and storage-class decisions, the upgrade sequencing, and the failure modes when a reconcile loop gets stuck. That something is a platform team, and staffing it is the real cost of this route. The Kubernetes on OpenStack architecture guide lists exactly what that route hands you: the cloud controller manager, Cinder CSI, the CNI, Octavia load balancers and the version matrix tying them together.
Magnum is OpenStack’s own cluster service, and a reasonable fit when your operators already live in OpenStack and want cluster provisioning inside the same API surface. In practice it tends to lag upstream Kubernetes, and the day-two experience, upgrades in particular, stays close to the infrastructure layer rather than reaching the teams consuming clusters.
edgeContinuum sits on the CAPO route and takes ownership of everything the framework leaves open: templates, images, the CNI and storage wiring, upgrades in place, autoscaling node pools, self-healing, and hosted or dedicated control planes as a choice rather than a rebuild. Your teams get a kubeconfig from the console, the API or Terraform, and nobody has to become the person who understands why a reconcile is stuck at 3am.
Clusters are declared, not built, so the platform can keep them true continuously: in-place Kubernetes upgrades, autoscaling node pools, and self-healing that replaces failed nodes without a ticket. Version skew across your fleet becomes a dashboard, not an audit.
prod-eu-west: v1.33.7 → v1.34.0, node pools rolled automatically.
Node pools grow and shrink with load, inside the quota you set.
Failed nodes are detected and replaced; desired state wins.
Request a free trial and provision a managed cluster against a lab OpenStack, or book a call and we’ll walk your case: control plane models, networking, upgrades.
