EKS OverProvisining - 1

Intro

 

AWS EKS를 사용하면서 서비스 규모가 확장되고, Pod의 수가 늘어나거나 HPA에 의해 Scale Out이 필요한 상황들이 발생한다. 이런 경우에 노드의 리소스 부족으로 인해 새로운 Pod를 실행할 수 없는 상황이 생길 수 있다. 이러한 문제를 해결하기 위해 EKS는 Cluster AutoScaling 기능을 제공하며, 추가적으로 Karpenter라는 도구도 사용할 수 있다. 관리형 노드 그룹에 새로운 노드를 추가하는 방식으로 동작한다. 그러나, 실제로 이 기능을 적용했을 때 문제점이 하나 있다. 바로 새로운 노드가 관리형 그룹에 추가되고 실행 가능 상태가 되기까지 약간의 시간이 소요된다는 점이다. 이때 요청이 증가해서 가동되고 있는 파드들 또한 문제가 발생한다면, 서비스의 다운타임이 발생할 수 있다. 이런 문제를 해결하고 동시에 비용 효율성을 유지하는 방법을 살펴보자.

 

 

Kubernetes Cluster Auto Scaler

 

먼저 Cluster Auto Scaler가 무엇이지 알아보자. 순서는 아래와 같다.

 

1. EKS Control Plane에서 노드 리소스가 부족해서 Unschedule 상태인 파드가 있는지 확인한다.

2. 파드 기동에 필요한 인스턴스 수만큼 AWS AutoScailing이 노드를 늘린다. (여기서 EC2 탭에 있는 Auto Scailing과는 다르다.)

3. 노드가 Ready 상태가 되면 파드들이 실행된다.

온디멘드, 스폿 인스턴스를 붙이느냐에 따라서 비용을 효율적으로 가져갈 수 있다. 다음 챕터에서 알아보자.

 

이 방식을 활용해서 추가적인 파드를 실행한다. 하지만 위에서 언급했듯이 스케일 아웃하는데, 시간이 소요된다. 문제는 생각보다 간단한다. Kubernetes Priority와 노드에 미리 많은 양의 파드를 실행시켜 놓으면 된다. 이것을 오버 프로비저닝이라고 한다. 개념을 알아보자.

 

Kuberenetes PriorityClass

 

PriorityClass(이하 PC)는 파드의 우선순위를 정하는 방법 중 하나다. PC는 파드에게 부여함으로써 리소스가 부족할 때 어느 파드를 삭제할지 판단한다. 이 기능을 활용하면 된다. 실제 서비스에 동작하는 파드에 높은 우선순위를 주고, 오버 프로비저닝을 활용하기 위한 더미 파드에 낮은 우선순위를 부여하면 된다. 

 

PC는 아래와 같이 작성할 수 있다.

 

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: dummy-priority
value: 1
globalDefault: false
description: "더미용 파드에만 사용해야 한다."

 

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: service-priority
value: 1000000
globalDefault: false
description: "서비스용 파드에만 사용해야 한다."

 

위와 같이 작성했을 때 더미용 파드는 우선순위가 낮으므로 서비스용 파드가 실행할 리소스가 부족할 때 더미용 파드의 리소스를 선점하여 동작한다. 더미용 파드가 실행되기 위해서 노드를 프로비저닝 하게 된다. 결과적으로 다운 타임 없이 새로운 노드에 서비스용 파드가 프로비전이 될 수 있다. 우선순위 같은 경우는 유연성을 제공하기 위해서 일정한 간격을 두는 것이 좋다.

ex) 1000, 2000, 3000

 

파드에는 아래와 같이 적용할 수 있다.

 

apiVersion: v1
kind: Pod
metadata:
  name: dummy
  labels:
    env: test
spec:
  containers:
  - name: dummy
    image: busy-box
    imagePullPolicy: IfNotPresent
  priorityClassName: dummy-priority
---
apiVersion: v1
kind: Pod
metadata:
  name: service
  labels:
    env: test
spec:
  containers:
  - name: service
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: service-priority

 

마무리

 

EKS Cluster Auto Scaler와 Kubernetes PriorityClass를 통해서 EKS의 노드 그룹 Auto Scailing에서 발생할 수 있는 다운 타임을 해결해 봤다. 다음 포스팅에서는 실제로 적용해보려고 한다. 거기에 대해서 노드 그룹 자체에도 우선순위를 부여해서 비용을 절감할 수 있는 방안도 알아본다.