AWS EKS의 AutoMode

 

들어가며

쿠버네티스(Kubernetes)는 강력한 오케스트레이션 플랫폼이지만, 클러스터 인프라 관리와 노드 스케일링 등 복잡한 작업이 늘 따라옵니다. AWS EKS를 사용할 때도 마찬가지죠. 컨트롤 플레인과 워커 노드를 직접 관리하거나 Karpenter 같은 오토스케일러를 세팅해야 하고, 때로는 인프라 최적화에 많은 시간을 쏟아야 합니다. 

 

이에 AWS에서는 EKS Auto Mode라는 새로운 관리 모드를 출시했습니다. AWS EKS의 특성상 Control Plane은 AWS에서 관리하지만, EKS Auto Mode는 Data Plane까지 AWS가 관리하는 개념입니다.

 

이번 포스팅에서는 EKS Auto Mode에 대해 살펴보고 실습을 진행해보겠습니다.

 

AWS EKS Auto Mode

EKS Auto Mode 란

https://aws.amazon.com/ko/blogs/containers/getting-started-with-amazon-eks-auto-mode/

 

EKS AutoMode는 새롭게 오픈된 클러스터 실행 모드로, 사용자는 쿠버네티스 리소스를 배포하는 것에만 집중하고, 인프라 리소스(노드, 스케일링, 패치)는 AWS가 자동으로 관리해주는 완전 관리형 모드입니다. 

 

즉, 쿠버네티스를 운영하면서 서버리스 같은 경험을 제공하는 기능이라고 볼 수 있는데요. 내가 Pod나 Deployment를 올리면, AWS가 알아서 리소스를 할당하고, 최적화된 인프라를 자동 구성합니다.

 

EKS Auto Mode 특징

클러스터 및 인프라 자동 프로비저닝

컨트롤 플레인과 워커 노드 리소스를 사용자가 직접 만들지 않아도 되며, eksctl이나 콘솔에서 몇 번 클릭만 하면 자동으로 클러스터가 구성됩니다.

노드 및 용량 관리

EC2 인스턴스나 Fargate 프로파일을 관리할 필요가 없습니다. 즉, Pod가 실행되면 AWS가 적절한 노드를 자동으로 생성하고, 스케일 아웃·인까지 자동 처리합니다.

 

자동 스케일링

워크로드 증가·감소에 따라 용량이 자동으로 조절되며 이로인해 오버프로비저닝과 비용 낭비를 크게 줄일 수 있습니다.

여기에는 Pod IP 주소 할당, Pod 네트워크 정책, 로컬 DNS 서비스, GPU 플러그인, 헬스 체커 및 EBS CSI 스토리지에 대한 내장 지원이 포함됩니다.

 

자동 보안 패치와 업그레이드

컨트롤 플레인 및 인프라 구성요소의 보안 패치와 유지보수는 AWS가 자동으로 진행하기에 항상 안전하고 최신 상태로 클러스터를 유지할 수 있습니다. 이로 인해 사용자는 보안 이슈에 대한 걱정 없이 워크로드 개발과 운영에 집중할 수 있습니다.

또한 Worker Node에 대해 가장 경량화 및 최적화된 AMI를 사용하는데, 이 AMI는 따로 수정할 수 없습니다. 또한 Node의 최대 수명은 21일이며 그 후 에는 자동으로 새로운 Node로 교체됩니다.

 

사용자 지정 가능한 NodePool 및 NodeClasses

스토리지, 컴퓨팅 또는 네트워킹 구성을 변경해야 하는 워크로드의 경우 EKS 자동 모드를 사용하게 되면 사용자 지정 NodePool 및 NodeClasses를 만들 수 있습니다.

이때 기본 NodePool 및 NodeClasses는 편집할 수 없지만, 특정 요구 사항을 충족하기 위해 기본 구성과 함께 새로운 사용자 지정 NodePool 또는 NodeClasses를 추가할 수 있습니다.

 

자동화된 구성 요소

Compute

EKS Auto Mode를 사용하면 많은 워크로드에서 EKS 클러스터에 대해 관리 포인트를 생각하지 않아도 됩니다.

 

Node

SELinux 강제 모드와 읽기 전용 Root file system을 사용하여 실행되는데 최적화된 AMI인 Bottlerocket을 사용합니다. 

또한 AWS에서 관리하는 주체임으로 SSH 또는 SSM 접근을 허용하지 않음으로써 Node에 직접 접근을 금지합니다.

 

