[Kubernetes] 파드의 리소스 자원 사용량을 제한시켜보자

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

쿠버네티스 클러스터를 멀티 노드 환경으로 구축하는 데 있어서 얻을 수 있는 또 다른 강점은 여러 대의 노드(서버)를 묶어서 리소스(CPU, 메모리) 풀로 사용할 수 있다는 점이다. 이러한 점을 활용한다면 특정 파드에서 더 많은 CPU 와 메모리를 필요로 한다면 리소스 풀을 사용해 동일한 리소스 스펙을 갖는 파드를 또 하나 추가시켜 수평 확장(Scale-Out)을 수행할 수도 있다.
 
하지만 이러한 Scale-Out 기능 만큼 또 다른 중요하게 신경써야 할 점이 있는데, 그것은 바로 컴퓨팅 자원 활용률(Utilization)이다. 이 '컴퓨팅 자원 활용률'이라 함은 실행 중인 파드 또는 컨테이너의 CPU, 메모리 사용률이 얼마나 잘 활용되고 있는지를 의미한다. 딥러닝 분야에서 쉬운 예시로, 이미지나 자연어 처리 모델을 GPU로 학습시키는데, GPU 사용률이 높지 않은 것을 보고 GPU Utilization이 높지 않다고 하기도 하는데, 이것도 컴퓨팅 자원 활용률이 낮은 하나의 예시이다. 
 
이번 포스팅에서는 파드 또는 컨테이너의 컴퓨팅 자원 활용률을 높일 수 있는 쿠버네티스의 여러 가지 기능에 대해 살펴본다. 우리는 지금까지 쿠버네티스의 파드에 대한 매니페스트(YAML) 파일의 내용을 작성해보면서 특정 파드 또는 컨테이너가 점유하고 사용해야 할 특정 스펙의 CPU, 메모리 리소스를 정의한 적은 없었다. 이렇게 따로 명시하지 않으면 파드 또는 컨테이너는 자신이 할당된 노드의 물리 자원을 모두 사용할 수 있게 되기 때문에 극단적으로는 특정 파드 때문에 해당 파드가 할당된 노드의 물리적인 자원이 고갈되어 그 노드에 할당되어 운영되고 있는 다른 파드들에 영향을 미칠 수가 있다.

1. 컨테이너와 파드의 자원의 사용량을 제한시키자!

1-1. 자원의 최대 사용량을 제한시킨다 : limits

쿠버네티스도 도커와 마찬가지로 내부적으로 파드의 최대 자원 사용량을 제한시키기 위해서 cgroup 이라는 리눅스 기술을 이용한다. 도커에서는 명령어에 --memory, --cpu, --cpu_shares, --cpu-quota, --cpu-runtime 과 같은 옵션을 주어 실행할 컨테이너가 사용할 자원 사용량의 최대값을 제한시켰다. 
 
쿠버네티스에서는 limits 라는 키워드를 통해서 자원의 사용량 최대값을 제한시킨다. limits를 사용한 예시 매니페스트 파일부터 살펴보자.
 

apiVersion: v1
kind: Pod
metadata:
  name: resource-limit-pod
  labels:
    name: resource-limit-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      resources:
        limits:
          cpu: "1000m"
          memory: "250Mi"

 
위 YAML 파일의 spec.containers.resources 항목을 보면 limits 항목에 cpu 와 memory 라는 키워드로 할당할 리소스의 하위 항목을 정의한 것을 볼 수 있다. cpu 와 memory 에 명시된 단위에 대해 잠시 알아보자면, cpu에서 1000m(밀리코어) 당 우리가 흔히 알고 있는 cpu core 1개를 의미한다. 그리고 memory가 250Mi 로 적혀있는데, 이는 우리가 흔히 알고 있는 단위인 MB와 거의 유사하다고 보면 된다. 엄밀히 말해서 Mi Mebibyte로 $2^{20}$ 바이트이지만, MB는 Megabyte로 $10^6$ 바이트이다. 그래서 250Mi를 MB로 변환하면 대략 262.14MB로 250MB 보다 약간 더 큰 수치이다. 간단히 말해서 250Mi = 250MB + 알파 라고 생각하면 되겠다.
 
그리고 위 예시에서는 파드에 리소스를 명시했지만, 사이드 컨테이너 패턴과 같이 하나의 파드에 여러 개의 컨테이너가 할당될 수 있는데, 만약 이럴 경우 각 컨테이너 마다에도 리소스를 할당할 수 있다는 점도 알아두자. 예시는 공식문서를 참조하자.
 
다음은 limits 와 비슷하지만 다른 역할을 하는 requests 라는 것을 살펴보도록 하자. 일단 requests가 무엇을 의미하는지부터 설명하자면 "적어도 이 만큼의 자원을 컨테이너에게 보장되어야 해"를 의미한다. 그런데 requests 라는 것이 어떤 것을 위해 등장했는지 이해하기 위해서는 쿠버네티스에서의 자원 오버커밋(Overcommit)에 대해서 먼저 이해를 해야 한다. 

1-2. 자원 활용률(Utilization)을 높이도록 오버커밋(Overcommit) 시키자 : requests

위에서 컨테이너의 자원 활용률을 높이는 것은 컨테이너 자체를 Scale-out 하는 것 만큼이나 중요하다고 했다. 이런 자원 활용률을 높이기 위한 방법 중 하나로 쿠버네티스에서는 오버커밋이라는 것을 할 수 있다. 오버커밋이란, 한정된 컴퓨팅 자원을 효율적으로 사용하기 위한 방법으로, 사용할 수 있는 자원보다 더 많은 양을 VM 또는 컨테이너에게 할당함으로써 전체 자원의 활용률을 높이는 방법을 의미한다.
 
