[AEWS] #3주차 ARM, AMD 아키텍처, Graviton에 파드, BottleRocketAMI 실습 (4)

25년도 AWS EKS Hands-on Study 스터디 정리 내용입니다.

ARM, AMD 

ARM과 AMD는 CPU 아키텍처 처리 방식이다. ARM과 AMD의 차이는 아키텍처 설계 철학이 다르며, 사용자가 어떤 용도로 CPU를 사용할지에 따라 적절한 아키텍처를 선택하는 것이 필요하다.

 

ARM은 RISC(Reduced Instruction Set Computing, 축소 명령어 집합 컴퓨팅) 아키텍처를 기반으로 설계된다. 이 방식은 명령어의 종류를 단순화하여 CPU가 더 빠르고 효율적으로 작동하도록 설계되었다. 명령어가 간단하면 실행 속도가 빨라지고전력 소비도 줄일 수 있는데 ARM 기반 프로세서는 저전력, 높은 전력 효율성, 발열이 적은 특성을 갖는다. 이러한 이유로 스마트폰, 태블릿, 임베디드 시스템, 저전력 서버 등에 널리 사용되고 대표적으로 애플의 M1, M2 칩과 퀄컴의 Snapdragon 프로세서가 대표적인 ARM 기반 칩이다.

 

AMD는 CISC(Complex Instruction Set Computing, 복합 명령어 집합 컴퓨팅) 아키텍처를 기반으로 하는 x86 프로세서를 설계한다. CISC 방식은 복잡한 명령어를 한 번에 실행할 수 있어 보다 강력한 연산 능력을 제공한다. 하지만 명령어가 복잡해질수록 전력 소비가 증가하고 발열이 발생한다. AMD의 CPU는 고성능 연산이 필요한 환경에서 강점을 발휘하며, 데스크톱, 서버, 게임용 PC, 데이터센터 등의 고성능 컴퓨팅 환경에서 많이 사용된다. 대표적인 제품으로는 라이젠, EPYC 서버 프로세서 등이 있다.

 

두 아키텍처는 각기 다른 용도와 장점을 갖고 있다. ARM 기반 칩은 저전력, 긴 배터리 수명, 모바일 및 에너지 효율적인 환경에서 강점을 보이며, AMD의 x86 기반 칩은 고성능 연산과 멀티태스킹이 필요한 환경에서 더 적합하다. 최근에는 ARM 기반 칩도 성능을 향상시키면서 서버와 데스크톱 시장으로 확장하고 있으며, 반대로 AMD도 전력 효율성을 개선하고 있다.

 

AWS graviton

AWS Graviton은 AWS가 자체 설계한 ARM 기반의 프로세서로, 고성능과 에너지 효율성을 동시에 제공한다.

Graviton 프로세서는 클라우드 환경에서 최적화된 성능과 비용 효율성을 제공하도록 설게되었으며 웹 애플리케이션, 컨테이너, 마이크로서비스, 빅데이터 분석, ML 등 다양한 워크로드에서 우수한 성능을 발휘한다.

eksctl create nodegroup -c $CLUSTER_NAME -r ap-northeast-2 --subnet-ids "$PubSubnet1","$PubSubnet2","$PubSubnet3" \
  -n ng3 -t t4g.medium -N 1 -m 1 -M 1 --node-volume-size=30 --node-labels family=graviton --dry-run > myng3.yaml

eksctl create nodegroup -f myng3.yaml

kubectl get nodes --label-columns eks.amazonaws.com/nodegroup,kubernetes.io/arch,eks.amazonaws.com/capacityType
NAME                                               STATUS   ROLES    AGE     VERSION               NODEGROUP   ARCH    CAPACITYTYPE
ip-192-168-1-127.ap-northeast-2.compute.internal   Ready    <none>   2m24s   v1.31.5-eks-5d632ec   ng3         arm64   ON_DEMAND
...


kubectl describe nodes --selector family=graviton
...
System Info:
  Machine ID:                 ec22fa7316c4486fe019bf98a12d486b
  System UUID:                ec22fa73-16c4-486f-e019-bf98a12d486b
  Boot ID:                    837ae6ee-0bb0-4615-bd23-da6bc27ecf56
  Kernel Version:             5.10.233-224.894.amzn2.aarch64
  OS Image:                   Amazon Linux 2
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.25
  Kubelet Version:            v1.31.5-eks-5d632ec
  Kube-Proxy Version:         v1.31.5-eks-5d632ec
