Cluster Upgrade

WHY UPGRADE

Here’s a comprehensive list of why EKS (Kubernetes) upgrades are important — from both a technical and business perspective:

1️⃣ Avoid Extended Support Costs

After the 14-month standard support window, AWS moves the version to Extended Support, charging $0.60 per cluster per hour ($432/month).

Older clusters with node groups on the same version can also incur charges.

2️⃣ Security Patches

Kubernetes regularly fixes critical CVEs in components like kube-apiserver, etcd, kubelet, etc.

Staying on an old version leaves you open to known exploits.

Extended Support gives only security fixes, but no feature enhancements.

3️⃣ API Deprecations & Removals

Kubernetes frequently deprecates or removes old APIs.

Example: extensions/v1beta1 → removed in v1.16, PodSecurityPolicy removed in v1.25.

If you skip too many versions, your workloads or Helm charts might break.

4️⃣ New Features & Improvements

Better autoscaling, scheduling, and workload management.

Example:

v1.31 introduced Pod Scheduling Readiness Gates.

v1.32 brought improved sidecar container lifecycle.

Staying current means access to new functionality.

5️⃣ AWS Service Integrations

Newer Kubernetes versions on EKS often add:

Better IAM roles for service accounts (IRSA) handling.

Improved EBS/EFS CSI driver compatibility.

Native support for new AWS networking features.

6️⃣ Performance & Efficiency

Optimizations in kube-scheduler, kubelet, and CNI plugins.

Reduced resource usage → cost savings.

Faster startup times for pods.

7️⃣ Compliance Requirements

Many industries (finance, healthcare, etc.) require vendor-supported software for compliance (ISO, SOC2, PCI DSS).

Running an unsupported Kubernetes version could violate audit policies.

8️⃣ Easier Upgrades in the Future

Skipping upgrades means you might have to do multi-hop upgrades (e.g., 1.28 → 1.29 → 1.30 → 1.31).

This increases downtime risk and operational complexity.

9️⃣ Stability & Bug Fixes

Every new release fixes known stability issues.

Old versions might have unresolved bugs that affect workloads during scaling, draining, or high load.

🔟 Support from Tools & Ecosystem

Helm charts, operators, and controllers are often tested only against recent Kubernetes versions.

Using an old version can lead to incompatibility with third-party tools.

💡 Bottom line:

Upgrading is not just about avoiding extra AWS costs — it’s about security, stability, compatibility, and performance.

For EKS specifically, AWS makes upgrades in-place with zero control-plane downtime, so the operational risk is low if planned well.

Steps

1. upgrade control plane

2. upgrade nodes

3. upgrade addons

Upgrade Control Plane

Increase node by one from current capacity

eksctl scale nodegroup --name=VG-KARP-NODEGROUP --cluster=VG-KARP-CLUSTER --nodes=7 --nodes-min=4 --nodes-max=7

convert remaining adds-on to managed addonsso that you can upgrade from UiFirst migrate via CLI → then upgrade from UI is a safe and clean workflow for production.

aws eks create-addon --cluster-name VG-KARP-CLUSTER --addon-name kube-proxy --resolve-conflicts=OVERWRITE

aws eks create-addon --cluster-name VG-KARP-CLUSTER --addon-name coredns --resolve-conflicts=OVERWRITE

aws eks create-addon --cluster-name VG-KARP-CLUSTER --addon-name vpc-cni --resolve-conflicts=OVERWRITE

update control plane (dry-run)

eksctl upgrade cluster --name VG-KARP-CLUSTER --region ap-southeast-1 --version 1.31

Once verify upgrade control plane with --approve

eksctl upgrade cluster --name VG-KARP-CLUSTER --region ap-southeast-1 --version 1.31 --approve

start time: 15:08 PMend time: 15: 18 PM

---

2. Managed Node Groups

• Once the control plane is done, upgrade the node groups so nodes run the same Kubernetes version as control plane.

• Options:

  • In-place rolling upgrade (EKS replaces one node at a time).

  • Blue-green (create a new node group at the new version, drain old one, then delete it).

• Add a buffer node (like we added earlier: scale to 7) to reduce disruption.

Navigate to Compute > Node GroupsClick on update now

Select Update strategy > Rolling update

start time: 15:30 PMend time: 16: 00 PM

---

3. Add-ons (kube-proxy → CoreDNS → VPC CNI → CSI drivers)

• After all nodes are on the new version, update your add-ons to versions that are compatible with the new Kubernetes release.

• This ensures networking, DNS, and storage plugins work correctly.

Check Add-ons compatible version as per Cluster version

aws eks describe-addon-versions \ 
--addon-name kube-proxy \ 
--kubernetes-version 1.31 \ 
--query "addons[].addonVersions[?compatibilities[?defaultVersion==\`true\`]].addonVersion" \ 
--output text 


aws eks describe-addon-versions \ 
--addon-name coredns \ 
--kubernetes-version 1.31 \ 
--query "addons[].addonVersions[?compatibilities[?defaultVersion==\`true\`]].addonVersion" \ 
--output text 

 aws eks describe-addon-versions \
  --addon-name vpc-cni \
  --kubernetes-version 1.31 \
  --query "addons[].addonVersions[?compatibilities[?defaultVersion==\`true\`]].addonVersion" \
  --output text

aws eks describe-addon-versions \
  --addon-name aws-ebs-csi-driver \
  --kubernetes-version 1.31 \
  --query "addons[].addonVersions[?compatibilities[?defaultVersion==\`true\`]].addonVersion" \
  --output text

 

Update Kube-proxy Add-ons

Do same for remaining Add-ons

---

✅ Summary Order

1. Control plane

2. Node groups

3. Add-ons (kube-proxy → CoreDNS → VPC CNI → EBS CSI driver)

---