Kubernetes Distribution

A Kubernetes distribution packages Kubernetes with a selected set of surrounding components and an update model. Commercial distributions add vendor support commitments; community distributions can use different maintenance arrangements. OpenShift 4.19 provides the concrete examples below.

Red Hat’s own description of OpenShift is a good illustration of how a distribution positions itself: “OpenShift Container Platform is a cloud-based Kubernetes container platform. The foundation of OpenShift Container Platform is based on Kubernetes and therefore shares the same technology.” The claim is deliberately modest about the core — and everything distinctive is elsewhere.

What certification actually guarantees

CNCF conformance tests required Kubernetes APIs for the certified version. This common behavior supports interoperability, but certification does not establish that every workload can move unchanged between two products.

Two properties of the program are worth using rather than just knowing.

• Certification has to be renewed with current software. “To remain certified, vendors need to provide the latest version of Kubernetes yearly or more frequently.” A distribution that has quietly stopped tracking upstream cannot stay certified.
• You can verify it yourself. “Any end user can confirm that their distribution or platform remains conformant by running the identical open source conformance application (Sonobuoy) that was used to certify.” That is a reasonable acceptance test to run against a cluster somebody sold you, and against your own after a major change.

Check both the common API and what a manifest refers to. StorageClasses, identity bindings, admission rules, runtime requirements and network integration may differ. A Deployment can be valid Kubernetes and still be rejected or behave differently at its destination. A portability and exit plan tests representative workloads and includes these dependencies in the exit cost estimate.

The three layers a distribution adds

Reading a mature distribution’s architecture, the additions sort into three groups. The examples below are OpenShift’s, because its documentation names them individually.

An integrated operating system. In OpenShift 4.19, RHCOS is required on control-plane machines and can also run on workers. Configuration and OS updates integrate with cluster management, including drift detection. RHEL workers are another supported choice, but require additional operator maintenance and upgrade tasks. Compare the selected node configuration with maintaining your own golden image pipeline.

An update graph. The Cluster Version Operator consults update information to identify available paths for the installed platform. This helps coordinate compatible components, including RHCOS where used. Longer support additionally requires maintained fixes, testing and a published support commitment; knowing the component combination alone is insufficient.

An integrated application layer. OpenShift combines a registry, Routes for external access, Source-to-Image builds, an operator catalog and lifecycle tools, templates, a CLI and a console. These reduce assembly work while creating dependencies to identify in a migration.

Candidate to reuse	Dependencies to verify
Deployments, Services, ConfigMaps and Secrets	API versions, admission requirements, referenced resources and networking behavior
Container images	Architecture, runtime contract, registry access and build dependencies
RBAC definitions	Subjects, effective grants and cloud or directory identity mapping
PersistentVolumeClaim definitions	StorageClasses, provisioners, topology, access and actual data migration
Application code	Platform APIs, configuration, operator behavior and deployment tooling

Why anyone chooses one

Two reasons come up repeatedly, and both are legitimate.

A longer support window. OpenShift offers phased support and EUS extensions for eligible releases, with the appropriate subscriptions allowing up to 48 months on one minor release. Check the release, architecture and contract conditions. Staying on an older minor delays newer features, while eligible security and bug fixes can still be backported.

A common platform across environments. Supported deployments span data centers and public clouds. Common tooling can reduce operating differences, but identity, networking and storage integration still depend on the environment.

Red Hat expects customers to use the current supported micro release to receive fixes. After the applicable support window ends, assistance is limited to upgrading to a supported version. For a self-operated installation this is a support boundary, not a vendor-triggered upgrade. See support lifecycle and version skew when planning maintenance.

One clarification, since the categories get muddled in evaluations. A distribution and a managed service are different things and can be combined: distributions are sold as software you run and also as vendor-operated offerings, and the question “who operates it” is separate from “whose assembly is it.” Answer both deliberately. For how the two questions interact when choosing a platform, see Someone Else’s Problem, Up to a Point; for what the shared core itself provides, control plane and desired state.

References

• CNCF: Certified Kubernetes Software Conformance
• Red Hat: OpenShift Container Platform 4.19 Architecture overview
• Red Hat OpenShift Container Platform Life Cycle Policy
• Red Hat OpenShift Service on AWS
• GKE Autopilot security measures