엥? 아니 어떻게 애초에 존재하는 자원보다 더 많은 자원을 할당한다는 것인가? 이는 예전에 배운 CS 지식 중 마치 가상 메모리가 동작하는 방식이랑 유사하다. 실제 그만큼 자원이 있는 것은 아니지만, 유휴 자원을 이용해 마치 실제 자원보다 더 많이 사용하는 듯하도록 하는 것이다 우선 아래와 같이 총 1GB의 메모리를 갖는 노드(서버)에 2개의 컨테이너가 운영되고 있다고 가정해보자.
 

 
B 컨테이너는 할당받은 500MB 메모리를 100% 만큼 아주 알차게 잘 사용하고 있다. 하지만 A 컨테이너의 경우, 할당 받은 500MB에 비해 고작 1/10 수준 정도 밖에 사용하지 않고 있다. 결국, A 컨테이너에 할당되었지만 450MB가 유휴 자원으로 남고 있는 것이다. 컨테이너를 실행할 때 정적으로 리소스를 명시하는 방법은 위와 같이 유휴 자원이 발생할 경우 유후 자원을 자원 활용률이 높은 B 컨테이너에 넘겨줄 수가 없다. 물론 각 컨테이너의 리소스 사용량을 사전에 정밀하게 계산해서 정적으로 리소스를 할당할 수도 있겠지만, 대부분의 개발자가 이미 알고있다시피 애플리케이션 서버나 데이터베이스 서버같은 경우, 트래픽이 많아지는 시점이 매번 달라질 수도 있으며, 이러한 것들을 모두 계산해서 최적의 리소스를 사전에 계산하기는 거의 불가능하다. 
 
하지만 쿠버네티스에서는 오버커밋이라는 기능을 통해 자원 활용률이 낮은 컨테이너의 유휴 자원을 자원 활용률이 높은 컨테이너에게 임시로 대여를 해줄 수가 있다.
 

 
위 그림을 보면 B 컨테이너는 A 컨테이너의 유휴 자원을 이용해서 총 750MB 까지의 메모리를 사용할 수 있게 되었다. 이 때, B 컨테이너가 A 컨테이너의 유휴 자원까지 사용해서 최대로 사용할 수 있는 메모리 용량인 750MB가 바로 위에서 알아본 limits가 된다.
 
물론 위 그림에서 할당된 전체 메모리가 1.5GB 라고 할지라도 노드의 실제 물리적인 전체 메모리인 1GB 이상으로 사용할 수 있는 것은 아니다. 만약 B 컨테이너가 750MB를 사용하고 있다가 갑자기 A 컨테이너의 메모리 사용률이 늘어서 500MB로 증가하게 되는 그 순간 메모리 경합이 발생하게 된다. 참고로 메모리의 경합이 발생하는 경우, 좀 더 우선순위가 낮은 컨테이너의 프로세스를 먼저 종료시키는데, 이런 우선순위에 대한 내용은 추후에 알아볼 QoS 클래스에 대해서 설명한다.
 
그러면 requests는 어떤 상황에서 등장하게 되었을까? 만약에 A, B 컨테이너 모두 500MB 메모리를 각각 점유하고 있다고 해보자. 그러던 중 B 컨테이너가 갑자기 사용중인 메모리가 증가해 750MB로 증가한다면 어떻게 될까?
 

 
이렇게 되면 메모리 충돌이 일어나 컨테이너가 비정상적으로 종료될 수 있는 문제가 발생한다. 이러한 상황을 사전에 예방하기 위해서 각 컨테이너가 반드시 사용을 보장받을 수 있는 리소스의 경계선을 정할 필요가 있었고, 이 경계선을 의미하는 것이 바로 requests다. 
 
A, B 컨테이너에 limits, requests 수치를 적용한 그림을 살펴보자.
 

 
A, B 컨테이너 모두 limits는 750MB, requests는 500MB 이다. 고로, A, B 컨테이너 모두 적어도 500MB의 메모리는 항상 보장받아야 하되 다른 컨테이너의 유휴 자원이 있을 경우 최대 250MB를 추가로 하여 즉, 최대 750MB 까지 메모리를 사용할 수 있게 된다. 위 그림의 경우, 현재 A 컨테이너가 50MB 밖에 메모리를 사용하지 않기 때문에 바로 B 컨테이너는 750MB 까지 메모리를 증가시킬 수 있을 것이다. 하지만 A 컨테이너가 500MB 메모리를 사용 중인 상태에서 B 컨테이너가 750MB 까지 메모리 사용량을 증가시킨다면 그 즉시, B 컨테이너에서 OOM 에러가 발생하게 된다.

결국, A 컨테이너에서 사용되지 않는 유휴 자원을 B 컨테이너가 가져다 사용하여 자원 활용률을 높일 수 있게 한다. 대신 컨테이너에서 OOM이 발생할 가능성이 있음을 대가로 치르는 셈이다.
 
이 requests는 당연하게도 노드의 총 자원의 크기보다 더 많은 양의 requests를 파드에 할당할 수는 없다. 따라서 파드 매니페스트에 requests를 명시하게 되면 쿠버네티스 스케쥴러는 파드 매니페스트에 명시된 requests 만큼의 여유가 있는 노드를 선택해서 해당 노드에 파드를 생성하게 된다. 결국, 쿠버네티스 스케쥴러가 파드를 어떤 노드에 생성할지 선택하는 기준은 생성할 파드 매니페스트에 명시된 requests 라는 항목이라는 것이다. 물론 이 requests 값을 극단적으로 낮게 설정해서 파드가 어떤 노드에라도 생성되는 것을 스케쥴링 할 수는 있겠지만, 그 파드가 실행하는 애플리케이션의 사용 리소스 자원이 requests 보다 높다면 파드가 생성되고 실행되는 과정에서 에러가 발생할 가능성이 매우 크기 때문에 requests 값을 극단적으로 낮게 설정하는 것이 능사는 아니라는 점을 염두해 두자.

2. CPU 자원 사용량을 제한시키는 원리

1번 목차에서 자원 활용률을 높이기 위한 방법으로 오버커밋을 수행하기 위해 쿠버네티스에서는 requests, limits 라는 것을 활용한다는 것을 배웠다. 이번 목차에서는 컴퓨팅 리소스 중 CPU에 초점을 맞추어, 이 CPU라는 자원 사용량을 쿠버네티스가 어떻게 제한시키는지 원리에 대해서 간단하게 알아보도록 하자. 파드에 리소스를 다음과 같이 정의한 매니페스트 파일이 있다고 해보자.
 

apiVersion: v1
kind: Pod
metadata:
  name: resource-limit-request-pod
  labels:
    name: resource-limit-request-pod
