HAQM EKS Auto Mode 시작하기

본 게시물은 AWS Container Blog에 게시된 “Getting started with HAQM EKS Auto Mode” by Sheetal Joshi을 한국어로 번역한 글입니다.

이 글은 Alex Kestner(Sr Product Manager, HAQM EKS), Ashley Ansari(Sr. Product Marketing Manager), Robert Northard(Principal GTM SSA Containers), Sheetal Joshi(Principal Solution Architect, Containers)가 공동 작성했습니다.

소개

컴퓨팅, 스토리지 및 네트워킹을 위한 쿠버네티스 클러스터 관리를 간소화하는 새로운 기능을 제공하는 HAQM Elastic Kubernetes Service(HAQM EKS) Auto Mode의 정식 버전을 발표했습니다. 이제 클러스터 관리를 AWS에 위임함으로써 신속하게 시작하고, 성능을 개선하며, 오버헤드를 줄여 혁신을 주도하는 애플리케이션 구축에 집중할 수 있습니다.

HAQM EKS Auto Mode는 인프라를 자동으로 프로비저닝하고, 최적의 컴퓨팅 인스턴스를 선택하며, 리소스를 동적으로 확장하고, 비용 최적화를 지속적으로 수행하며, 운영 체제(OS)를 패치하고, AWS 보안 서비스와 통합함으로써 쿠버네티스 클러스터 관리를 간소화합니다. EKS Auto Mode가 활성화되면 AWS 모범 사례가 포함된 클러스터 기능을 구성하여 애플리케이션 배포를 위한 클러스터 준비를 보장합니다. 이 글에서는 EKS Auto Mode의 상위 수준 아키텍처를 다루고 EKS Auto Mode를 사용하여 고가용성의 자동 확장 가능한 샘플 애플리케이션을 배포하는 과정을 안내합니다.

신규 기능

HAQM EKS는 오랫동안 쿠버네티스를 실행하기 위한 안전한 방법으로 신뢰받아 왔습니다. EKS Auto Mode 이전에는 관리형 컨트롤 플레인이 있음에도 불구하고, 프로덕션급 쿠버네티스 애플리케이션을 실행하는 데 필요한 인프라를 관리하기 위해서는 여전히 전문 지식과 지속적인 시간 투자가 필요했습니다. 사용자는 리소스 사용량과 비용을 최적화하기 위해 적절한 HAQM Elastic Compute Cloud(HAQM EC2) 인스턴스를 선택하고 프로비저닝하는 것부터 플러그인을 설치하고 유지관리하는 것까지 지속적인 유지보수 작업을 수행해야 했습니다. 이는 다음 그림과 같이 인프라를 안전하고 최신 상태로 유지하기 위한 클러스터 업그레이드 및 OS 패치 작업과 함께 이루어졌습니다.

Before Auto Mode

완전 자동화된 클러스터 운영은 EKS Auto Mode가 프로덕션급 쿠버네티스 인프라를 관리하는 데 필요한 전문 지식의 필요성을 줄여 사용자의 상당한 시간과 노력을 절약한다는 것을 의미합니다. 사용자는 더 이상 EC2 인스턴스 선택 및 프로비저닝, 리소스 및 비용 최적화, 플러그인 유지관리에 시간과 리소스를 소비할 필요가 없습니다.

EKS Auto Mode가 활성화된 상태에서 새로운 EKS 클러스터를 생성하거나 기존 클러스터를 업데이트할 때, HAQM EKS는 관리형 쿠버네티스 컨트롤 플레인 인프라와 함께 HAQM EKS 소유 AWS 계정 및 HAQM EKS 관리형 VPC 내부에 컴퓨팅, 네트워킹, 스토리지 기능을 위한 필수 컨트롤러를 자동으로 배포합니다.

EKS Auto Mode는 애플리케이션을 배포할 때 사용자의 AWS 계정과 사용자가 제공한 VPC 내에서 Bottlerocket OS 기반 EC2 인스턴스와 AWS Elastic Load Balancing(ELB)을 자동으로 시작하고 HAQM Elastic Block Storage(HAQM EBS) 볼륨을 프로비저닝합니다. EKS Auto Mode는 이러한 EC2 인스턴스의 수명 주기를 시작하고 관리하며, 런타임 동안 애플리케이션 요구사항이 변경됨에 따라 데이터 플레인을 확장하고 최적화하며, 비정상 노드를 자동으로 교체합니다. 다음 그림과 같이 HAQM EC2 기능의 깊이와 범위를 추상화하지 않고 관리형 인프라를 제공합니다.

