Clarification on Pending Upgrade for EKS Cluster

follow-up:

We have concerns about this automatic upgrade:

Extended support: Version 1.31 only reached end-of-support yesterday. Is extended support available to allow proper planning?

Terraform conflicts: Our infrastructure is version-pinned in Terraform. An automatic upgrade will cause state drift and block all infrastructure changes until we update our modules.

Can we schedule this upgrade for a maintenance window instead of having it happen automatically?

The banner you're seeing indicates that your cluster is set for an automatic upgrade because it's likely reaching the end of its standard support period for the current Kubernetes version.

Regarding your questions:

1. Downtime during upgrade: The control plane upgrade itself should not cause downtime as Amazon EKS launches new API server nodes with the updated Kubernetes version while maintaining the existing ones until the upgrade is complete. However, you should be aware that:

• For worker nodes, if your deployments aren't configured to handle node evictions properly, some downtime might occur during their upgrade
• It's recommended to configure Pod disruption budgets to minimize potential disruption
• In larger clusters with high network traffic, you might experience some dropped packets when upgrading add-ons

2. Upgrade schedule: The automatic upgrade is likely scheduled to occur when your current Kubernetes version reaches the end of its standard support period. Amazon EKS provides standard support for a minor version for 14 months after release.

3. Postponing the upgrade: Yes, you can change your cluster's upgrade policy from "STANDARD" to "EXTENDED" to postpone the automatic upgrade. This will put your cluster into extended support (which comes with additional costs per cluster hour) for up to 12 months beyond the standard support period. This gives you more control over when to perform the upgrade.

Before proceeding with any upgrade (automatic or manual), I recommend:

• Using the "Upgrade insights" tab in the EKS console to identify any potential issues that might affect your upgrade
• Testing your applications against the new Kubernetes version in a non-production environment
• Ensuring your add-ons and worker nodes are compatible with version 1.32

If you decide to proceed with the upgrade yourself rather than waiting for the automatic one, remember to upgrade the control plane first, followed by add-ons and worker nodes.
Sources
Community | Amazon EKS Upgrade Guidance (v1.25 to 1.26)
Prepare for Kubernetes version upgrades and troubleshoot misconfigurations with cluster insights - Amazon EKS
Update existing cluster to new Kubernetes version - Amazon EKS
View current cluster upgrade policy - Amazon EKS