spce:
  containers:
    - name: nginx
      image: nginx:latest
      resources:
        limits:
          cpu: "1000m"
          memory: "256Mi"
        requests:
          cpu: "500m"
          memory: "128Mi"

 
위 매니페스트를 간단하게 해석하면 생성된 파드의 nginx 컨테이너는 CPU를 1000m(CPU 코어 1개)를 최대로 사용할 수 있으며 최소 500m를 최소로 보장받아야 한다. 위 매니페스트의 requests 항목에 정의한 CPU 자원이 실질적으로 컨테이너 내부에서는 어떻게 설정되는지 알아보자. 
 
위 requests.cpu에 명시된 값은 컨테이너가 동작하고 있는 서버에 CPU가 몇 개 있는지 상관없이 requests.cpu에 명시된 값의 할당 비율에 따라서 컨테이너가 실질적으로 사용하는 CPU 자원이 결정된다. 엄밀히 말해서 requests.cpu에 명시된 값을 활용해서 '어떠한 공식'을 이용해 산출된 비율만큼의 CPU 자원이 결정되는 것이다. 이 '어떠한 공식'은 다음과 같다.
 

CPU Share를 결정하는 공식

 
참고로 도커 컨테이너에서는 쿠버네티스와 달리 CPU Share 직접적으로 옵션(--cpu-shares)에 명시하여 할당해줄 수 있다. 쿠버네티스에서는 requests 라는 값으로 결정되기 때문에 아래의 그림 예시는 도커를 활용했다고 가정해서 cpu-shares 값을 명시했다. 어떤 물리적인 서버에 총 3개의 컨테이너가 실행되고 있다고 가정해보자.
 

 
A, B, C 총 3개의 컨테이너가 존재하고, 각 컨테이너의 CPU Shares 값은 1024, 1024, 512 라고 해보자. 위에서 말했다시피 CPU Shares 값은 컨테이너들이 올라가 있는 물리 서버의 CPU 개수가 몇 개인지에 상관없이 물리 서버가 가지고 있는 총 CPU를 CPU Shares 값 비율에 따라 할당하게 된다. 
 
또한 CPU도 어떤 컨테이너가 사용하는 CPU 자원이 유휴 자원이 있게 되면 이를 활용하게 된다. 예를 들어, 위 그림에서 C 컨테이너의 프로세스가 종료되었다고 해보자.
 

 
그러면 위처럼 여전히 운영 중인 A, B 컨테이너에 각각 할당된 CPU Shares 값에 맞게 CPU 자원들이 재분배된다. 위 그림 상으로는 A, B 컨테이너의 CPU Shares 값이 동일하므로 이를 비율로 환산하게 되면 각각 50%씩 사용할 수 있게 된다.
 
이번에는 CPU도 requests 뿐만 아니라 limits 도 고려하는 상황 즉, 오버커밋 상황일 때도 고려해보자. 다시 A, B 컨테이너가 띄워져 있고, 각 컨테이너에 명시된 리소스 제한은 아래와 같다.
 

 
위와 같이 A 컨테이너는 50%를 알차게 잘 사용하고 있다. 그에 반해 B 컨테이너는 할당받을 수 있는 최소 양(requests.cpu)인 50% 중 25% 밖에 사용하지 않고 있다. 그래서 A 컨테이너는 limits.cpu 값이 700m으로 설정되어 있어서, 오버커밋을 수행하기 위해 B 컨테이너의 유후 자원을 가져와 CPU를 더 사용하게 되었다.
 

 
그런데 갑작스레 B 컨테이너에서 CPU를 많이 사용하는 작업이 필요하여 B 컨테이너가 자신에게 할당받은 최소 조건의 양만큼인 500m로 CPU 사용량을 늘리려고 시도하고 있다고 해보자.
 

 
이렇게 되면 어떤 상황이 발생할까? 바로 A 컨테이너에서 CPU 쓰로틀링(throttling)이 발생하게 된다. 여기서 CPU 쓰로틀링이란 개념에 대해서 잠시 살펴보도록 하자. 우선 CPU는 쿠버네티스에서 압축 가능한(Compressible) 리소스라고 부른다. 압축 가능한 리소스라는 것은 requests.cpu 보다 더 많은 CPU를 사용해 CPU 경합 상황(방금과 같은 상황)이 발생하더라도 컨테이너가 종료되지 않고, '쓰토틀' 이라는 것을 통해 컨테이너의 CPU 사용량을  억제할 수 있는 것을 CPU 쓰로틀링이라고 한다.
 
다시 돌아와서, 위와 같은 CPU 경합 상황이 발생하면 컨테이너 A에서 CPU 쓰로틀링이 발생하게 된다. 그런데 CPU 쓰로틀링이 발생하는 주체가 왜 컨테이너 A일까? 컨테이너 B이면 안될까? 위 상황에서 A 컨테이너는 requests.cpu 를 만족하면서도 심지어 최대 사용량인 limits.cpu 까지도 사용하고 있었다. 하지만 B 컨테이너는 requests.cpu 즉, 최소로 보장되어야 할 CPU도 사용하지 않고 있었다. 그렇기 때문에 쿠버네티스는 B 컨테이너에게 최소로 보장되어야 할 CPU의 양은 무조건 충족시켜주어야 하기 때문에 B 컨테이너가 아닌 A 컨테이너에게 "너 CPU 그만 써" 라고 하면서 A 컨테이너에서 CPU 쓰로틀링이 발생하는 것이다.
 
