--- title: "What is Kubernetes version support?" canonical: https://enum.co/learn/what-is-kubernetes-version-support locale: en topic: Kubernetes publishedAt: 2026-10-30 updatedAt: 2026-10-30 author: "Max Heyer" summary: "Kubernetes version support is the period in which a minor release still gets patches and security fixes, about 14 months for each release." --- # What is Kubernetes version support? Kubernetes version support is the period in which a minor release still gets patches and security fixes, about 14 months for each release. After reading this you will be able to: - Read a Kubernetes version as major, minor and patch - Explain how long a minor release receives patches - Plan upgrades before a cluster falls out of support ## What is Kubernetes version support? Kubernetes version support is the time during which a minor release still receives patch releases with bug and security fixes. Kubernetes maintains release branches for the three most recent minor releases. Each one gets about 14 months of patches, and after that it reaches end of life and no new fixes ship for it. Think of a phone that gets software updates for a fixed number of years. It keeps working after the last update, but every new security hole stays open. A cluster on an end-of-life Kubernetes version is in the same state. ## How are Kubernetes versions numbered? A version such as 1.37.1 has three parts: major, minor and patch. The major version is 1. The minor version is where new features, deprecations and API removals land. ### Minor releases A new minor release comes out roughly every four months, three per year. Each one can change behaviour, so moving from one minor to the next is an upgrade you plan and test. ### Patch releases Patch releases fix bugs and security issues inside one minor release. They usually ship monthly, with extra releases for critical fixes. A patch upgrade should not change APIs, so it is lower risk than a minor upgrade. ## How long does a release get patches? Each minor release has about 12 months of normal patch releases. It then enters a two-month maintenance mode, where fixes are limited to vulnerabilities with a CVE ID, dependency and base image issues, and critical bugs in core components. After those 14 months the release is end of life. With three releases a year and three branches maintained, a cluster that skips upgrades for about 14 months falls out of support. ## Why can't you skip versions? The API server must not skip minor versions when it is upgraded. Going from 1.35 to 1.37 means upgrading to 1.36 first, then to 1.37. A cluster that is three versions behind needs three upgrades in a row to catch up. ### Version skew Components in one cluster may run different versions for a while, within limits: - The kubelet on a node must not be newer than the API server, and may be up to three minor versions older. - kubectl is supported within one minor version of the API server, older or newer. - The control plane is upgraded first, then the nodes. A node is drained before its kubelet moves to a new minor version. ### API removals Minor releases can stop serving deprecated beta APIs. A beta API keeps being served for at least 9 months or 3 minor releases after its deprecation, whichever is longer. Before an upgrade, check your manifests and Helm charts for APIs that the target version removes. ## How enum handles Kubernetes version support [enum Kubernetes Engine](/kubernetes-engine) supports the three most recent Kubernetes minor releases, the same window the upstream project supports. enum applies patch releases for you and runs minor upgrades node by node, so replicated workloads keep serving while each node is replaced. ## FAQ **What happens when my Kubernetes version reaches end of life?** The cluster keeps running, but it gets no new bug or security fixes. Catching up later means one minor upgrade for every release you missed, done in order, with API removals to check at each step. **How often should I upgrade a cluster?** Plan for one minor upgrade every four months to stay current with the release cadence. At the very least, upgrade before your version reaches end of life, which comes about 14 months after its release. **Is a patch upgrade the same as a minor upgrade?** No. A patch upgrade such as 1.37.0 to 1.37.1 fixes bugs and security issues without changing APIs. A minor upgrade such as 1.36 to 1.37 can add features and remove deprecated APIs.