tencent cloud

Tencent Kubernetes Engine

Release Notes and Announcements
Release Notes
Announcements
Release Notes
Product Introduction
Overview
Strengths
Architecture
Scenarios
Features
Concepts
Native Kubernetes Terms
Common High-Risk Operations
Regions and Availability Zones
Service Regions and Service Providers
Open Source Components
Purchase Guide
Purchase Instructions
Purchase a TKE General Cluster
Purchasing Native Nodes
Purchasing a Super Node
Getting Started
Beginner’s Guide
Quickly Creating a Standard Cluster
Examples
Container Application Deployment Check List
Cluster Configuration
General Cluster Overview
Cluster Management
Network Management
Storage Management
Node Management
GPU Resource Management
Remote Terminals
Application Configuration
Workload Management
Service and Configuration Management
Component and Application Management
Auto Scaling
Container Login Methods
Observability Configuration
Ops Observability
Cost Insights and Optimization
Scheduler Configuration
Scheduling Component Overview
Resource Utilization Optimization Scheduling
Business Priority Assurance Scheduling
QoS Awareness Scheduling
Security and Stability
TKE Security Group Settings
Identity Authentication and Authorization
Application Security
Multi-cluster Management
Planned Upgrade
Backup Center
Cloud Native Service Guide
Cloud Service for etcd
TMP
TKE Serverless Cluster Guide
TKE Registered Cluster Guide
Use Cases
Cluster
Serverless Cluster
Scheduling
Security
Service Deployment
Network
Release
Logs
Monitoring
OPS
Terraform
DevOps
Auto Scaling
Containerization
Microservice
Cost Management
Hybrid Cloud
AI
Troubleshooting
Disk Full
High Workload
Memory Fragmentation
Cluster DNS Troubleshooting
Cluster kube-proxy Troubleshooting
Cluster API Server Inaccessibility Troubleshooting
Service and Ingress Inaccessibility Troubleshooting
Common Service & Ingress Errors and Solutions
Engel Ingres appears in Connechtin Reverside
CLB Ingress Creation Error
Troubleshooting for Pod Network Inaccessibility
Pod Status Exception and Handling
Authorizing Tencent Cloud OPS Team for Troubleshooting
CLB Loopback
API Documentation
History
Introduction
API Category
Making API Requests
Elastic Cluster APIs
Resource Reserved Coupon APIs
Cluster APIs
Third-party Node APIs
Relevant APIs for Addon
Network APIs
Node APIs
Node Pool APIs
TKE Edge Cluster APIs
Cloud Native Monitoring APIs
Scaling group APIs
Super Node APIs
Other APIs
Data Types
Error Codes
TKE API 2022-05-01
FAQs
TKE General Cluster
TKE Serverless Cluster
About OPS
Hidden Danger Handling
About Services
Image Repositories
About Remote Terminals
Event FAQs
Resource Management
Service Agreement
TKE Service Level Agreement
TKE Serverless Service Level Agreement
Contact Us
Glossary

TKE Kubernetes Version Maintenance Mechanism

PDF
Mode fokus
Ukuran font
Terakhir diperbarui: 2025-12-02 14:18:13
Tencent Kubernetes Engine (TKE) provides container-centric solutions based on native Kubernetes. Since 3 to 4 minor versions of the community-supported open source edition of Kubernetes are released each year, TKE will also regularly release and maintain the TKE Kubernetes versions supported by the platform. This document mainly describes the support mechanism, release schedule, and expiration risks of the TKE Kubernetes versions.

Version Maintenance

Since September 24, 2018, TKE has only released versions that support even-numbered minor versions of Kubernetes, such as 1.30, 1.28, and 1.26.

Version Number

The TKE Kubernetes versions are expressed as x.y.z-tke.n. x.y.z represents the community Kubernetes version, where x represents the major version, y represents the minor version, z represents the patch version, and n represents the TKE patch version. For example, 1.28.3-tke.1 represents a patch version provided based on the Kubernetes version 1.28.3.

Maintenance Cycle

TKE provides up to 27 months (18+6+3) of service support for each minor version released. The support cycle is divided into the following four stages:
Version Stage
Description
GA (General Availability)
Indicates that the current version can be fully delivered to existing network customers. Typically, it will go to the GA stage 3 months after a new even-numbered minor version is released in the community. During this period, the platform provides patches and service support for the version in this stage.
EOM (End of Marketing)
Indicates that the creation of new clusters for the current version will be stopped across the entire network. Typically, it will go to the EOM stage 18 months after update to the GA version. During this period, the platform provides patches and service support for the version in this stage.
EOFS (End of Full Support)
Indicates that the platform will stop providing new patches for the current version and product features under this version may be limited, such as limiting the creation of new nodes (pools). Typically, it will go to the EOFS stage 6 months after update to the EOM version. During this period, the platform only provides service support for the version in this stage.
EOS (End of Service & Support)
Indicates the time to stop providing services for the current version when the version has expired. Typically, it will go to the EOS stage 3 months after update to the EOFS version.
Notes:
TKE will conduct a comprehensive risk assessment and strict compatibility verification for all open versions. Typically, the creation of new clusters will be gradually opened up 2 months after a new even-numbered minor version is first released in the community. The version is still in the grayscale stage at this time and is expected to enter the GA stage after grayscale for one month. In the grayscale stage, it is not recommended to deploy production business directly.

Patches and Service Support

Patch Scope

New product features, feature defect repair, community feature merging, security risk remediation, and other features provided by the platform.

Service Support Scope

Cluster creation: TKE supports the creation of version clusters in the GA stage.
Upgrade and O&M assurance: TKE provides upgrade features for versions later than v1.10 and provides troubleshooting, fault recovery, and other support.
After-sales support: TKE provides answering questions, online guidance, and troubleshooting. However, for expired versions of Kubernetes clusters, the platform will not guarantee the quality and effectiveness of technical support, and the SLA may be affected due to failure to comply with best practices.

TKE Kubernetes Release Schedule

K8s Version
GA Date
EOM Date
EOFS Date
EOS Date
1.34
November 25, 2025
May 25, 2027
November 25, 2027
February 25, 2028
1.32 (upgrade supported)
June 25, 2025
December 25, 2026
June 25, 2027
September 25, 2027
1.30 (upgrade supported)
August 20, 2024
February 20, 2026
August 20, 2026
November 20, 2026
1.28 (upgrade supported)
April 28, 2024
October 28, 2025
April 28, 2026
July 28, 2026
1.26 (upgrade supported)
April 25, 2023
October 25, 2024
April 25, 2025
July 25, 2025
1.24 (upgrade supported)
January 6, 2023
July 6, 2024
January 6, 2025
April 6, 2025
1.22 (upgrade supported)
July 20, 2022
January 20, 2024
July 20, 2024
October 20, 2024
1.20 (upgrade supported)
September 9, 2021
March 9, 2023
September 9, 2023
December 9, 2023
Notes:
We have postponed the service support time for some versions. The EOM time for version 1.20/1.22/1.24 is postponed to October 25, 2024. The EOFS and EOS time for version 1.20/1.22 is postponed to December 20, 2024.

Expired Version Risks

1. The creation of new clusters for expired versions is not supported.
2. The platform no longer provides patch services for expired versions.
3. The quality and effectiveness of technical support cannot be guaranteed.
4. The platform reserves the right to forcibly upgrade expired versions of clusters. Before performing a forced upgrade, we will send relevant notifications at least one month in advance via SMS, email, and internal messages.
In summary, it is recommended that you should plan and upgrade the Kubernetes version in a timely manner. For details, see Upgrading a Cluster.


Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan