What is a Kubernetes distribution?
A Kubernetes distribution is a packaged version of upstream Kubernetes that adds the pieces a working cluster needs, such as a container runtime, networking, storage, an installer and an upgrade path, and is tested and supported as one product. Examples include k3s, RKE2, k0s, Talos Linux and OpenShift. Most distributions are CNCF Certified Kubernetes, which means they pass the same conformance tests and expose the same core API as upstream.
Upstream, distributions, installers and managed services
“Kubernetes” can mean several different things. The differences are about who assembles the parts and who keeps them running.
| Term | What it is | Examples |
|---|---|---|
| Upstream Kubernetes | The source code and release binaries from the Kubernetes project. Nothing beyond the core components. | Releases on kubernetes.io |
| Installer or bootstrap tool | A tool that installs upstream components on machines you provide. You choose and maintain the add-ons. | kubeadm, Kubespray, kOps, Cluster API |
| Distribution | Upstream Kubernetes plus chosen defaults, packaged and versioned as a product. You run it. | k3s, RKE2, k0s, Talos Linux, MicroK8s |
| Platform | A distribution plus developer and operations tooling such as builds, registries, consoles and policy. | OpenShift, Rancher with RKE2 |
| Managed service | A provider runs the control plane, and often the nodes, for you. | EKS, GKE, AKS |
The Kubernetes production environment guide lists kubeadm, kOps and Kubespray as deployment tools. They install Kubernetes, but they leave the choice of CNI, ingress, storage and OS to you. A distribution makes those choices for you. Our post on OpenShift vs Kubernetes shows how far a platform goes beyond the core, and the Rancher vs OpenShift comparison compares two enterprise platforms in detail.
What a distribution decides for you
Upstream Kubernetes ships the API server, scheduler, controller manager, kubelet and kube-proxy. Everything else is a choice, and a distribution makes it:
- Operating system. Some distributions run on any Linux. Others ship their own OS, as Talos Linux and OpenShift with Red Hat Enterprise Linux CoreOS do.
- Container runtime. Usually containerd or CRI-O.
- Network plugin (CNI). Flannel, Calico, Cilium or Canal, plus a network policy engine.
- Ingress and load balancing. A bundled ingress controller such as Traefik or NGINX, and sometimes a simple load balancer for bare metal.
- Storage. A default StorageClass, often a local-path provisioner on small distributions.
- Datastore. etcd in most distributions. k3s defaults to SQLite through kine, a shim that lets Kubernetes use a SQL database in place of etcd.
- Packaging and upgrades. A single binary, OS images, Helm charts or an operator that upgrades the cluster in place.
- Security defaults. CIS benchmark profiles, FIPS-validated builds or SELinux policies.
What conformance certification guarantees
The CNCF Certified Kubernetes program checks that a product implements the Kubernetes API the same way upstream does. Vendors run the conformance test suite with Sonobuoy and submit the results to the cncf/k8s-conformance repository. To stay certified, a vendor must offer the latest Kubernetes version at least once a year. The CNCF lists more than 90 certified offerings.
Certification guarantees that standard workloads and tools behave the same everywhere. A Deployment, a Service or a Helm chart that works on one certified cluster works on another.
It does not guarantee:
- the same add-ons, such as ingress controllers, storage drivers or policy engines,
- the same security defaults or hardening,
- the same support window or upgrade tooling,
- compatibility of vendor-specific APIs and custom resources.
Support windows differ from upstream
Upstream patches each minor version for about 14 months. A distribution can follow that window, shorten it, or sell a longer one. Enterprise platforms often support a release longer than upstream and backport fixes themselves, which is part of what their subscription pays for. Check the distribution’s lifecycle page before you standardize on it. How long Kubernetes versions are supported explains the upstream policy and the managed-service options.
Where lock-in comes from
The Kubernetes API itself is portable between certified distributions. Lock-in comes from what sits around it:
- vendor-specific resources, such as OpenShift Routes, SecurityContextConstraints and BuildConfigs,
- bundled tools that only exist in one platform, such as a console, an image builder or a policy engine,
- installer and upgrade tooling that is tied to one OS or one vendor,
- support contracts and per-core or per-node subscriptions.
A workload that only uses upstream resources moves between distributions with little work. A workload built on a platform’s extensions needs to be rewritten first. How to avoid cloud vendor lock-in covers the wider picture.
How to choose
Start from who will operate the cluster. If your team will run its own control plane, compare distributions on upgrade tooling, support windows and the add-ons they force on you. Lightweight distributions such as k3s suit edge sites and small clusters. Hardened distributions fit regulated environments. If you would rather not run the control plane at all, a managed service is the alternative to a distribution.
Cloudfleet and distributions
Cloudfleet Kubernetes Engine (CFKE) is a managed service, not a distribution you install. It runs upstream Kubernetes, follows Kubernetes conformance standards, and runs the control plane for you while nodes join from cloud providers and your own servers. See what Cloudfleet is.