Skip to content

Upgrade your EKS hosting cluster using Rancher

This document describes the step-by-step process for upgrading an Amazon EKS cluster managed via Rancher. The order of the steps is critical to ensure a smooth and successful upgrade.


1. Pre-Upgrade Checks

Before initiating the upgrade, perform the following manual checks:


2. Update Kubernetes Control Plane

  1. Log in to Rancher.
  2. Navigate to Cluster Management.
  3. Edit the target cluster config with the button.
  4. Under Cluster Options, increment the Kubernetes version by one minor version (e.g., from 1.30 to 1.31).

    ⚠️ Do not change any other settings.

  5. Save the changes and wait for the upgrade to complete.

You can monitor the upgrade progress in both Rancher and the AWS EKS console.


3. Upgrade vpc-cni Addon

Once the control plane upgrade is successful and the cluster is in a ready state:

  1. Check if the vpc-cni addon requires an upgrade.
  2. If needed, upgrade it via the AWS console or CLI to the default version for your kubernetes version.

4. Upgrade Node Groups

After upgrading vpc-cni:

  1. Return to Rancher.
  2. Edit the cluster again.
  3. Update the Kubernetes version for each node group to match the control plane version.

    ⚠️ This action will cycle all nodes and cause downtime during the upgrade process.

  4. Wait until all node groups are upgraded and in a ready state.

5. Upgrade Remaining EKS Addons

Once all nodes are successfully upgraded:

  1. Check other managed EKS addons (e.g., kube-proxy, coredns).
  2. Upgrade them if newer compatible versions are available. Always use the default version for your kubernetes version

6. Post-Upgrade Checks

Perform infrastructure and application post-upgrade validation:

  • Validate cluster health and workloads in Rancher.
  • Confirm that all critical services and applications are running as expected.
  • Run automated or manual tests if applicable.

Notes

  • Always follow the minor version upgrade path. Skipping versions is not supported.
  • This process assumes the cluster is managed entirely via Rancher.
  • Optionally schedule a maintenance window during node group cycling.