ProviderID:                   aws:///ap-northeast-2a/i-008befacce404ca12
Non-terminated Pods:          (4 in total)
  Namespace                   Name                  CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                  ------------  ----------  ---------------  -------------  ---
  kube-system                 aws-node-f4kld        50m (2%)      0 (0%)      0 (0%)           0 (0%)         2m29s
  kube-system                 ebs-csi-node-4wdqw    30m (1%)      0 (0%)      120Mi (3%)       768Mi (23%)    2m29s
  kube-system                 efs-csi-node-kv8rj    0 (0%)        0 (0%)      0 (0%)           0 (0%)         2m29s
  kube-system                 kube-proxy-gktwf      100m (5%)     0 (0%)      0 (0%)           0 (0%)         2m29s
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                180m (9%)   0 (0%)
  memory             120Mi (3%)  768Mi (23%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)
  hugepages-32Mi     0 (0%)      0 (0%)
  hugepages-64Ki     0 (0%)      0 (0%)
Events:
  Type     Reason                   Age                    From                   Message
  ----     ------                   ----                   ----                   -------
  Normal   Starting                 2m26s                  kube-proxy
  Normal   Starting                 2m30s                  kubelet                Starting kubelet.
  Warning  CgroupV1                 2m30s                  kubelet                Cgroup v1 support is in maintenance mode, please migrate to Cgroup v2.
  Warning  InvalidDiskCapacity      2m30s                  kubelet                invalid capacity 0 on image filesystem
  Normal   NodeHasSufficientMemory  2m30s (x2 over 2m30s)  kubelet                Node ip-192-168-1-127.ap-northeast-2.compute.internal status is now: NodeHasSufficientMemory
  Normal   NodeHasNoDiskPressure    2m30s (x2 over 2m30s)  kubelet                Node ip-192-168-1-127.ap-northeast-2.compute.internal status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID     2m30s (x2 over 2m30s)  kubelet                Node ip-192-168-1-127.ap-northeast-2.compute.internal status is now: NodeHasSufficientPID
  Normal   NodeAllocatableEnforced  2m30s                  kubelet                Updated Node Allocatable limit across pods
  Normal   Synced                   2m29s                  cloud-node-controller  Node synced successfully
  Normal   RegisteredNode           2m27s                  node-controller        Node ip-192-168-1-127.ap-northeast-2.compute.internal event: Registered Node ip-192-168-1-127.ap-northeast-2.compute.internal in Controller
  Normal   NodeReady                2m15s                  kubelet                Node ip-192-168-1-127.ap-northeast-2.compute.internal status is now: NodeReady

 

aws eks update-nodegroup-config --cluster-name $CLUSTER_NAME --nodegroup-name ng3 \
--taints "addOrUpdateTaints=[{key=frontend, value=true, effect=NO_EXECUTE}]"

kubectl describe nodes --selector family=graviton | grep Taints
Taints:             frontend=true:NoExecute

aws eks describe-nodegroup --cluster-name $CLUSTER_NAME --nodegroup-name ng3 | jq .nodegroup.taints[
  {
    "key": "frontend",
    "value": "true",
    "effect": "NO_EXECUTE"
  }
]

 

노드에 taint 설정을 걸어준 후 파드를 배포한다.

 

cat <<EOF | kubectl apply -f -
> apiVersion: v1
> kind: Pod
> metadata:
>   name: busybox
> spec:
>   terminationGracePeriodSeconds: 3
>   containers:
>   - name: busybox
>     image: busybox
>     command:
>     - "/bin/sh"
>     - "-c"
>     - "while true; do date >> /home/pod-out.txt; cd /home; sync; sync; sleep 10; done"
>   tolerations:
>     - effect: NoExecute
>       key: frontend
>       operator: Exists
>   nodeSelector:
>     family: graviton
> EOF
pod/busybox created

kubectl get pod -owide
NAME                    READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
busybox                 1/1     Running   0          6s    192.168.1.244   ip-192-168-1-127.ap-northeast-2.compute.internal   <none>           <none>

 

busybox를 graviton 노드에 띄운다. 

 

