LKE (Linode Kubernetes Engine) releases Kubernetes versions on a slightly modified schedule from upstream releases. This page outlines our Kubernetes versioning and life cycle policies on both LKE and LKE Enterprise so that you effectively plan, deploy, and maintain your applications on our platform.

Kubernetes versioning

Kubernetes releases new software versions and patches on a regular cadence. These updates are integrated into LKE after they are released on upstream Kubernetes, which ensures they are properly vetted. Kubernetes uses a semantic versioning system that includes three parts: x.y.z, where x is the major version, y is the minor version, and z is the patch version.

• Minor versions (ex: 1.31 to 1.32): Minor versions include new features and may make breaking changes or introduce incompatibilities.
• Patch versions (ex: 1.31.1 to 1.31.2): Patches are generally critical bug fixes, which include fixing security vulnerabilities.

In addition, Kubernetes versions for LKE Enterprise are appended with an LKE release version.

• LKE Enterprise release version (ex: v1.31.8-lke3): This number is incremented each time a Kubernetes version is upgraded within a patch release (and resets upon a new Kubernetes patch release). LKE release versions cover any individual LKE component upgrades needed due to bug fixes, security vulnerabilities, CVEs, and other updates.

Release notes for LKE are added when a new Kubernetes version is released and when we upgrade clusters with a patch version.

Version life cycle stages and cadence

These stages describe the Kubernetes version life cycle on Akamai’s LKE platform for each minor Kubernetes version release. To learn about upstream Kubernetes releases and support life cycles, see Kubernetes Release History.

Life cycle on LKE Enterprise

• Full support: 12 months (months 0-12). New minor versions are released on LKE Enterprise two weeks after the first patch release. So, 1.32 will be available on LKE two weeks after 1.32.1 is released on upstream Kubernetes. Subsequent patch versions are released on LKE Enterprise shortly after their upstream release.
• Maintenance support: 2 months (months 12-14). During this time, critical bug fixes and security patches are applied. Customers are encouraged to upgrade their clusters to a newer Kubernetes minor version during this support phase.
• End of life (EOL): 14 months after initial release. At this point, no new upgrades will occur on this minor Kubernetes versions. It is highly recommended that customers upgrade their clusters to a newer Kubernetes minor version before the existing version reaches EOL. That said, LKE Enterprise clusters are not force-upgraded.

Life cycle on LKE (non-enterprise)

• Full support: ~9 months (months 0-9). The full support stage begins when the Kubernetes version is released on LKE. New versions of Kubernetes are released on LKE typically within 4-8 weeks of the Kubernetes upstream release. Full support ends soon after regular security maintenance releases are stopped for the upstream Kubernetes version. This typically lasts 9 months (36 weeks). During this period, patch versions are quickly released on LKE following the upstream releases.
• Deprecated ~3 months (months 9-12). Once regular security releases are stopped on the upstream Kubernetes version, the version enters the deprecated stage. When a version is deprecated, it is removed from the Cloud Manager and Linode API and is no longer available for new LKE cluster deployments. This stage lasts 12 weeks. If you are using a Kubernetes version that’s marked as deprecated, you will be notified. We highly recommend customers upgrade their Kubernetes version at this time – before it reaches EOL.
• End of life (EOL): ~1 year after initial release. A Kubernetes version marked EOL is removed from our platform. As we strive to maintain a safe and compliant managed Kubernetes service, any clusters still remaining on a version that's reached EOL are automatically upgraded to the next minor Kubernetes version. This only upgrades the control plane components of an LKE cluster and not any existing worker nodes. If your cluster is using an EOL version, you will be notified of this action at least 48 hours in advance.

Version upgrades

If a more recent minor Kubernetes version is available, an LKE cluster can be upgraded at any point to the next consecutive version. We recommend upgrading a cluster while your current version is still in the full support stage. This ensures your cluster is always up-to-date and prevents you from remaining on a version that’s deprecated and no longer patched. After manually upgrading your cluster, you’ll need to recycle your worker nodes for them to be upgraded to the newer version.

If you do not manually upgrade your LKE non-enterprise cluster, it is automatically upgraded (forced upgraded) when its Kubernetes version reaches EOL. This process upgrades the control plane Kubernetes version and recycles the worker nodes so that they are also upgraded to the new version. If you wish to avoid this, please manually upgrade your cluster in advance, which will not automatically recycle worker nodes. This force-upgrade does not occur on LKE Enterprise clusters.

To learn more about upgrading your clusters, see the Upgrade a cluster to a newer Kubernetes version guide for complete details and instructions.

Current Kubernetes release schedule on LKE

The tables below lists the Kubernetes versions along with their life cycle milestone dates for LKE and LKE Enterprise. These are approximate dates and may change as old versions are removed, new versions are added, and existing version milestone dates are modified.

Kubernetes versions available for LKE Enterprise

On LKE Enterprise, Kubernetes version numbers are represented as [x].[y].[z]+lke[n]. They include the major version, minor version, patch version, and an iterative number representing the LKE release within this Kubernetes version. An example version number is v1.31.8+lke3. Only major and minor versions are listed in the table below.

Kubernetes versions available for LKE (non-enterprise)

Kubernetes version numbers on LKE are structured as [x].[y], meaning they include the major version and minor version. The patch version is not exposed through the Linode API or Cloud Manager, though you can view the specific version through tools like kubectl. Example: 1.32.