Supported Kubernetes Versions¶
This document outlines the version support policy for the Contain Base service, our release cadence, and what to expect when a version reaches its end-of-life (EOL).
Kubernetes uses a major.minor.patch versioning scheme. The community releases
a new minor version approximately every four months (three times per year).
These minor versions introduce new features, API changes, and improvements.
Further Information
For detailed information about the upstream Kubernetes release process, versioning, and support policy, please refer to the official Kubernetes Release Documentation.
Release Cadence and Support Policy¶
The Contain Platform aims to provide a stable and secure environment by supporting the three most recent minor versions of Kubernetes. When a new minor version is released by the upstream Kubernetes project and has been vetted for our platform, we will begin the process of deprecating the oldest supported version.
This N-2 policy (where N is the latest minor version) ensures that you have access to modern features while maintaining a high degree of stability.
Current Version Support¶
The following table details the current support status for recent Kubernetes versions on the Contain Platform.
| Version | State | Release Date | End-of-Life (EOL) Date |
|---|---|---|---|
| 1.34 | Supported | 2025-08-27 | 2026-10-27 |
| 1.33 | Supported | 2025-04-23 | 2026-06-28 |
| 1.32 | Supported | 2024-12-11 | 2026-02-28 |
| 1.31 | Deprecated | 2024-08-13 | 2025-10-28 |
- State: The current support status of the version.
- Release Date: The date when the version was released.
- End-of-Life (EOL) Date: The date after which the version is considered deprecated and no longer receives security patches or bug fixes from the upstream community.
Public Cloud Managed Kubernetes (AKS, EKS, GKE)¶
If your Workload Clusters are running on a public cloud provider's managed Kubernetes service (such as Azure Kubernetes Service, Amazon Elastic Kubernetes Service, or Google Kubernetes Engine), we adhere to the provider's specific release schedule and support lifecycle.
While we will assist with planning and executing upgrades, the available versions and deprecation timelines are determined by the cloud provider. Please refer to their official documentation for the most accurate versioning information.
Deprecation and End-of-Life (EOL)¶
When a Kubernetes version reaches its EOL date and its state becomes Deprecated, our support model changes significantly.
For any cluster running a deprecated version:
- Operational Responsibility: We can no longer guarantee the operational stability or uptime of the cluster's control plane or nodes. Support becomes "best effort."
- Technical Management: The cluster will no longer receive security patches, bug fixes, or routine maintenance. We may not be able to perform automated upgrades to or from this version.
- Managed Services: Our other managed services (such as databases, observability, etc.) are only guaranteed to be compatible with currently Supported versions of Kubernetes. Functionality for managed services on deprecated clusters may be limited or cease to work.
We strongly advise planning and executing an upgrade for your clusters well in advance of the EOL date to ensure continued security, stability, and full support.