Configure a cluster maintenance window to schedule planned changes such as automatic upgrades and CVE fixes during off-peak hours, protecting core business stability during peak hours and minimizing the potential impact on your workloads.
Applies to: ACK managed clusters
How it works
A maintenance window is a recurring period during which ACK performs automated operations and maintenance (O&M), such as Kubernetes version upgrades and CVE fixes.
ACK runs two types of maintenance:
-
ACK-initiated maintenance: ACK automatically schedules O&M tasks based on type and impact. No configuration needed.
-
User-configured maintenance: Set a custom window to control when ACK runs O&M—for example, limiting changes to off-peak hours.
A maintenance window defines when ACK may perform O&M. Tasks are not guaranteed to run at the next window. Actual timing depends on ACK's task scheduling and grayscale orchestration.
Examples of a weekly maintenance window:
Default behavior: 
Custom maintenance window: 
Configure a maintenance window
Set a maintenance window when you create a cluster, or update it later:
-
Console: Create an ACK managed cluster
-
API: Use CreateCluster to set the window at cluster creation, or ModifyCluster to update an existing cluster.
Best practices
| Setting | Recommendation |
|---|---|
| Period | Choose a weekly or custom period. For production, use a fixed period during off-peak hours, such as 00:00–04:00. |
| Duration | Set each window to at least 4 hours. Total maintenance time per month must be at least 48 hours so long-running tasks such as upgrades can complete. |
| Time zone | Match the time zone to your business location. |
| Application high availability | Deploy multiple replicas across nodes. For critical services, configure a Pod Disruption Budget (PDB) to limit simultaneous pod disruptions. |
| Multi-cluster setups | Stagger windows across production clusters for grayscale upgrades and improved stability. |
Operations and maintenance windows
Not all ACK O&M operations follow the maintenance window.
| Operation | Follows maintenance window | Notes |
|---|---|---|
| Automatic Kubernetes version upgrades for the control plane | Yes | — |
| Automatic scans and fixes for CVE vulnerabilities in the node OS | Yes | — |
| Automatic upgrades of critical system components in Auto Mode clusters | Yes | — |
| Automatic updates of the node pool image ID in Auto Mode clusters | Yes | Only newly added nodes use the new image. Existing nodes are not directly upgraded. |
Automatic responses to ECS system events (e.g., SystemMaintenance.Reboot) |
Yes (with fallback) | If a maintenance window is available before the ECS scheduled time, ACK uses it. Otherwise, ACK acts one hour before the ECS scheduled time. |
| Control plane repairs | No | Triggered immediately for control plane stability. |
| Node auto-healing | No | Triggered immediately on managed node pool node failure. |
| Node scaling | No | Driven by real-time workload demand (CPU, memory). Independent of scheduled windows. |
| Critical security vulnerability patches | No | ACK may bypass maintenance windows for emergency security fixes. |
FAQ
An O&M task failed. Will it be retried?
Yes. ACK retries failed tasks during the next available maintenance window.
An upgrade started during the maintenance window but didn't finish in time. What happens?
ACK handles unfinished O&M plans as follows:
-
Unstarted batches: Automatically canceled and postponed to the next maintenance window.
-
Started batches: Continue to completion for node consistency. Remaining unstarted batches are then canceled.