What Is OKD Kubernetes? How It Compares with Red Hat OpenShift, Plain Kubernetes and k3s

OKD is the free, community-built Kubernetes distribution that Red Hat OpenShift is made from. You get the same installer, the same operator-driven upgrades, the same web console, Routes and in-cluster image builds, running on CentOS Stream CoreOS instead of Red Hat Enterprise Linux CoreOS, with no subscription and nobody to call when it breaks. Put simply, OKD Kubernetes is OpenShift without the contract. The current release, OKD 5.0, came out on 17 September 2026 and runs Kubernetes 1.36.

Where OKD stands in early October 2026:

• The newest build is 5.0.0-okd-scos.1 (30 September 2026), with Kubernetes 1.36.4 on CentOS Stream CoreOS 10.
• OKD 5.0 arrived before Red Hat OpenShift 5. OpenShift's newest release was still 4.22.
• Support is community only: Slack, GitHub and the docs. No OKD version has a published end-of-life date.
• The smallest install is one node with 4 vCPUs, 16 GB of RAM and 120 GB of disk. A standard highly available cluster uses five machines (three if the control plane also runs your apps) plus a temporary bootstrap.
• If you only need to run a few apps on one server, k3s needs 2 cores and 2 GB of RAM.

What is OKD Kubernetes, and where does the name come from?

OKD started life as OpenShift Origin, the open-source project behind Red Hat's OpenShift. On 3 August 2018, with the 3.10 release, Red Hat renamed it OKD and described it in the rename announcement as "the Origin community distribution of Kubernetes that powers Red Hat OpenShift". That sentence is where the long forms come from. You will see OKD expanded as Origin Kubernetes Distribution or Origin Community Distribution, and both are fair readings. The project itself now treats OKD as a name, and its homepage never spells it out.