GPU 지원이 포함되어 있으며, 별도의 커널 드라이버와 NVIDIA 및 Neuron GPU용 플러그인이 내장되어있어 고성능 워크로드를 지원합니다.

 

Auto Scaling

Karpenter를 기반으로 Pod의 리소스를 모니터링 하고 새롭게 추가되는 Pod에 대해 새로운 Node를 배포하여 해당 Pod가 배포될 수 있게 계획할 수 있습니다.

또한, 워크로드가 종료되면 더 이상 필요하지 않은 노드를 동적으로 중단하고 종료하여 리소스 사용을 최적화합니다. 

 

Upgrade

워크로드의 중단을 최소화하도록 설계되어 필요에 따라 Node의 보안 패치와 구성 요소를 업그레이드합니다.

이때, 최신 소프트웨어 및 API를 보장하기 위해 최대 21일(기본14일)의 노드 수명을 적용합니다.

 

Load Balancing

AWS ELB서비스와 통합하여 로드 밸런싱을 간소화하여 자동으로 구성됩니다.

이를 통해 AWS 모범 사례를 준수하는 ELB를 구성하여 인프라 관리보다 애플리케이션에 집중할 수 있습니다.

 

Storage

볼륨 유형, 볼륨 크기, 암호화 정책, Node 종료 시 삭제 정책(DeleteOnTermination)을 설정하여 임시 Storage를 구성합니다.

 

Networking

IPv4/IPv6 및 보조 CIDR 블록 사용등 Pod 및 서비스 연결을 위한 중요한 네트워킹 작업에 대해 자동화하여 지원합니다. 

 

IAM

EKS pod Identity Agent를 설치할 필요가 없습니다.

 

커스텀 설정

Kubernetes DaemonSets

Node에 설치된 서비스를 수정하는 대신 K8s의 DaemonSet을 사용할 수 있습니다. 이러한 방식으로 Node를 모니터링하거나 모니터링을 하기 위한 서비스를 추가할 수 있습니다.

 

Custom NodePools 및 NodeClasses

기본 NodePools 및 NodeClasses는 수정할 수 없고, 특정 인스턴스 유형을 선택하거나 보안 및 비용 추적 목적으로 워크로드를 격리하거나 일시적인 스토리지 설정 구성등과 같은 행동은 가능합니다.

 

LoadBalancing

Kubernetes 객체로 실행하는 로드 밸런싱과 같은 일부 서비스는 EKS Auto Mode 클러스터에서 직접 구성할 수 있습니다.

 

실습 - EKS Auto Mode 배포

 

Cluster 배포

github source clone

git clone https://github.com/aws-samples/sample-aws-eks-auto-mode.git
cd sample-aws-eks-auto-mode/terraform

 

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

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

 

위 레포지토리에 접근해서 소스 샘플을 다운로드 합니다.

 

 

variables.tf 수정

...

variable "region" {
  description = "region"
  default     = "ap-northeast-2" 
  type        = string
}

variable "vpc_cidr" {
  description = "VPC CIDR. This should be a valid private (RFC 1918) CIDR range"
  default     = "10.20.0.0/16"
  type        = string
}

...

 

terraform/variables.tf 파일에서 region과 vpc_cidr 블록만 수정해줍니다.

 

eks.tf

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.24"
  ...
  
  
  cluster_compute_config = {
    enabled    = true
    node_pools = ["general-purpose"]
  }
}

 

eks.tf파일에서 cluster_compute_config 부분이 중요한데, 해당 부분이 auto mode를 설정하는 부분입니다.

 

Terraform init 및 plan

terraform init
terraform plan

 

먼저 terraform init으로 초기화를 진행한다음 plan으로 실행될 결과를 먼저 살펴보겠습니다.

 

 

위와 같이 문제 없이 plan 결과가 나오는다면 준비는 완료되었습니다.

 

 

terraform apply

terraform apply -auto-approve

 

apply 명령어로 eks cluster를 생성합니다. (대략 15분정도 소요됩니다...!)

 

 

aws console에 접근해서 확인해보면 위와 같이 automode-cluster라는 이름으로 cluster가 생성 중인 것을 확인하실 수 있습니다.

 

 

배포 확인

EKS Owned-ENI 확인

 

EC2 > 네트워크 인터페이스에서 현재 배포된 EKS Owned-ENI를 확인해보면 2개가 띄어져 있는 것을 확인하실 수 있습니다.

 

