Komodor is a Kubernetes management platform that empowers everyone from Platform engineers to Developers to stop firefighting, simplify operations and proactively improve the health of their workloads and infrastructure.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Empower developers with self-service K8s troubleshooting.
Simplify and accelerate K8s migration for everyone.
Fix things fast with AI-powered root cause analysis.
Explore our K8s guides, e-books and webinars.
Learn about K8s trends & best practices from our experts.
Listen to K8s adoption stories from seasoned industry veterans.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Kubernetes 101: A comprehensive guide
Expert tips for debugging Kubernetes
Tools and best practices
Kubernetes monitoring best practices
Understand Kubernetes & Container exit codes in simple terms
Exploring the building blocks of Kubernetes
Cost factors, challenges and solutions
Kubectl commands at your fingertips
Understanding K8s versions & getting the latest version
Rancher overview, tutorial and alternatives
Kubernetes management tools: Lens vs alternatives
Troubleshooting and fixing 5xx server errors
Solving common Git errors and issues
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Hear’s what they’re saying about Komodor in the news.
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.
This is part of a series of articles about Kubernetes Versions.
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:
Learn more in our detailed guide to Kubernetes upgrades.
Itiel Shwartz
Co-Founder & CTO
In my experience, here are tips that can help you better manage and upgrade EKS clusters:
Regularly review the EKS release calendar to plan upgrades and stay within the support window.
Utilize eksctl for managing EKS clusters to simplify and automate upgrade processes.
Ensure that all add-ons and plugins are compatible with the new Kubernetes version before upgrading.
Test upgrades in a staging environment identical to production to catch issues early.
Automate the backup of your clusters before upgrades to safeguard against data loss.
Here are a few things that are important to understand about the way EKS handles Kubernetes versions:
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.
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.
Learn more in our detailed guide to Kubernetes EOL.
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.
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:
my-cluster
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.
Here are some best practices for upgrading EKS clusters.
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.
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.
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.
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.
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.
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.
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.
Share:
How useful was this post?
Click on a star to rate it!
Average rating 5 / 5. Vote count: 8
No votes so far! Be the first to rate this post.
and start using Komodor in seconds!