모험가

AEWS 7주차 - EKS Mode/Nodes(EKS Automode) 본문

쿠버네티스/AEWS

AEWS 7주차 - EKS Mode/Nodes(EKS Automode)

라리음 2025. 3. 20. 15:38
본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다. 
모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다!

 

 

 

 

 

EKS Auto Mode

 

 

EKS Auto Mode란?

EKS Auto Mode는 2024년 12월에 출시한 신기능입니다. Auto Mode라는 말 그대로 사용자는 자동으로 더 AWS에게 맡긴다는 의미가 될 수 있네요. 아래 그림과 같이 일반적인 EKS는 Control Plane에 대해서만 완전관리를 지원해주며 EKS addon, EC2인스턴스 유지관리, 이외의 리소스에 대해서는 고객이 관리했습니다. Auto Mode는 EKS addon과 EC2인스턴스의 유지관리까지 도움을 줍니다. 기본적인 addon들을 모두 제공(karpenter 포함)하여 보다 편리하고 비용 효율적인 환경에서 사용자는 워크로드에만 집중할 수 있도록 출시하였습니다.

 

 

 

Auto Mode X 아키텍처

AWS re:Invent 2024 - The future of Kubernetes on AWS (KUB201)

 

 

Auto Mode O 아키텍처

AWS re:Invent 2024 - The future of Kubernetes on AWS (KUB201)

 

https://www.youtube.com/watch?v=IQjsFlkqWQY

 

 

 

그림들과 같이 compute, network, storage, observe에 관한 driver들과 addon들은 모두 AWS에서 관리해줍니다.

고객 관리 영역에는 OSS/ETC들이 존재합니다. (ex) istio)

 

 

그러면 책임 영역(Model)은 어떻게 변화할까요?

 

[출처] AWS re:Invent 2024 - Automate your entire Kubernetes cluster with Amazon EKS Auto Mode (KUB204-NEW)



[출처] AWS re:Invent 2024 - Automate your entire Kubernetes cluster with Amazon EKS Auto Mode (KUB204-NEW)

 

이와 같이 Cluster EC2 Instances와 Cluster Capabilities은 모두 이제 AWS에서 관리하기 때문에 AWS의 책임 모델로 되었습니다.

 

그러면 computing 관련해서 AWS가 어떤 방식으로 안전을 보장할까요?

 

EKS Auto Mode는 노드에 대해 불변으로 취급되는 AMI를 사용합니다. 이러한 AMI는 잠금 소프트웨어를 강제하고 SELinux 필수 액세스 제어를 활성화하며 읽기 전용 루트 파일 시스템을 제공합니다. 또한 EKS Auto Mode에서 실행하는 노드의 최대 수명은 21일이며(이를 줄일 수 있습니다), 그 후에는 자동으로 새 노드로 교체됩니다.

 

그리고 computing, eks addon을 모두 관리해주기에 자동으로 업그레이드를 진행해줍니다. 기존에는 고객이 addon 버전, controlplane, dataplane을 업그레이드하는데 많은 시간을 썼다면 이제 AWS에서 이를 대신 진행해주기에 편리합니다.

* 대신 자신의 워크로드에 문제가 없는지 체크는 필요합니다.

 

 

