Executive Summary
A Kubernetes platform is chosen for the years after the first cluster: how long each version is supported, who performs the upgrades, and how many clusters one team can run.
A Kubernetes platform is the product that installs, upgrades, secures and supports Kubernetes clusters for you, whether as a cloud service or as software you run. Choose one on three things: where your clusters must run, how long each Kubernetes version is supported and who performs the upgrades, and how the platform manages many clusters as one fleet. The orchestrator underneath is the same open-source project, so it rarely separates them.
Upgrades are the recurring cost. The Kubernetes project maintains release branches for the most recent three minor releases. The Kubernetes project states that Kubernetes 1.19 and newer receive approximately 1 year of patch support. A cluster that stays on one version needs a vendor that supports it longer, and that support is often priced separately. The version-support section below sets out each vendor’s published window.
The eight vendors here fall into five approaches: a managed service in one public cloud, an enterprise distribution sold self-managed or managed, Kubernetes built into a private cloud stack, multi-cluster management across distributions, and an open-source distribution with its own cluster manager. Start from where your clusters must run, then compare support windows and fleet tools on your own upgrade calendar.
Why Version Support and Conformance Shape the Choice
The Kubernetes project states that Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. The Kubernetes project states that Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important. Networking, ingress, storage, monitoring, policy and upgrades are assembled around it, and a Kubernetes platform is a decision about who assembles and maintains them.
Each Kubernetes upgrade has rules. The Kubernetes project states that the kubelet may be up to three minor versions older than kube-apiserver. So the control plane is upgraded first and the nodes follow, cluster by cluster. The Kubernetes project states that beta API versions are deprecated no more than 9 months or 3 minor releases after introduction (whichever is longer), and are no longer served 9 months or 3 minor releases after deprecation (whichever is longer). An application that still calls a removed API version breaks at the upgrade, so every upgrade starts with a check of the manifests and Helm charts that run on the cluster.
Conformance keeps the choice reversible. CNCF states that software conformance ensures that every vendor's version of Kubernetes supports the required APIs, as do open source community versions. CNCF states that, for organizations using Kubernetes, conformance enables interoperability from one Kubernetes installation to the next and allows them the flexibility to choose between vendors. CNCF states that, to remain certified, vendors need to provide the latest version of Kubernetes yearly or more frequently. CNCF states that 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. Ask each vendor for its current certification and run the conformance tests on a cluster you build during the evaluation.
Security policy is part of the platform. The Kubernetes Pod Security Standards define a Privileged policy, which is unrestricted and allows for known privilege escalations; a Baseline policy, which is minimally restrictive and prevents known privilege escalations; and a Restricted policy, which is heavily restricted and follows current Pod hardening best practices. Ask which policy each platform enforces by default, and how exceptions are approved for workloads that need more privileges.
Fleet management has an open-source reference point. The Kubernetes Cluster API project describes Cluster API as a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters. Ask each vendor whether its fleet tools use Cluster API, and whether they manage clusters the platform did not create.
Upstream, Distribution or Managed Service
Upstream Kubernetes is free, and tools such as kubeadm install it. Your team then owns every upgrade, patch and add-on, and answers for the cluster when it fails. That suits teams with deep Kubernetes skills and few clusters.
A managed cloud service runs the control plane for you, and you still choose and maintain most add-ons. An enterprise distribution comes with its add-ons tested together and supported by one vendor, on infrastructure you run or as a managed service. A multi-cluster manager adds one console and one policy model across clusters from several sources.
Most large organizations end up with more than one. A cloud service runs the cloud workloads, a distribution runs the data center and edge sites, and a fleet manager ties them together. Decide which clusters each layer will own before comparing vendors.
| Need | What it answers | Where it is bought |
|---|---|---|
| Run Kubernetes clusters | Control plane, nodes, upgrades and support for each cluster | This guide |
| Developer self-service | Templates, golden paths and a portal on top of clusters | Internal Developer Platform guide |
| Deploy applications from Git | Declarative delivery and drift correction across clusters | GitOps Platform guide |
| Service-to-service traffic and security | mTLS, traffic policy and telemetry between services | Service Mesh guide |
| Run virtual machines | Hypervisor, VM migration and VM operations | Virtualization Platform guide |
How Long Does Each Kubernetes Platform Support a Version?
Upstream Kubernetes supports each minor release for about a year. Vendors extend that window, and several charge for the extension or put it in a higher tier.
In the public clouds, support runs about one to two years. AWS states that a Kubernetes version is under standard support for the first 14 months after it is released in Amazon EKS, and then enters extended support for the next 12 months for an additional cost. AWS lists a price of $0.60 per hour for each Amazon EKS cluster running on a Kubernetes version covered under extended support. Microsoft states that AKS provides one year of community support, followed by one additional year of long-term support. Microsoft states that enabling LTS requires moving your cluster to the Premium tier and explicitly selecting the LTS support plan. Microsoft states that starting on June 1, 2027, AKS automatically upgrades any cluster that stays on an unsupported Kubernetes version after its 60-day platform support grace period ends. Google Cloud states that GKE provides at least 14 months of standard support, and up to a total of 24 months of support with extended support.
Distributions for data centers publish longer windows. Red Hat states that, starting with Red Hat OpenShift 5, each OpenShift minor release receives 12 months of Full Support followed by 12 months of Maintenance Support, for a total of 24 months, and that designated Extended Life Cycle (ELC) releases are eligible for an optional add-on providing up to 36 additional months, for a total of up to 60 months from general availability. Broadcom states that it provides 24 months of support for each minor vSphere Kubernetes release. SUSE states that RKE2 is built for security-focused and regulated environments, that K3s is a lightweight distribution for the edge, and that both offer long-term support of up to 5 years.
The window matters less than the upgrade it postpones. A longer window gives a regulated workload time to test, and it also lets the gap to current Kubernetes grow. Plan to upgrade each cluster at least once a year, and use extended support for the clusters that cannot.
Upgrades can also be automated. Microsoft states that in AKS Automatic, Azure handles node management, scaling, security, monitoring, and upgrades automatically. Google Cloud describes GKE Autopilot as a mode of operation in which Google manages your infrastructure configuration, including your nodes, scaling, security, and other preconfigured settings. AWS states that with Amazon EKS Auto Mode you can fully automate Kubernetes cluster management for compute, storage, and networking. Automatic upgrades suit stateless services and teams that keep manifests current. Workloads that need a fixed maintenance window still need upgrade controls.
Data platforms on Kubernetes need storage that outlives a container. The Kubernetes project describes a StatefulSet as the workload API object used to manage stateful applications. The Kubernetes project states that, unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods. The Kubernetes project states that PVs have a lifecycle independent of any individual Pod that uses the PV. The Kubernetes project states that Kubernetes does not provide application-level services, such as middleware, data-processing frameworks, databases, caches or cluster storage systems, as built-in services. Databases, streaming platforms and Spark run on Kubernetes through operators and storage drivers that you or a vendor add. Test failover, backup and an upgrade with production-sized volumes before moving a data platform onto a cluster.
| Capability | What it does | Buyer translation |
|---|---|---|
| Version support window | How long each Kubernetes minor release gets fixes | Months of standard and extended support, and the price of the extension |
| Upgrade automation | Rolls control plane and nodes to new versions | Maintenance windows, surge settings and what happens when an upgrade fails |
| Fleet management | One console and API for many clusters | Clusters from other sources, policy across clusters, drift detection |
| Where clusters run | Public cloud, data center, edge and air-gapped sites | The same tools and support in every location you need |
| Security baseline | Pod security, image controls and identity integration | Default policy, CVE response time and audit evidence |
| Stateful workloads | Persistent volumes and storage drivers for data services | Tested storage, backup and failover for your databases |
| Virtual machines | VMs managed next to containers | Whether VMs and containers share one platform and one support contract |
Vendors in Kubernetes Platforms
Representative vendors include Amazon EKS (Elastic Kubernetes Service), Broadcom VMware Tanzu (vSphere Kubernetes Service), Google GKE (Google Kubernetes Engine), Microsoft Azure AKS (Azure Kubernetes Service), Mirantis (IREN), Red Hat OpenShift (IBM), Spectro Cloud and SUSE Rancher Prime. The list is alphabetical, is not a ranking, and is not for sale. How we choose vendors
The approaches below follow where each platform runs and who operates it. Several vendors sell products in more than one approach, so check which product a document or price applies to.
Ownership has changed at several of these vendors. Red Hat announced that IBM and Red Hat had closed the transaction under which IBM acquired all of the issued and outstanding common shares of Red Hat. Broadcom announced on Nov. 22, 2023 that it had completed its acquisition of VMware, Inc. SUSE announced the completion of its acquisition of Rancher Labs on December 1, 2020. IREN announced on August 4, 2026 that it had completed the acquisition of Mirantis, Inc. Nutanix announced that it has acquired D2iQ's Kubernetes Platform (DKP).
Three vendors run Kubernetes as a managed service in their own public cloud. AWS describes Amazon Elastic Kubernetes Service (Amazon EKS) as a managed Kubernetes service that lets you run Kubernetes applications without managing, securing, or scaling a Kubernetes control plane. AWS states that with Amazon EKS Hybrid Nodes you can use your on-premises and edge infrastructure as nodes in Amazon EKS clusters. Microsoft describes Azure Kubernetes Service (AKS) as a managed Kubernetes service for deploying and managing containerized applications. Google Cloud describes Google Kubernetes Engine (GKE) as a managed implementation of the Kubernetes open source container orchestration platform.
One vendor sells its distribution both as software and as a managed service. Red Hat states that Red Hat OpenShift is available as a managed application platform on the cloud provider of your choice. Red Hat states that Red Hat OpenShift Service on AWS is jointly operated and supported by Red Hat and AWS with a 99.95% uptime SLA, and that customers receive a single bill from AWS for both OpenShift and AWS consumption. Red Hat states that OpenShift Virtualization is built on the open source KVM hypervisor and is an operator included with any Red Hat OpenShift edition.
One vendor builds Kubernetes into its private cloud stack. Broadcom describes VMware vSphere Kubernetes Service (VKS) as the Kubernetes runtime built directly into VCF as a fully integrated component. Broadcom states that vSphere Kubernetes releases (VKr) were formerly known as Tanzu Kubernetes releases (TKr). The same vendor sells a separate application platform. Broadcom states that Tanzu Platform provides an Agentic PaaS with Spring AI integration, centralized MCP management, and identity-driven governance to scale AI safely in production.
Two vendors focus on managing many clusters from one place. SUSE states that SUSE Rancher Prime turns open source Rancher into an enterprise platform for hybrid environments, and that backported fixes, audit-ready evidence and 24/7 SUSE support come standard. SUSE states that SUSE Rancher Prime manages any CNCF-certified Kubernetes distribution, including SUSE's own RKE2 and K3s, managed services like Amazon EKS, Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE), and clusters you import from other distributions. Spectro Cloud describes Palette as a complete and integrated platform that enables organizations to manage the entire lifecycle of any combination of new or existing, simple or complex, small or large Kubernetes environments. Spectro Cloud states that Palette extends and integrates the CNCF open source Cluster API project. Spectro Cloud states that Palette supports both IaaS and managed Kubernetes services AWS EKS, Azure AKS, and Google GKE. Spectro Cloud states that Palette can be delivered as multi-tenant or dedicated SaaS, self-hosted in your data center, or completely air-gapped.
One vendor sells its own distribution and a separate cluster manager. Mirantis states that Mirantis Kubernetes Engine was formerly Docker Enterprise 3.1. Mirantis states that MKE is CNCF-certified, hardened by Mirantis, and secured with its own DISA STIG and FIPS 140-2 encryption. Mirantis states that Mirantis k0rdent delivers enterprise Kubernetes management control, with a single platform to deploy and scale clusters across all your infrastructure, from multi cloud and edge to bare metal. IREN states that the open-source k0rdent AI platform will continue to be developed and supported for Mirantis' customers.
Other platforms cover the same needs from different starting points. Nutanix states that Nutanix Kubernetes Platform (NKP) simplifies platform engineering by reducing operational complexity and establishing consistency across any environment. Platform9 states that Private Cloud Director allows enterprises to run Kubernetes clusters on virtual machines.
| Vendor | Approach | Where it fits |
|---|---|---|
| Red Hat OpenShift (IBM) | Enterprise distribution, self-managed or managed | Self-managed or managed on major clouds; 24 months per minor release, up to 60 with ELC; VMs included |
| Broadcom VMware Tanzu (vSphere Kubernetes Service) | Kubernetes in a private cloud stack | VKS built into VMware Cloud Foundation; 24 months of support per minor release |
| Amazon EKS (Elastic Kubernetes Service) | Managed service in one public cloud | $0.10 per cluster hour; 14 months standard and 12 months extended support; Auto Mode and Hybrid Nodes |
| Google GKE (Google Kubernetes Engine) | Managed service in one public cloud | Autopilot mode; $0.10 per cluster hour with a monthly free-tier credit; up to 24 months of support |
| Microsoft Azure AKS (Azure Kubernetes Service) | Managed service in one public cloud | Free control plane on the Free tier; AKS Automatic; long-term support on the Premium tier |
| Spectro Cloud | Multi-cluster management across distributions | Palette, built on Cluster API; SaaS, self-hosted or air-gapped |
| SUSE Rancher Prime | Multi-cluster management across distributions | Manages any CNCF-certified distribution; RKE2 and K3s with up to 5 years of support |
| Mirantis (IREN) | Open-source distribution with a cluster manager | Mirantis Kubernetes Engine (formerly Docker Enterprise) and the k0rdent cluster manager; owned by IREN since August 2026 |
Eight vendors are named, across five approaches; the field also includes other cloud providers, Linux vendors and private cloud platforms. The approaches were written before any vendor was selected, and a row here cannot be bought. Kubernetes platform vendors, whether named here or not, can describe their own products in the Spotlight below.
How much should you budget for Kubernetes Platforms?
Managed cloud services charge a fee per cluster, then bill the compute, storage and network the cluster uses. AWS lists a price of $0.10 per hour for each Amazon EKS cluster. Google Cloud lists a flat cluster management fee of $0.10 per cluster per hour for all GKE clusters, irrespective of the mode of operation, cluster size, or topology. Google Cloud states that the GKE free tier provides $74.40 in monthly credits per billing account, equivalent to one free Autopilot or zonal Standard cluster per month. Microsoft states that when you create an AKS cluster, Azure automatically creates and configures a control plane at no cost. For most fleets the cluster fee is small next to nodes, load balancers and data transfer.
Version support changes the fee. The extended-support rates and tiers in the version-support section apply per cluster, so a fleet that falls behind on upgrades pays them on every cluster still on an old version.
Distributions and fleet managers are sold as subscriptions on top of the infrastructure they run on. The distributions and fleet managers in this guide do not list prices on the product pages cited here, so ask for a quote and for the unit it counts: cores, nodes or clusters. Managed editions of a distribution may bill through your cloud account, which can count against committed cloud spend.
Ask each vendor for a three-year price at your expected cluster and node counts, the cost of extended or long-term support, and the uplift cap at renewal.
| Meter | You are charged for | Grows with | Where it goes wrong |
|---|---|---|---|
| Cluster fee | Each managed control plane, by the hour | Number of clusters | One cluster per team or environment multiplies the fee |
| Extended or long-term support | Clusters kept on an older Kubernetes version | Upgrade backlog | Clusters that miss an upgrade move to the higher rate |
| Nodes and compute | Virtual machines or Pod resources | Workload size and density | Unused requests and idle nodes billed in full |
| Subscription | Cores, nodes or clusters under a distribution or fleet manager | Fleet size | Large nodes raise the count where pricing is per core |
| Data transfer | Traffic between zones, regions and the internet | Architecture and traffic | Replicas spread across zones adding traffic charges |
How long does implementation take for Kubernetes Platforms?
Build the first cluster as a reference you can recreate from code, then add clusters only through that template.
Define the cluster as code: network plugin, ingress, storage classes, identity, pod security policy and monitoring. Run the conformance tests and a full upgrade before any application arrives.
Add GitOps delivery, secrets management, image scanning and admission policy. Write the upgrade runbook and test it on the reference cluster.
Move stateless services first. Move stateful services only after backup, restore and failover have been tested with production-sized data.
Upgrade every cluster on a fixed calendar, track clusters approaching the end of support, and remove clusters that no team owns.
What should you ask vendors about Kubernetes Platforms?
Ask each vendor to answer in writing and to demonstrate on one of your own applications.
-
Will most clusters run in one public cloud?Yes Start with that cloud’s managed service, and price its extended support for clusters you cannot upgrade every year.No Compare distributions and fleet managers that run in every location you need.
-
Do you also need to run virtual machines on the same platform?Yes Shortlist platforms that manage VMs and containers together, and test VM migration during the evaluation.No Keep virtualization out of the Kubernetes decision.
-
Will one team run more than a handful of clusters?Yes Add a multi-cluster manager to the shortlist and test it on clusters it did not create.No A single distribution or cloud service with its own console may be enough.