A distribution is Kubernetes plus decisions somebody made for you: the node operating system, the network plugin, the ingress, the upgrade method and the security defaults. Upstream Kubernetes leaves those to you, and OKD makes nearly all of them. The okd.io homepage calls it a very opinionated deployment of Kubernetes that installs operators for more than 100 cluster components (the project's own count). The GitHub repository, under the Apache 2.0 licence, calls it self-managing and auto-upgrading, and that is the part people underestimate. The cluster upgrades its node OS, control plane and built-in add-ons as one versioned release. You pick a version and the cluster gets itself there.

Is OKD the same as Red Hat OpenShift?

Close, but it is not the same product. When OKD 4 became generally available in July 2020, Red Hat called OKD and OpenShift Container Platform sibling distributions built from the same container images, rather than an upstream and a downstream. In daily use the oc command, the APIs and the console match, and so do most install methods. The differences sit around the code, and Red Hat's own OKD vs OpenShift comparison lists them:

• OKD nodes run CentOS Stream CoreOS. OpenShift nodes run RHEL CoreOS.
• OpenShift comes with subscription support, certified partner operators and Red Hat middleware. OKD has community support only.
• OKD has a shorter lifecycle and usually runs ahead of OpenShift.

That last point is very visible this autumn. OKD 5.0 shipped on 17 September 2026, while OpenShift's newest release in early October was still 4.22, on Kubernetes 1.35. Red Hat has previewed OpenShift 5, with in-place upgrades from version 4, but had not released it when we checked. For now, OKD is the only way to run the 5.x platform.

Red Hat engineers still do much of the work: the 5.0 release notes and the announcement of OKD's new update service were both written by them. But "Red Hat OKD" is not a product you can buy. There is no SLA and no support ticket.

How does OKD compare with OpenShift, plain Kubernetes and k3s?

Here is how the four options stood in early October 2026. The versions come from the OKD 5.0 and OpenShift 4.22 release notes, the Kubernetes 1.37 announcement and the k3s releases page; the k3s sizing comes from its requirements page.

Read that table two ways. If what attracts you is "Kubernetes that comes complete", k3s also comes complete, with an ingress and a Helm controller, on an eighth of the RAM. If what attracts you is the OpenShift way of working (Routes, in-cluster builds, strict security defaults, a console developers actually use, upgrades from one place), OKD is the only free way to get it.

The version gap with upstream is small and, for most teams, welcome. OKD 5.0 tracks Kubernetes 1.36, one minor release behind upstream 1.37, so new Kubernetes releases reach you already integrated with the rest of the payload. On vanilla Kubernetes you carry that work yourself: ingress-nginx stopped getting releases and security fixes in March 2026, and replacing it is your job. On OKD, Routes keep working through the platform's own HAProxy router.

What does OKD add on top of Kubernetes?

These pieces are installed on day one, each run by its own operator:

• A web console with an administrator view and a developer view. Cluster dashboards and alerts live under Observe.
• Operator Lifecycle Manager and a catalog of add-ons. In the OKD 5 console, the page once called OperatorHub is now the software catalog. Its default source is the community-operators catalog, which needs no pull secret.
• An integrated container image registry. On bare metal and platform-agnostic installs it starts in the Removed state and does nothing until you give it storage, which catches out many first installs.
• Builds: BuildConfig objects that turn source code or a Dockerfile into an image inside the cluster, with Source-to-Image, Docker and custom build strategies.
• Routes, served by an HAProxy-based ingress controller, so you never choose, install or patch an ingress yourself. Gateway API is switched on through the same Ingress Operator, but on OKD it still deploys an Istio image from Red Hat's registry that needs an OpenShift pull secret (OKD issue 2332, reported on 4.22 and still open in early October 2026). Test it before you rely on it.
• OVN-Kubernetes networking, with network policies enforced from the start.
• A built-in OAuth server that signs people in through htpasswd, LDAP or an OpenID Connect provider, tied to Kubernetes RBAC.
• Prometheus-based cluster monitoring and alerting, upgraded with the rest of the platform.
• Security context constraints (SCCs). The default, restricted-v2, runs every pod as a non-root user with a UID taken from a range assigned to its namespace, blocks privilege escalation and applies the runtime's default seccomp profile.

The SCCs are where most newcomers lose their first afternoon. A Docker Hub image that expects root, or one fixed UID, often crash-loops on OKD with permission errors on its own data directory. Do not hand out a privileged SCC to make the error go away; use an image built for arbitrary UIDs, owned by group 0 with group-writable directories.

The catalog has a gap too. Red Hat's redhat-operators and certified catalogs are not provided to OKD, and some community operators depend on content from them, which shows up as missing-dependency errors. Test every operator you rely on before you plan around it.

Three claims you will still read about OKD, including in the 2025 version of this page, are out of date:

• Grafana is not included. The bundled Grafana and direct access to the Prometheus and Grafana interfaces were removed from the OpenShift monitoring stack in 4.11, back in 2022. Prometheus still runs underneath, and the dashboards moved into the console.
• OpenShift SDN is gone. It was deprecated and then removed in 4.17. OVN-Kubernetes is the network plugin.
• Tekton pipelines do not come preconfigured. They are not part of the OKD payload, and OpenShift Pipelines is distributed through Red Hat's catalog, which OKD does not get. CI is something you add.

Which OKD version is current, and who supports it?

The okd.io homepage lists 5.0 as the current release and 5.1 as the current engineering candidate. The GitHub release metadata gives a clear picture of the past year and a half:

That is a new minor release roughly every four months. Treat it as your maintenance calendar: a cluster left alone for a year falls three releases behind, and the project publishes no end-of-life dates. The newest 4.22 build we found was 4.22.0-okd-scos.10 from 9 September 2026, and nothing says whether more will follow. The 5.0.0-okd-scos.1 build lists it as a supported upgrade source, so plan to move. For comparison, Red Hat's OpenShift lifecycle policy covers each OpenShift 4 minor release for up to 18 months, and even-numbered Extended Update Support releases for 24, 36 or 48 months, depending on the add-on terms in the subscription.

The node operating system has changed twice. OKD 4 ran Fedora CoreOS up to 4.15. In June 2024 the OKD Working Group said licensed content had been accidentally included in OKD releases, and 4.16 and 4.17 (16 December 2024) moved to CentOS Stream CoreOS, with 4.16 as a pass-through step that needed manual work on Fedora CoreOS clusters. 4.20 then moved the nodes from CentOS Stream CoreOS 9 to 10. The GitHub README, some docs tables and even the 4.20 release notes still mention Fedora CoreOS; trust the machine-os version listed on each GitHub release.

What changed in OKD 5.0

The OKD 5.0 release notes list Kubernetes 1.36.3, CRI-O 1.36.4 and CentOS Stream CoreOS 10, and the Technical Release Team accepted the first build for production use. Before upgrading a 4.22 cluster, look for these:

• DeploymentConfig objects are deprecated. Move them to standard Deployments.
• ImageContentSourcePolicy is replaced by ImageDigestMirrorSet.
• The option to override the runtime back to runC is gone. OKD runs crun.
• oc adm release mirror is replaced by oc-mirror v2, which is now distributed separately.
• Kernel modules injected through KVC need the Kernel Module Management operator instead.
• From upstream Kubernetes 1.36, the gitRepo volume plugin is disabled and Service externalIPs are deprecated.

On the plus side, user namespaces, mutating admission policies and DRA partitionable devices are now generally available.

A real update service at last

Until September 2026, OKD's upgrade paths came from the CI release controller, which let engineering candidate builds leak into stable channels. OKD Cincinnati, announced on 18 September, is a proper update service at updates.okd.io with stable-5.0 and candidate-5.0 channels, and it can block bad paths: its first example steers clusters away from 4.22.0-okd-scos.4 to .6, whose CRI-O could hang during node shutdown. Once a cluster reaches 5.0.0-okd-scos.0, point it at the service:

# as the kubeadmin user, on a workstation where oc is 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 upgrade

The patch replies clusterversion.config.openshift.io/version patched. oc adm upgrade then shows the stable-5.0 channel and any newer build the service offers.

When something breaks, help comes from docs.okd.io, the #openshift-users channel on Kubernetes Slack and the issue tracker of the okd-project/okd repository on GitHub. The project's release status page states plainly that the builds and upgrade paths it lists are not officially supported. That is workable, as long as someone on your team can read a must-gather archive and fix things without a vendor.

Where can OKD run?

Nearly anywhere OpenShift runs. The OKD 5 documentation covers installs on AWS, Azure, Azure Stack Hub, Google Cloud, IBM Cloud, Alibaba Cloud, Nutanix, OpenStack, Oracle Distributed Cloud and VMware vSphere, plus bare metal with installer-provisioned or user-provisioned infrastructure. There is also a "platform none" route for any other environment, single-node clusters, and two-node clusters that use fencing or a small arbiter node.

Our favourite private cloud pairing is OKD on OpenStack: with an installer-provisioned install, the cluster creates its own machines through OpenStack's APIs and adds workers with the Machine API. We cover it in running OKD on an OpenStack private cloud. On vSphere, note that OKD 4.21 began deprecating vSphere 7.x. The same release removed the oVirt CSI driver, which matters only if you still run on oVirt. If you are leaving VMware anyway, read why organisations move from VMware to OpenStack first.

Check the architecture before you buy hardware. The single-node docs list x86_64, arm64, ppc64le and s390x, in text shared with OpenShift, but the 5.0 release payload on GitHub is published for linux/amd64. If your plan depends on Arm nodes, test the exact release first.

How much hardware does OKD really need?

More than most people expect, because a fresh cluster runs dozens of operators, a monitoring stack and etcd before your first app arrives. The first four columns are the minimums from the OKD 5 bare-metal install guide and the single-node install guide. The last column is our own sizing for a cluster that runs real work.

Add it up. The standard highly available layout, three control plane machines and two workers, comes to 16 CPUs, 64 GB of RAM and 500 GB of disk, plus the bootstrap machine during the install. A compact cluster of three control plane nodes that also run your workloads is allowed and needs 12 CPUs and 48 GB at the documented minimum. A cluster with exactly one compute machine is not supported. Either have none or have at least two.

Disk latency matters as much as size. The docs ask for a 99th percentile fsync time of 10 ms for etcd on the control plane, which in practice means SSD or NVMe. On slow or busy storage you see leader elections and an API server that times out at random.

The single-node minimum has moved too. The 4.18 to 4.21 docs asked for 8 vCPUs; from 4.22 it is 4 vCPUs, with a warning that this leaves "very little headroom" and a high risk of resource contention.

A 2023 report on the OpenShift docs tracker points the same way: on OKD 4.14, workers at the documented 2 CPU and 8 GB could not start their Prometheus pods, and the control plane needed 8 cores before TLS handshake timeouts stopped. It is one report on an older release, so read it as a warning rather than a benchmark, but it is why our column sits well above the minimums.

When should you pick OKD, and when should you not?

OKD earns its weight in these cases:

• Several teams share one cluster, and you want projects, quotas, SSO logins and strict pod security from day one.
• Developers should deploy from Git or a Dockerfile through the console without learning Helm first.
• You run a private cloud on OpenStack or bare metal with three or more decent machines, and per-core subscriptions would outweigh the people who run the platform.
• You plan to buy OpenShift later, or your engineers are heading for OpenShift jobs, and want them fluent first.

Pick something else in these cases:

• You have one server and a handful of containers. Docker Compose or k3s will be running before an OKD install has finished pulling its images.
• You need a vendor to call at 3 a.m., certified partner operators or a long, documented support window. That is what an OpenShift subscription is for.
• Your apps are third-party images that insist on running as root and cannot be rebuilt.
• Nobody has time to read release notes every four months. A cluster that misses two upgrades becomes a project of its own.
• Your hardware is Arm only and you cannot test the payload first.

Our rule of thumb: OKD pays off from about three serious machines and two or more teams. Below that, the platform eats more resources and attention than it gives back.

Where our VPS and VDS plans fit around OKD

RS Computers runs KVM virtual servers in Amsterdam (Netherlands), Prishtina (Kosovo) and Dublin (Ireland), each with NVMe storage, its own IPv4 and IPv6 addresses and free weekly backups, on a 1 Gb/s port (VPS) or a 10 Gb/s port (VDS). The vCPUs are shared. That suits labs and tooling, and it is one reason we would not put a production etcd quorum on any provider's VPS: for production OKD, use hardware or a private cloud you control. Our servers fit three roles around it.

The first is a single-node lab or proof of concept. VDS Large (16 vCPU, 32 GB RAM, 960 GB NVMe) clears the single-node minimum with room for monitoring and a few test apps. VDS Medium (8 vCPU, 16 GB) only matches the RAM floor, so we would skip it for this. A single-node install needs DNS records for api, api-int and *.apps under the cluster's domain, which is simple when the server has its own IPv4. OKD nodes boot CentOS Stream CoreOS from the OKD installer's own image rather than a standard Linux template, so ask us on Telegram or by email whether your install method works on the plan before you order.

The second is tooling for a cluster that runs elsewhere: a bastion host with oc and openshift-install, a mirror registry filled with oc-mirror v2 for a disconnected cluster (the 10 Gb/s VDS port helps with large release images), a Git server, or a monitor that watches the cluster from outside. Our free weekly backups cover the server, not the cluster, so take etcd backups with the docs' cluster-backup.sh script and copy them off site; our guide to off-site backups with restic or Borg handles that part. VPS Mini or VDS Small covers most of these jobs.

The third is the simpler alternative. If the comparison talked you out of OKD, follow our single-node k3s setup on a VPS, which fits on VPS Micro for learning and runs comfortably on VPS Mini. Still building your Linux basics? Start with the 30-day Linux and DevOps lab on a VPS. The VPS and VDS plans page lists every plan, with the same plans and prices in all three cities.

Frequently asked questions

What does OKD stand for?

OKD comes from OpenShift Origin. When Red Hat renamed the project on 3 August 2018, it described OKD as the Origin community distribution of Kubernetes that powers Red Hat OpenShift, so "Origin Kubernetes Distribution" and "Origin Community Distribution" are both common expansions. Today the project uses OKD as a name and does not spell it out.

Is OKD free to use?

Yes. OKD is open source under the Apache 2.0 licence, with no subscription or per-core fee. You pay for the hardware and for the time it takes your own team to run and support it.

What is the latest version of OKD?

OKD 5.0. Its first build, 5.0.0-okd-scos.0, came out on 17 September 2026 with Kubernetes 1.36.3, and 5.0.0-okd-scos.1 followed on 30 September 2026 with Kubernetes 1.36.4. Both run on CentOS Stream CoreOS 10, and 5.1 is the current engineering candidate.

Is OKD production ready?

The OKD release team accepted 5.0.0-okd-scos.0 for production use. There is no SLA, no vendor support and no published lifecycle, though, so it is production ready only for teams that can support themselves and keep upgrading every few months.

What operating system does OKD use?

CentOS Stream CoreOS, version 10 since OKD 4.20. OKD 4 used Fedora CoreOS until 4.15 and switched with 4.16 and 4.17 in December 2024. The cluster manages and upgrades the node OS itself.

Does OKD include OperatorHub?

Yes, under a new name. In the OKD 5 web console it is called the software catalog, and it installs operators from the community-operators catalog by default. Red Hat's own redhat-operators and certified catalogs are not available on OKD.

Can RS Computers help with an OKD lab or a lighter Kubernetes setup?

Yes. Message us on Telegram or email info@rscomputers-ks.com with what you want to run, whether that is a single-node OKD lab, tooling for an existing cluster or a small k3s setup, and we will suggest a plan and quote the setup.

← All articles