이번에는 A, B 컨테이너가 잘 동작중임에도 여전히 유휴 자원이 남을 때 어떻게 리소스를 분배하는지 살펴보도록 하자. 새로운 예시로 A, B 컨테이너의 requests, limits가 아래처럼 재명시되어 컨테이너가 운영되고 있다고 가정해보자.
 

 
이러한 상황에서 유휴 자원이 남아있을 때, A, B 컨테이너 모두 limits에 명시되어 있는 리소스 양까지 최대한 사용할 수 있다. 하지만 쿠버네티스에서는 아래 그림처럼 이런 유휴 자원 마저도 A, B 컨테이너에 명시된 requests.cpu 의 비율에 맞게 분배된다.
 

 
그리고 위에서 쿠버네티스에서는 매니페스트에 명시하는 1000m를 마치 고정된 CPU Core 1개라고 이해를 할 수 있지만 엄밀히 말하면 사실이 아니다. 1000m가 할당된 컨테이너는 CPU 1개에 해당하는 성능을 활용할 수 있는 것 뿐이지 1개의 CPU를 해당 컨테이너 혼자 즉, 배타적으로 사용할 수 있는 것은 아니다. 즉, 어떤 컨테이너에 1000m을 할당하면 이 1000m가 여러 개의 쪼개진 부분 CPU Core들을 모아 마치 1개의 CPU Core 1개에 달하는 성능을 사용하는 것이다. 
 

 
그래서 위처럼 CPU Core 여러 개의 부분 부분을 모아 사용하는 것이기 때문에 만약 CPU 성능을 최대한 활용해야 하는 상황 예를 들어, 멀티 쓰레딩에서 CPU 연산을 실행하기 위해 쓰레드가 CPU 내부의 레지스터 상태를 백업하고 다시 가져오는 등의 컨텍스트 스위칭이나 캐시 미스같은 것들로 인해 성능이 낮아질 수도 있다. 쿠버네티스에서는 이러한 경우를 대비하기 위해서 컨테이너가 특정 CPU를 배타적으로 사용할 수 있도록 CPU Manger 라는 기능도 지원한다. CPU Manager는 kubelet 실행 옵션에서 변경할 수 있다. 

3. 메모리 자원 사용량을 제한시키는 원리 : OOM Killer 와 QoS 클래스

아까 위에서 쿠버네티스에서는 CPU를 압축 가능한 리소스라고 불렀다고 했다. 하지만 다른 종류의 리소스인 메모리와 스토리지는 CPU 와 달리 압축이 불가능한 리소스라고 부른다. 그래서 이런 리소스들에 대해서 경합 상황이 발생하면 OOM과 같은 에러가 발생하면서 어떤 컨테이너의 프로세스가 종료되고 만다. 이렇게 가용 메모리를 확보하기 위해 수많은 파드 또는 컨테이너 프로세스 중 하나를 선정해서 강제로 종료하는 것을 쿠버네티스에서는 퇴거(Eivction)라고 부른다. 그리고 이 때 강제로 종료할 파드 또는 컨테이너 프로세스의 우선순위를 선정하는 데 활용되는 것이 QoS 클래스다.
 
쿠버네티스에서는 강제로 종료할 파드 또는 컨테이너의 우선순위를 정할 때, 먼저 일차적으로 매니페스트에 명시된 limits 와 requests 값에 따라 내부적으로 QoS 라는 클래스를 기준으로 우선순위를 정한다. 구체적으로, QoS 클래스는 크게 3가지 종류가 존재한다. 
 
QoS 클래스에 알아보기에 앞서 쿠버네티스에서는 메모리 부족 현상을 언제, 그리고 어떻게 감지하고 이 때 어떤 기준으로 메모리 자원 사용량을 제한시키는지 순서대로 알아볼 필요가 있다. 결론적으로, 아래 그림을 먼저 보고 하나하나씩 설명을 이어나가 보도록 하자.
 

k8s에서 파드를 Eviction 하는 구조

 
우선 쿠버네티스 클러스터를 구성하는 노드에는 현재 자원 사용량은 어떠한지와 같은 노드의 상태를 나타내는 다양한 값들이 존재한다. 예를 들어, 메모리(RAM) 사용량이 임계치에 도달했는지 여부를 나타내는 MemoryPressure이 있고 디스크(HDD, SDD, ...) 사용량이 임계치에 도달했는지 여부를 나타내는 DiskPressure도 있다.(참고로 이 값들은 boolean 값으로 되어있다) 이러한 상태값을 노드 마다 붙어있는 kubelet 이라는 일종의 Agent가 계속 해당 노드의 상태값을 주기적으로 체크하고 갱신해준다. 이처럼 kubelet이 노드의 상태값을 계속적으로 체크하는 상황 중에 쿠버네티스는 2가지 방법을 이용해서 노드의 가용 메모리를 확보하려고 한다.
 
첫 번째는 kubelet이 노드의 상태값을 체크하면서 노드의 메모리 사용량이 부족하다는 상황을 감지 즉, 예를 들어 MemoryPressure 값이 True로 바뀐 상황을 감지하기 이전에 OOM Killer 라는 것이 먼저 노드의 가용 메모리를 확보하기 위해 선제적인 액션을 수행할 수도 있다.
 
OOM Killer는 쿠버네티스에만 있는 것은 아니고, 원래 리눅스라는 시스템에 내장되어 있는 기능을 의미한다. 그런데 왜 이 OOM Killer가 쿠버네티스에서 동작하는걸까? 바로 쿠버네티스 클러스터를 구성하는 노드도 '리눅스 시스템'이기 때문이다. 따라서 노드에 내장되어 있는 OOM Killer라는 기능이 '어떤 점수'가 높은 컨테이너의 프로세스를 강제로 종료해서 가용 메모리를 확보할 수 있게 된다.
 
그러면 '어떤 점수'가 구체적으로 무슨 점수일까? 이 점수에는 크게 2가지가 존재하는데, 하나는 노드에서 돌아가고 있는 모든 프로세스마다 기본적으로 할당되는 OOM 점수가 존재하고 이를 oom_score_adj 라고 표시한다. 이 oom_score_adj 는 시스템이 돌아가는 데 핵심적인 역할을 할수록 낮은 점수가 할당된다. 실제로 kubelet 과 같은 핵심 프로세스는 -999로 매우 낮은 점수가 할당되어 있는 것을 볼 수 있다. 또 다른 점수로는 oom_score가 있는데, 이는 프로세스가 사용하는 메모리 사용량에 따라 이전에 언급한 oom_score_adj 점수에 반영하여 최종 OOM 점수를 갱신하게 된다. 당연히 메모리 사용량이 많을수록 oom_score는 높게 산정된다. 이유는 메모리를 많이 점유하는 프로세스로 인해서 시스템의 핵심 프로세스를 종료시키게 할수도 있기 때문에 시스템의 안정성을 확보하기 위해 메모리를 많이 점유하는 프로세스부터 강제종료하게 된다.
 
