Kubernetes distribution selection starts with who will run the cluster
The Kubernetes distribution you pick decides who patches the cluster, who performs upgrades, who answers support tickets and whether you can install without internet access. Make that decision before comparing feature lists. Upstream kubeadm, a certified vendor distribution and a managed service all run the same upstream Kubernetes API, so workloads behave the same way on each. The differences sit in packaging, lifecycle support, bundled add-ons, licensing and the staffing each path requires. For infrastructure you control, the useful question is which operating model your team can sustain for the life of the cluster.
Kubernetes is licensed under Apache 2.0, so no distribution owns the API and upstream builds can be used without a license agreement with the project. The upstream project maintains the three most recent minor releases. Patch support for releases from 1.19 onward runs about one year, roughly 14 months including the pre-release period, and new minor releases arrive about three times a year on a cycle of around 14 weeks. That cadence sets how often you must upgrade under any path. A distribution chosen early also fixes constraints you will feel later: when the vendor ships each minor version, how it packages images and charts for offline use and which upgrade tooling you inherit. Changing distributions after go-live is a migration project of its own.
Conformance is necessary but not sufficient. The CNCF Certified Kubernetes program checks that a distribution supports the required Kubernetes APIs, and the CNCF page lists over 90 certified offerings. Passing confirms the API surface matches. It does not show how the distribution handles your node operating system, add-on versions, etcd operations, certificate renewal or mirroring images into a private registry. Support windows are the second trap. A vendor may support a minor release for a longer or shorter period than the upstream window, and its fix backports may stop on a date that does not line up with upstream end of life. Ask for the written support matrix for each minor version you plan to run, including the date patches stop and whether security fixes are included.
Before you shortlist vendors, settle who will run the cluster. Name the people who will take etcd snapshots and perform restores, renew control plane certificates, patch node images and rehearse each upgrade. Count how many of these tasks your staff can cover and how many you would buy from a partner or vendor. If the environment is air-gapped, add a check: confirm the distribution documents how to mirror control plane and add-on images, how chart and package repositories are handled and how upgrades are delivered offline. Then write those answers into the quote request so each option is scoped and priced against the same support terms.
The three distribution paths and what each one packages
Three distribution paths package different parts of Kubernetes for you. Upstream kubeadm leaves the most to your team, certified vendor distributions add installers and support, and managed services hand over the control plane. The two checks in the last card apply whichever path you choose.
Upstream kubeadm
Kubeadm is community tooling that bootstraps the control plane, and your team assembles and operates everything around it: etcd, the API server load balancer, the container network, storage drivers and add-ons. The kubeadm high availability guide describes a stacked topology, with etcd on the control plane nodes, and an external etcd topology. Both call for at least three control plane nodes behind a TCP load balancer on port 6443. Check who patches each component, who builds the etcd backup job, and whether your team can rehearse a minor version upgrade before production. Kubeadm can also list and pull control plane images and point at a private registry, which supports installs without internet access.
Certified vendor distributions
A vendor packages a Kubernetes build that passes CNCF conformance, adds installers and curated add-ons, and sells a support contract. Conformance checks that the required Kubernetes APIs are supported, but it says nothing about your security configuration, upgrade tooling or support quality, so ask for those separately. The CNCF program lists over 90 Certified Kubernetes offerings, so the label confirms a shared API baseline and does not rank one product above another. Confirm the support lifecycle against the three minor releases the project maintains, whether air-gapped bundles and offline upgrades are included, and how licensing scales with nodes or cores.
Managed Kubernetes services
The cloud provider runs and upgrades the control plane and its etcd, while you own node groups, networking choices, add-on configuration, identity mapping and workloads. The CIS Kubernetes Benchmark covers managed services such as EKS, AKS, GKE, OKE and OpenShift, so you can assess your configuration against it even though the provider controls parts of the platform. Check where the cluster runs relative to your account and data center boundaries, which controls you can apply inside the provider account, and what backup access you receive for cluster state. Air-gapped requirements generally do not fit this path, so confirm that early in the evaluation.
Conformance label and CIS scope
Two checks apply to every path: the conformance label and the CIS Kubernetes Benchmark. Ask the vendor or provider which conformance version they certified, then test the APIs your own workloads and add-ons call, because conformance does not cover your add-ons. Use the benchmark to sort recommendations into three groups: those the provider or vendor handles, those that fall to your node configuration, and those that fall to your workloads. Keep scan output with the cluster record so auditors can see the basis for each decision. The benchmark is freely available as a PDF for non-commercial use, so review its terms before commercial use.
Which distribution fits which constraints
This table compares upstream kubeadm, certified vendor distributions and managed services against the constraints that usually decide the choice: in-house skills, patching, air-gapped operation, licensing and support lifecycle. Read each row as a question to answer before you ask for a quote. The main takeaway is that every option leaves a patch window you must track, and the options differ mainly in who carries that work.
| Option or constraint | When it fits | Operational cost to you | What to confirm with the vendor |
|---|---|---|---|
| Upstream kubeadm | Strong in-house Kubernetes skills, a platform team to own upgrades, and no required vendor support contract | You own patching, certificates, etcd backups, add-on compatibility and every upgrade, with community support as the only escalation path | Which minor releases you will track, who owns each upgrade, and which external support you will rely on |
| Certified vendor distribution | You need vendor support, a defined lifecycle, or a supported path for air-gapped or regulated environments | Subscription plus in-house skills for installation and upgrades, with the vendor sharing patch and escalation duties | Conformance version, end-of-support date for each release, offline install steps, and license scope per node or core |
| Managed service | A cloud-hosted control plane is acceptable and you want the provider to run control plane upgrades and availability | Less control plane work, but you still own workloads, node pools, add-ons, RBAC and cloud account setup | Supported Kubernetes versions and their end dates, where the cluster runs, and how etcd backups are handled |
| Air-gapped requirement | Clusters must install, update and pull images without internet access | Image mirroring, offline package and chart repositories, and certificate handling for every upgrade cycle | Full list of control plane and add-on images, the mirror process for each release, and how security fixes arrive offline |
| Licensing terms | Legal and budget review need clear terms for support, use and proprietary add-ons | Upstream Kubernetes is Apache 2.0 licensed, but vendor add-ons and support may carry separate terms | Whether the subscription covers every component you run, the term length, and what changes if you stop renewing |
| Support lifecycle | Your change calendar and audit evidence need known end dates for each minor release | Upstream keeps the three most recent minor releases in support, each with about one year of patch releases | End-of-support dates for each release the vendor ships, its backport policy, and the notice given before end of life |
| Conformance | Your tooling and standard manifests must work against the Kubernetes APIs without modification | Certified offerings show API conformance, but your own operators and add-ons still need testing on each upgrade | Conformance version and test results for the exact release you will run |
How to check a conformance claim before you sign
A conformance claim tells you one specific thing: the distribution passes the CNCF Certified Kubernetes conformance tests, which check that the required Kubernetes APIs behave as the specification describes. It is a useful floor, but the CNCF program lists over 90 Certified Kubernetes offerings, so the claim alone does not separate vendors on anything else. The tests do not cover the add-ons a vendor bundles, such as ingress, storage drivers or monitoring stacks. They also do not check default security settings, whether Secrets are encrypted at rest, the air-gapped installer, the upgrade tooling or the support terms you will rely on. Treat the claim as a statement about the API surface only, and evaluate every other requirement separately.
Run the same short checklist against each candidate before you sign. First, confirm the exact certified Kubernetes version and the minor releases the vendor supports today. Second, ask which of the three maintained minor releases the vendor's current build tracks. As of September 2026 those were 1.37, 1.36 and 1.35, and their end-of-life dates differ, so a build on 1.35 has less remaining support than one on 1.37. Third, ask how far the vendor's builds lag upstream patch releases, since Kubernetes 1.19 and newer receive about one year of patch support. Fourth, request the vendor's version skew and upgrade documentation in writing, and check that it describes the exact upgrade path you would follow.
The skew rule decides how often you must upgrade and what the vendor has to ship. The kube-apiserver is upgraded first, one minor version at a time, and the controller manager, scheduler and kubelets follow. Kubelets may be up to three minor versions older than the API server. That window only helps if the vendor keeps node images current. If node images trail the control plane, your nodes drift toward the edge of the allowed skew, and the next control plane upgrade can force an urgent node rebuild. Ask how often new node images are published, how each image is tested against the minor releases in scope, and whether you can build and store those images in your own registry for an air-gapped estate.
Turn these answers into a written record before the contract is signed. For each candidate, note the certified version, the tracked minor release, the typical patch lag, the node image cadence and the skew documentation reference. Compare those answers with the upgrade rhythm your own platform team can sustain, because a distribution that forces you to jump across several minor versions at once asks more of your people than one that follows the upstream schedule closely. Ask the vendor to confirm in writing which add-ons and default settings sit outside the conformance claim, then include the work to close each gap in the quote. Verify release-specific details against the kubernetes.io release pages and the vendor's own documentation, not marketing material.
Build the selection in five steps
This sequence turns a list of distribution options into a decision the platform team can defend. Each step produces a written artifact or a test result, so the choice rests on your constraints, your team's skills and evidence you can rerun before anyone signs a contract.
Write down hard constraints
Start by listing the conditions a distribution cannot break: connected or air-gapped installation, data residency, which cloud accounts or data centers the cluster may use, and the support hours your operations need. The compliance lead, the platform lead and the owner of the business service review the list together. Any candidate that fails a constraint is removed before features are compared. The check is a signed-off constraint list.
Map current platform team skills
For each path (upstream kubeadm, a certified vendor distribution or a managed service), list the tasks your team would own: control plane installation, certificate rotation, etcd backups, upgrades, add-on management and incident response. Mark each task as already covered, covered after training, or missing. The check is a skills matrix reviewed by the team lead, with every gap tied to a named owner or an outside partner.
Shortlist candidates and collect written terms
Narrow the field to candidates that pass the constraints and fit the skills matrix. Ask each vendor or provider for its written lifecycle policy, licensing model, support terms and CNCF conformance evidence for the exact version you plan to run. If the environment is air-gapped, confirm in writing what offline support covers. The check is a comparison sheet in which every claim points to a document the vendor provided.
Run a proof-of-concept install and rehearsals
Build each shortlisted option in a non-production environment that matches your network, storage and identity setup. Rehearse an upgrade from one minor version to the next, following the version skew rules, then take an etcd snapshot with etcdctl and restore it to a fresh control plane with etcdutl. For air-gapped sites, pull every control plane and add-on image from the private registry with no internet route. A self-built kubeadm cluster, for example, needs at least three control plane nodes behind a TCP load balancer on port 6443. The check is a completed upgrade rehearsal and a successful restore test, both logged with the problems found.
Record the decision with dates, owners and exit path
Write a decision record that names the chosen distribution and minor version, the end-of-life date for that release from the Kubernetes release schedule, and an owner for each lifecycle task such as upgrades, certificate renewal and backups. Add an upgrade calendar and an exit path that describes how workloads and data would move to another distribution if support ends or terms change. Security, compliance and the platform owner sign it. The check is a signed decision record the team can reference at the next upgrade.
How the choice changes by environment
In a connected data center, nodes can reach public registries and package repositories, so the main question becomes who controls the update path. Upstream kubeadm can pull images directly, but many teams still mirror them for change control and audit trails.
- Image mirroring: Run kubeadm config images list and pull against an internal registry, then point kubeadm init at it with --image-repository so every pull is approved and logged.
- Package and chart sourcing: Confirm which package and chart repositories the distribution uses, whether you can pin exact versions and whether you can mirror them internally.
- Certificate handling: Confirm whether the distribution issues cluster certificates at install, how renewal is scheduled and whether an internal certificate authority can be supplied.
- Vendor support access: Connected sites usually reach vendor portals directly. Confirm the support channels, response terms and whether support covers upstream components or only the vendor build.
- Upgrades: Your team or a partner typically runs upgrades on the schedule set by the distribution, one minor version at a time under the version skew rules.
Check the update channels, support contacts and certificate renewal behavior in writing before you commit to a distribution.
Without internet access, every image, binary, package, chart and certificate must arrive through an approved transfer path. The distribution's offline support model therefore decides how much work each upgrade adds.
- Image mirroring: kubeadm supports clusters without internet access. Use kubeadm config images list to enumerate control plane images, pull them on a connected staging host, move them across the boundary and push them to a private registry that kubeadm init reaches through --image-repository.
- Package and chart sourcing: Add-ons, operating system packages and Helm charts each need their own mirror. Confirm whether the distribution publishes offline bundles and how signatures are verified after transfer.
- Certificate handling: Plan certificate issuance and renewal for an environment with no public endpoints and possibly no external certificate authority. Confirm how the distribution handles this case.
- Vendor support access: Support often arrives by ticket or media transfer, and patches may take longer to reach you. Confirm in writing whether offline support and offline updates are included and how they are delivered.
- Upgrades: Each minor upgrade needs its image set, binaries and manifests staged in advance, followed by a rehearsal in a non-production enclave. Keep each step to one minor version under the version skew policy.
Before purchase, ask the vendor to confirm offline support and update channels in writing, including what happens when a security patch is released during a change freeze.
With a managed service, the provider runs the control plane, so your work shifts to node images, add-ons, workload identity and the upgrade calendar the provider sets. Image mirroring matters less for the control plane but still matters for workloads and add-ons.
- Image mirroring: The provider manages control plane images. Your team still mirrors workload and add-on images if you want them in your own registry, and should confirm whether node provisioning pulls from public registries.
- Package and chart sourcing: Node operating system images and add-on charts often come from provider-maintained channels. Confirm which ones you can pin and whether you can host your own copies.
- Certificate handling: The provider manages control plane certificates. Confirm what you still own, such as ingress certificates, certificates used for identity federation and any workload certificates.
- Vendor support access: Support usually runs through the cloud account and the provider's support plan. Confirm response terms, the escalation path and whether the plan covers add-ons you install yourself.
- Upgrades: The provider sets upgrade windows and the deprecation schedule, while your team tests workloads and add-ons against them. Confirm how much notice you receive and whether you can defer an upgrade.
Check the provider's upgrade notice period, support plan and list of managed components before you assume a control plane upgrade is someone else's task.
A hybrid estate runs more than one environment, such as a data center and a cloud account, or a managed service beside self-managed clusters. Sources, support paths and certificate authorities multiply, and version drift becomes the main operational risk.
- Image mirroring: Use one registry strategy across environments where possible. Mirror images with kubeadm config images list and pull for self-managed clusters, and confirm that managed clusters can reach the same registry.
- Package and chart sourcing: Pin the same chart and package versions in every environment. Confirm the distribution's repositories work in each location and that signatures verify the same way everywhere.
- Certificate handling: Each environment may issue certificates differently. Document which authority signs which cluster and how rotation is scheduled for each one.
- Vendor support access: Support contracts may differ by environment. Confirm which contract covers which cluster, who opens tickets and how an incident that spans environments is routed.
- Upgrades: Clusters may sit on different minor versions. Plan upgrades per environment within the three supported minor releases and the version skew rules, and keep one shared upgrade calendar.
Confirm in writing which support terms, update channels and certificate authorities apply to each environment before you standardize on one distribution.
What drives the effort and cost of the selection and the platform it leads to
This table lists the factors that change how much work a Kubernetes distribution choice and its resulting platform will take, what raises effort for each, how to keep it down and what to request in writing. Read it as a checklist to fill in for your own environment before comparing vendor or partner quotes, since most scope gaps come from factors that were never written down.
| Driver | What raises effort | How to keep it down | What to ask for in a quote |
|---|---|---|---|
| Number of clusters | Each cluster adds its own control plane, upgrades, backups, monitoring and access reviews, and environments such as production, staging and disaster recovery multiply the count | Standardize one cluster blueprint and reuse it through automation, and decide early how many tenancy boundaries you truly need | Per-cluster scope, how many clusters are covered, and whether the quote assumes identical builds |
| Air-gapped requirements | Mirroring images, charts and packages to a private registry, handling certificates offline and running upgrades without internet access all add steps to every release | Decide early whether the environment is fully disconnected, and choose a distribution with documented offline installation and update paths | Written list of mirrored artifacts, offline upgrade procedure, and who maintains the registry |
| Required add-ons and integrations | Ingress, storage, networking, identity, logging, metrics and policy engines each need versioning, configuration and compatibility checks against every Kubernetes upgrade | Limit add-ons to what the workloads need and favor components the distribution already supports | Named add-on list with versions, compatibility statement per Kubernetes minor release and integration test scope |
| Support hours and escalation needs | Round-the-clock coverage, named severity levels, and vendor escalation to engineering raise subscription and staffing costs | Match support tiers to the real impact of an outage and document an internal first-line rota | Support hours, response targets by severity as written in the contract, escalation path and who is on call |
| Licensing model | Subscriptions may be priced per node, per core, per cluster or per socket, and some features sit in higher tiers; upstream Kubernetes itself is under Apache 2.0, so the cost sits in support and operations | Compare licensing on your expected node and cluster counts for three years, not only today's footprint | Licensing unit, what the price includes, renewal terms, and whether air-gapped and disaster recovery use cases are covered |
| Team skills | Operating a cluster needs people who understand networking, certificates, etcd, RBAC and upgrades; a gap in these skills shifts work to the vendor or partner or to incidents | Assess current skills against the distribution's runbooks, train before go-live and pair staff with implementers | Named roles the partner covers, knowledge transfer deliverables, runbooks and training included in scope |
| Compliance evidence needs | Assessors may ask for CIS Kubernetes Benchmark results, Secrets encryption settings, Pod Security Standards enforcement, audit logs and access reviews, each collected and kept over time | Define the control set early, map it to the distribution's configuration options, and automate evidence collection | Evidence list, format, retention period and whether the partner prepares evidence only, since auditors and certification bodies issue any formal opinion |
| Upgrade cadence | Kubernetes ships about three minor releases a year, and only the three most recent minors are maintained, so every add-on, the distribution and workloads must be retested on that rhythm | Set a fixed upgrade calendar, rehearse in staging, and confirm the distribution's support window for each minor release | Upgrade frequency included, rehearsal environment, deprecated API checks, and whether upgrades are priced per cycle or under a retainer |
Security questions the distribution choice must answer
Every Kubernetes distribution ships with a security baseline, and the baseline varies more than the marketing suggests. The four questions below cover the control plane entry point, how people and machines prove identity, how Secrets are protected at rest, and how pods are constrained, so you can test each claim in your own environment before signing a subscription or building a cluster.
API server exposure and reachability
The kube-apiserver is the single front door to the cluster, so its network path decides who can even attempt authentication. In a self-built kubeadm cluster you choose the load balancer, the listening address on port 6443 and the firewall rules. In a vendor distribution or managed service, the default may be a public endpoint, a private endpoint or both. Ask each option to show the reachable paths for administrators, CI systems, worker nodes and the internet, and confirm whether a private-only endpoint is available and can be enforced in your network design.
Authentication methods the distribution exposes
Kubernetes does not store normal users as API objects. It accepts X.509 client certificates, bearer tokens including OpenID Connect and JWT tokens, webhook token authentication and an authenticating proxy. Confirm which of these the distribution lets you configure at the API server, especially OIDC issuer settings that connect to your identity provider. Check whether static token files or shared admin certificates are created by default, and how long issued client certificates remain valid, because those defaults decide how much of your identity model you can enforce.
Secrets encryption at rest in etcd
Secrets are stored unencrypted in etcd by default, so anyone who can read etcd data or its snapshots can read every Secret in the cluster. Do not assume the distribution has turned on encryption at rest. Ask for the EncryptionConfiguration in use, the key provider and where its keys live, and whether key rotation is documented. Also verify that etcd snapshots and backups are encrypted, and that access to Secrets is restricted through least-privilege RBAC. Where external stores are required, confirm support for the Secrets Store CSI Driver.
Pod Security Standards through admission
Kubernetes defines three Pod Security Standards: Privileged, Baseline and Restricted. They are enforced per namespace by the built-in Pod Security Admission controller, which the distribution must leave enabled and not replace with an unreviewed plugin. Verify that the admission controller is active, that namespace labels can set enforce, audit and warn modes, and that the distribution's own system namespaces run with settings that do not break the platform. Test a privileged workload in a sandbox namespace to confirm the policy actually rejects it.
How to verify the selection holds up before you commit
Test the candidate distribution in your own environment before you sign, and write a pass or fail criterion for each test in advance. Start with a fresh install in the target setting: the same network segments, identity provider, storage backend, registry and hardware you will use in production. If the design calls for high availability, build the control plane in the topology you intend to run, either stacked or with external etcd, with at least three control plane nodes behind a TCP load balancer on port 6443. If the environment is air-gapped, run the install with no route to the internet and record every image and package the installer tried to fetch. Any fetch you did not plan for is a finding.
Next, run one minor version upgrade and follow the version skew order: kube-apiserver first, then kube-controller-manager and kube-scheduler, then kubelets. Kubelets may be up to three minor versions behind the API server, so confirm the distribution's node pools fall inside that window during the rolling change. Before the upgrade, run a deprecated API check against the manifests of every workload and add-on you plan to run, and compare the results to the target version's removal notes. Then take an etcd snapshot with etcdctl snapshot save, restore it into a scratch cluster with etcdutl, and confirm that namespaces, workloads and Secrets came back as expected. A snapshot you have never restored is not yet a backup.
Test the failure modes that cause most support tickets. Remove one control plane image from the private mirror and confirm the upgrade stops with an error your operators can trace to the missing image, then restore it and document the recovery path. Simulate or force an expiring certificate in a staging cluster, then check that the distribution reports the expiry, that alerting fires before it, and that the renewal procedure works without downtime. Check the patch cadence for the minor version you plan to run against its support dates. For example, as of September 2026 Kubernetes 1.35 reaches end of life on February 28, 2027, so a plan built on it needs a dated move to a newer minor before then. Finally, open a severity ticket with the vendor's support desk and measure first response and escalation against the contract terms.
Conformance is the last check. The CNCF Certified Kubernetes program verifies that a distribution supports the required Kubernetes APIs, and the program lists over 90 certified offerings. Ask the vendor for conformance results for the exact version you will run, and where the vendor allows it, run the conformance suite yourself in your environment. Passing conformance does not confirm your add-ons, storage or identity integration, so keep it as one line of evidence among your own test results. Sign-off should come from named owners: the platform engineering lead signs the install and upgrade results, the operations lead signs the etcd restore, the security lead signs the certificate and mirror tests, and the vendor relationship owner signs the escalation result. Record each signature with the test date and version in the selection decision record.
What to track, document and hand over after selection
The distribution decision only holds if someone keeps watching the dates, terms and evidence behind it. These four records connect the selection to day-two operations, so the platform team can plan upgrades, renewals and audits from written records.
Lifecycle calendar
List every Kubernetes minor release your chosen distribution supports, with its upstream end-of-life date and the vendor's own dates. Upstream, the project maintains the three most recent minor releases. 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). Releases arrive roughly three times a year on a cycle of about 14 weeks, so the calendar needs a scheduled review. Ask the vendor how long it backports patches after upstream end of life, and whether that date is in writing.
Upgrade plan
Write down the rule the team will follow: upgrade kube-apiserver one minor version at a time, then the controller manager, scheduler and kubelets. The version skew policy allows kubelets to run up to three minor versions behind the API server, which sets the outer limit on how far a node pool can lag. Record which add-ons, CNI plugins, CSI drivers and ingress controllers must be checked against each target version, and which deprecated APIs in your manifests must be fixed first. Rehearse every upgrade in a staging cluster that matches production, and attach the results to the change record before production work is scheduled.
Contract and licensing record
Keep one record per distribution or support agreement. Include the covered versions, support start and end dates, renewal and notice deadlines, and the named contacts for severity-one escalations. Confirm in writing whether the license allows offline updates, meaning patches and images can be mirrored into an air-gapped environment and applied without vendor connectivity. Note whether support covers the add-ons you run, not only the core distribution, and what happens to support when a minor version reaches end of life. Review the record at each renewal and whenever the upstream calendar changes.
Runbook and evidence
Store the decision record with the options assessed, the selection criteria, the conformance evidence for the chosen distribution, and the test results from the first cluster build. Name an owner for each runbook covering installation, upgrades, etcd backup and restore, certificate rotation and vendor escalation. Hand over to the platform team with a walkthrough of each runbook, access to the records, and a restore drill they run themselves without the implementation team present. Keep conformance and scan output together so auditors can trace a finding to a decision and a named owner.
Questions teams ask before choosing a Kubernetes distribution
Is a CNCF conformant Kubernetes distribution enough to choose on?
No. Conformance shows that a distribution implements the Kubernetes APIs the conformance program checks, and the CNCF program lists over 90 certified offerings, so it works as a floor for comparison. It says little about how long a vendor supports each minor release, how the platform installs without internet access, what licensing applies, which add-ons ship with it, how identity and admission controls are integrated, or what your staff must run afterwards. Score each candidate on those points in writing, and test the ones that matter most in a lab that resembles your target environment.
How does a vendor's support window relate to upstream patch support?
The vendor's window is what you actually receive, and it is set separately from upstream. The Kubernetes project maintains only the three most recent minor releases, and minor releases from 1.19 onward receive about one year of patch support, roughly 14 months including the pre-release period. A vendor may support a minor release longer by backporting fixes, or for a shorter period, and may deliver security fixes on its own schedule. Ask which upstream minor each build is based on, how long each minor receives fixes, how backports are tested, and what happens when upstream reaches end of life for a version you run.
Can an in-house team run the distribution selection without outside help?
Many in-house teams can, if they have clear requirements, a named owner and time to test. The work is mostly comparison and verification: reading lifecycle and licensing terms, checking air-gapped installation steps, building a test cluster, and confirming identity, backup and upgrade behavior. Outside help is most useful when the team lacks recent Kubernetes operations experience, when the candidate list is long, or when independent evidence is needed for an assessment. DeployOpen plans and runs selection work as fixed-scope engagements, with scope and deliverables agreed in writing before work starts.
What does a distribution selection need from our team?
Three things: named owners, a lab, and network access. Name a platform lead who makes the technical call, a security owner for control requirements, a contact for identity and networking, a procurement contact and an approver. Provide a lab environment in your own cloud account, data center or isolated network, sized close enough to production to expose installation and upgrade issues. Give the work access to the target network, including DNS, package and container registries, proxies, load balancers and the identity provider. Without these, the selection stalls at the point where vendor claims must be tested.
How long does choosing a Kubernetes distribution take, and what drives it?
The duration depends on the written scope and constraints, so ask for a timeline tied to a defined scope. The main drivers are the number of candidates, whether a proof of concept runs in your environment or only on paper, how deep air-gapped and identity testing goes, how many compliance evidence items must be produced, and how long your procurement and approval cycles take. Requirements that are still undecided add time, as do vendors that need trial access or licensing discussions. Ask any provider to state assumptions, the deliverables at each stage and the dependencies on your team in the written scope.
Can we switch distributions later, and what would that involve?
Yes, but a switch is a migration with its own plan and cost. Application manifests and container images usually carry over, but cluster-specific parts need rework, including ingress, storage classes, identity configuration, admission policies, operators, Secrets handling and backup jobs. Stateful data needs its own move and cutover plan, and a rollback path must exist before cutover. You can lower the cost of a later exit by keeping manifests in version control, limiting dependence on vendor-specific resources, and documenting etcd backup and restore steps. The migration page covers the move itself, the upgrades and support page covers lifecycle, and the cost of ownership page covers recurring spend.
How DeployOpen works on this
DeployOpen helps teams choose between upstream kubeadm, a certified vendor distribution and a managed service, then implements the option they pick inside their own infrastructure. The work is scoped in writing before it starts, so the decision is tested against your conformance, air-gap, licensing and skills requirements rather than assumed.
How we scope
- Written scope lists the candidate distributions, the requirements each must meet, and the environments they will run in.
- Requirements cover conformance to the CNCF Certified Kubernetes program, air-gapped operation, and the Kubernetes minor releases you need to stay within.
- Scope states who runs each platform tier afterward, so skills gaps in your team are identified before a distribution is chosen.
How we build
- We build a small proof cluster per shortlisted option to check installation, API compatibility and day-two operations in your environment.
- Control plane designs follow the kubeadm high availability guide, with three or more control plane nodes behind a TCP load balancer on port 6443.
- Each option is tested for upgrade paths within the three supported minor releases, including the one-minor-version-at-a-time rule for kube-apiserver.
How we hand over
- Deliverables include a written comparison, the chosen distribution's build runbook, and the configuration used in the proof cluster.
- Documentation records etcd backup with etcdctl snapshot save and restore with etcdutl, so your team can run the procedures without us.
- Handover covers the open decisions still needed, such as licensing terms, support contracts and the owner for each upgrade cycle.
How we support
- Engagements are fixed-scope, so the support boundary is written down at handover rather than assumed.
- Ongoing support, upgrades and continuous testing for the chosen distribution are available as a retainer.
- Before any retainer starts, confirm with the vendor which Kubernetes versions and add-ons its support terms cover.