Cluster Mode 확인

 

EKS 메뉴에 접근해서 해당 cluster에 접근해서 살펴보면 EKS 자율 모드가 활성화되어있는 것을 확인하실 수 있습니다.

 

관리 버튼을 클릭하면 현재 설정된 자율 모드의 기능을 볼 수 있습니다. 위와 같이 ALB, Storage, AutoScaling, GPU, DNS, Networking등이 지원되는 것을 확인하실 수 있습니다.

 

 

add-on도 하나도 없는 것을 확인하실 수 있습니다.

 

즉, Auto Mode를 사용하면 AWS측에서 관리가 가능한 부분은 완전하게 관리를 하고, 사용자(고객)에게 노출 시키지 않습니다.

 

kubectl 설정

aws eks --region ap-northeast-2 update-kubeconfig --name automode-cluster

 

생성된 automode-cluster를 kubeconfig 파일에 설정해줍니다.

 

kubectl config rename-context "arn:aws:eks:ap-northeast-2:$(aws sts get-caller-identity --query 'Account' --output text):cluster/automode-cluster" "automode-lab"

 

그 후 arn은 생략하고 automode-cluster로 이름을 수정합니다.

 

kubectl 확인

kubectl get crd

 

특이한 것은 node template와 같은 개념의 nodeclasses.eks crd와 node를 분석하는 nodediagnostics.eks crd가 생성된 것입니다.

 

nodediagnostics

 

즉, 노드에 Access가 불가능하니, nodediagnostics CRD를 통해 해당 기능을 대체하여 제공합니다.

 

nodepool 확인

kubectl get nodepools

 

 

general-purpose가 생성되어있고, 자세히 살펴보겠습니다.

 

kubectl get nodepools -o yaml

 

...
  spec:
    disruption:
      budgets:
      - nodes: 10%
      consolidateAfter: 30s
      consolidationPolicy: WhenEmptyOrUnderutilized
    template:
      metadata: {}
      spec:
        expireAfter: 336h
        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
...

 

 

위 설정 값에서 budget과 expireAfter 값을 살펴보겠습니다.

 

budget

- nodes: 10% 👉  전체 노드의 10% 이상을 한 번에 중단/교체/정리하지 않는다.

- consolidateAfter: 30s 👉 노드가 비거나 비효율적인 상태(WhenEmptyOrUnderutilized)가 되고 30초 이상 지속되면 정리(terminate) 시도를 시작한다.

 

expireAfter

expireAfter: 336h -> 기본값인 14일 후 새 노드로 교체한다.

 

실습 - Pod 배포하여 Karpenter 동작 확인[컴퓨팅]

현재 노드 확인

kubectl get node -A

 

현재 cluster에 배포되어있는 worker node를 확인해보겠습니다.

 

worker node는 없는것을 확인하실 수 있습니다.

 

 

AWS console에서도 현재 운영중인 EC2는 없는 것을 확인하실 수 있습니다.

 

Pod 생성 (1개)

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

 

 

위와 같이 테스트용 애플리케이션을 배포해보겠습니다.

 

Kubernetes 이벤트 확인

kubectl get events -w --sort-by '.lastTimestamp'

 

kubectl get events 명령어를 통해 pod를 배포함으로서 현재 진행되는 event를 확인해보겠습니다.

 

 

Pod가 생성되고 Node가 생성되는 이벤트를 확인하실 수 있습니다.

 

현재 노드 확인

kubectl get node

 

node를 조회해보겠습니다.

 

하나의 node가 생성된 것을 확인하실 수 있습니다.

 

 

AWS Console에서도 running 상태의 EC2가 하나 생성된 것을 확인하실 수 있습니다.

 

생성된 Node 접근

 

현재 Node가 하나 배포되어있는데 해당 Node에 접근해보겠습니다.

 

 

접근이 허용되어있지 않습니다. 

 

즉, Auto Mode로 Cluster를 배포하고 해당 Cluster에서 생성된 Worker Node인 EC2는 어떠한 접근이 불가능한 것을 확인하실 수 있습니다.

 

Pod 배포 (100개)

kubectl scale deployment inflate --replicas 100 && kubectl get events -w --sort-by '.lastTimestamp'

 

위 명령어로 생성되어있는 deploy의 replica를 100개로 늘리고, event를 확인해보겠습니다.

 

 