After Auto Mode

EKS Auto Mode를 통해 이전에 쿠버네티스 DaemonSet으로 실행되던 노드 기능들이 이제 AWS가 관리하는 시스템 프로세스로 실행됩니다. 여기에는 서비스 검색, 서비스 로드 밸런싱, 파드 네트워킹, 블록 스토리지, 자격 증명 제공과 같은 구성 요소들이 포함됩니다. AWS는 보안 패치를 위한 업데이트와 같은 이러한 구성 요소들의 수명 주기 관리를 담당하며, 지원되는 쿠버네티스 버전에 대해 업데이트된 구성 요소가 포함된 새로운 버전의 EKS Auto Mode HAQM Machine Image(AMI)를 배포합니다.

또한 EKS Auto Mode는 인프라의 보안과 최신 상태 유지를 위해 정의된 쿠버네티스 스케줄링 제약 조건을 준수하면서 노드를 정상적으로 교체하여 클러스터 업그레이드와 OS 업데이트를 자동으로 처리합니다. 이러한 운영 오버헤드의 큰 감소로 인해 팀은 인프라 관리가 아닌 애플리케이션 개발에 집중할 수 있습니다.

시작하기

EKS Auto Mode는 현재 버전 1.29 이상에서 실행되는 새로운 EKS 클러스터와 기존 클러스터에서 사용할 수 있습니다. EKS Auto Mode를 시작하려면 적절한 기본값이 사전 구성된 클러스터를 빠르게 시작할 수 있는 원클릭 시작 환경을 제공하는 새로운 콘솔 기능인 ‘Quick Configuration’을 사용할 수 있습니다. 또는 HAQM EKS API, AWS Management Console, eksctl 또는 선호하는 Infrastructure as Code(IaC) 도구를 사용할 수 있습니다.

이 섹션에서는 EKS Auto Mode가 HAQM EKS에서 애플리케이션 배포를 어떻게 간소화하는지 보여드립니다. EKS Auto Mode가 활성화된 EKS 클러스터를 생성한 다음, 샘플 소매점 애플리케이션을 배포하는 것으로 시작합니다. EKS Auto Mode가 새로운 노드를 자동으로 시작하고, AWS Load Balancer를 설정하며, 영구 스토리지 요구사항을 관리하고, 애플리케이션의 자동 확장 요구사항을 처리하는 방법을 확인할 수 있습니다.

전제 조건

이 게시물에서 언급된 단계를 완료하려면 다음과 같은 전제 조건이 필요합니다:

AWS 계정: 이 게시물에서는 관리자 권한이 있는 AWS 계정이 이미 있다고 가정합니다.
다음 도구 설치: Helm 3.9+, kubectl, eksctl 및 AWS Command Line Interface(AWS CLI).

클러스터 생성

이 게시물에서는 EKS 클러스터를 빠르게 생성하는 데 도움이 되는 명령줄 유틸리티 도구인 eksctl을 사용합니다. 다음 예제 구성은 eksctl을 사용하여 클러스터 인프라와 애플리케이션 배포를 위한 클러스터 서브넷을 자동으로 생성합니다. 샘플 구성을 사용하지 않는 경우 HAQM EKS 사용자 가이드에서 전체 전제 조건 목록을 참조하십시오. 이러한 전제 조건에는 EKS Auto Mode가 계정의 EC2 인스턴스를 관리하기 위한 새로운 권한을 제공하는 클러스터 IAM 역할 및 노드 IAM 역할의 변경 사항이 포함됩니다.

general-purpose 및 system 워크로드를 위한 내장 관리형 NodePool로 EKS Auto Mode를 활성화하고 있습니다. general-purpose NodePool은 범용 워크로드 실행을 지원하고, system NodePool은 애드온을 처리합니다. 두 NodePool 모두 amd64 아키텍처를 가진 C, M, R 계열의 온디맨드 EC2 인스턴스(5세대 이상)를 사용합니다. 내장 NodePool에 대한 자세한 내용은 EKS Auto Mode 사용자 가이드를 참조하십시오.

cat << EOF > cluster.yaml 
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: eks-auto-mode-demo
  region: us-west-2
  version: "1.31"
  
addonsConfig:
  disableDefaultAddons: true

autoModeConfig:
  enabled: true
  nodePools: ["general-purpose", "system"]
  
EOF

eksctl create cluster -f cluster.yaml

클러스터 상태가 Active가 될 때 까지 기다립니다.

aws eks describe-cluster --name eks-auto-mode-demo --output json --query 'cluster.status'

