With savings of up to 20% when using Graviton instances, this how-to explainer will look at how simple it is to run both Graviton (ARM) and X86 instances on an EKS cluster.
Both architectures have its pros and cons, combining these two in well designed infrastructure we could achieve higher standards in terms of performance and cost. As for ARM processors, they are based on the RISC (Reduced Instruction Set Computer) architecture, which is much simpler than CISC (x86), x86 can perform complex calculations in less time as a result it need more power which means more heat. This is just only one difference, but there is more…
Following is a infrastructure setup using AWS Graviton and AMD EPYC..
|AWS EKS Cluster||1.21|
Note: The above label on the nodes within the Graviton node group.
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.2.0/deploy/static/provider/aws/deploy.yaml
Note: From deploying the nginx ingress, you can see the pods can be easily scheduled on the Graviton instances and you also have the ability to schedule them on the x86 instances.
$ kubectl apply -f https://raw.githubusercontent.com/microservices-demo/microservices-demo/master/deploy/kubernetes/complete-demo.yaml
$ kubectl logs -f carts-b4d4ffb5c-mzf7v -n sock-shop standard_init_linux.go:228: exec user process caused: exec format error
nodeSelector: beta.kubernetes.io/os: linux kubernetes.io/arch: amd64
Note: The sock shop application will support only amd64 architecture, here the pod is trying to schedule on the graviton node group that is using an arm64 processor.
Note: For EKS cluster autoscaler installation, please refer.
As you can see it’s quite easy to add a graviton node group to the cluster and use the popular tooling as long as the containers are in this list, it should work on both graviton and x86 architectures.
Looking for help with your Infrastructure or want help with your DevOps implementation strategy? Reach out to us and see how we can help.