EKS Versions and Kubernetes Upgrades: Everything You Need to Know

What Is AWS EKS? 

Elastic Kubernetes Service (EKS) is a managed container service that allows users to run Kubernetes on Amazon Web Services (AWS) without the need for installing and operating their own Kubernetes control plane or nodes. It simplifies the process of building, securing, operating, and maintaining Kubernetes clusters in the cloud, offering integration with AWS services for scalability and security. 

EKS is designed to provide highly available and secure clusters, automatically managing tasks such as patching, node provisioning, and updates. It supports running containers on both Amazon EC2 and AWS Fargate. With EC2, users have granular control over the infrastructure, such as choosing the instance types and optimizing the cost. Fargate offers a serverless compute engine for containers, removing the need to manage servers or clusters.

One of the primary reasons for using managed services like EKS is to make Kubernetes upgrades easier. We’ll cover how EKS helps with upgrades, how EKS aligns with and supports new Kubernetes versions, and provide practical guidance for updating your EKS clusters.

How Does EKS Make Kubernetes Version Upgrades Easier? 

When self-managing a Kubernetes cluster, one of the most complex tasks is upgrading Kubernetes Here are the key capabilities EKS provides which can ease and simplify Kubernetes upgrades:

  • Automated upgrades: EKS streamlines the upgrade process by automating many of the steps involved. This includes updating the control plane and nodes to the latest Kubernetes version with minimal manual intervention.
  • Managed control plane: EKS manages the Kubernetes control plane, relieving users from the complexity of manually updating and securing it. This ensures that the control plane is always running a supported and secure version of Kubernetes.
  • Compatibility checks: Before upgrading, EKS performs compatibility checks to ensure that the new Kubernetes version will work with the user’s existing configurations and workloads. This reduces the risk of issues post-upgrade.
  • Rollback capabilities: In the event that an upgrade does not go as planned, EKS provides options to rollback changes, helping users maintain stability and uptime.
  • Documentation and support: AWS provides comprehensive documentation and support for upgrading EKS clusters, including step-by-step guides, best practices, and troubleshooting tips.
  • Version flexibility: Users have the flexibility to choose when to upgrade, within the bounds of the EKS support policy, allowing them to plan and prepare for upgrades according to their own schedules.
  • Extended support for older versions: For organizations that need more time to upgrade, EKS offers extended support for older Kubernetes versions, ensuring they continue to receive security patches and support until they can upgrade. However, extended support comes at extra cost.

Amazon EKS Version and Release Policy 

Here are a few things that are important to understand about the way EKS handles Kubernetes versions:

Versions Available on Standard Support

Amazon EKS follows the Kubernetes community’s release and deprecation cycle, updating its service to support new Kubernetes versions as they become available. Amazon EKS offers standard support for at least four most recent Kubernetes minor versions, typically for the first 14 months after their release. This standard support includes backported security patches and updates to ensure the reliability and security of Kubernetes clusters running on EKS.

For each version supported under the standard support, AWS applies updates and patches as necessary. Users are encouraged to upgrade their clusters to these versions to take advantage of the latest features and improvements in Kubernetes​​.

Versions Available on Extended Support

For users who need more time to upgrade their clusters or have specific requirements that necessitate staying on an older Kubernetes version, even after the official end of life (EOL) date, Amazon EKS offers an extended support option. This option provides an additional 12 months of support beyond the standard support period, albeit at an additional cost. 

Extended support ensures that users can maintain their clusters on a specific Kubernetes version longer, receiving crucial security patches and support from AWS. Typically, EKS offers extended support for the two previous minor versions before those supported in Standard Support.

Note: Please refer to the official documentation to see which Kubernetes versions are currently available under standard and extended support.

Kubernetes Versions vs. EKS Platform Versions

Amazon EKS introduces the concept of platform versions alongside the Kubernetes versions it supports. These platform versions correspond to the capabilities and configurations of the EKS cluster control plane, including enabled Kubernetes API server flags and the current Kubernetes patch version. For each Kubernetes minor version, there are one or more associated Amazon EKS platform versions, denoting incremental updates and improvements.

For example, Kubernetes version 1.29 on Amazon EKS started with platform version eks.1, representing the initial release of this Kubernetes version on the EKS service. As Amazon EKS makes periodic updates to incorporate new control plane settings, security fixes, or other enhancements, the platform version number is incremented (e.g., eks.2, eks.3). These updates are applied automatically to existing clusters, ensuring they benefit from the latest improvements without disrupting service.

This system allows Amazon EKS to fine-tune the cluster control plane’s functionality and security over time while making it clear which underlying Kubernetes version is being used in the cluster.

How to Upgrade the Kubernetes Version on Your Amazon EKS Cluster 

Let’s see the steps involved in upgrading Kubernetes version on your Amazon EKS cluster:

Step 1: Compare version of the Kubernetes control plane and nodes

You can retrieve the control plane’s Kubernetes version using:

kubectl version

Next, obtain the Kubernetes version for your nodes. This command will list all the self-managed nodes and managed Amazon EC2 and Fargate nodes present. Each Fargate Pod is shown as an individual node:

kubectl get nodes

Before proceeding to upgrade your control plane to a new Kubernetes version, it is crucial to ensure that both the managed nodes and Fargate nodes in your cluster have the same Kubernetes minor version as your control plane. For instance, if your control plane uses version 1.28 and a node runs on 1.27, you’ll need to update your nodes to version 1.28 before upgrading your control plane to 1.29. Amazon also recommends syncing the version of your self-managed nodes with your control plane before upgrading the control plane.

Note: For Kubernetes 1.25 or earlier, there may be additional steps, see the official documentation.

Step 2: Upgrade the cluster with eksctl

eksctl is an Amazon command line utility which lets you manage EKS clusters. You can also perform these steps in the AWS management console or the AWS CLI. 

Before proceeding, install eksctl and make sure you have version 0.171.0 or later. You can verify your version by running this command:

eksctl version

Now, upgrade the Kubernetes version of your Amazon EKS control plane. Run the following command, replacing my-cluster with your cluster’s actual name and x.xx with the Kubernetes version number you desire for your cluster, making sure that it is one of the versions currently supported by EKS:

eksctl upgrade cluster --name my-cluster --version x.xx --approve

The process usually takes several minutes to complete.

Step 3: Update Kubernetes nodes

Once the cluster upgrade finishes, update your nodes to match your cluster’s updated Kubernetes minor version. See Amazon’s instructions for:

Note: There are additional steps for updating your Cluster Autoscaler, NVIDIA drivers for clusters with GPUs, Amazon VPC CNI plugin, CoreDNS, Kube-Proxy add-ons, and kubectl, if applicable. Refer to the official documentation for details.

Best Practices for AWS EKS Cluster Upgrades 

Here are some best practices for upgrading EKS clusters.

Review the EKS Release Calendar

AWS regularly publishes updates about new Kubernetes versions, features, and deprecation schedules. By monitoring these releases, users can plan their upgrade paths, ensuring that their clusters take advantage of the latest improvements while remaining within the support window.

The release calendar also provides insights into when to expect deprecations and when to begin testing newer versions. This proactive approach enables organizations to allocate resources effectively, ensuring that upgrades are timely, tested, and aligned with business objectives. 

Assess Cluster Add-Ons Compatibility

Add-ons such as logging, monitoring, network plugins, and security tools, which extend Kubernetes functionality, may not be immediately compatible with newer versions. Users should check the compatibility of these tools with the planned Kubernetes version, updating or replacing add-ons as necessary to avoid disruptions.

This compatibility check should extend to applications and services running within the cluster. Ensuring that APIs, libraries, and dependencies are compatible with the new Kubernetes version prevents runtime issues and ensures that applications continue to operate smoothly post-upgrade. Thorough testing in a staging environment helps catch and resolve issues before they impact production workloads.

Upgrading Managed vs. Self-Managed Node Pools

Managed node groups offer a simplified upgrade process, as AWS handles much of the heavy lifting, including applying updates and patches. This reduces the operational burden on users and ensures that node pools are kept up-to-date with the latest Kubernetes version and security patches. Users can initiate upgrades through the EKS console or CLI, with minimal disruption to running applications.

For self-managed nodes, users are responsible for manually updating their clusters. This process requires more detailed planning and execution, including draining nodes, applying updates, and then carefully reintroducing them to the cluster. While this approach offers more control over the upgrade process and timing, it also requires a deeper understanding of Kubernetes and EKS specifics. 

Consider Using EKS on Fargate

EKS on Fargate offers a serverless experience, eliminating the need to manage nodes altogether, including upgrades. This is suitable for applications requiring simplified scaling and management, or for those prioritizing cost efficiency and operational simplicity.

Fargate reduces the operational complexity of running Kubernetes clusters, but it is not suitable for all use cases. For instance, Fargate is particularly beneficial for burstable workloads or microservices with variable resource demands. Managed node groups offer more control over the compute environment, which may be necessary for specific regulatory or performance requirements.

Use eksctl for Cluster Management

eksctl is a command-line tool for creating and managing AWS EKS clusters. It simplifies many aspects of cluster management, including upgrades. eksctl allows users to upgrade clusters and manage node groups with simple commands, streamlining the process and reducing the potential for errors. 

Using eksctl for cluster upgrades can significantly reduce the complexity and time required, especially for users managing multiple clusters or large-scale deployments. It provides mechanisms for automating upgrades, including dry runs to validate changes before applying them. 

Create Upgrade Runbooks

Comprehensive upgrade runbooks provide step-by-step instructions for the upgrade process, including pre-upgrade checks, backup procedures, and how to handle potential issues. These documents ensure consistency and reduce the risk of errors, especially in complex environments or when upgrades involve multiple teams.

Runbooks should be regularly reviewed and updated to reflect changes in the cluster configuration, Kubernetes versions, or operational practices. They should include rollback procedures, allowing for a quick response if the upgrade encounters problems. 

Troubleshooting EKS Upgrades with Komodor

EKS upgrades often introduce issues in clusters, which require complex troubleshooting. Without the right tools and expertise in place, the troubleshooting process can become stressful, ineffective and time-consuming. Some best practices can help minimize the chances of things breaking down, but eventually something will go wrong – simply because it can.

This is where Komodor comes in – Komodor is the Continuous Kubernetes Reliability Platform, designed to democratize K8s expertise across the organization and enable engineering teams to leverage its full value.

Komodor’s platform empowers developers to confidently monitor and troubleshoot their workloads while allowing cluster operators to enforce standardization and optimize performance.

Specifically when it comes to EKS version upgrades, Komodor enables you to proactively monitor each cluster’s End-of-Life status, as well as its associated APIs. With Komodor, your infrastructure remains up-to-date and compliant, while preventing potential issues from occurring.

By leveraging Komodor, companies of all sizes significantly improve reliability, productivity, and velocity. Or, to put it simply – Komodor helps you spend less time and resources on managing Kubernetes, and more time on innovating at scale.

If you are interested in checking out Komodor, use this link to sign up for a Free Trial.

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 1

No votes so far! Be the first to rate this post.