이제 클러스터에 애플리케이션을 배포할 준비가 되었습니다. 다음 섹션에서는 EKS Auto Mode가 애플리케이션 배포를 어떻게 간소화하는지 보여드립니다.

애플리케이션 배포

사용자가 카탈로그를 탐색하고, 장바구니에 상품을 추가하고, 체크아웃 프로세스를 통해 주문을 완료할 수 있는 샘플 소매점 애플리케이션을 사용합니다. 이 애플리케이션에는 UI, 카탈로그, 주문, 장바구니, 체크아웃 서비스와 같은 여러 구성 요소가 있으며, 쿠버네티스 Deployment와 StatefulSet으로 모델링된 영구 블록 스토리지가 필요한 백엔드 데이터베이스가 포함되어 있습니다. 클러스터 외부에서 애플리케이션에 접근하기 위해 쿠버네티스 인그레스를 사용하고, 카탈로그 애플리케이션이 HAQM EBS 영구 스토리지를 사용하도록 구성합니다. EKS Auto Mode가 성능을 개선하고, 확장성을 제공하며, 가용성을 향상시키는 방법을 보여주기 위해 UI 애플리케이션이 Horizontal Pod Autoscaling, Pod Topology Spread Constraints, Pod Disruption Budgets(PDB)을 지원하도록 구성합니다.

애플리케이션을 배포하기 전에 클러스터 상태를 확인하십시오.

kubectl get nodes
kubectl get pods

노드와 파드 목록이 비어 있습니다.

애플리케이션 배포를 진행하기 전에 StorageClass와 IngressClass를 생성합니다. 이 설정은 나중에 배포되는 애플리케이션의 스토리지 및 인그레스 요구 사항을 지원하는 데 필요한 인프라 구성이 제대로 갖춰져 있는지 확인합니다. 일반적으로 이는 클러스터가 생성된 후 플랫폼 팀이 한 번 수행하는 단계입니다.

cat >ingress.yaml <<EOF
---
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
  name: eks-auto-alb
spec:
  scheme: internet-facing
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: eks-auto-alb
spec:
  controller: eks.amazonaws.com/alb
  parameters:
    apiGroup: eks.amazonaws.com
    kind: IngressClassParams
    name: eks-auto-alb
EOF

kubectl apply -f ingress.yaml

cat >ebs-sc.yaml <<EOF
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: eks-auto-ebs-csi-sc
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
EOF
 
kubectl apply -f ebs-sc.yaml

helm을 사용하여 애플리케이션을 배포합니다. 앞서 지정한 애플리케이션 요구사항을 명시하는 values.yaml 파일을 생성하기 위해 다음 명령을 실행합니다.

cat >values.yaml <<EOF
catalog:
  mysql:
    secret:
      create: true
      name: catalog-db
      username: catalog
    persistentVolume:
      enabled: true
      accessMode:
        - ReadWriteOnce
      size: 30Gi
      storageClass: eks-auto-ebs-csi-sc

ui:
  endpoints:
    catalog: http://retail-store-app-catalog:80
    carts: http://retail-store-app-carts:80
    checkout: http://retail-store-app-checkout:80
    orders: http://retail-store-app-orders:80
    assets: http://retail-store-app-assets:80
  autoscaling:
    enabled: true
    minReplicas: 5
    maxReplicas: 10
    targetCPUUtilizationPercentage: 80
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: ui
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: ui
  ingress:
    enabled: true
    className: eks-auto-alb
EOF

소매점 애플리케이션을 배포합니다. 배포를 진행할 때 values.yaml 파일의 구성, 특히 UI의 엔드포인트를 고려하십시오. 기본값인 retail-store-app과 다른 차트 이름을 선택한 경우 이러한 엔드포인트를 적절히 업데이트해야 합니다.

helm install -f values.yaml retail-store-app oci://public.ecr.aws/aws-containers/retail-store-sample-chart --version 0.8.3

EKS Auto Mode는 이러한 파드의 리소스 요구사항을 평가하고 Topology Spread Constraints를 포함하여 구성한 스케줄링 제약 조건을 고려하여 애플리케이션 실행에 최적화된 컴퓨팅을 결정합니다. 내장된 general-purpose NodePool을 사용하여 노드를 시작합니다. 노드가 Ready 상태가 될 때까지 기다리세요.

kubectl wait --for=condition=Ready nodes --all

별도의 터미널에서 애플리케이션이 사용 가능한 상태가 되는 것을 모니터링합니다.

kubectl wait --for=condition=available deployments --all

소매점 애플리케이션의 구성 요소들이 실행 상태에 있어야 합니다.