두 번째는 kubelet이 노드의 상태값을 체크하면서 노드의 메모리 사용량이 부족하다는 상황을 감지한 후에 kubelet이 직접적인 주체가 되어서 파드 또는 컨테이너 프로세스를 종료하고 다른 노드로 해당 파드를 재할당하는 방식이다. 이 때 바로 QoS 클래스가 등장한다. QoS 클래스 종류는 매니페스트에 명시되는 requests 와 limits 값에 따라 결정이 된다.

3-1. 얘네들 만큼은 무조건 살려야해! : Guaranteed 클래스

가장 먼저 알아볼 QoS 클래스 종류로는 Guaranteed(이하 개런티드) 클래스가 있다. 이는 requests 과 limits 값이 완전이 동일할 때 부여되는 클래스이다. 참고로 limits 값만 명시하더라도 개런티드 클래스로 분류되는데, 이는 limits 값만 명시하면 내부적으로 requests 값을 limits 값과 동일하게 설정되기 때문이다. 
 
그러면 이 개런티드 클래스의 의미는 무엇일까? requests 와 limits 값의 의미를 잘 생각해보면 된다. requests는 최소 보장받아야 할 리소스 양이고, limits 값은 최대로 보장받을 수 있는 리소스 양이다. 이 2개가 서로 값이 같다는 것은 결국 할당된 자원의 사용만큼만 사용하고 더 사용하지 않는 즉, 오버커밋을 수행하지 않는다는 것이다. 따라서 개런티드 클래스로 분류된 파드 또는 컨테이너들은 할당받은 자원을 매우 안정적으로 사용할 수 있음을 의미한다. 결국, 자원 사용을 안정적으로 보장받는 이 개런티드 클래스를 할당받은 파드의 역할은 도커 데몬이나 kubelet 처럼 시스템의 핵심적인 역할을 할 것이라는 걸 암시하기도 한다.
 
실제로 개런티드 클래스로 분류되는 파드 또는 컨테이너 내부에서 동작하는 프로세스들의 OOM Score를 보면 도커 데몬이나 kubelet 과 같이 점수가 -997로 매우 낮음을 알 수 있다. 참고로 파드 내에 여러 컨테이너가 동작하도록 되어 있다면 모든 컨테이너들의 requests 와 limits 값이 동일하게 설정되어야만 해당 파드가 개런티드 클래스로 분류됨을 기억하도록 하자.

3-2. 아예 사용하지 못하거나, 최대한 많이 사용하거나! : BestEffort 클래스

다음으로 알아볼 QoS 클래스의 종류로는 BestEffort 클래스이다. 이 BestEffort 클래스는 requests 와 limits 값이 매니페스트에 아예 명시되지 않았을 경우 분류된다. 이 BestEffort 클래스로 분류되는 파드는 limits 값을 아예 설정하지 않았기 때문에 노드에 유휴 자원이 있다면 제한없이 모두 사용할 수 있게된다. 하지만 그 반대로 requests 값 또한 아예 설정하지 않았기 때문에 노드에 모든 자원들이 다른 파드들 운영에 모두 쓰이고 있다면 BestEffort 클래스로 분류된 파드는 해당 노드에 생성되지 않는다. 

3-3. 그 외의 경우 : Burstable 클래스

마지막으로 알아볼 종류로는 Burstable 클래스이다. Burstable 클래스는 앞서 배운 Guaranteed 클래스, BestEffort 클래스로 분류되지 않는 파드들이 분류되는 클래스이다. 이는 우리가 2번 목차에서 배운것처럼 requests 와 limits 값이 설정되어 있지만, limits 값이 requests 값보다 더 클 경우에 분류되는 클래스이다. 따라서 이는 노드에 유휴 자원이 있다면 requests 값보다는 높되 최대 limits에 명시된 만큼만 자원의 한계를 확장 즉, 오버커밋을 수행할 수 있게 된다.
 
물론 이 Burstable 클래스로 분류되는 파드는 오버커밋을 수행하다가 다른 파드랑 리소스(CPU, RAM) 경합이 발생할 수 있는 가능성이 존재하는 단점이 있다. 이럴 경우, kubelet은 requests 보다 더 많은 리소스를 사용하고 있는 파드이거나우선순위가 더 낮게 설정되어있는 파드를 선정하여 강제 종료할 가능성이 높아진다.

3-4. QoS 클래스의 우선순위 vs OOM Killer의 OOM Score

방금 Burstable 클래스에서 설명한 것처럼 오버커밋을 수행하다가 경합이 발생하고, 노드의 메모리가 부족한 상황을 kubelet이 감지하면 QoS 클래스에 따라 설정된 우선순위에 따라 특정 파드를 해당 노드로부터 퇴거(Eviction)시켜 다른 노드에다가 파드를 생성하게 된다. 이 때, "우선순위가 낮을수록 퇴거될 가능성이 높은 파드"를 의미한다. 
 
하지만 3번 목차에서 배운것처럼 kubelet이 노드의 메모리 부족 상황을 감지하기 이전에 노드에 장착되어 있는 (리눅스의) OOM Killer 라는 것이 메모리 사용량이 급증하는 것을 보고 해당 노드에서 실행되고 있는 프로세스들 중에 "OOM Score 점수가 가장 높은 컨테이너의 프로세스를 강제로 종료"할 수도 있다.
(참고로 책 p.484 쪽에서는 "OOM Score가 가장 낮은 컨테이너의 프로세스를 강제로 종료" 한다고 하였는데, OOM Score가 낮은 컨테이너는 곧 시스템의 핵심 컨테이너고 이는 강제로 종료할 프로세스 후보에 최대한 배제되어야 한다. 관련해서 저자 분께 이슈로 질문을 하였고, 필자가 이해한 바가 맞다고 한다. 해당 책을 읽으시는 분 중에 헷갈리실 것 같아 참고로 적어둔다.)
 
QoS 클래스의 우선순위와 OOM Killer가 바라보는 OOM Score가 어떤지에 따라 강제 종료할 프로세스를 선택하는 기준이 달라지는데, 필자도 헷갈려서 직접 정리해보도록 하자. 앞으로 아래 규칙만 생각하면 된다.
 

• QoS 클래스에 따라 QoS 우선순위가 낮다 = 강제 종료시킬 가능성이 높은 파드 또는 컨테이너 또는 프로세스
• OOM Score가 높다 = 강제 종료시킬 가능성이 높은 프로세스