Auto Mode 기능

 

  • 자동화 지원 구성요소 : The following is a list of data plane components that are automated
    • Compute: EKS 자동 모드를 사용하면 많은 워크로드에서 EKS 클러스터의 여러 측면을 잊어버릴 수 있습니다. 여기에는 다음이 포함됩니다:
      • Nodes: EKS 자동 모드 노드는 가전제품처럼 취급되도록 설계되었습니다. EKS 자동 모드는 다음을 수행합니다:
        • 작업 부하를 개입 없이 실행하는 데 필요한 다양한 서비스로 구성된 적절한 AMI를 선택합니다.
        • SELinux 강제 모드와 읽기 전용 루트 파일 시스템을 사용하여 AMI의 파일에 대한 액세스를 차단합니다.
        • SSH 또는 SSM 액세스를 허용하지 않음으로써 노드에 대한 직접 액세스를 방지합니다.
        • GPU 지원이 포함되어 있으며, 별도의 커널 드라이버와 NVIDIA 및 Neuron GPU용 플러그인이 있어 고성능 워크로드를 지원합니다.
      • Auto scaling: Karpenter 자동 확장을 기반으로 EKS Auto Mode는 일정에 맞지 않는 포드를 모니터링하고 새로운 노드를 배포하여 포드를 실행할 수 있도록 합니다. 워크로드가 종료되면 EKS Auto Mode는 더 이상 필요하지 않은 노드를 동적으로 중단하고 종료하여 리소스 사용을 최적화합니다.
      • Upgrades: 노드를 제어하면 필요에 따라 보안 패치와 운영 체제 및 구성 요소 업그레이드를 제공하는 EKS Auto Mode의 기능이 간소화됩니다. 이러한 업그레이드는 워크로드의 중단을 최소화하도록 설계되었습니다. EKS Auto Mode는 최신 소프트웨어 및 API를 보장하기 위해 최대 21일의 노드 수명을 적용합니다.
    • Load balancing: EKS Auto Mode는 Amazon의 Elastic Load Balancer 서비스와 통합하여 로드 밸런싱을 간소화하여 Kubernetes 서비스 및 입력 리소스에 대한 로드 밸런싱 장치의 프로비저닝 및 구성을 자동화합니다. 이 시스템은 애플리케이션 및 네트워크 로드 밸런싱 장치 모두에 고급 기능을 지원하고, 수명 주기를 관리하며, 클러스터 수요에 맞게 확장할 수 있습니다. 이 통합은 AWS 모범 사례를 준수하는 생산 준비형 로드 밸런싱 솔루션을 제공하므로 인프라 관리보다는 애플리케이션에 집중할 수 있습니다.
    • Storage: EKS 자동 모드는 볼륨 유형, 볼륨 크기, 암호화 정책 및 노드 종료 시 삭제 정책을 설정하여 임시 스토리지를 구성합니다.
    • Networking: EKS Auto 모드는 Pod 및 서비스 연결을 위한 중요한 네트워킹 작업을 자동화합니다. 여기에는 IPv4/IPv6 지원과 IP 주소 공간 확장을 위한 보조 CIDR 블록 사용이 포함됩니다.
    • Identity and Access Management: EKS 자동 모드 클러스터에 EKS Pod Identity Agent를 설치할 필요는 없습니다.

 

 

스터디의 내용을 그대로 발췌했습니다.

 

여기에서 AMI 파일에 대한 엑세스 차단과 노드에 대한 직접 엑세스를 막은게 특징으로 보입니다.

책임 모델이 AWS에게 있는만큼 사용자가 직접 일으킬 수 있는 장애들을 최대한 막고자하는 것으로 생각이되네요

 

 

이러한 AWS Auto Mode 장점이 많은데 왜 많은 사용자들이 바로 도입하지 않는 것일까요?

 

바로 제약 사항들이 존재하다 보니까 신기능 도입을 아직은 많이 못하는 실정입니다.

 

제약 사항은 스터디 내용을 발췌하여 그대로 접은글에 넣겠습니다. 

* 현재 EKS Auto Mode에 관해 정리된 내용중 제일 잘 작성되었습니다. 감사합니다.