catalog-mysql-ebs StatefulSet을 검사해보면, EKS Auto가 30 GiB 용량과 eks-auto-ebs-csi-sc라는 storageClassName을 가진 PersistentVolumeClaim을 생성하여 연결한 것을 확인할 수 있습니다.

kubectl get statefulset retail-store-app-catalog-mysql \
  -o jsonpath='{.spec.volumeClaimTemplates}' | jq . 
  
Output: 
[
  {
    "apiVersion": "v1",
    "kind": "PersistentVolumeClaim",
    "metadata": {
      "creationTimestamp": null,
      "name": "data"
    },
    "spec": {
      "accessModes": [
        "ReadWriteOnce"
      ],
      "resources": {
        "requests": {
          "storage": "30Gi"
        }
      },
      "storageClassName": "eks-auto-ebs-csi-sc",
      "volumeMode": "Filesystem"
    }
  }
]

EKS Auto Mode가 UI 애플리케이션을 위한 Application Load Balancer(ALB)를 자동으로 생성했습니다. 다음 명령을 통해 ALB 이름을 확인할 수 있습니다. ALB가 준비되면 웹 브라우저에서 해당 링크에 접속할 수 있습니다. 소매점의 홈페이지가 표시되어야 합니다.

kubectl get ingress retail-store-app-ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}"

Output:
k8s-ui-uinlb-1111111111.elb.us-west-2.amazonaws.com

애플리케이션 확장

이제 애플리케이션을 배포했으므로, EKS Auto Mode가 HorizontalPodAutoscaler(HPA)와 metrics-server를 사용하여 애플리케이션의 요구사항을 충족하기 위해 클러스터 인프라 리소스를 어떻게 확장하는지 확인할 수 있습니다. 쿠버네티스에서 HPA는 관찰된 메트릭을 기반으로 디플로이먼트의 레플리카 수를 자동으로 조정합니다. metrics-server는 kubelet에서 CPU와 메모리 사용량 데이터를 수집하고 쿠버네티스 API 서버를 통해 HPA에 노출합니다. HPA는 이러한 메트릭을 지속적으로 모니터링하고 지정된 목표에 맞게 레플리카 수를 조정합니다.

먼저, 쿠버네티스 metrics-server를 배포합니다.

kubectl apply -f http://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

이 예제에서는 ui 서비스를 사용하고 maxReplicas가 10인 상태에서 CPU 사용률(80%)을 기준으로 확장합니다. 애플리케이션 설치 단계의 일부로 HPA를 이미 적용했습니다. values.yaml의 Auto Scaling 섹션을 참조하십시오. 다음 명령을 사용하여 Auto Scaling 정책을 확인할 수 있습니다.

kubectl get hpa retail-store-app-ui

AutoScaling 정책에 대한 응답으로 EKS Auto Mode가 클러스터 인프라를 확장하는 것을 관찰하기 위해 부하를 생성합니다.

kubectl run load-generator \
  --image=public.ecr.aws/amazonlinux/amazonlinux:2023 \
  --restart=Never -- /bin/sh -c "while sleep 0.01; do curl http://retail-store-app-ui/home; done"

애플리케이션에 요청이 들어오고 있으므로, 새로운 노드가 시작되고 더 많은 UI 파드가 실행되는 것을 모니터링할 수 있습니다.

kubectl get nodes --watch

Output:
NAME                  STATUS   ROLES    AGE    VERSION
i-00018eaec7a3d5370   Ready    <none>   155m   v1.31.0-eks-672e808
i-043c71a371a8514a1   Ready    <none>   155m   v1.31.0-eks-672e808

HPA 리소스를 모니터링하여 진행 상황을 확인할 수 있습니다.

kubectl get hpa retail-store-app-ui --watch

Output:
NAME                  REFERENCE                        TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
retail-store-app-ui   Deployment/retail-store-app-ui   cpu: 158%/80%   3         10        5          16m
retail-store-app-ui   Deployment/retail-store-app-ui   cpu: 161%/80%   3         10        6          16m
retail-store-app-ui   Deployment/retail-store-app-ui   cpu: 148%/80%   3         10        9          16m

보시는 바와 같이 EKS Auto Mode는 애플리케이션 요구사항에 따라 클러스터 인프라를 완전히 관리하고 동적으로 확장합니다. 파드를 종료하여 부하 생성기를 중지할 수 있습니다. 부하 생성기가 종료되면 HPA는 구성에 따라 레플리카 수를 최소값으로 천천히 줄입니다.

kubectl delete pod load-generator

주요 고려사항