여기서 QoS 클래스에 따라 파드가 퇴거되는 것과 OOM Killer가 OOM Score에 기반해서 프로세스를 종료하는 것만 보면 동일한 동작이라고 착각할 수 있다. 하지만 엄연히 다르다. QoS 클래스에 따라 파드가 퇴거하는 것은 말 그대로 파드가 생성될 '노드가 다른 노드로 변경' 되는 것이다. 하지만 OOM Killer가 종료하는 것은 '프로세스'이므로 파드 자체를 종료하는 것은 아니다. 그래서 파드 내의 문제가 되는 '특정 프로세스'만을 종료시키게 된다. 그래서 OOM Killer에 의해 영향받는 파드들은 파드가 노드를 옮기지 않고 동일한 노드에서 파드의 재시작 정책(restartPolicy)에 의해 재시작(Restart)하게 된다. 
 
그러면 이제 QoS 클래스에서 클래스 종류에 따라 우선순위가 어떻게 부여되는지 살펴보자. 우선 Guaranteed 클래스가 가장 우선순위가 높으며, 그 다음은 Burtsable, 마지막으로는 BestEffort 이다. 즉, 뒤로 갈수록 강제 종료되어 퇴거될 가능성이 높아진다는 것이다. 하지만 여기서 Burtsable과 BestEffort 클래스 간의 우선순위는 어떤 클래스로 분류된 파드가 얼마나 메모리를 많이 점유하는지에 따라 우선순위가 역전될 수도 있다는 점을 알아두도록 하자.

4. 네임스페이스 별로 가용 리소스 자원을 격리! : ResourceQuota 와 LimitRange

개발 조직이 커지고, 운영하는 서비스와 시스템이 커지다 보면 쿠버네티스 클러스터도 점점 커지기 마련이다. 그럼에 따라 자연스레 팀 또는 조직 별로 쿠버네티스 클러스터의 리소스를 어떻게 관리할지에 대한 고민이 생기기 마련이다. 가장 간단한 방법은 팀 별로 쿠버네티스 클러스터를 별도로 구성하는 방식이다. 하지만 이 방식은 팀 별로 쿠버네티스 클러스터를 관리하는 담당자가 지정되어야 하고, 자연스레 관리 포인트가 늘어나게 된다.
 
또 다른 방법으로는 하나의 클러스터에 팀 별로 네임스페이스를 생성한 뒤, 각 팀은 해당 팀에 속하는 네임스페이스에서만 쿠버네티스 API를 사용할 수 있도록 RBAC(Role-Based Access Control)을 설정할 수도 있다. 하지만 이 방식은 모든 네임스페이스가 클러스터의 자원을 공유할 수 있기 때문에 특정 네임스페이스에 속하는 파드가 대부분의 리소스를 점유할 수도 있는 극단적인 상황도 발생할 수 있다.
 
이번 목차에서는 팀 별로 네임스페이스를 생성하되, 각 네임스페이스마다 할당받을 수 있는 자원의 최대한도 또는 최대 범위를 설정할 수 있는 ResourceQuota, LimitRange에 대해 배워보려고 한다. 이 2개의 오브젝트는 네임스페이스에 종속되는 오브젝트이기 때문에 네임스페이스별로 사용 가능한 자원량을 관리할 수 있다.

4-1. 네임스페이스에서 파드들의 사용 자원 양의 총합을 제한하자! : ResourceQuota

먼저 ResourceQuota는 특정 네임스페이스에서 사용할 수 있는 자원 사용량의 총합을 제한할 수 있는 오브젝트이다. 좀 더 구체적으로 ResourceQuota는 다음과 같은 2가지 기능을 한다.
 
첫번째로 특정 네임스페이스에 할당할 수 있는 CPU, 메모리, PVC, 컨테이너 내부의 임시 스토리지(ephemeral storage)의 총합을 제한할 수 있다. 이 기능은 네임스페이스 별로 자원 사용량의 총합을 제한하는 것이 주요 목적이다.
 
두번째로 특정 네임스페이스에서 생성할 수 있는 리소스(서비스, 디플로이먼트, 컨피그맵, 시크릿 등)의 개수를 제한할 수 있다. 이는 쿠버네티스 클러스터의 자원을 고갈시키는 것을 막기 위함이다. 예를 들어, 쿠버네티스를 사용하는 개발자의 실수로 어떤 웹서버 애플리케이션을 파드로 하는 디플로이먼트가 무한정으로 계속 생성되고 있다고 해보자. 그러면 결국은 쿠버네티스 클러스터가 느려져서 장애가 발생할 수 있게 된다. 따라서 이러한 문제를 막고자 서비스나 디플로이먼트과 같은 쿠버네티스 리소스들도 생성 개수에 제한을 둘 수 있다.
 
이제 ResourceQuota의 기능 2가지를 차례로 하나씩 살펴보자. 먼저 첫번째 기능으로 특정 네임스페이스에서 CPU, 메모리의 양을 제한하는 ResourceQuota 오브젝트를 생성하는 매니페스트를 살펴보자. 이 때 CPU, 메모리의 양을 제한할 때 위에서 배운 requests, limits 키워드가 또 등장한다는 점도 알아두자.
 

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota-test
  namespace: zedd
spec:
  hard:
    requests.cpu: "1000m"
    requests.memory: "500Mi"
    limits.cpu: "1500m"
    limits.memory: "1000Mi"

 
해당 ResourceQuota를 생성할 네임스페이스는 'zedd'로 설정했다. 위 매니페스트에서는 requests 와 limits를 함께 명시하긴 했지만, 둘 중 하나만 정의해도 상관없다. 위 매니페스트를 해석하면 앞으로 zedd 라는 네임스페이스에서 생성되는 파드의 CPU는 최소 1000 밀리코어에서 1500 밀리코어까지, 메모리는 500Mi 에서 1000Mi 범위 안에 있어야 함을 의미한다. 만약 zedd 라는 네임스페이스에서 운영되고 있는 파드들의 사용 메모리 총합이 900Mi 상태인데, 여기에다가 requests가 200Mi인 파드를 생성하려고 시도 한다면 파드가 생성되지 못하고 에러가 발생한다.
 
만약 ResourceQuota 리소스를 생성한 뒤, 현재 zedd 네임스페이스에서 어느정도의 리소스를 사용하고 있는지 보려면 생성된 ResourceQuota 리소스에 대한 정보를 보면 된다. 
 

kubectl describe $NAME_OF_RESOURCE_QUOTA

 
ResourceQuota의 두번째 기능으로 리소스 개수를 제한하는 것에 대해 알아보자. 좀 더 구체적으로 ResourceQuota는 아래와 같은 쿠버네티스 리소스가 생성되는 개수를 제한시킨다.
 

• 디플로이먼트, 파드, 서비스, 시크릿, 컨피그맵, PVC 등의 개수
• NodePort, LoadBalancer 타입의 서비스 개수
• QoS 클래스 중 BestEffort 종류로 분류되는 파드의 개수

리소스가 생성되는 개수를 제한시키려면 count/{RESOURCE}.{API GROUP NAME} 와 같은 포맷으로 매니페스트에 정의할 수 있다. 예시 파일을 보자.
 

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota-test
  namespace: zedd
spec:
  hard:
    requests.cpu: "1000m"
    requests.memory: "500Mi"
    limits.cpu: "1500m"
    limits.memory: "1000Mi"
    count/pods: "3"
    count/services: "3"
    count/secrets: "3"
    count/services.nodeports: "3"
    count/services.loadbalancers: "4"

 
직전에 보았던 매니페스트 예시에서 추가된 부분만 보자. 파드나 시크릿 같은 경우 API 그룹이 코어에 속하기 때문에 포맷 중 {API GROUP NAME} 이 빈 문자열로 들어간 셈이다. 다만 NodePort 나 LoadBalancer 유형의 서비스를 정의할 때는 위처럼 API 그룹명을 꼭 같이 명시해주어야 한다.
 
다음은 ResourceQuota로 QoS 클래스 중 BestEffort 종류로 분류되는 파드의 개수를 제한시키는 방법에 대해 알아보자. 앞서 살펴본 것처럼 BestEffort 라는 QoS 클래스로 분류되는 파드의 매니페스트에는 requests 와 limits 값이 명시되지 않는다는 점을 배웠다. 그래서 이로 인해 극단적으로는 노드의 유휴 자원을 모조리 끌어다 사용할 수 있는 문제가 발생할 수 있다고 했다. 이러한 문제를 막기 위해 ResourceQuota를 이용해서 BestEffort 클래스의 파드가 사용할 리소스 양을 생성될 파드의 개수로 제한시킬 수 있다. 우선 BestEffort 클래스의 파드가 사용할 리소스 양을 파드의 개수로 제한시키는 것을 명시한 ResourceQuota의 매니페스트부터 살펴보자.
 

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota-test
  namespace: zedd
spec:
  hard:
    count/pods: "1"
  scopes:
    - BestEffort

 
스코프라는 영역이 추가되었는데, 이곳에는 파드의 상태값을 명시할 수 있다. 여기서는 파드의 상태 값 중 BestEffort 라는 값을 명시해서 BestEffort 클래스로 분류되는 파드를 가리키는 셈이다. 참고로 이처럼 BestEffort 클래스로 분류되는 파드에 리소스 제한을 걸 경우, (ResourceQuota의 첫번째 기능을 설명할 때 등장한) ResourceQuota 매니페스트에 직접적으로 requests, limits 값을 명시하지 않는다. 왜냐하면 BestEffort 클래스로 분류되는 파드 자체는 에초에 requests, limits 값을 갖지 않기 때문이니깐! 그래서 보통 BestEffort 클래스로 분류되는 파드에 리소스 제한을 걸기 위해 ResourceQuota를 사용할 때는 위 매니페스트처럼 "count/pods"를 명시해 생성될 파드 개수를 제한시켜준다.
(혹여나 BestEffort 클래스로 분류되는 파드가 아닌 다른 클래스로 분류되는 파드에 대한 제한을 걸 경우, scopes 영역에 'NotBestEffort' 라고 명시해주면 된다. 참고해서 알아두자.)
 
하지만 만약에 생성할 파드 개수를 명시적으로 작성하지 않고 requests, limits 값을 제한하도록 한 ResourceQuota를 생성했다면, 이 경우에는 BestEffort 클래스로 분류되는 즉, 매니페스트에 requests, limits 값을 명시하지 앟은 파드는 생성되지 않는다. 즉, 아래와 같은 매니페스트로 ResourceQuota를 생성한 뒤에 BestEffort 클래스로 분류되는 파드를 생성하려면 에러가 발생한다.
 

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota-test
  namespace: zedd
spec:
  hard:
    requests.cpu: "1000m"
    requests.memory: "500Mi"
    limits.cpu: "1500m"
    limits.memory: "1000Mi"

 
왜냐하면 ResourceQuota에서 명시적으로 requests, limits를 선언했다는 것은 곧 해당 네임스페이스(zedd 라는 네임스페이스)에서 사용 가능한 자원의 총합을 제한시켜준 것이기 때문에 이 말을 다른 말로 하면 해당 네임스페이스에 생성될 파드들은 반드시 매니페스트에 requests, limits 값이 명시되어야 함을 의미한다. 하지만 BestEffort 클래스로 분류되는 파드들이라는 것은 애초에 매니페스트에 requests, limits 값이 명시되지 않고, 이 명시되지 않는다는 것은 노드이 모든 자원을 끝까지 끌어다 쓸수 있다는 것인데, 위 ResourceQuota에는 requests, limits 값이 명시되어 있기 때문에 BestEffort 클래스의 파드들은 위 ResourceQuota가 존재하는 네임스페이스에서는 생성되지 못하는 것이다.
 
이러한 문제를 해결하기 위해서 BestEffort 클래스로 분류되는 파드들이더라도 파드의 자원 사용량을 기본적으로 제한할 수 있도록 해주는 LimitRange 라는 리소스 오브젝트가 등장한다.

4-2. 네임스페이스에서 생성되는 파드들의 기본 사용량을 제한시키자! : LimitRange

