The Kubernetes Release Cycle

You are running Kubernetes 1.28 in production. Your clusters have been stable for months. Then your security team sends a message: "Kubernetes 1.31 is out. Are we on a supported version?"

You freeze. You know 1.28 has been working fine. But "working fine" and "supported" are two different things. If a CVE drops tomorrow for a version that is no longer receiving patches, "working fine" becomes "actively vulnerable."

Before you can answer the security team, before you can plan an upgrade, you need to understand how Kubernetes releases work, and how the support window determines when your cluster goes from "stable" to "abandoned."

---

Part 1: How Kubernetes Ships Software

Kubernetes follows a predictable release cadence. Once you understand the rhythm, you can plan upgrades months in advance instead of scrambling when support ends.

Three Releases Per Year

The Kubernetes project ships three minor releases per year, roughly every four months. The approximate schedule:

Release Window	Typical Month
First release	February/March
Second release	June/July
Third release	October/November

Each minor release (1.28, 1.29, 1.30) brings new features, deprecations, and bug fixes. Patch releases (1.28.1, 1.28.2) follow as needed, typically every two weeks, containing only bug fixes and security patches.

The Support Window

Each minor release enters a patch support window of approximately 14 months (extended from 12 months in 2020). During this window:

• Critical bug fixes are backported
• Security patches (CVEs) are backported
• No new features are added to older releases

Once the window closes, the release is end-of-life (EOL). No more patches, no more security fixes, nothing. You are on your own.

Here is how the support windows overlap:

There Is No LTS

If you come from the Linux world, you might expect a Long-Term Support (LTS) release, a version that gets patches for 5+ years. Kubernetes does not have LTS. Every release gets the same 14-month window, then it is done.

This has major implications:

• You must upgrade at least once every 14 months to stay on a supported version
• You cannot "skip" to a comfortable version and stay there for years
• Compliance frameworks (SOC 2, PCI-DSS, HIPAA) that require "supported software" mean you need an upgrade cadence

---

Part 2: Reading the Release: What Changed and What Broke

Every Kubernetes release comes with a set of artifacts that tell you what changed. Knowing how to read them is a critical skill.

The Changelog

Every release publishes a CHANGELOG.md in the Kubernetes repo. It is long, often thousands of lines. The sections that matter for upgrade planning:

1. Urgent Upgrade Notes: read these first. They describe breaking changes that require action before upgrading.
2. Deprecations: APIs, flags, or features marked for future removal.
3. API Changes: new, modified, or removed API resources.
4. Bug Fixes: occasionally a fix changes behavior you were relying on.

# Quick way to see what changed between versions
# Visit: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md

# Or use kubectl to check available API versions
kubectl api-versions | sort

# Check for deprecated API usage in your cluster
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

Kubernetes Enhancement Proposals (KEPs)

Major features go through the KEP process. Each KEP documents:

• Motivation: why the change exists
• Design: how it works
• Migration plan: how to adopt it

For upgrade planning, KEPs matter when a feature moves from beta to stable (defaults change) or when a feature gate you relied on is removed.

Feature Gates: Alpha, Beta, Stable

Every new feature in Kubernetes goes through a lifecycle:

Stage	Default	Meaning
Alpha	Disabled	Experimental. May be removed entirely. Never use in production.
Beta	Enabled (since 1.24: disabled by default)	Mostly stable. API may change.
Stable (GA)	Enabled, cannot be disabled	Production-ready. Feature gate is removed.

Deprecation Policy

Kubernetes has a formal deprecation policy that dictates how long deprecated features remain available:

• GA APIs: must be supported for at least 12 months or 3 releases (whichever is longer) after deprecation
• Beta APIs: must be supported for at least 9 months or 3 releases after deprecation
• Alpha APIs: can be removed in any release without notice

This policy is your friend. It means you have advance warning before something breaks, but only if you are reading the deprecation notices.

---

Part 3: When to Upgrade

Not every release demands immediate action. Here is how to decide.

Upgrade Immediately: Security CVEs

When a CVE is announced for your Kubernetes version, upgrade to the latest patch release as soon as possible. Critical CVEs (CVSS 9.0+) affecting the API server or kubelet should be treated as emergencies.

# Check your current version
kubectl version --short

# Check for available patch releases
# Visit: https://kubernetes.io/releases/patch-releases/

# Example: if you are on 1.29.2 and 1.29.5 fixes a critical CVE,
# upgrade to 1.29.5 immediately (patch upgrades are low-risk)

Upgrade Within 1-2 Months: New Minor Releases

When a new minor release ships (e.g., 1.31.0), do not upgrade on day one. The .0 release often has rough edges that get fixed in .1 and .2. A practical timeline:

1. Week 0: Release ships. Read the changelog and upgrade notes.
2. Weeks 1-4: Upgrade dev/test clusters. Run your test suite.
3. Weeks 4-8: Upgrade staging. Soak test for 1-2 weeks.
4. Weeks 6-10: Upgrade production.

The Cost of Falling Behind

The most dangerous thing you can do is fall 2+ minor versions behind. Here is why:

• You must upgrade one minor version at a time. You cannot jump from 1.27 to 1.30 directly.
• Each hop requires its own testing cycle. That is 3 separate upgrade cycles.
• Deprecated APIs accumulate. Two versions of deprecations compound.
• The further behind you are, the more painful each hop becomes.

---

Part 4: Practical: Checking Your Current State

Before you can plan an upgrade, you need to know exactly where you stand.

# Control plane version
kubectl version -o json | jq '.serverVersion.gitVersion'
# "v1.28.4"

# Kubelet versions across all nodes
kubectl get nodes -o json | jq -r '.items[] | "\(.metadata.name) \(.status.nodeInfo.kubeletVersion)"'
# node-1 v1.28.4
# node-2 v1.28.4
# node-3 v1.28.3  <-- this node is behind!

# Check which versions are currently supported
# Visit: https://kubernetes.io/releases/
# Or: https://endoflife.date/kubernetes

# Check for deprecated API usage
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

---

Key Concepts Summary

• Kubernetes ships 3 minor releases per year, roughly every 4 months (February, June, October)
• Each release gets ~14 months of patch support: after that, no security fixes, no bug fixes, nothing
• There is no LTS: you must upgrade at least once every 14 months to stay supported
• Patch upgrades (1.29.2 to 1.29.5) are low-risk and should be applied quickly for security fixes
• Minor upgrades (1.29 to 1.30) require planning, never upgrade on day one of a .0 release
• You must upgrade one minor version at a time, skipping versions is not supported
• Falling 2+ versions behind compounds the pain, each hop requires its own testing cycle
• Feature gates progress through alpha, beta, and stable, since 1.24, beta features are disabled by default
• The deprecation policy gives you advance warning, start migrations when APIs are deprecated, not when removed

Common Mistakes

• Assuming "working fine" means "supported", your cluster runs fine on an EOL version until a CVE drops and there is no patch
• Upgrading to a .0 release in production, wait for at least .1 or .2 to shake out early bugs
• Confusing managed Kubernetes extended support with upstream support, provider extensions have caveats and sometimes extra costs
• Ignoring deprecation notices because "removal is far away", two releases pass faster than you think
• Not checking kubelet versions across all nodes, one lagging node can cause subtle scheduling issues
• Treating minor version upgrades like patch upgrades, they have fundamentally different risk profiles

---