Since 2020, AWS has supported running ARM-based Kubernetes worker nodes using AWS Graviton processors. Graviton is an ARM 64-bit CPU family designed by AWS to provide more performance with less power consumption than Intel/AMD processors. Currently, the Graviton2 CPUs are available on sixth-generation instances, and the Graviton3 CPUs are available on the seventh-generation. In AWS, ARM-based instances are cheaper than Intel/AMD instances. More performance, less consumption and cost.

Follow our social media:

https://www.linkedin.com/in/ssbostan

https://www.linkedin.com/company/kubedemy

https://www.youtube.com/@kubedemy

https://telegram.me/kubedemy

Register for the FREE EKS Tutorial:

If you want to access the course materials, register from the following link:

Register for the FREE AWS EKS Black Belt Course

Watch on YouTube:

ARM-based Instances key facts:

  • 35% faster than x86-64 processors in running Redis.
  • 30% faster than x86-64 processors in running Apache Cassandra.
  • 115% higher throughput than x86-64 processors in running MongoDB.
  • 70% less power consumption than x86-64 processors.
  • 20% less cost than x86-64 EC2 instances.

When to choose ARM-based instances:

Applications need to be compiled for ARM64 architecture to be able to run on ARM-based instances. So, your application must support ARM-based architecture, or if you use interpreted programming languages, like Python, its runtime must be available for the ARM64 platform. In EKS, you can have both arm64 and x86_64 instances simultaneously and run your applications based on their architectures on the proper nodes.

AWS EC2 Instance type naming convention:

Every EC2 instance type is named based on its family, generation, processor family, additional capabilities and size. If the processor family is not mentioned in the instance type name, it will be an Intel or AMD processor instance.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html

The processor family can be:

  • i: Intel processor.
  • a: AMD processor.
  • g: Graviton processor.

ARM-based worker node deployment procedure:

  • Find Graviton ARM-based instance types.
  • Deploy EKS ARM-based managed node groups.
  • Test ARM-based Kubernetes worker nodes.

Step 1 – Find AWS Graviton ARM-based instances:

To list all available ARM-based instance types, execute the following command:

aws ec2 describe-instance-types \
  --filters "Name=current-generation,Values=true" \
  "Name=processor-info.supported-architecture,Values=arm64" \
  --query "InstanceTypes[*].InstanceType"

To list all available ARM-based instances with specific resources:

aws ec2 describe-instance-types \
  --filters "Name=current-generation,Values=true" \
  "Name=vcpu-info.default-vcpus,Values=2" \
  "Name=memory-info.size-in-mib,Values=4096" \
  "Name=processor-info.supported-architecture,Values=arm64" \
  --query "InstanceTypes[*].InstanceType"

Step 2 – Deploy ARM-based worker nodes:

To deploy a node group for cluster-critical workloads:

aws eks create-nodegroup \
  --cluster-name kubedemy \
  --nodegroup-name system-arm-managed-workers-001 \
  --scaling-config minSize=2,maxSize=5,desiredSize=2 \
  --subnets subnet-0ff015478090c2174 subnet-01b107cea804fdff1 subnet-09b7d720aca170608 \
  --node-role arn:aws:iam::231144931069:role/Kubedemy_EKS_Managed_Nodegroup_Role \
  --remote-access ec2SshKey=kubedemy \
  --instance-types c6g.xlarge \
  --ami-type AL2_ARM_64 \
  --capacity-type ON_DEMAND \
  --update-config maxUnavailable=1 \
  --taints "key=CriticalAddonsOnly,value=true,effect=NO_SCHEDULE" "key=CriticalAddonsOnly,value=true,effect=NO_EXECUTE" \
  --labels node.kubernetes.io/scope=system \
  --tags owner=kubedemy

To deploy a node group for applications:

aws eks create-nodegroup \
  --cluster-name kubedemy \
  --nodegroup-name application-arm-managed-workers-001 \
  --scaling-config minSize=2,maxSize=5,desiredSize=2 \
  --subnets subnet-0ff015478090c2174 subnet-01b107cea804fdff1 subnet-09b7d720aca170608 \
  --node-role arn:aws:iam::231144931069:role/Kubedemy_EKS_Managed_Nodegroup_Role \
  --remote-access ec2SshKey=kubedemy \
  --instance-types c6g.xlarge \
  --ami-type AL2_ARM_64 \
  --capacity-type ON_DEMAND \
  --update-config maxUnavailable=1 \
  --labels node.kubernetes.io/scope=application \
  --tags owner=kubedemy

Step 3 – Test Kubernetes ARM-based worker nodes:

In Kubernetes, worker nodes’ architecture is specified within kubernetes.io/arch label. On ARM worker nodes, only ARM-based images can be deployed.

Run this command to see nodes and their architecture:

kubectl get no -L kubernetes.io/arch

Now, if you try to run a Pod using a non-ARM image, you’ll get an error:

kubectl run test --image ssbostan/alpine-nonroot:latest

But if you run a Pod using an image with ARM-arch available:

kubectl run redis --image redis:latest

Conclusion:

ARM is a cool processor as it follows the RISC architecture, and it’s quite faster than CISC-based processors like Intel/AMD. When it comes to Kubernetes, it means you have a faster train with less power consumption to reach the destination; the only thing you need to be aware of is your images need to be built for ARM architecture.

If you like this series of articles, please share them and write your thoughts as comments here. Your feedback encourages me to complete this massively planned program. Just share them and provide feedback. I’ll make you an AWS EKS black belt.

Follow my LinkedIn https://www.linkedin.com/in/ssbostan

Follow Kubedemy LinkedIn https://www.linkedin.com/company/kubedemy

Follow Kubedemy Telegram https://telegram.me/kubedemy

Leave a Reply

Your email address will not be published. Required fields are marked *