How to migrate Seamlessly Migrating Your EKS Nodes to ARM/Graviton: Good for your Money and the Planet

In this guide, I’ll walk you through the process of migrating your EKS nodes from the X86 architecture to ARM without disrupting your workload in the AWS EKS context using Terraform. My aim is to share insights and lessons learned from my own experience migrating EKS cluster nodes to ARM.

TL;DR:
The article provides a technical guide for migrating EKS nodes to ARM processors. Key steps include setting up new node groups specifically for Graviton instances, ensuring applications and Docker images are ARM-compatible, and updating deployment configurations. The process emphasizes the need for careful compatibility checks and the potential adjustments required for libraries and applications that are typically designed for x86 architectures. RISC family Processors not only optimizes costs but also align with environmental sustainability by reducing power consumption.

Understanding ARM Processors

ARM (Advanced RISC Machine) processors belong to a family of processors based on a RISC (Reduced Instruction Set Computing) architecture. Unlike traditional x86 architectures primarily used in Intel and AMD processors, ARM processors prioritize energy efficiency while maintaining competitive performance.

Key Features of ARM Processors :

• RISC Architecture: Simplified instructions enable faster execution compared to the complex instructions of CISC architectures.
• Low Energy Consumption: The simplicity and speed of ARM instructions result in lower power consumption, benefiting both the environment and cost saving

What about Graviton processors ?

The Graviton processor, developed by Amazon Web Services (AWS), is a custom ARM processor optimized for cloud workloads. Sharing the advantages of ARM processors, Graviton processors are identifiable by the “g” suffix in their names (m6g, m6g.medium, m6g.large, m6g.xlarge, etc)

Now you know what is ARM and why they are important, it’s time to have your hands dirty and migrate your workload.

IMPORTANT: Before migrating your workload to ARM, ensure compatibility with ARM processors. Many libraries and applications are designed for x86 processors by default and may require adjustments or compatible versions for ARM processors.😉

Prerequisites

To follow the steps below, ensure you have Docker Desktop installed, Terraform, Kubectl, and an EKS Cluster set up.

Let’s Go

Please note that the steps outlined below are tailored for EKS nodes managed with Cluster Autoscaler. If you are managing your nodes with Karpenter, the procedure will differ ( Might be the subject of another article ?!).

Step 1 — Setting Up New Node Groups for ARM

The first step is to add a new node group that will contain only graviton instances. At this step two information are important to ensure that your node is dedicated only to the Graviton processor :

• Add a new node group containing only Graviton instances.
• Configure the ami_type parameter with the value AL2_ARM_64 and specify instance_types with instances containing “g” in their names (e.g., m6g.large).

Apply your changes and inspect your cluster to view the new instances.

Step 2— Verifying Node Creation

Get the list of nodes that are located on your AMR Nodegoup. In my case cluster10-nodegroup-m6glarge

kubectl get nodes — selector eks.amazonaws.com/nodegroup=cluster10-nodegroup-m6glarge

Check node details to confirm ARM architecture (e.g., arm64)

kubeclt describe node id-node-arm

You can see in the information related to system info that the Architecture is : arm64

Step 3— Directing Applications to ARM Nodes

To force the pod of your deployment to run in a new arm node for testing/validating, add NodeAffinity in spec. NodeAffinity is a great functionality in Kubernetes designed to helping you to chose in which node you want your application run (pod). With this parameter, the control plane will always schedule the pod based on the NodeSelectorTerms.

Validate that your application is running on the nodes for ARM that you’ve created

kubectl get pods — all-namespaces — field-selector spec.nodeName=id-node-arm

Except if your image has been built in multi-arch mode, the pods of your application won’t be able to start and will be in-state CrashLoopBackOff.

That indicates your Docker image is not ARM-compatible, which is typical if you’ve built the image without explicitly instructing Docker to build it for ARM architecture.

For instance, in this tutorial, I created a Gunicorn Docker image, and as depicted below, the error message clearly indicates that the format is incompatible with ARM.

Step 4— Build Docker image in ARM

To fix the problem, the image must be rebuild to be ARM compatible. You can install buildx to extend docker capability to build ARM image as the command below.

docker buildx build — platform=linux/arm64 -t xxxxxxxxxx.dkr.ecr.eu-west-1.amazonaws.com/test-frontend:test-arm

Then I push the image to ECR

docker push xxxxxxxxxx.dkr.ecr.eu-west-1.amazonaws.com/test-frontend:test-arm

Important : Important: If your application relies on an external library, you may encounter compatibility issues due to the lack of a suitable version for the ARM architecture of your library. In such cases, you’ll need to update your code as previously explained

Step 5—Updating Image Versions and Deployment

Change the docker image version in your Kubernetes yaml file, to use the one build for ARM, then relaunch your deployment, to see your application running properly

Important: When you add a new node, the Kubernetes control plane automatically assigns pods to that node if it has available resources. This means that applications in other namespaces may be affected if their images are not compatible with ARM architecture. It’s crucial to test this procedure in a non-production environment, specifically for migrating to ARM for a specific application. For production deployments, I recommend building your images in a multi-architecture format to mitigate this issue..

Et Voilà, you’ve migrated your node an application to ARM which are good for your money and the planet

I’m Hervé-Gaël KOUAMO, Founder and CTO of HK-TECH, a French tech company specializing in designing, building, and optimizing applications. Our mission is to assist businesses throughout their cloud migration journey, ensuring seamless transitions and maximizing their digital potential. You can follow me on LinkedIn : https://www.linkedin.com/in/herv%C3%A9-ga%C3%ABl-kouamo-157633197/