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

Planned Upgrade Overview

Mode fokus
Ukuran font
Terakhir diperbarui: 2025-11-20 14:16:52
The cluster planned upgrade feature of Tencent Kubernetes Engine (TKE) is a planned upgrade service for container cluster components provided by Tencent Cloud. It supports planned upgrades for components of TKE standard clusters and TKE Serverless clusters. It provides enterprise-level customers with refined change maintenance window management. The feature also supports custom cluster release sequences based on upgrade tags, meeting the needs of enterprise-level customers for multi-environment collaborative upgrades and compliance control. The feature provides built-in pre-upgrade and post-upgrade checks, which ensure the security and stability of business operations.

Why Use Planned Upgrade

Expired component versions may pose stability and security risks. Tencent Cloud will stop fixing feature issues and security vulnerabilities on expired cluster component versions, and will provide only limited technical support. Enabling the cluster planned upgrade feature keeps components on supported versions, reducing risk from long-term use of expired components.
The cluster planned upgrade feature can reduce the Ops pressure of continuous cluster component version maintenance. Tencent Cloud automatically pushes cluster component upgrade tasks to ensure that clusters run on stable, supported component versions, eliminating the need for manual version maintenance and improving Ops efficiency.

Upgrade Scope

The planned upgrade scope includes control plane components (such as kube-apiserver) managed on the Tencent Cloud side, as well as system components (such as coredns and kubernetes-proxy) deployed in user clusters. User node components are excluded. TKE will strive to upgrade cluster components in accordance with the user-configured maintenance window. However, to maintain continuous security and stability of user clusters, emergency changes may be performed outside the maintenance window in critical scenarios, such as applying security vulnerability fixes, to rapidly mitigate risks.

Features

Refined maintenance window management: Support configuring maintenance windows at the region and cluster levels, enabling refined upgrade window management for clusters.
Custom release order: Support orchestrating the cluster upgrade order based on tags and provide grayscale capabilities for cluster upgrades.
Pre-upgrade and post-upgrade checks: Provide built-in pre-upgrade and post-upgrade checks to ensure the stable operation of components after the upgrade.

User Guide

1. Log in to the TKE console, set the maintenance window at the region and cluster levels. For details, see Maintenance Windows and Exclusion Items.
2. Go to the Cluster Orchestration page, set cluster tags. For details, see Creating a Cluster Tag.
3. Go to the Cluster Orchestration page, set the cluster release sequence. For details, see Creating a Release Sequence.

Must-Knows

To enable the cluster planned upgrade feature, ensure that the cluster has a configured maintenance window at the region or cluster level. Clusters without an available maintenance window cannot enable this feature. For details about the maintenance window configuration at the region and cluster levels, see Maintenance Windows and Exclusion Items.
Cluster upgrade sequence orchestration depends on cluster tags to group clusters into different release batches. Users can customize the cluster release order by configuring tags for different batches in the release sequence. If a cluster lacks a release sequence tag or its tag does not match any entry in the release sequence, the cluster components will be excluded from the release sequence. Clusters not included in the release sequence will follow the default grayscale policy for upgrade. For details about the cluster upgrade tags and release sequence configuration, see Cluster Orchestration.

Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan