AWS EKS - Autoscaling - Compute

CloudNet@ 팀의 AWS EKS Workshop Study 2기 - 5주차
# EKS Workshop 참고

• Kubernetes에서 컴퓨팅 자동 확장을 구현하는 방법
  
  • Kubernetes Cluster Autoscaler

    

     
    
    • Kubernetes 클러스터 내에서 자동으로 노드를 확장 또는 축소하여 클러스터의 리소스 사용을 최적화하는 도구
    • 애플리케이션의 요구 사항에 따라 클러스터 크기를 동적으로 조정
    • 클러스터 내에서 실행 중인 애플리케이션의 수요가 증가하면, Cluster Autoscaler는 추가 노드를 프로비저닝하여 이에 대응합니다. 반대로, 애플리케이션의 수요가 감소하면, 더 이상 필요하지 않은 노드를 자동으로 제거하여 리소스를 절약
    • 이러한 작업은 Kubernetes API와 통합되어 있으며, 클러스터 상태를 모니터링하고 리소스 사용량에 따라 적절한 조치
  • Karpenter

    

    • AWS에서 Kubernetes 클러스터를 자동으로 확장하는 오픈 소스 도구
    • AWS의 EC2 인스턴스를 관리하고 클러스터의 리소스 요구에 따라 인스턴스를 동적으로 조정하여 클러스터의 확장성과 효율성을 향상
    • Kubernetes 클러스터의 Auto Scaling 기능을 향상시켜, 클러스터 내에서 실행 중인 워크로드의 요구 사항에 따라 EC2 인스턴스를 자동으로 확장하거나 축소
    • AWS의 Auto Scaling 그룹을 활용하여 인스턴스를 관리하며, 클러스터에 필요한 EC2 인스턴스 유형과 용량을 설정
    • AWS의 Spot 인스턴스와 같은 저렴한 인스턴스 유형을 활용하여 비용을 절약

---

• Workshop 실습 환경 준비

• EKS 클러스터에 쿠버네티스 클러스터 오토스케일러를 설치

---

✅ Cluster Autoscaler (CA)

• EKS 클러스터에 설치된 Cluster Autoscaler 확인

 

• 모든 애플리케이션 구성 요소를 업데이트하여 복제본 수를 4개로 늘립니다.
• 클러스터에서 사용 가능한 것보다 더 많은 리소스가 소비되어 더 많은 컴퓨팅을 프로비저닝

• 클러스터 오토스케일러가 EC2 fleet 을 확장하도록 트리거

• 클러스터-자동 스케일러 로그 확인

• EC2 AWS 관리 콘솔에서 자동 확장 그룹이 수요에 맞게 확장되고 있는지 확인

 

💠 클러스터 오버 프로비저닝

• 쿠버네티스 클러스터 오토스케일러(CA)는 스케줄 대기 중인 파드가 있을 때 클러스터의 노드를 스케일링하도록 EKS 노드 그룹의 AWS EC2 자동 스케일링 그룹(ASG) 을 구성
• ASG를 수정하여 클러스터에 노드를 추가하는 이 프로세스는 본질적으로 파드를 스케줄링하기 전에 추가 시간을 추가
• 애플리케이션이 확장될 때 생성된 파드를 사용할 수 있게 되기까지 몇 분 소요
• placeholder 로 사용되는 우선순위가 낮은 파드를 실행하는 추가 노드로 클러스터를 "오버 프로비저닝"함으로써 이 문제를 해결
  • Placeholder Pod
    • Kubernetes 클러스터 내에서 특정 노드의 일시적인 이용 가능한 자원을 나타내는 데 사용되는 임시 파드
• 우선순위가 낮은 파드는 중요한 애플리케이션 파드가 배포될 때 제거
• 빈 파드는 CPU와 메모리 리소스뿐만 아니라 AWS VPC 컨테이너 네트워크 인터페이스(CNI)에서 할당된 IP 주소도 확보

---

• 파드는 다른 파드에 상대적인 우선순위를 할당
• 쿠버네티스 스케줄러는 이를 사용하여 우선순위가 더 높은 파드를 수용하기 위해 우선순위가 더 낮은 다른 파드를 선점
• 우선순위 값을 가진 우선순위클래스 리소스가 생성되어 파드에 할당되며, 기본 우선순위클래스는 네임스페이스에 할당

---

• 파드가 다른 파드보다 상대적으로 높은 우선순위를 가질 수 있도록 하는 우선순위 클래스

• 우선순위 클래스를 사용하는 파드 명세

