Kubernetes Support Options: Community, Cloud, Vendor or Independent

Kubernetes has no vendor. Kubernetes support comes from the Kubernetes community for the three most recent releases, from cloud providers for their managed Kubernetes service, from distribution vendors such as Red Hat for their own platform, and from independent providers for the clusters and workloads that none of those cover. Each source supports a different layer, and most production incidents fall between the layers.

What the Kubernetes project supports

Kubernetes is an open source project under the Cloud Native Computing Foundation (CNCF). Its releases page states that the Kubernetes project maintains release branches for the most recent three minor releases, and that Kubernetes 1.19 and newer receive approximately one year of patch support. At the time of writing those are 1.37, 1.36 and 1.35, with end of life dates of 28 October 2027, 28 June 2027 and 28 February 2027. End-of-life versions of Kubernetes no longer receive security updates or bug fixes.

One year is short for an infrastructure platform, and with three releases a year a cluster falls out of the maintained set quickly. Community support is documentation, Slack, GitHub and the forums. The Kubernetes community is generous and owes nobody a response during an outage.

Managed Kubernetes services

Amazon EKS, Azure AKS and Google GKE run the Kubernetes control plane for you: the API server, etcd and the scheduler. The cloud provider supports that managed Kubernetes service under your cloud support plan, and each keeps its own version calendar, which is separate from the upstream project. Providers typically support a Kubernetes version for a fixed period after they release it, and then either upgrade the cluster automatically or move it to a paid extended support period. Check your provider's current policy for the versions you run, because the date that matters is theirs, not the project's.

What the provider does not support is everything you deploy on the cluster: your workloads, Helm charts, operators, ingress controllers, service mesh, container images, and the way your pods use compute, storage and the network. Worker nodes sit in between, managed to a degree that depends on the node type you chose.

Distribution vendors

Red Hat OpenShift, SUSE Rancher, VMware Tanzu and Mirantis sell a certified Kubernetes distribution with their own lifecycle and a support contract. That is real vendor support for the platform, tied to the vendor's versions and components. It still stops at the platform boundary. A RabbitMQ cluster that loses quorum during a node drain, or a database whose persistent volume will not reattach, is a workload problem that a platform vendor will triage and hand back.

The Kubernetes incidents that actually page people

• Pods stuck Terminating or Pending. A node goes NotReady, the pod on it cannot be confirmed dead, and its volume stays attached, so the replacement pod cannot schedule. Force-deleting is the obvious move and the dangerous one for stateful workloads, because two instances can end up writing the same disk.
• Node drains that break quorum. A PodDisruptionBudget that looks safe still allows a drain while another member is restarting. The upgrade tooling reports success and the clustered application has lost its majority.
• OOMKilled containers. The container is killed at its memory limit while the application believes it has headroom, because the runtime sized itself from node memory, or because off-heap memory and page cache were never counted. JVM workloads are the classic case.
• Failed cluster upgrades. An API version that was removed in the new release is still used by a Helm chart or an operator, admission webhooks block the API server, or the version skew between control plane and kubelets is exceeded. Upgrades need a preflight, not optimism.
• Storage that cannot keep up. A default storage class with burst credits or low IOPS throttles at the worst moment. Databases and brokers stall on fsync while CPU and memory look fine.
• Networking and DNS. A default-deny NetworkPolicy blocks cluster-internal ports, CoreDNS is overloaded, conntrack tables fill, or a service mesh sidecar intercepts traffic it should leave alone.
• etcd and control plane pressure. On self-managed clusters, slow disks under etcd or too many objects and watches make the whole Kubernetes API sluggish, and every controller suffers at once.

Staying on a supported version

Kubernetes only supports upgrading one minor version at a time, so a cluster three releases behind needs three upgrades, each with its own API deprecations to clear. The removal of dockershim in 1.24 is the best-known example of a change that caught teams out: Docker-built container images still run, but clusters that depended on Docker Engine as the container runtime had to move to containerd or CRI-O first. The best practices are consistent. Scan manifests and Helm releases for deprecated APIs before each upgrade, keep operators and ingress controllers within their own supported version matrix, upgrade a non-production environment first, and treat the upgrade as a scheduled event three times a year, not an emergency once every three years.

Where independent Kubernetes support fits

• Self-managed clusters, on-premises or on virtual machines in a public cloud, including versions outside the upstream support window.
• Stateful workloads on any cluster: message brokers, databases, caches and search, where the platform vendor and the cloud provider both stop.
• Small platform teams that cannot staff 24/7 cover for a production environment. A cluster run by two engineers has a staffing single point of failure.
• Upgrade planning and execution, across the cluster and the operators, charts and workloads that must move with it.

AceMQ provides 24/7 Kubernetes support on EKS, AKS, GKE, OpenShift and self-managed clusters, with a 15-minute emergency SLA and named senior engineers, and particular depth in stateful workloads. Related reading: what breaks when you run messaging on Kubernetes, Kafka on Kubernetes and the RabbitMQ on Kubernetes guide. For how this window compares with other technologies, see support windows compared.