더보기
  • 제약사항 및 고려사항 최종 정리*
    • 6가지 구성요소가 파드로 구성되는게 아니고, 해당 노드에 systemd 데몬(agent)로 실행됨. - 아래 프로세스 확인
      • kube-proxy, kubelet, eks-pod-identity-agent, eks-node-monitor-agent, eks-healthcheck, eks-ebs-csi-driver,
      • csi-node-driver-registrar, coredns, containerd, aws-network-policy-agent, apiserver, ipam
    • 노드에 대해 불변으로 취급되는 AMI를 사용합니다. 이러한 AMI는 잠금 소프트웨어를 강제하고 SELinux 필수 액세스 제어를 활성화하며 읽기 전용 루트 파일 시스템을 제공합니다. 또한 EKS Auto Mode에서 실행하는 노드의 최대 수명은 21일. SELinux 강제 모드와 읽기 전용 루트 파일 시스템을 사용하여 AMI의 파일에 대한 액세스를 차단합니다.
    • SSH 또는 SSM 액세스를 허용하지 않음으로써 노드에 대한 직접 액세스를 방지합니다.
    • 자동 업그레이드: EKS 자동 모드는 최신 패치를 통해 Kubernetes 클러스터, 노드 및 관련 구성 요소를 최신 상태로 유지하면서 구성된 Pod Disruption Budgets(PDB) 및 NodePool Disruption Budgets(NDB)를 준수합니다. 최대 21일의 수명까지 PDB 또는 기타 구성을 차단하여 업데이트를 방해하는 경우 개입이 필요할 수 있습니다.
    • 관리되는 구성 요소: EKS Auto 모드에는 추가 기능으로 관리해야 하는 핵심 구성 요소로 Kubernetes와 AWS 클라우드 기능이 포함되어 있습니다. 여기에는 Pod IP 주소 할당, Pod 네트워크 정책, 로컬 DNS 서비스, GPU 플러그인, 헬스 체커 및 EBS CSI 스토리지에 대한 내장 지원이 포함됩니다.
    • Create node class : ephemeralStorage(80GiB), 노드 당 최대 파드 110개 제한.
    • Create node pool : 기본 노드풀은 활성화/비활성화 가능, budgets 로 disruption 중지 가능.
    • Create ingress class : IngressClassParams 리소스 및 API 일부 변경, 미지원 기능 확인
    • Create StorageClss : provisioner: ebs.csi.eks.amazonaws.com , EBS 성능 프로메테우스 메트릭 접근 불가.
    • Update Kubernetes version : 업그레이드 시 자체 관리 Add-on 등은 고객 담당.
    • Review build-in node pools : 공통(온디멘드) - system(amd, arm64), general-purpose(amd64).
    • Run critical add-ons : system 노드풀로 **전용인스턴스(dedicated instances)**에 파드 배포 - Docs , 전용인스턴스
    • Control deployment : mixed mode 시 Auto-mode node 사용/미사용 방법 잘 확인 할 것
    • Managed Instances : AWS 소유 관리 인스턴스(OS, CRI, Kubelet 등 관리/책임) - Docs
    • EKS Auto Mode에서 생성된 EC2 인스턴스는 다른 EC2 인스턴스와 다르며 관리되는 인스턴스입니다. 이러한 관리되는 인스턴스는 EKS가 소유하고 있으며 더 제한적입니다. EKS Auto Mode에서 관리하는 인스턴스에는 직접 액세스하거나 소프트웨어를 설치할 수 없습니다.
    • EKS 자동 모드는 다음 인스턴스 유형을 지원합니다 : vCPU 1개 이상, 불가(nano, micro, small)
    • EKS 자동 모드는 지원되는 인스턴스 유형에 대해 NVMe 로컬 스토리지를 자동으로 포맷하고 구성합니다. 여러 개의 NVMe 드라이브를 가진 노드의 경우, EKS는 RAID 0 어레이를 설정합니다. 이 자동화를 통해 EKS 클러스터에서 로컬 NVMe 스토리지를 수동으로 포맷하고 RAID를 구성할 필요가 없습니다.
    • EKS 자동 모드 노드에 Neuron Device Plugin을 설치할 필요가 없습니다.
    • Identity and access : Cluster IAM role, Node IAM role, Service-linked role - Docs
    • Networking : VPC CNI 관련 미지원 기능 확인 - Docs

 

 

 

[출처] 가시다님 스터디

 

 

 

 

실습은 AWS sample 소스를 이용하여 진행했습니다. (terraform 사용)

-> 기본 us-west-2로 진행됩니다.

 

https://github.com/aws-samples/sample-aws-eks-auto-mode

 

GitHub - aws-samples/sample-aws-eks-auto-mode

Contribute to aws-samples/sample-aws-eks-auto-mode development by creating an account on GitHub.

github.com

 

 

배포 이후 ENI IP를 확인해봅니다.

 

 

 

두개의 IP는 콘솔에서도 확인이 가능한 EKS Owned ENI일 것으로 보입니다.

이전 내용들과 동일하게 Cross Account ENI임도 보이네요.

 

 

EKS 콘솔을 확인합니다.

 

 

EKS addon이 보이지 않습니다. 그러면 그냥 addon이 없는것일까요?

 

 

vpc cni, ebs csi, karpenter 등이 보입니다.

 

기본적으로 eks addon을 제공하고 이는 콘솔에서 안보이는거네요

-> 근데 요즘 metric server은 기본 addon이던데 auto mode에서는 보이지 않네요

 

 

기본 내용들은 cli로 확인해봅니다.

 

kubectl api-resources | grep -i node
nodes                               no           v1                                false        Node
cninodes                            cni,cnis     eks.amazonaws.com/v1alpha1        false        CNINode
nodeclasses                                      eks.amazonaws.com/v1              false        NodeClass
nodediagnostics                                  eks.amazonaws.com/v1alpha1        false        NodeDiagnostic
nodeclaims                                       karpenter.sh/v1                   false        NodeClaim
nodepools                                        karpenter.sh/v1                   false        NodePool
runtimeclasses                                   node.k8s.io/v1                    false        RuntimeClass
csinodes                                         storage.k8s.io/v1                 false        CSINode
cninodes                            cnd          vpcresources.k8s.aws/v1alpha1     false        CNINode

