In this post, We will discuss why upgrading is essential and the cost implications of control plane operations. What are the essential steps to prepare your EKS cluster for an upgrade, including backup strategies, compatibility checks, and automation tools to make the process efficient, as well as best practices to ensure a smooth upgrade
Why should you upgrade EKS clusters?
Upgrading your EKS clusters is an essential step in maintaining the smooth operation of your Kubernetes environment. With each new version, Amazon introduces improvements that enhance performance, security, and reliability. This means that your clusters will not only run more efficiently but also be better protected against potential vulnerabilities.
If you’re managing workloads on Amazon Web Services (AWS), you’re probably aware of the benefits of using the Elastic Kubernetes Service (EKS). But did you know that regularly upgrading your EKS clusters can lead to significant cost savings?
Recently, we did the upgrade of our EKS cluster from version v1.23 to v1.30, and the results led to cost savings.” Not only did we experience improved stability and performance, but we also managed to save $360 per month in costs.
Understand the cost of control plan.
Amazon Web Services (AWS) charges for:
Control Plane Operations:
Standard Charge: $0.10 per hour per cluster.
Extended Support:
Additional Charge: $0.60 per hour per cluster for control plane extended support.
Here are some common mistakes to avoid:
We’ll walk through the most critical mistakes to avoid when upgrading an EKS cluster. For each mistake, we’ll cover its description and the potential impact on your infrastructure, helping you understand why avoiding these issues is essential for a smooth and successful upgrade.
1. Version compatibility checks are ignored.
Description:
Verifying that Helm charts and EKS add-ons (CoreDNS, kube-proxy, and VPC CNI) work with the latest version of Kubernetes is essential before upgrading.
Impact:
Skipping compatibility checks can lead to broken deployments, failed roll-outs, or unexpected behaviour in your applications. Incompatible ad-dons can cause networking issues, DNS failures, or even prevent critical services from starting. This can result in extended downtime and troubleshooting efforts.
2. Ad-dons are not upgraded before nodes.
Description:
The control plane, worker nodes, and ad-dons are parts of the EKS cluster. Because older ad-dons might not support new Kubernetes capabilities, upgrading worker nodes before updating CoreDNS and VPC CNI may result in incompatibilities.
Impact:
DNS resolution issues and network outages might result from using out-of-date CoreDNS or VPC CNI versions. Your micro-services may experience cascading failures as a result of this breaking service discovery. n the worst case, workloads may become unreachable, causing significant downtime and requiring manual intervention.
3. Prior to node upgrades, the Kubelet version was not checked.
Description:
Kubelet, which is used by worker nodes in an EKS cluster, must be compatible with the control plane version. Unexpected compatibility problems between the control plane and worker nodes may arise during an upgrade if the kubelet version is not checked.
Impact:
If the kubelet version is not compatible, worker nodes fail to join the cluster or experience degraded performance. This can lead to failed pod scheduling, increased API request failures, and potential service downtime, impacting application availability.
4. Helm charts are not being updated.
Description:
Helm charts specify the Kubernetes application deployment process. Every version of Kubernetes introduces new APIs and deprecates older ones. Helm charts may make reference to deprecated APIs that are no longer in use if you don't update them before upgrading.
Impact:
Applications that depend on out-of-date Helm charts may not deploy or execute properly, resulting in downtime. Your entire application stack might break in the worst situation, requiring quick fixes and delay your update.
Pre-requisites for EKS Upgrade:
An Amazon EKS cluster upgrade is a crucial operation that needs to be carefully planned to prevent compatibility problems and downtime. To guarantee a seamless transfer, certain preparatory procedures must be followed before moving forward with the upgrade. By following these checks, you can proactively detect and address API deprecation's, ensuring a smooth EKS upgrade without unexpected failures.
1. Check Dependency Information:
To check for API deprecation, use the AWS EKS Console:
The EKS dashboard now features an API Deprecation Report from AWS that searches your cluster and identifies deprecated Kubernetes APIs that your workloads use. Prior to updating, this function assists in identifying possible compatibility problems.
Example: API Deprecation in Kubernetes v1.25
Kubernetes v1.25 removed certain beta APIs, including:
PodDisruptionBudget.policy/v1beta1→ Must migrate topolicy/v1.Ingress.networking.k8s.io/v1beta1→ Must usenetworking.k8s.io/v1.
2. Verify NGINX Ingress Controller Compatibility
Before upgrading, make sure your current version of the NGINX Ingress Controller is compatible with the target EKS Kubernetes version if your cluster uses it. For services that depend on ingress traffic, incompatibilities may result in downtime, broken routing, or ingress failures.
3. Ensure Amazon EKS Add-ons Compatibility
EKS-managed add-ons must be updated for compatibility with the new Kubernetes version. Use the following commands to check and update add-ons:
VPC CNI Add-on: Check the latest version compatible with your target EKS version.
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
CoreDNS: Ensure the CoreDNS add-on is updated to the compatible version (check if any configuration changes are necessary).
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
Kube-proxy: Update to the appropriate version based on your target EKS version.
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
4. Backup Your EKS Cluster
Before initiating the upgrade process, it is critical to take a full backup of your EKS cluster. This backup will serve as a safety net, ensuring that you can quickly recover your cluster in case of unexpected issues, such as infrastructure loss or data corruption during the upgrade process.
Using Velero for Cluster Backup:
For backing up and recovering Kubernetes resources, such as persistent volumes, namespaces, configurations, and more, Velero is a powerful open-source tool designed for backing up and restoring Kubernetes resources. It integrates well with Amazon EKS and provides a simple way to create backups and restore resources in case of a failure.
You provide an additional degree of security by using Velero to create a backup before executing the upgrade, guaranteeing that your EKS environment can be quickly restored in case of emergency.
Validate Your Restore in a Lower Environment: You must also test the restore process in a non-production (lower) environment to ensure the backup is valid and All configurations and dependencies are properly restored.
Steps for EKS Upgrade:
You can start the EKS upgrade when you've finished the prerequisite checks and made the required backups. Follow these steps to ensure a smooth and efficient upgrade process.
Check Current Version:
aws eks describe-cluster --name <cluster-name> --query cluster.version --output
2. Control Plane Upgrade:
Updating the control plane to the desired Kubernetes version is the initial step in cluster upgrading.This is a critical step, as the control plane manages the overall cluster's operations.
Run the following command to update the control plane:
aws eks update-cluster-version --name <cluster-name> --kubernetes-version
Managed Node Groups Upgrade:
Once the control plane is updated, the next step is to upgrade your managed node groups to ensure they are compatible with the new Kubernetes version. This will allow your worker nodes to properly support the upgraded control plane.
Execute the following command to update your node group:
aws eks update-nodegroup-version --cluster-name <cluster-name> --nodegroup-name <node_group_name> --kubernetes-version
Key advantages:
Upgrading your Amazon EKS cluster offers several key advantages that directly impact performance, cost efficiency, and security. By the recommended upgrade process, we experienced significant improvements across the board.
Why should you upgrade EKS clusters?
Upgrading your EKS clusters is an essential step in maintaining the smooth operation of your Kubernetes environment. With each new version, Amazon introduces improvements that enhance performance, security, and reliability. This means that your clusters will not only run more efficiently but also be better protected against potential vulnerabilities.
If you’re managing workloads on Amazon Web Services (AWS), you’re probably aware of the benefits of using the Elastic Kubernetes Service (EKS). But did you know that regularly upgrading your EKS clusters can lead to significant cost savings?
Recently, we did the upgrade of our EKS cluster from version v1.23 to v1.30, and the results led to cost savings.” Not only did we experience improved stability and performance, but we also managed to save $360 per month in costs.
Understand the cost of control plan.
Amazon Web Services (AWS) charges for:
Control Plane Operations:
Standard Charge: $0.10 per hour per cluster.
Extended Support:
Additional Charge: $0.60 per hour per cluster for control plane extended support.
Here are some common mistakes to avoid:
We’ll walk through the most critical mistakes to avoid when upgrading an EKS cluster. For each mistake, we’ll cover its description and the potential impact on your infrastructure, helping you understand why avoiding these issues is essential for a smooth and successful upgrade.
1. Version compatibility checks are ignored.
Description:
Verifying that Helm charts and EKS add-ons (CoreDNS, kube-proxy, and VPC CNI) work with the latest version of Kubernetes is essential before upgrading.
Impact:
Skipping compatibility checks can lead to broken deployments, failed roll-outs, or unexpected behaviour in your applications. Incompatible ad-dons can cause networking issues, DNS failures, or even prevent critical services from starting. This can result in extended downtime and troubleshooting efforts.
2. Ad-dons are not upgraded before nodes.
Description:
The control plane, worker nodes, and ad-dons are parts of the EKS cluster. Because older ad-dons might not support new Kubernetes capabilities, upgrading worker nodes before updating CoreDNS and VPC CNI may result in incompatibilities.
Impact:
DNS resolution issues and network outages might result from using out-of-date CoreDNS or VPC CNI versions. Your micro-services may experience cascading failures as a result of this breaking service discovery. n the worst case, workloads may become unreachable, causing significant downtime and requiring manual intervention.
3. Prior to node upgrades, the Kubelet version was not checked.
Description:
Kubelet, which is used by worker nodes in an EKS cluster, must be compatible with the control plane version. Unexpected compatibility problems between the control plane and worker nodes may arise during an upgrade if the kubelet version is not checked.
Impact:
If the kubelet version is not compatible, worker nodes fail to join the cluster or experience degraded performance. This can lead to failed pod scheduling, increased API request failures, and potential service downtime, impacting application availability.
4. Helm charts are not being updated.
Description:
Helm charts specify the Kubernetes application deployment process. Every version of Kubernetes introduces new APIs and deprecates older ones. Helm charts may make reference to deprecated APIs that are no longer in use if you don't update them before upgrading.
Impact:
Applications that depend on out-of-date Helm charts may not deploy or execute properly, resulting in downtime. Your entire application stack might break in the worst situation, requiring quick fixes and delay your update.
Pre-requisites for EKS Upgrade:
An Amazon EKS cluster upgrade is a crucial operation that needs to be carefully planned to prevent compatibility problems and downtime. To guarantee a seamless transfer, certain preparatory procedures must be followed before moving forward with the upgrade. By following these checks, you can proactively detect and address API deprecation's, ensuring a smooth EKS upgrade without unexpected failures.
1. Check Dependency Information:
To check for API deprecation, use the AWS EKS Console:
The EKS dashboard now features an API Deprecation Report from AWS that searches your cluster and identifies deprecated Kubernetes APIs that your workloads use. Prior to updating, this function assists in identifying possible compatibility problems.
Example: API Deprecation in Kubernetes v1.25
Kubernetes v1.25 removed certain beta APIs, including:
PodDisruptionBudget.policy/v1beta1→ Must migrate topolicy/v1.Ingress.networking.k8s.io/v1beta1→ Must usenetworking.k8s.io/v1.
2. Verify NGINX Ingress Controller Compatibility
Before upgrading, make sure your current version of the NGINX Ingress Controller is compatible with the target EKS Kubernetes version if your cluster uses it. For services that depend on ingress traffic, incompatibilities may result in downtime, broken routing, or ingress failures.
3. Ensure Amazon EKS Add-ons Compatibility
EKS-managed add-ons must be updated for compatibility with the new Kubernetes version. Use the following commands to check and update add-ons:
VPC CNI Add-on: Check the latest version compatible with your target EKS version.
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
CoreDNS: Ensure the CoreDNS add-on is updated to the compatible version (check if any configuration changes are necessary).
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
Kube-proxy: Update to the appropriate version based on your target EKS version.
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
4. Backup Your EKS Cluster
Before initiating the upgrade process, it is critical to take a full backup of your EKS cluster. This backup will serve as a safety net, ensuring that you can quickly recover your cluster in case of unexpected issues, such as infrastructure loss or data corruption during the upgrade process.
Using Velero for Cluster Backup:
For backing up and recovering Kubernetes resources, such as persistent volumes, namespaces, configurations, and more, Velero is a powerful open-source tool designed for backing up and restoring Kubernetes resources. It integrates well with Amazon EKS and provides a simple way to create backups and restore resources in case of a failure.
You provide an additional degree of security by using Velero to create a backup before executing the upgrade, guaranteeing that your EKS environment can be quickly restored in case of emergency.
Validate Your Restore in a Lower Environment: You must also test the restore process in a non-production (lower) environment to ensure the backup is valid and All configurations and dependencies are properly restored.
Steps for EKS Upgrade:
You can start the EKS upgrade when you've finished the prerequisite checks and made the required backups. Follow these steps to ensure a smooth and efficient upgrade process.
Check Current Version:
aws eks describe-cluster --name <cluster-name> --query cluster.version --output
2. Control Plane Upgrade:
Updating the control plane to the desired Kubernetes version is the initial step in cluster upgrading.This is a critical step, as the control plane manages the overall cluster's operations.
Run the following command to update the control plane:
aws eks update-cluster-version --name <cluster-name> --kubernetes-version
Managed Node Groups Upgrade:
Once the control plane is updated, the next step is to upgrade your managed node groups to ensure they are compatible with the new Kubernetes version. This will allow your worker nodes to properly support the upgraded control plane.
Execute the following command to update your node group:
aws eks update-nodegroup-version --cluster-name <cluster-name> --nodegroup-name <node_group_name> --kubernetes-version
Key advantages:
Upgrading your Amazon EKS cluster offers several key advantages that directly impact performance, cost efficiency, and security. By the recommended upgrade process, we experienced significant improvements across the board.
Why should you upgrade EKS clusters?
Upgrading your EKS clusters is an essential step in maintaining the smooth operation of your Kubernetes environment. With each new version, Amazon introduces improvements that enhance performance, security, and reliability. This means that your clusters will not only run more efficiently but also be better protected against potential vulnerabilities.
If you’re managing workloads on Amazon Web Services (AWS), you’re probably aware of the benefits of using the Elastic Kubernetes Service (EKS). But did you know that regularly upgrading your EKS clusters can lead to significant cost savings?
Recently, we did the upgrade of our EKS cluster from version v1.23 to v1.30, and the results led to cost savings.” Not only did we experience improved stability and performance, but we also managed to save $360 per month in costs.
Understand the cost of control plan.
Amazon Web Services (AWS) charges for:
Control Plane Operations:
Standard Charge: $0.10 per hour per cluster.
Extended Support:
Additional Charge: $0.60 per hour per cluster for control plane extended support.
Here are some common mistakes to avoid:
We’ll walk through the most critical mistakes to avoid when upgrading an EKS cluster. For each mistake, we’ll cover its description and the potential impact on your infrastructure, helping you understand why avoiding these issues is essential for a smooth and successful upgrade.
1. Version compatibility checks are ignored.
Description:
Verifying that Helm charts and EKS add-ons (CoreDNS, kube-proxy, and VPC CNI) work with the latest version of Kubernetes is essential before upgrading.
Impact:
Skipping compatibility checks can lead to broken deployments, failed roll-outs, or unexpected behaviour in your applications. Incompatible ad-dons can cause networking issues, DNS failures, or even prevent critical services from starting. This can result in extended downtime and troubleshooting efforts.
2. Ad-dons are not upgraded before nodes.
Description:
The control plane, worker nodes, and ad-dons are parts of the EKS cluster. Because older ad-dons might not support new Kubernetes capabilities, upgrading worker nodes before updating CoreDNS and VPC CNI may result in incompatibilities.
Impact:
DNS resolution issues and network outages might result from using out-of-date CoreDNS or VPC CNI versions. Your micro-services may experience cascading failures as a result of this breaking service discovery. n the worst case, workloads may become unreachable, causing significant downtime and requiring manual intervention.
3. Prior to node upgrades, the Kubelet version was not checked.
Description:
Kubelet, which is used by worker nodes in an EKS cluster, must be compatible with the control plane version. Unexpected compatibility problems between the control plane and worker nodes may arise during an upgrade if the kubelet version is not checked.
Impact:
If the kubelet version is not compatible, worker nodes fail to join the cluster or experience degraded performance. This can lead to failed pod scheduling, increased API request failures, and potential service downtime, impacting application availability.
4. Helm charts are not being updated.
Description:
Helm charts specify the Kubernetes application deployment process. Every version of Kubernetes introduces new APIs and deprecates older ones. Helm charts may make reference to deprecated APIs that are no longer in use if you don't update them before upgrading.
Impact:
Applications that depend on out-of-date Helm charts may not deploy or execute properly, resulting in downtime. Your entire application stack might break in the worst situation, requiring quick fixes and delay your update.
Pre-requisites for EKS Upgrade:
An Amazon EKS cluster upgrade is a crucial operation that needs to be carefully planned to prevent compatibility problems and downtime. To guarantee a seamless transfer, certain preparatory procedures must be followed before moving forward with the upgrade. By following these checks, you can proactively detect and address API deprecation's, ensuring a smooth EKS upgrade without unexpected failures.
1. Check Dependency Information:
To check for API deprecation, use the AWS EKS Console:
The EKS dashboard now features an API Deprecation Report from AWS that searches your cluster and identifies deprecated Kubernetes APIs that your workloads use. Prior to updating, this function assists in identifying possible compatibility problems.
Example: API Deprecation in Kubernetes v1.25
Kubernetes v1.25 removed certain beta APIs, including:
PodDisruptionBudget.policy/v1beta1→ Must migrate topolicy/v1.Ingress.networking.k8s.io/v1beta1→ Must usenetworking.k8s.io/v1.
2. Verify NGINX Ingress Controller Compatibility
Before upgrading, make sure your current version of the NGINX Ingress Controller is compatible with the target EKS Kubernetes version if your cluster uses it. For services that depend on ingress traffic, incompatibilities may result in downtime, broken routing, or ingress failures.
3. Ensure Amazon EKS Add-ons Compatibility
EKS-managed add-ons must be updated for compatibility with the new Kubernetes version. Use the following commands to check and update add-ons:
VPC CNI Add-on: Check the latest version compatible with your target EKS version.
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
CoreDNS: Ensure the CoreDNS add-on is updated to the compatible version (check if any configuration changes are necessary).
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
Kube-proxy: Update to the appropriate version based on your target EKS version.
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
4. Backup Your EKS Cluster
Before initiating the upgrade process, it is critical to take a full backup of your EKS cluster. This backup will serve as a safety net, ensuring that you can quickly recover your cluster in case of unexpected issues, such as infrastructure loss or data corruption during the upgrade process.
Using Velero for Cluster Backup:
For backing up and recovering Kubernetes resources, such as persistent volumes, namespaces, configurations, and more, Velero is a powerful open-source tool designed for backing up and restoring Kubernetes resources. It integrates well with Amazon EKS and provides a simple way to create backups and restore resources in case of a failure.
You provide an additional degree of security by using Velero to create a backup before executing the upgrade, guaranteeing that your EKS environment can be quickly restored in case of emergency.
Validate Your Restore in a Lower Environment: You must also test the restore process in a non-production (lower) environment to ensure the backup is valid and All configurations and dependencies are properly restored.
Steps for EKS Upgrade:
You can start the EKS upgrade when you've finished the prerequisite checks and made the required backups. Follow these steps to ensure a smooth and efficient upgrade process.
Check Current Version:
aws eks describe-cluster --name <cluster-name> --query cluster.version --output
2. Control Plane Upgrade:
Updating the control plane to the desired Kubernetes version is the initial step in cluster upgrading.This is a critical step, as the control plane manages the overall cluster's operations.
Run the following command to update the control plane:
aws eks update-cluster-version --name <cluster-name> --kubernetes-version
Managed Node Groups Upgrade:
Once the control plane is updated, the next step is to upgrade your managed node groups to ensure they are compatible with the new Kubernetes version. This will allow your worker nodes to properly support the upgraded control plane.
Execute the following command to update your node group:
aws eks update-nodegroup-version --cluster-name <cluster-name> --nodegroup-name <node_group_name> --kubernetes-version
Key advantages:
Upgrading your Amazon EKS cluster offers several key advantages that directly impact performance, cost efficiency, and security. By the recommended upgrade process, we experienced significant improvements across the board.
Why should you upgrade EKS clusters?
Upgrading your EKS clusters is an essential step in maintaining the smooth operation of your Kubernetes environment. With each new version, Amazon introduces improvements that enhance performance, security, and reliability. This means that your clusters will not only run more efficiently but also be better protected against potential vulnerabilities.
If you’re managing workloads on Amazon Web Services (AWS), you’re probably aware of the benefits of using the Elastic Kubernetes Service (EKS). But did you know that regularly upgrading your EKS clusters can lead to significant cost savings?
Recently, we did the upgrade of our EKS cluster from version v1.23 to v1.30, and the results led to cost savings.” Not only did we experience improved stability and performance, but we also managed to save $360 per month in costs.
Understand the cost of control plan.
Amazon Web Services (AWS) charges for:
Control Plane Operations:
Standard Charge: $0.10 per hour per cluster.
Extended Support:
Additional Charge: $0.60 per hour per cluster for control plane extended support.
Here are some common mistakes to avoid:
We’ll walk through the most critical mistakes to avoid when upgrading an EKS cluster. For each mistake, we’ll cover its description and the potential impact on your infrastructure, helping you understand why avoiding these issues is essential for a smooth and successful upgrade.
1. Version compatibility checks are ignored.
Description:
Verifying that Helm charts and EKS add-ons (CoreDNS, kube-proxy, and VPC CNI) work with the latest version of Kubernetes is essential before upgrading.
Impact:
Skipping compatibility checks can lead to broken deployments, failed roll-outs, or unexpected behaviour in your applications. Incompatible ad-dons can cause networking issues, DNS failures, or even prevent critical services from starting. This can result in extended downtime and troubleshooting efforts.
2. Ad-dons are not upgraded before nodes.
Description:
The control plane, worker nodes, and ad-dons are parts of the EKS cluster. Because older ad-dons might not support new Kubernetes capabilities, upgrading worker nodes before updating CoreDNS and VPC CNI may result in incompatibilities.
Impact:
DNS resolution issues and network outages might result from using out-of-date CoreDNS or VPC CNI versions. Your micro-services may experience cascading failures as a result of this breaking service discovery. n the worst case, workloads may become unreachable, causing significant downtime and requiring manual intervention.
3. Prior to node upgrades, the Kubelet version was not checked.
Description:
Kubelet, which is used by worker nodes in an EKS cluster, must be compatible with the control plane version. Unexpected compatibility problems between the control plane and worker nodes may arise during an upgrade if the kubelet version is not checked.
Impact:
If the kubelet version is not compatible, worker nodes fail to join the cluster or experience degraded performance. This can lead to failed pod scheduling, increased API request failures, and potential service downtime, impacting application availability.
4. Helm charts are not being updated.
Description:
Helm charts specify the Kubernetes application deployment process. Every version of Kubernetes introduces new APIs and deprecates older ones. Helm charts may make reference to deprecated APIs that are no longer in use if you don't update them before upgrading.
Impact:
Applications that depend on out-of-date Helm charts may not deploy or execute properly, resulting in downtime. Your entire application stack might break in the worst situation, requiring quick fixes and delay your update.
Pre-requisites for EKS Upgrade:
An Amazon EKS cluster upgrade is a crucial operation that needs to be carefully planned to prevent compatibility problems and downtime. To guarantee a seamless transfer, certain preparatory procedures must be followed before moving forward with the upgrade. By following these checks, you can proactively detect and address API deprecation's, ensuring a smooth EKS upgrade without unexpected failures.
1. Check Dependency Information:
To check for API deprecation, use the AWS EKS Console:
The EKS dashboard now features an API Deprecation Report from AWS that searches your cluster and identifies deprecated Kubernetes APIs that your workloads use. Prior to updating, this function assists in identifying possible compatibility problems.
Example: API Deprecation in Kubernetes v1.25
Kubernetes v1.25 removed certain beta APIs, including:
PodDisruptionBudget.policy/v1beta1→ Must migrate topolicy/v1.Ingress.networking.k8s.io/v1beta1→ Must usenetworking.k8s.io/v1.
2. Verify NGINX Ingress Controller Compatibility
Before upgrading, make sure your current version of the NGINX Ingress Controller is compatible with the target EKS Kubernetes version if your cluster uses it. For services that depend on ingress traffic, incompatibilities may result in downtime, broken routing, or ingress failures.
3. Ensure Amazon EKS Add-ons Compatibility
EKS-managed add-ons must be updated for compatibility with the new Kubernetes version. Use the following commands to check and update add-ons:
VPC CNI Add-on: Check the latest version compatible with your target EKS version.
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
CoreDNS: Ensure the CoreDNS add-on is updated to the compatible version (check if any configuration changes are necessary).
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
Kube-proxy: Update to the appropriate version based on your target EKS version.
aws eks describe-addon-versions --kubernetes-version <target-version> --addon-name
4. Backup Your EKS Cluster
Before initiating the upgrade process, it is critical to take a full backup of your EKS cluster. This backup will serve as a safety net, ensuring that you can quickly recover your cluster in case of unexpected issues, such as infrastructure loss or data corruption during the upgrade process.
Using Velero for Cluster Backup:
For backing up and recovering Kubernetes resources, such as persistent volumes, namespaces, configurations, and more, Velero is a powerful open-source tool designed for backing up and restoring Kubernetes resources. It integrates well with Amazon EKS and provides a simple way to create backups and restore resources in case of a failure.
You provide an additional degree of security by using Velero to create a backup before executing the upgrade, guaranteeing that your EKS environment can be quickly restored in case of emergency.
Validate Your Restore in a Lower Environment: You must also test the restore process in a non-production (lower) environment to ensure the backup is valid and All configurations and dependencies are properly restored.
Steps for EKS Upgrade:
You can start the EKS upgrade when you've finished the prerequisite checks and made the required backups. Follow these steps to ensure a smooth and efficient upgrade process.
Check Current Version:
aws eks describe-cluster --name <cluster-name> --query cluster.version --output
2. Control Plane Upgrade:
Updating the control plane to the desired Kubernetes version is the initial step in cluster upgrading.This is a critical step, as the control plane manages the overall cluster's operations.
Run the following command to update the control plane:
aws eks update-cluster-version --name <cluster-name> --kubernetes-version
Managed Node Groups Upgrade:
Once the control plane is updated, the next step is to upgrade your managed node groups to ensure they are compatible with the new Kubernetes version. This will allow your worker nodes to properly support the upgraded control plane.
Execute the following command to update your node group:
aws eks update-nodegroup-version --cluster-name <cluster-name> --nodegroup-name <node_group_name> --kubernetes-version
Key advantages:
Upgrading your Amazon EKS cluster offers several key advantages that directly impact performance, cost efficiency, and security. By the recommended upgrade process, we experienced significant improvements across the board.