HAQM EKS Auto Mode에 워크로드를 배포할 때 고려해야 할 몇 가지 사항은 다음과 같습니다:

자발적 중단으로부터 워크로드를 보호하기 위한 pod disruption budgets: EKS Auto Mode가 활용도가 낮은 노드를 중단하는 경우와 같은 자발적 중단 시, disruption budgets는 디플로이먼트 레플리카의 중단 비율을 제어하여 트래픽 처리나 작업 처리를 계속할 수 있는 일부 워크로드 용량을 보호하는 데 도움을 줍니다.
고가용성을 위한 노드 및 가용 영역 간 레플리카 스케줄링: Pod Topology Spread Constraints을 사용하여 워크로드를 노드 전체에 분산하고 동일한 노드에서 디플로이먼트의 여러 레플리카가 실행될 가능성을 최소화합니다.
적절한 리소스 요청 및 제한 구성: EKS Auto Mode는 워크로드의 vCPU 및 메모리 요청을 기반으로 EC2 인스턴스를 시작합니다. 리소스가 과도하게 프로비저닝되는 것을 방지하기 위해 리소스 요청을 신중하게 구성해야 합니다. EKS Auto Mode는 리소스 제한이나 사용량을 고려하지 않습니다.
애플리케이션은 graceful shutdown을 처리해야 합니다: 자발적 중단 중에 작업 손실이나 최종 사용자 경험 중단을 방지하기 위해 애플리케이션은 SIGTERM 신호를 처리하여 정상적으로 종료할 수 있어야 합니다. 쿠버네티스 파드가 제거되기로 결정되면, 제거되는 파드의 각 컨테이너의 메인 프로세스에 SIGTERM 신호가 전송됩니다. SIGTERM 신호가 전송된 후, 쿠버네티스는 SIGKILL 신호를 보내기 전에 프로세스에 일정 시간(grace period)을 제공합니다. 해당 grace period는 기본적으로 30초입니다. 파드 사양에서 terminationGracePeriodSeconds를 선언하여 기본값을 재정의할 수 있습니다.
컴퓨팅 선택을 과도하게 제한하지 않기: general-purpose EKS Auto Mode NodePool은 워크로드에 맞는 크기의 EC2 인스턴스를 선택할 기회를 최대화하기 위해 다양한 크기의 c, m, r HAQM EC2 제품군을 활용합니다. 특정 컴퓨팅 요구사항이 있는 워크로드의 경우, 잘 알려진 쿠버네티스 레이블을 사용하여 노드 생성 시 파드가 특정 인스턴스 유형, 아키텍처 또는 기타 속성만 요청하도록 할 수 있습니다.

HAQM EKS 모범 사례 가이드의 안정성 섹션에서 애플리케이션 모범 사례에 대해 자세히 알아볼 수 있습니다.

정리하기

향후 요금이 발생하지 않도록 이 게시물의 일부로 생성된 리소스를 삭제하세요.

kubectl delete deploy -n kube-system metrics-server

helm uninstall retail-store-app

kubectl delete pvc/data-retail-store-app-catalog-mysql-0

eksctl delete cluster --name eks-auto-mode-demo

결론

HAQM EKS Auto Mode는 즉시 사용 가능한 컴퓨팅, 스토리지 및 네트워킹 기능을 제공하여 애플리케이션 배포와 관련된 복잡성을 제거합니다. 새로운 클러스터를 생성하든 기존 클러스터를 업데이트하든, EKS Auto Mode는 클러스터 인프라를 관리할 뿐만 아니라 업스트림 쿠버네티스 규격을 유지하면서 핵심 클러스터 기능을 제공하는 간소화된 경험을 제공합니다.

EKS Auto Mode는 기존 HAQM EKS 제품을 보완하여 다양한 워크로드에 대한 유연성을 제공합니다. 특정 요구사항이 있는 사용자는 여전히 전통적인 HAQM EKS 컴퓨팅 옵션을 사용하여 사용자 정의 쿠버네티스 클러스터 구성, 클러스터 인프라의 수동 프로비저닝 및 관리, 쿠버네티스 환경에 대한 세부적인 제어가 가능합니다. Auto Mode와 전통적인 옵션을 모두 지원한다는 것은 HAQM EKS가 단순성과 운영 오버헤드 감소를 추구하는 경우부터 쿠버네티스 설정에 대한 사용자 정의/세부적인 제어가 필요한 경우까지 광범위한 사용 사례를 지원한다는 것을 의미합니다.

EKS Auto Mode 기능에 대한 자세한 내용은 HAQM EKS 문서를 참조하세요.

AWS 기술 블로그