LimitRange는 네임스페이스 별로 자원의 범위 또는 기본값을 지정할 수가 있는 리소스 오브젝트이다. LimitRange의 용도로는 크게 2가지가 존재한다. 먼저 파드의 컨테이너 매니패스트에 CPU와 메모리가 명시되어 있지 않는 즉, BestEffort 클래스로 분류되는 경우, 자동으로 기본 requests 또는 limits 값을 설정한다. 두 번째로는 파드 또는 컨테이너의 CPU, 메모리, PVC 등과 같은 리소스 크기의 최댓값, 최솟값을 설정할 수 있다. LimitRange을 생성하는 예시 매니페스트 파일을 살펴보자.
 

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range-test
spec:
  limits:
  - default:
      memory: 256Mi
      cpu: 200m
    defaultRequest:
      memory: 128Mi
      cpu: 100m
    max:
      memory: 1Gi
      cpu: 1000m
    min:
      memory: 16Mi
      cpu: 50m
    type: Container

 
항목을 하나씩 살펴보자.

• default : 파드의 컨테이너에 limits 값이 설정되어 있지 않다면 해당 값으로 자동 설정됨
• defaultRequest : 파드의 컨테이너에 requests 값이 설정되어 있지 않다면 해당 값으로 자동 설정됨
• max : 파드의 컨테이너에 설정될 수 있는 limits 값의 최대치를 의미. 해당 값보다 더 많은 자원을 할당하려고 시도하면 파드 생성 실패
• min : 파드의 컨테이너에 설정될 수 있는 limits 값의 최소치를 의미. 해당 값보다 더 적은 자원을 할당하려고 시도하면 파드 생성 실패
• type: Container : 위와 같은 자원할당을 어떤 단위로 할 것인지를 의미. 여기서는 컨테이너(Container) 단위로 할 것임을 명시

그리고 위 예제 파일에선 나타나지 않았지만 maxLimitRequestRatio 라는 값도 명시할 수 있는데, 이는 limits 와 requests 값 비율이 몇인지를 명시하는 것인데, 해당 값보다 무조건 작아야만 한다는 것을 의미한다. 예를 들어, maxLimitRequestRatio 값이 1.5인데, limits 값이 200Mi 이고, requests 값이 100Mi 면 200 / 100은 2이므로 1.5보다 커지므로 할당이 불가능해진다. 이렇게 maxLimitRequestRatio 값을 사용함에 따라 '오버커밋을 어느정도 할당해야 할지' 그리고 maxLimitRequestRatio 값을 1로 설정하면 'Guaranteed 클래스'로 분류되는 파드를 생성하겠다는 것을 암시한다.

4-3. ResourceQuota 와 LimitRange는 Admission Controller의 종류들이다

마지막 목차에서는 방금 [4-1, 4-2] 목차에서 배운 ResourceQuota 와 LimitRange가 속하는 어드미션 컨트롤러(Admission Controller)라는 개념에 대해 배워보도록 하자. 어드미션 컨트롤러를 이해하기 위해서는 쿠버네티스를 사용하는 개발자가 kubectl 이라는 CLI를 수행했을 때, 쿠버네티스에서 해당 명령어를 어떻게 처리하는지 단계를 알아볼 필요가 있다. 먼저 아래 그림을 보자.
 

 
마치 kubectl 명령어를 입력하는 개발자가 클라이언트, 쿠버네티스 클러스터가 백엔드 서버라고 보면 된다. 위 구조에서 어드미션 컨트롤러는 쿠버네티스를 사용하는 사용자 즉, kubectl 명령어를 입력하는 개발자의 API 요청이 적절한지 검증하고, 필요에 따라 API 요청을 변형하는 단계를 수행해주는 주체라고 생각하면 된다. 심지어 어떤 API 요청이 쿠버네티스 클러스터에 들어왔을 때, 해당 API 요청이 부적절하다고 생각되면 거절하거나 API 요청에 담겨있는 파라미터 값도 수정할 수가 있다. 
 
위 그림에서도 알 수 있듯이 어드미션 컨트롤러에는 Mutating 과 Validating 2가지가 존재한다. 먼저 API 요청을 적절하게 수정하는 역할을 하는 Mutating 어드미션 컨트롤러가 있고, API 요청을 검사하는 역할을 하는 Validating 어드미션 컨트롤러가 존재한다. 그러면 위에서 배운 ResourceQuota 와 LimitRange는 어떤 어드미션 컨트롤러에 해당하는 걸까? 만약 사용자가 파드를 생성하는 상황을 가정해보자.
 
가장 먼저 사용자가 kubectl 명령어를 입력하게 되면 쿠버네티스 클러스터의 kube api server로 API 요청을 전송(HTTP 핸들러)한다. 그러면 인증서나 서비스 어카운트 등을 통해 인증 단계(Authentication)를 거친다. 그리고 나서 롤, 클러스터 롤 등을 통해 인가 단계(Authorization)를 거친다.
 
이제 어드미션 컨트롤러의 역할 차례다. 먼저 LimitRange라는 어드미션 컨트롤러는 사용자가 작성한 파드의 매니페스트를 보고 자원 할당 요청을 변형(Mutating)한다. 즉, 만약 파드의 매니페스트에 어떤 리소스 할당량도 명시되어 있지 않다면(즉, BestEffort 클래스로 분류되는 파드) LimitRange는 파드에다가 CPU 및 메모리 할당의 기본 값을 추가함으로써 원래 사용자가 요청한 API의 데이터를 변형(Mutate)하게 된다.
 
그리고 난 뒤, 이제 ResourceQuota 라는 어드미션 컨트롤러가 역할을 할 차례다. 만약 생성될 파드에 자원이 할당하려고 하는데 해당 파드가 속할 네임스페이스의 자원 할당량이 이미 초과된 상태라면 API 요청은 거절된다. 이런 경우에는 ReourceQuota가 생성될 파드의 리소스를 검증하는 즉, Validating 어드미션 컨트롤러 역할을 하는 셈이다.
 
이런 어드미션 컨트롤러는 기본적으로 쿠버네티스에 자체적으로 제공하는 것들도 엄청 많다. 하지만 사용자가 언제든 이런 어드미션 컨트롤러를 커스텀하게 구현해서 사용할 수도 있다. 유명한 서비스 매쉬 솔루션인 Istio도 이렇게 커스텀하게 어드미션 컨트롤러를 통해서 파드에 프록시 사이드카 컨테이너를 주입하는 방법을 사용하기도 한다.