OpenStack vs Kubernetes: when a team should choose each
A team that must offer self-service infrastructure inside its own data center or cloud account should choose OpenStack when most of its workload is virtual machines and multi-tenant infrastructure APIs are required, and choose Kubernetes when most of its workload is containers. The decision turns on four drivers: workload mix, team skills, upgrade capacity and whether OpenStack itself will run on Kubernetes. Most teams weighing these platforms are not choosing between them in isolation, because a container platform still needs machines underneath it, and someone has to provision, network and patch those machines. Frame the choice as a question about where the platform team's operating hours will go.
Upgrade capacity is the driver teams most often underestimate. OpenStack ships a release every six months, and 2026.2 Hibiscus was released on September 30, 2026. Stable branches are maintained for approximately 18 months, and SLURP releases allow skip-level upgrades, so confirm which release path your team will follow. 2027.1 Indri is a SLURP release estimated for March 24, 2027. Kubernetes runs about three minor releases per year and maintains only the three most recent minors, so each cluster must move one minor version at a time, with kube-apiserver upgraded before kubelets. Check which OpenStack and Kubernetes versions your vendors and internal standards support before committing.
Whether OpenStack runs on Kubernetes changes the answer. OpenStack-Helm deploys OpenStack services as charts on Kubernetes, but it is a separate deployment path with its own skill requirements, while Kolla-Ansible and OpenStack-Ansible take different routes, as described in the OpenStack 2026.1 deployment guides. A team strong in Kubernetes but without OpenStack operators should not assume that overlap covers the cloud control plane. Ceph block devices can back Glance images, Cinder volumes and Nova guest disks, which is one reason teams run both. Before deciding, name the people who will own control plane upgrades, etcd backups and Keystone identity mapping.
Which platform fits which scenario
This table matches common team situations to the platform that usually fits better, and names the condition that drives each choice. Read each row against your own estate, team size and the workloads you must run, because the better fit often depends on whether you need virtual machines, containers or both.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Replacing a VMware estate that is mostly virtual machines | OpenStack, or a simpler hypervisor platform if scale is small | OpenStack fits when you need multi-tenant APIs, many hosts and a planned upgrade path. Kubernetes alone is a poor substitute for VM lifecycle management, so a hypervisor-first platform may be the better choice for a small VM count. |
| Container-first product platform | Kubernetes | Kubernetes fits when application teams deploy containers continuously and need scheduling, rollouts and service discovery. OpenStack adds a VM layer that container-first teams may not need, so it is usually the wrong first platform here. |
| Mixed estate needing both VMs and containers | Kubernetes on OpenStack, or Kubernetes on separate VM hosts | Running Kubernetes nodes as OpenStack instances fits when one team owns both layers and needs VM isolation for tenants. Running Kubernetes on dedicated hosts is simpler when the VM estate is small and the platform team is limited. |
| Sovereign or multi-tenant cloud offered to internal business units | OpenStack | OpenStack's identity, project and quota model supports separate tenants and self-service VM requests. Confirm your federation and tenancy design with Keystone documentation before committing, since mapping rules must match your identity provider. |
| Small team with no cloud operations experience | Kubernetes on managed or single-purpose hosts, or a simpler virtualization platform | OpenStack has many services to upgrade and operate, and a six-monthly release cycle adds recurring work. Kubernetes has a smaller footprint for a single workload, but etcd and control plane operations still need trained staff. Confirm the skills gap before choosing either. |
| Upgrade cadence and skills budget | Kubernetes for faster minor upgrades, OpenStack for long-term planned cycles | Kubernetes ships about three minor releases per year and supports the three most recent minors, so teams must upgrade often. OpenStack releases twice a year, with SLURP releases allowing skip-level upgrades, which suits teams planning fewer, larger upgrade windows. |
| Storage shared between VMs and containers | OpenStack with Ceph, or Kubernetes with a CSI-backed storage layer | Ceph block devices can back Glance images, Cinder volumes and Nova guest disks in OpenStack. Kubernetes needs a storage driver that fits your backend, so confirm persistent volume support and failure behavior with your storage vendor. |
| Regulated workloads needing evidence of access control | Depends on the control plane you operate | Both platforms need identity federation, least-privilege RBAC and encryption of secrets. Kubernetes stores Secrets unencrypted in etcd by default unless you configure encryption at rest, so plan that setting from the start. |
How OpenStack and Kubernetes relate in practice
OpenStack and Kubernetes solve different layers of the stack. OpenStack is a cloud operating system that controls pools of compute, storage and networking through APIs with common authentication, so it answers the question of where virtual machines, block volumes and networks come from. Kubernetes schedules containers onto nodes and reconciles their desired state, so it answers where workloads run once capacity exists. A team that needs multi-tenant self-service VMs with quotas and identity federation is solving the OpenStack problem. A team that needs to deploy and scale containerized services is solving the Kubernetes problem. Many teams end up needing both, and the first decision is whether the infrastructure layer is already provided by something else, such as a virtualization platform or bare metal.
The common pattern is Kubernetes running on OpenStack virtual machines. Nova provides the guest VMs, Cinder or Ceph-backed volumes provide persistent disks, and Neutron provides the networks that the nodes attach to. The kubeadm high availability guide describes stacked and external etcd topologies with at least three control plane nodes, and those nodes can be VMs requested through the OpenStack API. Teams should confirm which storage class the Kubernetes cluster will use, how load balancers are provisioned, and whether the cloud provider integration for their chosen OpenStack release is supported. The reverse case, running OpenStack services as containers on Kubernetes, is handled by OpenStack-Helm, which is covered in the sibling comparison of OpenStack deployment projects.
The two can coexist without either replacing the other. OpenStack keeps owning tenant isolation, VM lifecycle and infrastructure APIs, while Kubernetes keeps owning container scheduling and rollout behavior. The cost of doing both is a second control plane to operate: a second upgrade calendar, a second set of certificates and credentials, and a second backup and restore process for etcd and the OpenStack databases. Before committing, ask whether the workloads actually need VM-level isolation, whether the team can staff two platforms, and how each platform's release cadence will be absorbed. OpenStack releases every six months, and Kubernetes releases about three times per year, so the upgrade windows will not line up.
How each platform is built and what that means for operations
OpenStack and Kubernetes solve different layers, so their operational burdens sit in different places. The cards below tie each component to the duty it creates for your team, from identity and storage to control plane backups and upgrade order.
OpenStack modular services and Keystone
OpenStack is a set of separate projects that share common authentication through Keystone, which issues tokens and maps users to projects and roles. Keystone federation supports SAML 2.0 and OpenID Connect, and mapping rules decide which federated users receive which OpenStack roles. Your operational duty is to keep those mapping rules, trust relationships and service catalog entries under change control, because a mistake there affects every service at once. Confirm which federation protocol your identity provider supports before you design the project model.
Kubernetes control plane and etcd
Kubernetes keeps all cluster state in etcd, so the control plane is only as recoverable as your etcd backups. Secrets are stored unencrypted in etcd by default, which makes encryption at rest and tight RBAC on list and watch part of the initial build rather than a later hardening task. Plan for an odd number of etcd members, a tested snapshot routine with etcdctl and a restore path with etcdutl. Restores are rarely practiced, so ask who on your team will run one under pressure.
Ceph backing Glance, Cinder and Nova
Ceph block devices can back OpenStack Glance images, Cinder volumes and backups, and Nova guest disks, so VMs can boot from Ceph without local hypervisor storage. This makes the storage cluster a shared dependency for the whole cloud, and its health, capacity planning and upgrades become cloud-wide events. Kubernetes has no equivalent default requirement, so teams running both must decide whether Ceph serves VM disks, persistent volumes or both. Confirm the Ceph release you will run against the support window published on the Ceph releases page before you commit.
kubeadm stacked or external etcd topology
The kubeadm high availability guide describes a stacked control plane, where etcd runs on the control plane nodes, and an external etcd cluster on separate hosts. Both need at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. Stacked is fewer machines to run but couples etcd failure to control plane failure. External etcd adds hosts and certificate management but lets you size and back up etcd separately. Decide this before the first node is built, since changing topology later is a rebuild.
OpenStack deployment tooling choices
The OpenStack 2026.1 deployment guides cover Kolla-Ansible, which runs OpenStack services in Docker containers driven by Ansible, and OpenStack-Ansible, which deploys services in LXC containers or directly on bare metal. Your choice sets how upgrades run, how host dependencies are managed and which skills your operators need. Container images and playbooks become the artifacts you version, test and back up. Confirm which deployment tool matches your team's Ansible and container experience before you plan the upgrade cadence.
Upgrade order across services
OpenStack upgrades move one release at a time between adjacent releases, or skip levels only on SLURP releases, while Kubernetes requires kube-apiserver to be upgraded one minor version at a time before the controller manager, scheduler and kubelets. Kubelets may trail the API server by up to three minor versions. Both platforms therefore make upgrade order a documented sequence, not a single event. Map each component to its order and window in your runbook, and test the sequence in a non-production copy of your environment before the first production change.
Capability comparison using supplied facts
This table sets OpenStack and Kubernetes side by side on workload, isolation, release cadence, upgrades, identity, storage, tenancy, license and skills. Read each row as a question about your own team: where a cell says the answer depends on distribution or deployment, confirm that choice before you commit. The main takeaway is that the two projects solve different layers, so the comparison is less about picking one than about deciding which layer your team must own.
| Capability | OpenStack | Kubernetes |
|---|---|---|
| Primary workload | Virtual machines and the compute, storage and network pools that host them, exposed through APIs | Containers orchestrated across nodes, with workloads declared as Kubernetes objects |
| Unit of isolation | Project-scoped resources such as instances, volumes and networks, separated by tenant and role | Namespaces and pods, with isolation depending on RBAC, network policy and Pod Security Standards you configure |
| Release cadence | Six-month cycle; 2026.2 Hibiscus released September 30, 2026; 2027.1 Indri estimated for March 24, 2027 | About three minor releases per year on a cycle of roughly 14 weeks; three most recent minors maintained |
| Supported upgrade paths | Upgrades between adjacent releases and between SLURP releases, which allow skip-level upgrades | kube-apiserver upgraded one minor version at a time; kubelets may run up to three minor versions behind |
| Identity integration | Keystone federation over SAML 2.0 and OpenID Connect, with mapping rules to groups, roles and projects | Authentication through X.509 client certificates, OIDC or JWT bearer tokens, webhooks or an authenticating proxy; the identity provider is wired in per cluster |
| Storage integration | Ceph RBD can back Glance images, Cinder volumes, backups and Nova guest disks; storage is a managed service of the cloud | Storage through CSI drivers and persistent volumes; Secrets are unencrypted in etcd by default unless encryption at rest is configured |
| Multi-tenancy model | Built-in tenancy with projects, users and quotas across compute, storage and networking APIs | Namespace-based tenancy; hard isolation for untrusted tenants usually needs extra controls or separate clusters |
| License | Apache 2.0 for official OpenStack projects, as required by OpenStack TC licensing rules | Apache 2.0 for the kubernetes/kubernetes repository; distributions may add their own licensed components |
| Operational skills demanded | Cloud operators who run hypervisors, Ceph or other storage backends, networking and identity federation, often through Kolla-Ansible, OpenStack-Ansible or OpenStack-Helm | Platform engineers who run control plane, etcd backups, certificates, upgrades and workload security policy, often through kubeadm or a managed distribution |
Licensing and what is paid for each platform
OpenStack official projects must be licensed under the Apache License, Version 2.0, so the cloud operating system and its services carry a permissive license. The OpenInfra Foundation, which hosts OpenStack, operates as part of the Linux Foundation, so project governance runs through a foundation structure. The license does not decide who you pay, because the costs come from the vendors and service providers who support, distribute or implement the platform.
- Apache-2.0 for official projects: Official OpenStack projects must use the Apache License 2.0, which your legal team should review against internal policy.
- Foundation hosting: The OpenInfra Foundation operates within the Linux Foundation, which matters when procurement asks who stewards the project.
- No paid edition tiers confirmed: Ask any vendor whether it sells an OpenStack distribution or support subscription, and price that separately from the open-source code.
- Support from third parties: Support contracts, distributions and implementation services come from outside the project, so recurring cost depends on whom you hire.
Check the license of every add-on driver, plugin or distribution you add, because those components may carry their own terms.
Kubernetes is open source and licensed under Apache 2.0, as the kubernetes/kubernetes repository states. The CNCF Certified Kubernetes conformance program checks that vendor and community distributions support the required Kubernetes APIs, and the CNCF page states there are over 90 Certified Kubernetes offerings. Conformance confirms that an API surface is present, but it does not measure a vendor's support responsiveness, patch cadence or hardening against your own standard.
- Apache 2.0 core: Using the upstream code does not involve a license purchase, so the license is not a line item in the budget.
- Conformance as a filter: The conformance program helps you exclude distributions that lack required APIs, but it does not certify day-two operations.
- Many offerings to compare: With over 90 Certified Kubernetes offerings listed, each with its own support model, pricing and upgrade commitments, the comparison work is mostly commercial.
- Add-ons carry their own licenses: Tools such as Argo CD and Flux are both Apache-2.0, but their support paths and any vendor services around them are separate purchases.
Ask each distribution vendor which Kubernetes version its conformance covers and who carries the cluster through an upgrade.
This page does not document paid editions for either project, so the paid part of ownership is services: support contracts, design, implementation, hardening and upgrades. These come from vendors or service providers, and the reader must confirm and price each one separately. DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
- One-time work: Design, build, integration and initial hardening are usually one-time costs tied to the written scope.
- Recurring work: Support, upgrades and testing recur, and retainers are one option for ongoing coverage.
- What raises cost: Cluster count, tenant count, compliance evidence requirements and the number of integrations all increase effort.
- What to ask in a quote: Request the named support window, upgrade responsibility, on-call scope, and whether the price covers each new release.
- Who is paid for what: Separate the software license (none for either core project), the support subscription and the implementation labor.
Ask each provider to state in writing which versions it supports and for how long, then compare those windows with the release calendars before you sign.
What release cadence and upgrade work each platform demands
OpenStack's six-month cycle sets the pace for a private cloud team, so the release calendar is the first thing to plan around. 2026.2 Hibiscus was released on September 30, 2026, and 2026.1 Gazpacho, a SLURP release, came out on April 1, 2026. SLURP releases are the ones to build on because they allow skip-level upgrades, so a team can move between SLURP releases without stopping at every six-month release in between. The next SLURP, 2027.1 Indri, is estimated for March 24, 2027. Stable branches are maintained for approximately 18 months, after which only SLURP releases may enter an unmaintained phase. Confirm the end-of-maintenance date for each branch in the OpenStack release schedule before you commit to a version.
Kubernetes moves faster and asks for smaller, more frequent steps. The project ships about three minor releases a year on a cycle of roughly 14 weeks, and it maintains the three most recent minors. As of September 2026, those were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027). Patch support for each minor runs about one year, so a cluster left on one minor falls out of support within roughly a year of that minor's release. The version skew policy sets the order of work: upgrade kube-apiserver one minor version at a time, then kube-controller-manager, kube-scheduler and the kubelets. Kubelets may run up to three minor versions behind the API server, which gives node pools some room, but it does not remove the need to keep moving.
The two platforms imply different calendars. An OpenStack upgrade is a planned, project-wide event in which the control plane and compute services move together, and a SLURP path lets a team skip intermediate releases, so the work lands in a few large windows a year. A Kubernetes upgrade is a repeated routine. Each minor hop needs a version check, an etcd backup taken with etcdctl snapshot save, and node-by-node draining, and a team that wants to stay on a supported minor has to absorb that work roughly every 14 weeks. Ask any distribution or managed vendor which Kubernetes minors it certifies and how quickly it ships them, and measure how long one hop takes in your own environment before you set the calendar.
Questions buyers ask before choosing OpenStack or Kubernetes
How much effort does an OpenStack private cloud take to run?
Running OpenStack is a continuing platform job, not a one-time install. The work recurs because OpenStack ships a release every six months, and stable branches are maintained for approximately 18 months before they move toward end of life. Your team needs to plan each upgrade, test it against your compute, storage and networking, and keep the deployment tooling current. The 2026.1 deployment guides describe two main routes: Kolla-Ansible, which runs services in Docker containers, and OpenStack-Ansible, which runs them in LXC containers or on bare metal. Before committing, ask a vendor or partner which release train they will support, how upgrades are tested in your environment, and who on your side owns the operational runbooks.
Can Kubernetes replace OpenStack?
Kubernetes can replace OpenStack only when your workloads are containers and you do not need to provision virtual machines, block volumes and tenant networks through a cloud API. Kubernetes orchestrates containers, while OpenStack pools compute, storage and networking for VMs and exposes those resources through APIs with common authentication. Many organizations still run VMs for legacy applications, licensed software or strict isolation, and those workloads stay on a hypervisor layer. If you need both, you will typically run Kubernetes on top of infrastructure that already provides VMs. Confirm with your application owners which workloads must remain virtual before deciding that one platform covers everything.
Do we need OpenStack to run Kubernetes?
No. Kubernetes can run on virtual machines or bare metal without OpenStack, and the kubeadm high availability guide describes a control plane built from at least three nodes with a TCP load balancer in front of kube-apiserver on port 6443. OpenStack becomes useful as the layer that supplies those VMs, block storage and tenant networks on demand, and some teams use OpenStack-Helm to deploy OpenStack itself on Kubernetes. The decision depends on whether you need self-service infrastructure for more than one team. Ask whether your Kubernetes platform needs to create VMs or volumes through an API, and whether the platform team will maintain that layer alongside the cluster.
How long does an implementation take?
The duration depends on scope, the number of hosts, your integrations and how much of the platform is new to your staff, and no supplied figure gives a reliable typical timeline. A Kubernetes cluster with a defined control plane and etcd layout can be a smaller first step than a multi-service OpenStack cloud, which also needs storage backends, identity federation and network design. DeployOpen works from a written, fixed scope with agreed deliverables and timelines before work starts. Ask any implementation partner to break the timeline into phases: design, build, integration, hardening, handover and the first upgrade cycle, and confirm which items depend on your hardware delivery or access approvals.
What skills must our staff have?
The OpenStack side needs people who understand Linux networking, storage backends, identity and the OpenStack service model, and who can run upgrades across releases. The Kubernetes side needs people who can operate a control plane, manage etcd backups and restores, and handle the version skew rules, which require the API server to be upgraded one minor version at a time before the other control plane components and kubelets. Kubernetes also depends on authentication design, and Secrets are stored unencrypted in etcd by default, so someone must own encryption at rest and least-privilege RBAC. Map these skills against your current team before you choose, and ask partners which of them they will transfer through documentation and training.
Can we run both OpenStack and Kubernetes?
Yes, and this is a common pattern when VMs and containers both matter. One approach is to run OpenStack to provide VMs, volumes and networks, then run Kubernetes clusters on those VMs. Ceph can back Glance images, Cinder volumes, backups and Nova guest disks, so VMs can boot from Ceph storage without local hypervisor storage. The cost is two upgrade cycles, two sets of skills and two sets of monitoring and backup procedures. Before you commit, list which teams own each layer, which release calendars you will follow, and how a failure in the lower layer would affect the cluster above it.
What does a cost quote depend on?
A quote depends on the written scope, which sets the platforms, number of environments, integrations, hardening work, documentation and handover, along with your infrastructure and compliance needs. DeployOpen does not publish a price list, and a quote follows from the agreed scope. Costs have several parts: the software itself, which is open source in both cases, the hardware or cloud capacity you run it on, the people who operate it, and any implementation or retainer work. Ongoing costs recur with each upgrade cycle and with support. Ask every bidder to itemize implementation, upgrades, testing and support separately, and to state which release versions and support windows the quote assumes.
Which release and support dates should we plan around?
Plan around the published calendars, because they set how often you must upgrade. OpenStack 2026.2 Hibiscus was released on September 30, 2026, and 2027.1 Indri, a SLURP release that allows skip-level upgrades, is estimated for March 24, 2027. Kubernetes releases about three times per year on a cycle of roughly 14 weeks, and as of September 2026 the three supported minor releases were 1.37, 1.36 and 1.35. Kubernetes 1.19 and newer receive about one year of patch support. Confirm with each vendor which release you will run at go-live and when its support ends.
Moving between the two platforms: what transfers and what is rebuilt
This sequence shows which assets carry over when a team moves workloads between OpenStack VMs and Kubernetes containers, which parts must be rebuilt for each platform, and how to keep the existing estate running while the new one takes load.
Inventory workloads and their dependencies
The platform or application owner lists every workload on the source platform, including VMs, containers, Helm releases, Git repositories holding manifests or Heat and Ansible code, storage volumes, identity groups, network policies and backup jobs. Each item is tagged with its owner, data classification and dependencies on other services. The step is done when the inventory is reviewed by the security team and each workload has a named owner and a proposed target platform. Ask the vendor or your platform team which items must stay where they are, since a switch rarely removes the other platform entirely.
Classify what transfers unchanged
The platform engineering team separates assets that move as they are from assets that need rework. Container images, Helm charts and Git-based manifests usually transfer with little change, provided the registry, chart repository and Git server are reachable from the target cluster. Data held in Ceph volumes can be reused where the target platform accesses the same Ceph cluster, which is the case when OpenStack Cinder or Glance images are backed by Ceph block devices. Confirm each storage path with the storage team before any cutover plan is written, because object, block and file access patterns differ between Ceph interfaces.
Map identities and tenant models
The identity team rebuilds how users reach each platform. OpenStack uses Keystone with projects, roles and groups, and its federation maps external users through mapping rules. Kubernetes does not represent normal users as API objects and relies on certificates, OpenID Connect tokens or webhook authentication, with RBAC bindings defining access. Each OpenStack project or tenant needs a matching namespace, group and role binding model, documented as a table. The step is complete when every existing role has a documented equivalent and a test user from each group can reach only the intended resources on the target platform.
Rebuild network policy and segmentation
The network engineers recreate traffic rules in the target model. OpenStack security groups and tenant networks do not translate directly into Kubernetes NetworkPolicy objects, so each allowed flow must be restated against pod labels, namespaces and ports. Ingress, load balancer and API endpoint placement also change, and the kube-apiserver load balancer on port 6443 needs its own review when a control plane is added. The step is done when a documented flow list has been tested in a non-production environment and every denied path has been confirmed as denied by a test, not by assumption.
Rebuild backup jobs and restore tests
The operations team recreates backup coverage for the target platform. VM-level backups on OpenStack and cluster or volume backups on Kubernetes use different tools, schedules and retention settings, so existing jobs cannot simply be repointed. For Kubernetes-based databases or etcd, a backup plan is required, and etcd snapshots are taken with etcdctl and restored with etcdutl. The step is complete only after a restore has been performed in a test environment and the restored workload has been checked against the expected data. Ask your backup vendor which connectors support both platforms before you commit to a tool.
Run a pilot workload in parallel
The delivery team moves one low-risk workload to the target platform while the source platform continues to serve production traffic. The pilot runs with real monitoring, logging and alerting, and its owners record any change in performance, access behavior or operational effort. The step is finished when the pilot has run through at least one planned upgrade or patch cycle on the target platform and the team has written down the runbook changes. Confirm the target platform's release support window before you choose the version for the pilot, since OpenStack stable branches and Kubernetes minor releases each have a defined maintenance period.
Migrate in phases and retire the source last
The platform owner moves workloads in waves, starting with stateless services and finishing with stateful systems and shared storage. Each wave has a rollback plan and a named approver, and the source platform keeps its capacity until every dependent service has been verified. The source platform is decommissioned only after the audit and access logs show no remaining traffic, and the decommission record lists which data was archived and where. The sequence is complete when both platforms are documented, the remaining estate is inventoried, and the operating team has signed off the final runbooks.
What drives the running cost of each platform
The running cost of an OpenStack or Kubernetes platform is mostly people and capacity, not licenses. Both projects are Apache-2.0 licensed, so the recurring money goes to the hardware or cloud capacity underneath, the staff who operate the control plane and storage, the time spent on upgrades, and any support contract or training you buy. Ask any quote to list each of these as a separate line, name who operates it (your team, DeployOpen under a retainer, or a vendor), and mark which items are one-time (initial build, migration, hardening) and which recur (monthly operations, support, patch cycles, training refreshers).
For Kubernetes, the cost drivers you control most directly are the control plane layout and etcd. The kubeadm high availability guide describes a stacked topology, with etcd on the control plane nodes, or an external etcd cluster, and requires at least three control plane nodes behind a TCP load balancer on port 6443. Kubernetes documentation recommends an odd number of etcd members, with five in production, and requires a backup plan for etcd data using etcdctl snapshot save. Every extra member adds hardware and patching, and the backup and restore routine is a recurring duty someone must own. Secrets are stored unencrypted in etcd by default, so encryption at rest is a configuration task with an ongoing review cost. Confirm which of these duties your quote includes and which stay with your staff.
For OpenStack, the largest recurring line is usually the storage footprint and the upgrade window. If you back Glance, Cinder and Nova disks with Ceph, the Ceph cluster becomes a second system to size, monitor and upgrade, and its replication overhead raises the raw capacity you buy. OpenStack's six-monthly release train and the stable branch window of about 18 months mean planned upgrades recur, while SLURP releases such as 2026.1 Gazpacho and 2027.1 Indri, which is estimated for March 24, 2027, reduce how often you must move. Keep the team sized for both the control plane and Ceph, and ask a quote to price the Ceph operating work separately from the OpenStack control plane work.
How DeployOpen helps teams choose and implement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For OpenStack vs Kubernetes, we start by establishing which layer your workloads actually need, then scope the build and handover around that decision.
How we scope
- We map which workloads are VMs, which are containers, and which need both before naming a platform.
- Scope covers control plane layout, etcd or database sizing, identity federation, networking and storage backends.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
- We confirm your team's Kubernetes and OpenStack skills and which upgrade cadence your operations can sustain.
How we build
- We deploy the chosen platform inside your cloud accounts, data centers or air-gapped networks.
- Keystone federation or Kubernetes OIDC integration is configured against your existing identity provider.
- Storage integration, such as Ceph backing for images, volumes and VM disks, is built and tested as a unit.
- Security testing of APIs, cloud infrastructure and control plane access runs before handover.
How we hand over
- Architecture, runbooks and upgrade procedures are documented against the exact versions deployed.
- Backup and restore for etcd or control plane data is set up and tested with your operators.
- Compliance-relevant evidence, such as access configuration and encryption settings, is prepared for your assessors.
- Your team receives knowledge transfer on day-to-day operation, scaling and release-cycle upgrade planning.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover tracking of OpenStack release and stable branch windows and Kubernetes minor version support.
- Upgrade work is planned in written scope, including skip-level or one-minor-version-at-a-time paths where relevant.
- We confirm the support terms and response expectations you need in writing before the retainer begins.