node가 부족하여 새롭게 생성하고 pod가 schedule되는 것을 확인하실 수 있습니다.

 

현재 노드 확인

kubectl get node

 

위 이벤트를 확인하고 난 후 node를 확인해보면 한개의 노드가 추가로 생성되었습니다.

 

 

추가로 생성된 Node는 c5a.2xlarge로 생성되었는데요.

이처럼 EKS Auto Mode는 Karpenter의 기능으로 Pod의 리소스 요구 사항에 맞춰 Node의 Spec을 동적으로 프로비저닝합니다.

 

Pod 삭제

kubectl delete deployment inflate

 

다음 실습을 위해 배포했던 pod를 제거 합니다.

 

실습 - ALB(ingress)를 통한 Graviton Workloads 배포 [네트워킹]

Nodepool 설정

nodepool yaml 확인 및 배포

cat ../nodepools/graviton-nodepool.yaml

 

Terraform으로 Cluster를 배포할 때 생성된 gravition-nodepool.yaml 파일을 확인 후 배포해보겠습니다.

 

kubectl apply -f ../nodepools/graviton-nodepool.yaml

 

kubectl get NodeClass

 

현재 배포되어있는 NodeClass를 확인해보겠습니다.

 

 

graviton-nodeclass가 생성된 것을 확인하실 수 있습니다.

 

애플리케이션 배포

yaml 파일 확인

cat ../examples/graviton/game-2048.yaml

 

예제로 포함되어있는 game-2048.yaml 파일을 확인해보겠습니다

 

 

nodeselector에 arm64인 경우 배포되게 설정되어있습니다.

Pod 배포

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

 

해당 Pod를 배포합니다.

 

애플리케이션 배포 후 리소스 확인

nodeclaim 확인

kubectl get nodeclaims

 

위에서 pod를 배포함으로써 생성된 nodeclaims를 확인해보겠습니다.

 

type이 m7g.xlarge, spot으로 자동으로 생성된을 확인할 수 있습니다.

 

Node 확인

kubectl get node

 

node 정보를 확인해보면 아래와 같이 1개의 node가 생성된것을 알 수 있습니다.

 

 

AWS Console에서도 1개의 노드가 확인됩니다.

 

 

 

관리 주체가 eks인 것을 확인할 수 있습니다.

 

ALB 배포 및 확인

ALB (ingress) 배포

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

 

위에서 생성한 Pod와 마찬가지로 예제로 수록되어있는 2048-ingress.yaml 파일을 배포합니다.

 

ALB 배포 후 리소스 확인

kubectl get ingressclass,ingressclassparams,ingress,svc,ep -n game-2048

 

그 후 ingressClass, ingressclassparam, ingress, svc, ep와 같이 ingress와 관련된 리소스를 확인해보겠습니다.

 

ALB 확인

 

EKS Auto Mode를 사용하면 따로 controller를 생성할 필요없이 바로 ALB가 배포된 것을 확인하실 수 있습니다. 

 

보안그룹 설정

ALB를 통해 애플리케이션을 배포하면 보안그룹 설정까지 자동으로 되는 줄 알았지만, EKS Cluster에 EC2 보안그룹 설정을 따로 진행해주셔야 합니다.

ALB_SG=$(aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[?contains(DNSName, `game2048`)].SecurityGroups[0]' \
  --output text)

EKS_SG=$(aws eks describe-cluster \
  --name automode-cluster \
  --query 'cluster.resourcesVpcConfig.clusterSecurityGroupId' \
  --output text)
  
  aws ec2 authorize-security-group-ingress \
  --group-id $EKS_SG \
  --source-group $ALB_SG \
  --protocol tcp \
  --port 80

 

ALB를 통해 애플리케이션 접근

kubectl get ingress ingress-2048 \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' \
  -n game-2048

 

그 후 위의 명령어를 통해 ALB의 엔드포인트를 확인하고 접근합니다.

 

 

---

참고

https://aws.amazon.com/ko/eks/auto-mode/

Managed Kubernetes – Amazon Elastic Kubernetes Service (EKS) Auto Mode - AWS

https://docs.aws.amazon.com/eks/latest/userguide/automode.html

Automate cluster infrastructure with EKS Auto Mode - Amazon EKS

https://aws.amazon.com/ko/blogs/containers/getting-started-with-amazon-eks-auto-mode/

Getting started with Amazon EKS Auto Mode | Amazon Web Services

 

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

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