Why Kubernetes Needs an LTS: Stability in a Fast-Moving Cloud Native World
Kubernetes has transformed how we build, deploy, and scale applications. It’s the powerhouse behind modern cloud-native infrastructure – including our own c12n Private Cloud. But while Kubernetes moves fast, not everyone can keep up with its release velocity.
By the way, if you’re new to our blog and not yet familiar with Kubernetes yet, feel free to check out our other articles where we explain kubernetes basics and multi-tenancy in more depth. We’ve got you covered!
With three major releases a year and support lifecycles that last just over a year, many companies find themselves constantly scrambling to upgrade. This can cause disruptions, increase operational costs, and add complexity that distracts from actual business value. That’s why there’s a growing call within the community: Kubernetes needs a Long-Term Support (LTS) version.
But before we go further, let’s zoom out for a moment and look at what LTS really is — and what the current Kubernetes support policy (N-2) looks like in practice.
What is LTS (Long-Term Support)?
LTS (Long-Term Support) is a software release model where a version is maintained and supported for an extended period, typically 3 to 5 years or even longer.
Key characteristics of LTS:
- Security patches and bug fixes are provided for a long time.
- No major feature changes, which means fewer potential disruptions.
- Ideal for production environments where stability matters more than new features.
- Some examples:
- Ubuntu 22.04 LTS is supported for 5 years (until 2027).
- Node.js LTS versions receive 30 months of support.
- Red Hat Enterprise Linux (RHEL) supports versions for up to 10 years.
- Ubuntu 22.04 LTS is supported for 5 years (until 2027).
So, if Kubernetes had an LTS, that would mean you’d get several years of guaranteed updates without needing to upgrade every year — perfect for enterprises and regulated industries where things tend to move slower. Currency, Kubernetes follows an N-2 support policy.
Kubernetes release cycle:
What is an N-2 Support Policy?
N-2 (read: “N minus 2”) is a version support policy that means the system or tool supports:
- the current version (N),
- the previous version (N-1),
- and the one before that (N-2).
Applied to Kubernetes:
Kubernetes currently releases 3 new versions per year coming out every 4 months. Under the N-2 policy, each version is supported for approximately 12-14 months.
Example:
- If the current version is 1.33, then Kubernetes will support
- 1.33 (N)
- 1.32 (N-1) and
- 1.31 (N-2)
- Version 1.30 is EOL (End-of-life) on the 2025-06-28
- All EOL releases do not receive updates, not even security fixes.
This policy is what pushes teams to upgrade at least once a year, even if their workloads are stable and working fine. It’s one of the key reasons people are calling for an LTS release – to avoid this rapid upgrade treadmill.
| N-2 Policy | LTS Model | |
|---|---|---|
|
🔁 Upgrade Pace |
Every ~12–14 months
|
Every 3–5 years, with more frequent security updates
|
|
🛠️Maintenance |
High (frequent upgrades)
|
Lower (long-term support)
|
|
🏢 Enterprise Fit |
❌ Challenging for stability
|
✅ Ideal for production systems |
|
🚨 Risk |
Higher if upgrades are delayed |
Lower due to extended coverage |
The Upgrade Hamster Wheel
Kubernetes currently has just about a 1-year support window for each version. That means even a version released just over a year ago is already nearing end-of-life. For large organizations running mission-critical workloads, this creates a relentless cycle of upgrades, patches, and migrations — often without delivering new features that are actually needed.
Upgrades in Kubernetes in the most recent versions have become much easier and less disruptive, yet they are not trivial. All changes in APIs, deprecations, or behavior tweaks require testing and adaptation. And when you’re running tens and hundreds of clusters in production — risk mitigation takes time. The result? DevOps teams spend lots of time managing Kubernetes.
What an LTS Could Offer
A Long-Term Support (LTS) version of Kubernetes would significantly reduce operational overhead and increase adoption among more conservative industries (finance, healthcare, public sector) that value stability over cutting-edge features.
Key benefits could include:
- Extended Security Support: Fixes for CVEs and security patches for 3-5 years.
- Reduced Upgrade Churn: Less time and money spent testing and migrating.
- Reduced Operational Overhead: Frequent Kubernetes upgrades are operationally expensive
- Encouragement of Best Practices: Allowing operators to focus on building robust systems instead of racing to keep up.
- Strategic Flexibility for Mixed Workloads: Not every Kubernetes cluster serves the same purpose. Some environments (e.g. DEV or UAT) may benefit from fast access to new features. Others (e.g. PROD) demand maximum uptime and stability. An LTS allows teams to adopt a mixed-version strategy: fast lanes for innovation, and slow lanes for mission-critical apps.
In fact, many managed Kubernetes services already try to simulate this. Azure Kubernetes Service (AKS), for example, offers extended support for older versions through their own mechanisms. But these are vendor-specific band-aids, not a community-wide solution.
But Wouldn’t This Slow Down Innovation?
Not necessarily. Most successful open source ecosystems support both fast and slow tracks. Take Ubuntu: it has regular releases every 6 months, but also LTS versions every 2 years that are supported for 5-10 years. This model balances the needs of developers and enterprises alike.
An LTS release for Kubernetes wouldn’t need to replace the current cadence. It would just add an option for users who prioritize stability. Contributors and vendors can continue iterating at full speed — while offering a more sustainable path for users who need it.
Kubernetes Is Growing Up — And That Means Growing Pains
At Cloudification, we’ve seen this tension firsthand when helping customers migrate to Kubernetes-based environments. The platform is powerful — especially when paired with open infrastructure like Ceph, OpenStack and ArgoCD as in our c12n solution.
Enterprise users, especially those moving away from proprietary platforms like VMware, often want a stable, open, vendor-neutral platform they can rely on for years. Kubernetes has the potential to be that — but only if we make it sustainable.
Final Thoughts
The cloud native ecosystem has matured a lot over the last 5 years. The next step is to make it a bit “boring”, meaning: Predictable. Reliable. Unexciting in some of the ways. An LTS version of Kubernetes would be a great piece of that puzzle.
A Kubernetes LTS release wouldn’t just make life easier for operators — it would reduce risk, lower operational costs, and help teams align infrastructure with the enterprise business needs.
At Cloudification, we’ve seen firsthand how challenging it is for organizations to keep up with the Kubernetes release treadmill — especially in larger, multi-tenant or highly regulated environments. That’s why we’re advocating for an LTS strategy: because stability is a feature.
