Kubernetes FAQ
Common questions about Kubernetes version support, upgrades, end-of-life dates, and migration paths.
The latest stable version of Kubernetes is 1.35.2. There are currently 3 actively supported versions and 17 versions that have reached end of life. Visit the Kubernetes Version Tracker on ReleaseRun for a complete breakdown of all versions, including release dates, support timelines, and end-of-life dates.
Each Kubernetes minor version receives approximately 14 months of patch support (extended from 12 months in 2022). This includes roughly 12 months of regular patch releases followed by 2 months of critical-only fixes. After that, no further patches are released.
Kubernetes components must run within certain version differences. The API server can be at most 1 minor version ahead of kubelets. kubectl can be within 1 minor version (older or newer) of the API server. This means you cannot skip minor versions when upgrading, you must go 1.30 to 1.31 to 1.32 sequentially.
Upgrade one minor version at a time (never skip versions). Before upgrading: check the release notes for deprecated APIs, run kubectl deprecations or the ReleaseRun K8s Deprecation Checker against your manifests, back up etcd, upgrade the control plane first, then worker nodes. In managed services (EKS, GKE, AKS), the provider handles control plane upgrades but you still need to update node pools.
When a Kubernetes API is deprecated, it means it will be removed in a future version. Starting from Kubernetes 1.19, the API server returns deprecation warnings in response headers when deprecated APIs are used. Tools like kubectl will display these warnings. You should update your manifests to use the replacement API before upgrading to the version where removal happens.
Not immediately. Wait at least 1-2 patch releases after a new minor version before deploying to production. This lets the community catch early bugs. For most teams, running the second-latest minor version (n-1) is the sweet spot: you get recent features and security fixes while avoiding brand-new version instability.
Managed Kubernetes providers (AWS EKS, Google GKE, Azure AKS) typically lag 1-3 months behind upstream Kubernetes releases. They also extend support beyond upstream EOL. GKE is usually fastest to offer new versions, followed by AKS, then EKS. Each provider may also backport security fixes to versions that are EOL upstream.
Run 'kubectl version' to see both client and server versions. For more detail, 'kubectl version --output=yaml' shows the full version info including git commit and build date. In managed clusters, check your cloud provider console for the control plane version.
Kubernetes Resources on ReleaseRun
Stay ahead of breaking changes
Get notified when Kubernetes versions reach end of life or have critical security updates.