• EKS 클러스터에서 컴퓨팅 오버프로비저닝을 수행하는 방법
  • 우선순위 값이 "-1"인 우선순위 클래스가 생성되어 빈 일시 중지 컨테이너 파드에 할당 : 빈 "일시 중지" 컨테이너는 플레이스홀더 역할
  • 기본 우선순위 클래스는 우선순위 값 "0"으로 생성 : 이것은 클러스터에 대해 전역적으로 할당되므로 우선순위 클래스가 없는 모든 배포에는 이 기본 우선순위가 할당
  • 실제 워크로드가 예약되면 빈 플레이스홀더 컨테이너가 제거되고 애플리케이션 파드가 즉시 프로비저닝
  • 클러스터에 보류(Pause Container) 파드가 있기 때문에, 클러스터 오토스케일러가 시작되고 EKS 노드 그룹과 연결된 ASG 구성(--max-size)에 따라 추가 Kubernetes 워커 노드를 프로비저닝
• 필요한 오버 프로비저닝의 양은 다음과 같이 제어
  • 필요한 CPU 및 메모리 리소스 요청이 있는 일시 정지 파드(레플리카) 수
  • EKS 노드 그룹의 최대 노드 수(최대 크기)

💠 오버프로비저닝 설정

• 애플리케이션에 적합한 PriorityClass 를 생성
  • PriorityClass
    • 우선순위 클래스를 정의하는 Kubernetes 리소스
    • 시스템은 어떤 파드를 먼저 처리해야 하는지 결정
    • 높은 값일수록 더 높은 우선순위
• global default priority 클래스를 globalDefault:true  필드를 사용하여 생성
• 기본 PriorityClass 는 PriorityClassName 을 지정하지 않은 파드/디플로이먼트에 할당

• 우선순위 값 -1로 오버프로비저닝에 사용되는 파드를 일시 중지하는 데 할당될 PriorityClass 를 생성

• Pause pods 는 환경에 필요한 오버 프로비저닝의 양에 따라 사용 가능한 노드가 충분한지 확인
• ASG의 -max-size 매개변수(EKS 노드 그룹의) 에 유의
• 클러스터 오토스케일러는 ASG에 지정된 이 최대값을 초과하여 노드 수를 늘리지 않음

• 7Gi 의 메모리를 요청하는 단일 pause pods 를 예약 -> 거의 전체 m5.large 인스턴스를 소비 -> 항상 2개의 "예비" 워커 노드를 사용
• 클러스터에 업데이트를 적용

• 작업이 완료되면 pause pods 가 실행

• CA에 의해 추가 노드가 프로비저닝된 것을 확인

• 두 노드는 "실제" 워크로드가 예약될 때 퇴출되는 일시 중지 포드를 제외하고는 어떤 워크로드도 실행하고 있지 않음

💠 추가 확장

• CA 보다 전체 애플리케이션 아키텍처를 더 확장하여 응답성이 어떻게 달라지는지 확인

• 클러스터에 업데이트 적용

• 새 파드가 생성되면 결국 pause pods 가 워크로드 서비스가 사용할 수 있는 리소스를 소비하는 충돌이 발생
• 우선순위 구성으로 인해 워크로드 파드가 시작될 수 있도록 하기 위해 pause pods  가 제거
• pause pods  의 일부 또는 전부가 Pending 상태로 남음
• 워크로드 포드가 ContainerCreating 및 Running 으로 더 빠르게 전환

✅ Karpenter 

• Workshop 실습 환경 준비

• EKS 클러스터에 Karpenter 설치

• Karpenter EKS 클러스터 설치 확인

• Karpenter 노드가 클러스터에 참여할 수 있도록 EKS IAM 매핑을 업데이트

💠 노드 풀 설정

• 카펜터 구성은 NodePool CRD(커스텀 리소스 정의) 형태로 제공
  • 단일 카펜터 NodePool  은 다양한 파드 형태를 처리
  • 카펜터는 레이블 및 선호도와 같은 파드 속성을 기반으로 스케줄링 및 프로비저닝 결정
• Karpenter의 주요 목표 중 하나는 용량 관리를 간소화하는 것
  • Karpenter 는 group-less auto scaling  이라는 다른 접근 방식 사용
  • 다른 솔루션은 전통적으로 node group 이라는 개념을 제어 요소로 사용해 제공되는 용량의 특성(예: 온디맨드, EC2 스팟, GPU 노드 등)을 정의하고 클러스터에서 원하는 그룹의 규모를 제어
  • AWS에서 노드 그룹의 구현은 Auto Scaling groups 과 일치
  • Karpenter를 사용하면 컴퓨팅 요구 사항이 서로 다른 여러 유형의 애플리케이션을 관리할 때 발생하는 복잡성을 피할 수 있음

