Kubernetes Lifecycle: End Of Life And Support Status

Last updated on February 26, 2025

Kubernetes is an open-source automation platform used for running and managing container applications from many container runtimes. It has a server-client relationship that is used by DevOps teams for container orchestration.

Support status guide

End of life (EOL) is the end of a product’s useful life. When a product reaches the end of its life cycle, the manufacturer no longer supports it. The following table explains the different phases of a product’s lifecycle. Testing status is when the product is initially released and EOL is when product support is no longer offered. The time between these two points is the support timeframe.

Testing

The software is not yet publicly available. It is in testing phase i.e., alpha, beta, release preview etc.

Active

The software is actively supported by the vendor.

Phasing Out

The software will soon reach its end of life. You need to look for upgrade or migration options. The software will automatically go into phasing out status 2 months before end of life.

End Of Life

The software is no longer supported by the vendor. You need to make sure your system and environment are safe.

Version

Released

Active Support

Maintenance Support

Kubernetes follows the semantic versioning policy, which means that it has major releases, minor releases, and patch releases. Which is why it has a versioning as “Major.Minor.Patch”.

In 2020 after the pandemic hit, Kubernetes shifted to a 15-week release cycle, which meant that there will be now 3 (minor) updates per year. Before this, Kubernetes followed a release cadence of 4 releases per year. You can learn more about the Kubernetes release cadence.

Each Kubernetes version is supported for 14 months in total, out of which 2 months are the upgrade period, and receives 12 months of active support. When combined with a 25-week release cycle, it means that at a time, 3 Kubernetes versions are actively supported.

Fixes and security updates may or may not be backported to the older supported versions of Kubernetes. The decision for these patch releases lies with the Release Managers group – which refers to the Kubernetes contributors.

Due to the client-server design of Kubernetes, the supported component upgrade sequence is also determined by the supported version skew between the client and the server.

Talk to us now

Talk to us straight and get your questions answered right away

Tell Us About Your Project