# 노드에 Access가 불가능하니, 분석 지원(CRD)제공
kubectl explain nodediagnostics
GROUP:      eks.amazonaws.com
KIND:       NodeDiagnostic
VERSION:    v1alpha1

DESCRIPTION:
    The name of the NodeDiagnostic resource is meant to match the name of the
    node which should perform the diagnostic tasks

 

 

karpenter은 nodepool을 이용해 적합한 노드들을 배치하는데 어디에 있을까요?

 

클러스터 -> eks auto mode -> nodepool

 

 

# nodepool 확인
kubectl get nodepools
NAME              NODECLASS   NODES   READY   AGE
general-purpose   default     0       True    33m

kubectl get nodepools -o yaml
...
  spec:
    disruption:
      budgets:
      - nodes: 10%
      consolidateAfter: 30s
      consolidationPolicy: WhenEmptyOrUnderutilized
    template:
      metadata: {}
      spec:
        expireAfter: 336h # 14일
        nodeClassRef:
          group: eks.amazonaws.com
          kind: NodeClass
          name: default
        requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values:
          - on-demand
        - key: eks.amazonaws.com/instance-category
          operator: In
          values:
          - c
          - m
          - r
        - key: eks.amazonaws.com/instance-generation
          operator: Gt
          values:
          - "4"
        - key: kubernetes.io/arch
          operator: In
          values:
          - amd64
        - key: kubernetes.io/os
          operator: In
          values:
          - linux
        terminationGracePeriod: 24h0m0s
...

 

 

 

karpenter 동작 확인

 

이제 pod를 배포하여 karpenter이 동작하는 것을 확인합니다.

 

# 애플리케이션 배포
# eks.amazonaws.com/compute-type: auto selector requires the workload be deployed on an Amazon EKS Auto Mode node.
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      nodeSelector:
        eks.amazonaws.com/compute-type: auto
      securityContext:
        runAsUser: 1000
        runAsGroup: 3000
        fsGroup: 2000
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: 1
          securityContext:
            allowPrivilegeEscalation: false
EOF

 

이렇게 노드가 생기고 그에 pod가 배포되었습니다.

 

OS는 Bottlerocket을 이용합니다.

 

 

현재는 1개의 파드를 배포하기 위해 c6a.large 타입의 인스턴스가 생성되었습니다.

 

replicaset을 조정하여 karpenter가 정상 작동하는지 확인합니다.

 

# scale up
kubectl scale deployment inflate --replicas 200 && kubectl get events -w --sort-by '.lastTimestamp'

# scale down
kubectl scale deployment inflate --replicas 50 && kubectl get events -w --sort-by '.lastTimestamp'

# 실습 확인 후 삭제
kubectl delete deployment inflate && kubectl get events -w --sort-by '.lastTimestamp'

 

 

c6a.16xlarge 타입의 인스턴스로 올라왔습니다. (소요 시간 2분)

 

로그를 보니 판단하에 제일 적합한 노드를 생성하고 drain하였습니다.

 

Graviton Workloads (2048 game) 배포 with custom nodepool

 

auto mode에서 custom node pool을 만들고 alb를 이용하는 game workload를 배포하겠습니다.

 

nodeclass, nodepool 배포

# custom node pool 생성 : 고객 NodePool : Karpenter 와 키가 다르니 주의!
## 기존(karpenter.k8s.aws/instance-family) → 변경(eks.amazonaws.com/instance-family) - Link
ls ../nodepools
cat ../nodepools/graviton-nodepool.yaml
kubectl apply -f ../nodepools/graviton-nodepool.yaml

# 확인
kubectl get nodeclass
kubectl get nodepool

 

 

 

deployment 배포

kubectl apply -f ../examples/graviton/game-2048.yaml

 

m7g.xlarge타입의 spot 인스턴스가 배포되었습니다.

 

이렇게 nodeclass와 nodepool을 배포해서 graviton type의 SPOT인스턴스가 배포되게끔 Auto Mode를 배포해보았습니다.

 

 

'쿠버네티스 > AEWS' 카테고리의 다른 글

AEWS 8주차 - K8S CI/CD(ArgoCD in k8s)  (1) 2025.03.28
AEWS 8주차 - K8S CI/CD(Jenkins CI/CD in k8s)  (1) 2025.03.28
AEWS 7주차 - EKS Mode/Nodes(EKS Fargate)  (0) 2025.03.19
AEWS 6주차 - EKS Security(OIDC, IRSA, Pod Identity)  (1) 2025.03.14
AEWS 6주차 - EKS Security(k8s 인증/인가, EKS 인증/인가, access management controls)  (0) 2025.03.13
'쿠버네티스/AEWS' Related Articles more