---

• 두 가지 CRD인 NodePool 과 EC2NodeClass 를 적용
  • Karpenter가 기본적인 확장 요구 사항을 처리하기 시작하기 위한 요구 사항

모든 새 NodePool 에 데모 목적으로 파드가 있는 카펜터 노드를 특별히 타겟팅할 수 있도록 레이블 유형: karpenter로 시작하도록 요청

---

• Karpenter의 구성의 두 부분
  • 첫 번째는 일반적인 NodePool 사양을 정의
  • 두 번째 부분은 AWS용 공급자 구현(이 경우 EC2NodeClass)에 의해 정의되며 AWS에 적용되는 특정 구성을 제공
• 요구 사항 섹션
  • NodePool  CRD 는 인스턴스 유형 및 영역과 같은 노드 속성 정의를 지원
  • 실습에서는 처음에 카펜터를 온디맨드 인스턴스 프로비저닝으로 제한하기 위해 karpenter.sh/capacity-type 을 설정하고, 적절한 인스턴스 유형의 하위 집합으로 제한하기 위해 kubernetes.io/os, karpenter.k8s.aws/instance-category 및 karpenter.k8s.aws/instance-generation 을 설정
• 제한 섹션
  • NodePool  은 관리되는 CPU 및 메모리 양에 대한 제한을 정의
  • 이 한도에 도달하면 카펜터는 해당 특정 NodePool  과 관련된 추가 용량을 프로비저닝하지 않으므로 총 컴퓨팅에 제한이 적용
• 태그
  • EC2NodeClass 는 EC2 인스턴스가 생성될 때 갖게 될 태그 집합을 정의
  • 이는 EC2 수준에서 계정 및 거버넌스를 활성화하는 데 도움
• 셀렉터
  • EC2NodeClass 리소스는 securityGroupSelectorTerms 와 subnetSelectorTerms 용어를 사용하여 노드를 시작하는 데 사용되는 리소스를 검색
  • 이러한 태그는 워크샵을 위해 제공된 관련 AWS 인프라에 자동으로 설정

---

• NodePool 및 EC2NodeClass 를 적용

• 카펜터 로그 확인

💠 자동 노드 프로비저닝

• 주어진 시간에 예약할 수 없는 파드의 필요에 따라 적절한 크기의 EC2 인스턴스를 동적으로 프로비저닝
• EKS 클러스터에서 사용되지 않는 컴퓨팅 리소스의 양을 줄일 수 있음
• 현재 Karpenter가 관리하는 노드 확인

• 클러스터를 예측 가능하게 확장하는 데 사용할 memory: 1Gi  의 리소스 요청이 있는 간단한 일시 pause 컨테이너 이미지를 사용
• nodeSelector 는 type: karpenter 로 설정되어 있으며, 이는 Karpenter 노드 풀에서 프로비저닝된 해당 레이블이 있는 노드에서만 파드를 스케줄해야 한다는 점에 유의
• 0 개의 레플리카로 시작

 

PAUSE CONTAINER 란?
public.ecr.aws/eks-distro/kubernetes/pause 이것은 실제 리소스를 소비하지 않고 빠르게 시작하는 작은 컨테이너로, 확장 시나리오를 시연하는 데 적합.

• 배포를 적용

• 이제 이 배포를 의도적으로 확장하여 Karpenter가 최적화된 의사 결정을 내리고 있음을 입증
• 1Gi의 메모리를 요청했으므로 배포를 5개의 복제본으로 확장하면 총 5Gi의 메모리를 요청하게 됨
• 배포 확장

• 이 작업은 하나 이상의 새 EC2 인스턴스를 생성하는 것이므로 시간이 소요

• 모든 파드가 실행되면, 어떤 인스턴스 유형을 선택하는지 확인
• 우리가 예약한 파드는 8GB 메모리가 있는 EC2 인스턴스에 잘 맞을 것이며, Karpenter는 항상 온디맨드 인스턴스에 대해 가장 낮은 가격의 인스턴스 유형을 우선시하기 때문에 m5.large를 선택

최저 가격이 아닌 다른 인스턴스 유형이 선택될 수 있는 경우가 있습니다(예: 가장 저렴한 인스턴스 유형이 작업 중인 지역에 사용 가능한 잔여 용량이 없는 경우).