kubectl exec -it busybox -- arch
aarch64

kubectl exec -it busybox -- tail -f /home/pod-out.txt
Sat Feb 22 02:43:11 UTC 2025
Sat Feb 22 02:43:21 UTC 2025
Sat Feb 22 02:43:31 UTC 2025
Sat Feb 22 02:43:41 UTC 2025
Sat Feb 22 02:43:51 UTC 2025
Sat Feb 22 02:44:01 UTC 2025
Sat Feb 22 02:44:11 UTC 2025

 

busybox 파드가 x86이 아닌 ARM(Graviton)기반의 인스턴스에서 실행되고 있음을 확인할 수 있다.

BottleRocket AMI

클라우드 환경에서 컨테이너를 실행할 때 일반적으로 Amazon Linux, Ubuntu 같은 일반적인 리눅스 배포판을 사용한다.

하지만 이런 운영체제는 컨테이너를 실행하는 것 외에도 많은 여러 패키지와 서비스가 포함되어 있어 보안 관리와 업데이트가 복잡할 수 있다.

이를 해결하기 위해 AWS에서는 Bottlerocket이라는 컨테이저 전용 운영체제를 개발했다.

Bottlerocket은 컨테이너 실행에 필요한 최소한의 구성만 포함하여 경량화된 OS이며 보안과 성능 최적화에 초점을 맞추었다고 한다.

 

cat << EOF > ng-br.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: myeks
  region: ap-northeast-2
  version: "1.31"

managedNodeGroups:
- name: ng-bottlerocket
  instanceType: m5.large
  amiFamily: Bottlerocket
  bottlerocket:
    enableAdminContainer: true
    settings:
      motd: "Hello, eksctl!"
  desiredCapacity: 1
  maxSize: 1
  minSize: 1
  labels:
    alpha.eksctl.io/cluster-name: myeks
    alpha.eksctl.io/nodegroup-name: ng-bottlerocket
    ami: bottlerocket
  subnets:
  - $PubSubnet1
  - $PubSubnet2
  - $PubSubnet3
  tags:
    alpha.eksctl.io/nodegroup-name: ng-bottlerocket
    alpha.eksctl.io/nodegroup-type: managed

- name: ng-bottlerocket-ssh
  instanceType: m5.large
  amiFamily: Bottlerocket
  desiredCapacity: 1
  maxSize: 1
  minSize: 1
  ssh:
    allow: true
    publicKeyName: $SSHKEYNAME
  labels:
    alpha.eksctl.io/cluster-name: myeks
    alpha.eksctl.io/nodegroup-name: ng-bottlerocket-ssh
    ami: bottlerocket
  subnets:
  - $PubSubnet1
  - $PubSubnet2
  - $PubSubnet3
  tags:
    alpha.eksctl.io/nodegroup-name: ng-bottlerocket-ssh
    alpha.eksctl.io/nodegroup-type: managed
EOF

eksctl create nodegroup -f ng-br.yaml

 

 

kubectl get node --label-columns=alpha.eksctl.io/nodegroup-name,ami,node.kubernetes.io/instance-type


kubectl get node --label-columns=alpha.eksctl.io/nodegroup-name,ami,node.kubernetes.io/instance-type
NAME                                               STATUS   ROLES    AGE     VERSION               NODEGROUP-NAME        AMI            INSTANCE-TYPE
ip-192-168-1-13.ap-northeast-2.compute.internal    Ready    <none>   5d15h   v1.31.5-eks-5d632ec   ng1                                  t3.medium
ip-192-168-1-69.ap-northeast-2.compute.internal    Ready    <none>   2m40s   v1.31.4-eks-0f56d01   ng-bottlerocket-ssh   bottlerocket   m5.large
ip-192-168-2-229.ap-northeast-2.compute.internal   Ready    <none>   5d15h   v1.31.5-eks-5d632ec   ng1                                  t3.medium
ip-192-168-2-249.ap-northeast-2.compute.internal   Ready    <none>   2m40s   v1.31.4-eks-0f56d01   ng-bottlerocket       bottlerocket   m5.large
ip-192-168-3-122.ap-northeast-2.compute.internal   Ready    <none>   5d15h   v1.31.5-eks-5d632ec   ng1                                  t3.medium