OKD on OpenStack works, and it installs with the same openshift-install program Red Hat uses for OpenShift. You either let the installer create the networks, ports and servers in your OpenStack project (installer-provisioned infrastructure, IPI) or build them yourself with Ansible playbooks (user-provisioned, UPI). In October 2026 the release to install is OKD 5.0, which runs Kubernetes 1.36 on CentOS Stream CoreOS 10, and a default cluster needs 88 GB of RAM, 22 vCPUs, 275 GB of volume storage and 3 floating IPs from your project quota.
New to OKD itself? Our explainer on OKD and how it compares with OpenShift and plain Kubernetes covers that. In one line: OKD is the community Kubernetes distribution that shares its code with Red Hat OpenShift. Red Hat's 2018 rename announcement called it the Origin community distribution of Kubernetes, hence the searches for an "Origin Kubernetes Distribution".
Where things stand in early October 2026:
- OKD 5.0.0-okd-scos.0 shipped on 17 September 2026 as the first stable 5.x release, and 5.0.0-okd-scos.1 followed on 30 September with Kubernetes 1.36.4.
- Nodes run CentOS Stream CoreOS (SCOS) 10. Fedora CoreOS builds stopped after OKD 4.15.
- OpenStack is a documented OKD platform but not one the project's CI tests, so test on your exact OpenStack release.
- Once a cluster reaches 5.0, you point it at OKD's own update service at updates.okd.io.
- Octavia, Swift (or Ceph RGW) and Cinder make the install pleasant. Manila is optional.
Is OKD on OpenStack still a good idea in 2026?
For a team that already runs OpenStack, yes. The installer talks to the OpenStack APIs directly, so the cluster does things a pile of hand-built VMs cannot. The Machine API creates and deletes worker servers through Nova, the Cluster Autoscaler adds workers when pods stop fitting, Services of type LoadBalancer become Octavia load balancers and persistent volumes become Cinder volumes. Old VMs and new containers share one cloud, one quota system and one set of networks. Neither project has a licence fee, so what you pay for is hardware and the people who run it.
Two caveats rarely make the front page. First, nobody upstream tests your combination. When OKD moved to CentOS Stream CoreOS, its SCOS migration FAQ said the OKD CI tested installer-provisioned clusters on AWS and vSphere, and the 5.0 release notes name AWS, Azure, GCP and vSphere but touch OpenStack only through a Manila CSI driver update, with no word on Cinder or Octavia. Red Hat tests OpenShift on its own OpenStack product: its support matrix, updated on 15 September 2026, lists OpenShift 4.22 and 5.0 on Red Hat OpenStack Services on OpenShift 18.0 only. On a Kolla-Ansible or OpenStack-Ansible cloud you are the test lab, so build a throwaway cluster before you promise anyone a date.
Second, the OKD documentation is OpenShift's documentation with the product names swapped, and on the OpenStack pages the seams show. The OKD 5 page on preparing an OpenStack install says it supports OpenStack Train, a 2019 release long out of maintenance. The user-provisioned guide still creates a Fedora CoreOS image from a file named rhcos-*. Read the docs for the YAML and parameters, which are accurate, and ignore the operating system names and support claims, which are template leftovers.
Which OKD release and base OS should you install?
Install 5.0 for anything new; the 4.22 line had its latest update, 4.22.0-okd-scos.10, on 9 September 2026. The OKD 5.0 release notes say the release was manually accepted by the Technical Release Team and is ready for production use. Most of the installer news in those notes, such as disk encryption applied by default at cluster creation and OS streams for day-2 installs, belongs to the Agent-based Installer, which OpenStack installs do not use; the IPI and UPI steps below are the ones that matter here. The okd.io front page already lists 5.1 as the current engineering candidate. Dates and versions in the table come from OKD's GitHub releases page.
| Release | Published on GitHub | Kubernetes | Node OS |
|---|---|---|---|
| 4.19.0-okd-scos.0 | 13 May 2025 | 1.32.4 | SCOS 9 (9.0.20250507-0) |
| 4.20.0-okd-scos.0 | 22 September 2025 | 1.33.4 | SCOS 10 (10.0.20250913-0) |
| 4.21.0-okd-scos.0 | 16 January 2026 | 1.34.2 | SCOS 10 (10.0.20260113-0) |
| 4.22.0-okd-scos.0 | 11 May 2026 | 1.35.4 | SCOS 10 (10.0.20260428-0) |
| 5.0.0-okd-scos.0 | 17 September 2026 | 1.36.3 | SCOS 10 (10.0.20260819-0) |
| 5.0.0-okd-scos.1 | 30 September 2026 | 1.36.4 | SCOS 10 (10.0.20260819-0) |
The base OS history explains the "okd scos" searches. Up to 4.15, OKD nodes ran Fedora CoreOS. In June 2024 the OKD Working Group said licensed content had been included in OKD releases by mistake, which forced a new release process and a move to CentOS Stream CoreOS. OKD 4.16 and 4.17 arrived together on 16 December 2024 as the first SCOS releases. 4.19 was the last on SCOS 9, and 4.20 moved nodes to CentOS Stream 10. Red Hat's own comparison sums it up: OKD uses CentOS Stream CoreOS, OpenShift uses RHEL CoreOS.
What does your OpenStack project need before you install OKD?
The installer's OpenStack README lists the services it cannot do without: Keystone, Neutron, Nova with the metadata service enabled, Glance, and Swift or Cinder for the image registry, plus resource tagging. Every node fetches its Ignition config (CoreOS's first-boot instructions) from 169.254.169.254, and the installer parks the bootstrap Ignition in a temporary Glance image, <clusterID>-ignition, for the 10 to 30 minutes bootstrap usually takes. Octavia is optional for the install and close to essential once apps arrive.
These are the quotas the OKD docs recommend for a default cluster on their OpenStack install page, identical for OKD 4.22 and OKD 5:
| Resource | Default cluster | What uses it |
|---|---|---|
| Floating IPs | 3 | API and ingress addresses, plus the bootstrap machine during install |
| Ports | 15 | Machine ports plus the API and ingress VIPs |
| Routers and subnets | 1 each | The machine network and its route to the external network |
| RAM | 88 GB | Three 16 GB control plane machines, three 8 GB workers, one 16 GB bootstrap machine |
| vCPUs | 22 | 4 per control plane machine, 2 per worker, 4 for bootstrap |
| Volume storage | 275 GB | Drops to 175 GB when Swift holds the image registry |
| Instances | 7 | 3 control plane, 3 compute, 1 bootstrap |
| Security groups and rules | 3 groups, 60 rules | Control plane and worker traffic |
| Server groups | 2, plus 1 per extra availability zone in each machine pool | Spreading machines of one role across hypervisors |
Control plane machines need a flavor with at least 16 GB of RAM, 4 vCPUs and 100 GB of disk, workers 8 GB, 2 vCPUs and 100 GB, and the bootstrap machine the same as the control plane until the installer deletes it. We would ask for more: the installer README, last changed in November 2024, still asks for 112 GB of RAM, 28 vCPUs and 700 GB of volumes, and replacing a broken machine creates the new server before deleting the old one, which a project at its ceiling cannot do.
The docs' quota command sets values rather than adding to them, so look first and only run the second line if your numbers are lower. The third line gives the install account the role that lets the registry use Swift:
# as the OpenStack admin user (admin credentials loaded in your shell)
openstack quota show <project>
openstack quota set --secgroups 3 --secgroup-rules 60 <project>
openstack role add --user <user> --project <project> swiftoperatorThe first command prints a table of the project's limits; the other two print nothing when they succeed.
Put the control plane on fast disks. etcd waits for every write to reach the disk, so the installer README recommends SSD-backed control plane flavors and warns that Ceph RBD and other network storage can add unpredictable latency. If your Nova disks live on Ceph, the documented "rootVolume and etcd on local disk" layout gives etcd a local ephemeral disk. A slow etcd disk shows up as leader elections and API timeouts, and nothing on the OKD side fixes it.
Installer-provisioned or user-provisioned: which method fits your cloud?
The OKD 4.22 and 5 docs describe four ways in, which differ in who creates the OpenStack resources and who cleans them up.
| Method | Who creates the resources | Pick it when | The catch |
|---|---|---|---|
| IPI with customizations | The installer: network, router, ports, security groups, servers | Your account may create networks and routers and the quota is there | Less say over names and layout |
| IPI in a restricted or disconnected network | The installer, pulling from your mirror of the release images | Nodes cannot reach public registries | You run and update the mirror |
| UPI with Ansible playbooks | You, with playbooks from the openshift/installer repository | A network team builds networks and ports, or policy forbids the installer creating routers | The playbooks must stay with the cluster for its whole life |
| Three-node cluster | The installer; control plane machines also run apps | Labs and small sites | Three machines carry everything |
Choose IPI unless someone forbids it. More people run it, so its failure modes are better known, and openshift-install destroy cluster removes what the installer created. On OpenStack that matters, because orphaned ports, floating IPs and server groups quietly eat the quota of the next attempt.
UPI is for clouds where you do not own the network. The OKD 4.22 user-provisioned guide downloads the playbooks from the release-4.22 branch of openshift/installer, under upi/openstack; use the branch that matches your installer. They need the collections ansible-, ansible- and ansible-, plus python3-openstackclient, python3-openstacksdk and python3-netaddr. Two rules cause most UPI grief: every edit to a playbook must be repeated in its down- twin or removal fails, and the playbooks must be kept for the life of the cluster, because you cannot remove it without them.
The image step is where the doc leftovers hurt. Nodes boot SCOS, not Fedora CoreOS or RHCOS. openshift-install coreos print-stream-json prints the stream metadata the installer was built with, and SCOS 10 images for OpenStack are published under cloud.centos.org/
One open bug deserves a look first. Issue #2333, opened on 27 May 2026, describes an OKD 4.22 IPI install on OpenStack 2025.1 Epoxy, deployed with Kolla-Ansible, where the bootstrap server received a 162-byte #cloud-config file instead of Ignition JSON, so bootkube never started. It was still untriaged in October, with no word on 5.0. If your bootstrap machine sits at a login prompt while the installer waits, check the user data it received before anything else. An older report, #2105 from January 2025, shows 4.17 installing fine on OpenStack, so the platform works; it is just untested.
How does OKD plug Kubernetes into Octavia, Cinder, Manila and Swift?
Any Kubernetes on OpenStack talks to the cloud through the same upstream code, the kubernetes/
Load balancers: Octavia for Services, keepalived for the API
Since OKD 4.12 the external OpenStack Cloud Controller Manager has replaced the old in-tree provider. A Service of type LoadBalancer becomes an Octavia load balancer. You choose the provider in the [LoadBalancer] section of openshift/ after openshift-install create manifests. amphora runs a small HAProxy VM per load balancer: slower to create, more features. ovn lives in the OVN data path: light and quick, but it only balances with SOURCE_IP_PORT. Services with externalTrafficPolicy: Local need create-monitor = True, and the docs warn that the OVN provider on Red Hat OpenStack 16.2 had no health monitors, so those Services stop answering. Our guide to Octavia load balancing in OpenStack explains the amphora model.
The API and ingress addresses do not need Octavia. By default the cluster serves both VIPs from keepalived and HAProxy on its own nodes, set as lists in apiVIPs and ingressVIPs (the singular forms are deprecated since 4.12). To use your own load balancer, set platform. to UserManaged and send it TCP 6443 (API) and 22623 (machine config server) for the control plane, plus 80 and 443 for ingress, at layer 4 only.
Block and file storage: Cinder CSI and Manila CSI
OKD installs the OpenStack Cinder CSI Driver Operator and driver in the openshift- namespace, with a standard-csi storage class whose provisioner is cinder.csi.openstack.org. A Cinder volume attaches to one node at a time. Keep Cinder availability zones in line with Nova's, or pods land where their volume cannot follow.
Manila is optional. Where it exists, OKD installs the Manila CSI Driver Operator by default and creates one storage class per share type. Only NFS is supported, not native CephFS or CIFS, and each share gets the access rule 0.0.0.0/0 unless your storage classes set nfs-ShareClient to your machine subnet. Do that on day one. Snapshots are not supported when the back end is CephFS through NFS.
The image registry: Swift, or Ceph RGW speaking Swift
If Swift is there and the install account has the swiftoperator role, the installer puts the registry on Swift; otherwise it creates a 100 GB Cinder volume, which pins the registry to one replica. Many clouds answer the Swift API with Ceph RGW, and there two settings bite. Red Hat OpenStack 17 sets rgw_max_attr_size to 256, which breaks image uploads to the registry; it must be at least 1024. RGW also needs "account in url" enabled. Both are Ceph settings, so raise them with your storage admin early. Our overview of Ceph block and object storage shows where RGW sits.
Networking: OVN-Kubernetes, and Kuryr is gone
Clusters use networkType: OVNKubernetes on top of Neutron, an overlay inside an overlay. OVN-Kubernetes takes 100 bytes per packet, so pods see the tenant network's MTU minus 100, and a larger MTU on the physical network pays off. Kuryr, which gave pods Neutron ports directly, was removed in OpenShift 4.15; guides that still recommend it are out of date.
How do you upgrade OKD on OpenStack?
Upgrades are where OKD earns its keep: the cluster updates itself, node by node, from an update graph. Until September 2026 that graph came from OKD's release controller, and it leaked. GitHub issue #2226, opened in July 2025, shows the stable channel offering a 4.20 engineering candidate as an upgrade from 4.19.0-okd-scos.6. On 18 September 2026 the project launched OKD Cincinnati, its own update service at updates.okd.io, with the channels stable-5.0 and candidate-5.0 and the power to block a bad upgrade path after release.
A cluster has to reach 5.0.0-okd-scos.0 first. Then point it at the new service and ask what it offers:
# as the cluster-admin user (oc logged in to the cluster)
oc patch clusterversion version --type merge -p '{"spec":{"upstream":"https://updates.okd.io/api/updates/graph","channel":"stable-5.0"}}'
oc adm upgradeThe patch answers clusterversion., and oc adm upgrade shows the running version, the new upstream and channel, and any recommended updates. Before the jump from 4.22 to 5.0, the release notes ask you to review the deprecations and removals, check IngressControllers against HAProxy 3.2 and confirm your apps work with the Kubernetes 1.36 APIs.
Older clusters meet three known traps:
- Clusters that started on 4.18 or earlier carry two MachineConfigs that force runc,
00-override-and its worker twin. The 4.20 known-issues post says to delete both before upgrading.master- generated- crio- default- container- runtime - 4.20 removed cgroup v1, so move nodes to cgroup v2 before that hop.
- A cluster still on Fedora CoreOS goes 4.15, then 4.16, then 4.17, following the FCOS to SCOS migration notes. Disable Secure Boot before the switch to SCOS, and expect older packages: CentOS Stream 9 has a 5.x kernel where Fedora CoreOS had 6.x, and its fsck can fail on ext4 file systems that use the newer orphan_file feature (issue #2041 has workarounds).
Your OpenStack moves too. According to the OpenStack releases page, 2026.2 Hibiscus came out on 30 September 2026, 2026.1 Gazpacho from April is the current SLURP release (the yearly releases you can upgrade between directly) and 2024.2 Dalmatian has reached end of life. Upgrade one layer at a time, never OpenStack and OKD in the same window, and point a scratch cluster at the upgraded cloud first.
Day 2 also means backups the cloud cannot make for you. A volume snapshot of a control plane disk is not an etcd backup: run the documented cluster-backup.sh script on a control plane node and copy the result off the cluster and off the cloud. Keep the installer directory too, with its metadata.json and admin kubeconfig, because openshift-install destroy cluster needs it years later.
Where RS Computers fits around an OKD cluster
RS Computers sells KVM virtual servers, VPS and VDS, not OpenStack projects, so the cluster itself does not live with us: a default cluster wants 88 GB of RAM across seven machines, and our largest plan, VDS Large, has 32 GB. Our servers fit around the cluster, or in place of it when a cluster is more than the job needs.
- The tooling host.
openshift-install,oc, yourclouds.yaml, the UPI playbooks and the install directory should outlive the laptop that first ran them. A VPS Micro or Mini with Debian 13 is plenty; keepclouds.yamlreadable by its owner only. - An outside view. A monitor inside the cloud goes quiet when the cloud does; a small VPS in another city watches the API on port 6443 and your app routes as users reach them.
- Off-site copies of etcd backups and the installer directory, in an encrypted repository in another city. Our guide to append-only off-site backups with restic sets one up.
- A smaller platform when OKD is overkill. Five services and a database do not need seven VMs and an update graph. Docker Compose or a single k3s node on one VDS runs the same containers, as our guide to Docker, Compose and a small k3s node on a VPS shows. The manifests carry over to OKD later, except that OKD's stricter security context constraints refuse containers that insist on running as root.
Every plan is a KVM virtual machine with NVMe storage (shared vCPUs on VPS, dedicated vCPUs on VDS), its own IPv4 and IPv6 addresses and free weekly backups. VPS plans have a 1 Gb/s port and VDS plans 10 Gb/s. The servers run in Amsterdam, Prishtina and Dublin, with the same plans and prices in all three; the VPS and VDS plans page lists them. Support is there around the clock for emergencies.
Frequently asked questions
What is OKD in Kubernetes?
OKD is a Kubernetes distribution: upstream Kubernetes plus an installer, CentOS Stream CoreOS, a web console, an image registry, monitoring and over-the-air upgrades, built by the OKD community from the same code as Red Hat OpenShift. OKD 5.0 ships Kubernetes 1.36. Our OKD explainer goes through the parts.
Does OKD stand for Origin Kubernetes Distribution?
Close, but not quite. When Red Hat renamed OpenShift Origin to OKD on 3 August 2018, its rename announcement called OKD "the Origin community distribution of Kubernetes that powers Red Hat OpenShift", so "Origin Community Distribution" has the better claim and "Origin Kubernetes Distribution" is a common paraphrase. Today's okd.io about page uses OKD as a name, calls it the community distribution of Kubernetes and says it is also referred to as Origin.
Is OpenShift based on OpenStack?
No. OpenStack is infrastructure as a service: it hands out virtual machines, networks and volumes. OpenShift and OKD are Kubernetes platforms for containers, and OpenStack is one of several places they run, next to bare metal, vSphere and public clouds. The two also meet the other way round: Red Hat OpenStack Services on OpenShift 18.0 runs OpenStack's control plane on OpenShift.
What Kubernetes version does OKD use?
OKD 5.0.0-okd-scos.1, the newest stable release on 6 October 2026, ships Kubernetes 1.36.4. 5.0.0-okd-scos.0 had 1.36.3, and the first releases of OKD 4.22, 4.21 and 4.20 shipped 1.35.4, 1.34.2 and 1.33.4.
What is OKD SCOS?
SCOS is CentOS Stream CoreOS, the image-based operating system OKD nodes have run since 4.16. It replaced Fedora CoreOS after the OKD Working Group's June 2024 decision, moved from CentOS Stream 9 to 10 with OKD 4.20, and is why OKD release names contain "okd-scos".
Is OKD free, and is it ready for production?
OKD is open source under the Apache 2.0 licence, with no subscription or per-node fee. The 5.0 release notes call it ready for production use, but support comes from the community, not a vendor, so on OpenStack, which OKD's CI does not test, production means rehearsing every upgrade on a scratch cluster first.
Can RS Computers host the servers around an OKD cluster?
Yes. Message us on Telegram or email info@rscomputers-ks.com with what you want next to the cluster, such as a tooling host, an outside monitor or off-site backups, and we will suggest a plan and quote the setup.
Pre-flight checklist
- Download
openshift-installandocfrom the same 5.0 tag on OKD's GitHub releases page. - Compare
openstack quota showwith the table above, with headroom for one replacement machine. - Boot a test VM and confirm the metadata service answers. On Ceph-backed Glance, plan for raw images.
- Check the OpenStack API endpoints' certificates: since OKD 4.10 they must carry subject alternative names, and the docs include a script that scans the whole catalog.
- Choose the Octavia provider and write the
[LoadBalancer]section before the install, not after. - Give the install account
swiftoperator, or getrgw_max_attr_sizeand "account in url" fixed on RGW. - Create DNS records for
api.<cluster>.<domain>and*.apps.<cluster>.<domain>pointing at the floating IPs. - Build a scratch cluster, upgrade it once, destroy it, and check the project for anything left behind.
If the scratch cluster survives that on your cloud, the real one usually will too.