• Karpente가 노드에 추가한 메타데이터를 확인
• 인스턴스 유형, 구매 옵션, 사용 가능 영역 등 설정된 다양한 레이블이 표시

• 컴퓨팅 용량이 필요한 워크로드의 리소스 요구사항에 따라 적합한 인스턴스 유형을 동적으로 선택할 수 있다는 사실을 확인
• 이는 단일 노드 그룹 내의 인스턴스 유형이 일관된 CPU 및 메모리 특성을 가져야 하는 클러스터 오토스케일러와 같은 노드 풀을 중심으로 하는 모델과는 근본적으로 다름

💠 중단(통합)

• Karpenter는 중단 가능한 노드를 자동으로 발견하고 필요할 때 대체 노드를 스핀업합니다. 이는 세 가지 이유로 발생
  • 만료
    • 기본적으로 Karpenter는 720시간(30일) 후에 인스턴스를 자동으로 만료하여 노드를 최신 상태로 유지할 수 있도록 강제로 재활용
  • 드리프트
    • Karpenter는 구성(예: NodePool 또는 EC2NodeClass)의 변경을 감지하여 필요한 변경 사항을 적용
  • 통합
    • 비용 효율적인 방식으로 컴퓨팅을 운영하기 위한 중요한 기능인 Karpenter는 지속적으로 클러스터의 컴퓨팅을 최적화
    • 예를 들어, 활용도가 낮은 컴퓨팅 인스턴스에서 워크로드가 실행되고 있는 경우 더 적은 수의 인스턴스로 통합

---

• 중단은 노드풀의 중단 블록을 통해 구성
• 다음 정책은 이 실습의 앞부분에서 정의한 노드풀에 이미 구성

• 워크로드 파드를 포함하지 않는 노드로만 중단을 제한하는 WhenEmpty로 consolidationPolicy를 설정할 수도 있음

---

• 인프라를 확장하는 것은 비용 효율적인 방식으로 컴퓨팅 인프라를 운영하기 위한 방정식의 한 측면
  • 예를 들어 활용도가 낮은 컴퓨팅 인스턴스에서 실행되는 워크로드를 더 적은 수의 인스턴스로 압축하는 등 지속적으로 최적화할 수 있어야 함
  • 이렇게 하면 컴퓨팅에서 워크로드를 실행하는 방식의 전반적인 효율성이 향상되어 오버헤드가 줄어들고 비용이 절감
• 중단이 consolidationPolicy: WhenUnderutilized 로 설정된 경우 자동 통합을 트리거하는 방법
  
  • 인플레이트 워크로드를 5개에서 12개 복제본으로 확장하여 Karpenter가 추가 용량을 프로비저닝하도록 트리거
  • 워크로드를 다시 5개 복제본으로 축소
  • Karpenter가 컴퓨팅을 통합하는 것을 관찰
• 인플레이트 워크로드를 다시 확장하여 더 많은 리소스를 사용

• 총 메모리 요청이 약 12Gi로 변경되며, 각 노드의 kubelet을 위해 예약된 약 600Mi를 고려하도록 조정하면 이는 m5.large 유형의 인스턴스 2개에 적합하다는 의미

• 그런 다음 복제본 수를 다시 5개로 줄임

• Karpenter 로그를 확인하여 배포에서 확장에 따라 어떤 조치가 취해졌는지 파악

• 쿠버네티스 스케줄러가 남은 용량에 따라 해당 노드에 파드를 배치하게 되며, 이제 카펜터가 총 1개의 노드를 관리하고 있음

• 워크로드 변화에 대응하여 노드를 더 저렴한 변형으로 교체할 수 있는 경우 Karpenter를 더욱 통합
• 이는 인플레이트 배포 복제본을 1로 축소하여 총 메모리 요청량을 약 1Gi로 줄임으로써 입증

• 카펜터 로그를 확인하여 컨트롤러가 이에 대응하여 어떤 조치를 취했는지 확인
• 출력에는 Karpenter가 대체를 통해 통합하고, m5.large 노드를 프로비저너에 정의된 더 저렴한 c5.large 인스턴스 유형으로 대체하는 것이 표시

 

• 복제본 1개를 사용하면 총 메모리 요청량이 1Gi 정도로 훨씬 낮기 때문에 4GB 메모리를 사용하는 저렴한 c5.large 인스턴스 유형에서 실행하는 것이 더 효율적
• 노드가 교체되면 새 노드에서 메타데이터를 확인하여 인스턴스 유형이 c5.large임을 확인