[Kubernetes] 쿠버네티스의 파드 스케쥴링

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

Kubernetes

---

저번 포스팅에서는 쿠버네티스에서 파드나 컨테이너와 같은 리소스 자체를 얼마나 알차게 활용할 수 있는지에 대해서 배웠다. 이번 포스팅에서는 파드나 컨테이너와 같은 인스턴스를 생성할 때, 그 인스턴스를 어떤 서버 즉, 쿠버네티스 클러스터의 어떤 노드에 생성할 것인지를 결정하는 쿠버네티스의 스케쥴링에 대해서 배워보려고 한다.
 
간단한 예시로, 어떤 애플리케이션을 쿠버네티스 클러스터에 배포하려고 하는데, 해당 애플리케이션의 기반이 되는 (도커)이미지가 amd64 OS 플랫폼만 지원이 된다면 해당 애플리케이션은 amd64 OS 플랫폼으로 구성되어 있는 노드에 생성되어야 한다. 또한 고가용성(HA, High Availability) 즉, 서비스 무중단을 위해 어떤 애플리케이션의 파드나 컨테이너를 쿠버네티스의 모든 노드에 고르게 분포시켜야할 수도 있다. 이렇게 특정 목적에 따라 어떤 성격의 파드 또는 컨테이너가 특정 워커 노드에 생성되도록 하는 것을 바로 스케쥴링이라고 한다.
 
쿠버네티스에서는 다양한 스케쥴링 방법을 제공하고 있으며, 심지어 더 복잡한 스케쥴링 방법을 커스텀하게 구현할 수도 있다. 이번 포스팅에서는 쿠버네티스가 파드를 할당하는 워커 노드를 선택하는 스케쥴링 과정에 대해 간략히 알아보고, 선택할 수 있는 스케쥴링 전략이 무엇이 있는지에 대해 알아보도록 하자.

1. 파드를 스케쥴링하는 주체: kube-scheduler

저번 포스팅의 마지막 목차에서 ResourceQuota 와 LimitRange 리소스 오브젝트에 대해 배우면서 해당 오브젝트들이 어드미션 컨트롤러의 종류라는 것에 대해 배웠었다. 그 때 소개한 그림을 다시 보자. 만약 개발자가 kubectl 이라는 명령어를 사용해서 쿠버네티스 클러스터로 요청을 보내면 크게 아래의 순서로 진행된다고 했다.
 

어드미션 컨트롤러 소개 시 사용한 자료

 
개발자가 kubectl 명령어로 입력한 요청이 파란색 영역에 들어가는 부분을 모두 무사 통과하고 나면 그 때 kube-scheduler 라는 것이 이제 파드를 어떤 워커 노드에 생성할지 정하기 시작한다. 이제 우리가 주목할 부분은 위 파란색 영역이 모두 통과된 후, kube-scheduler 가 구체적으로 어떻게 동작하는지에 대한 부분이다.
 

우리가 알아볼 것은 kube-scheduler !

 
kube-scheduler를 알아보기에 앞서 쿠버네티스는 사용자의 모든 요청 즉, kubectl 명령어로 입력해온 요청들, 심지어 쿠버네티스 내부 컴포넌트들 간의 요청들도 kube-apiserver 라는 컴포넌트를 통해서 소통을 진행한다는 점이다. 앞으로 설명할 때, 이 점을 꼭 염두에 두도록 하자.
 
그리고 kube-scheduler는 말 그대로 파드를 생성하도록 하게 하는 쿠버네티스 스케쥴러에 해당하며, 위 그림에서도 등장하는 etcd는 쿠버네티스 클러스터의 전반적인 상태 데이터를 저장하는 일종의 데이터베이스 역할을 담당하는 컴포넌트이다. 실제로 생성되어 있는 파드를 보기 위해 kubectl get pods 라는 명령어를 수행하면 kube-api server를 통해서 etcd에 저장되어 있는 데이터를 가져와 보여준다.
 
etcd에 대해서 좀 더 구체적으로 설명하면, etcd는 주키퍼, Consul 과 같은 분산 코디네이터 도구의 일종으로, 클라우드 플랫폼 환경에서 여러 컴포넌트가 정상적으로 상호 작용할 수 있도록 데이터를 조정하는 역할을 담당한다. 쿠버네티스에서는 예를 들어 생성된 디플로이먼트나 파드의 목록, 정보, 클러스터 자체의 정보 등과 같은 대부분의 데이터가 etcd에 저장이 된다. 물론 이 kube-apiserver, kube-scheduler, etcd 모두 쿠버네티스에서 동일하게 파드의 형태로 실행된다. 
 
이제 kube-scheduler가 구체적으로 어떤 과정을 통해 생성할 파드를 어떤 워커 노드로 선정하는지 살펴보도록 하자. 우선 아래 그림을 보자.
 

 
위 그림의 단계를 하나씩 살펴보자.
 

1. 개발자는 파드를 생성하기 위해 kubectl CLI를 이용해 명령어를 입력하고, 이 명령어는 마스터 노드에서 파드 형태로 실행되고 있는 kube-api server로 요청이 전송된다.
2. 요청에 담겨있는 정보를 가지고 파드를 생성하는 요청이라는 것을 인지한 후, 생성할 파드에 대한 정보가 담긴 데이터를 etcd에 저장한다. 단, 이 때는 파드 정보에 nodeName 즉, 해당 파드가 어떤 노드에서 생성될지에 대한 값이 명시되지 않은 채 etcd에 저장된다. 
3. 상시적으로 kube-api server가 계속 Watch API를 이용해 모니터링을 하고 있다가 etcd에 저장된 데이터 중 nodeName 데이터가 없는 파드가 있다는 것을 감지
4. kube-scheduler는 3번에서 kube-api server가 감지한 정보를 전달받음
5. kube-scheduler가 해당 파드를 어떤 노드에 생성할지 결정(이 때, worker node 1으로 선정했다고 가정)
6. 선정한 노드에 파드를 생성(바인딩)할 것을 kube-api server에 요청
7. 각 워커 노드에 붙어있는 kubelet 에이전트들이 kube-api server의 Watch API를 이용해서 계속 감지 중이다가 nodeName에 명시된 worker node 1 값을 보고 worker node 1에 붙어있는 kubelet이 실질적으로 파드를 생성하기 시작
8. 파드 생성 완료 후 개발자에게 파드 정상 생성되었다고 응답

파드가 생성되는 과정은 크게 위와 같다. 우리는 이제 위 단계에서 5번 단계인 kube-scheduler가 생성할 파드를 어떤 노드에 할당할지 결정하는 과정과 기준에 대해서 살펴볼 것이다.

2. 워커 노드를 선택하는 스케쥴링 과정 2단계: 노드 필터링과 스코어링

kube-scheduler가 적절한 노드를 선택하는 과정은 크게 2가지 단계를 거친다. 먼저 노드 필터링을 거치는데, 말 그대로 파드를 할당할 수 있는 노드인지 아닌지를 판단해서 걸러내는 단계이다. 예를 들어, 파드 매니페스트에 설정된 최소 요건(저번 시간에 배운 requests)의 CPU, 메모리 만큼의 가용 자원이 없는 노드는 당연히 해당 파드를 할당할 수 있는 노드로 선정될 수 없을 것이다. 또, 위 그림에서 보았던 kube-api server, etcd, kube-scheduler 와 같은 핵심적인 컴포넌트 역할을 하는 파드들이 할당되어 있는 마스터 노드는 일반적으로 파드를 할당할 수 없는 노드이므로, 마스터 노드도 선정될 수 없을 것이다. 이렇게 여러 가지 조건들에 의해 필터링되어 파드를 할당할 수 있다고 선정된 노느들은 그 다음 단계인 노드 스코어링 단계로 넘겨지게 된다.
 
이제 노드 스코어링 단계에서는 쿠버네티스를 구현한 Go 언어 소스코드에 미리 정의된 알고리즘의 가중치에 따라서 각 노드의 점수를 계산하게 된다. 예를 들어서 파드가 사용하는 도커 이미지가 이전에 pull 했던 이미지와 동일하여 어떤 노드의 파일 시스템에 해당 도커 이미지가 이미 존재하여 빠르게 파드를 생성할 수 있게 되면 점수가 높아진다(이 점수를 Image Locality라고 함). 또 다른 예로 노드의 가용 자원이 많으면 많을수록 당연히 노드의 점수가 높게 평가된다(이러한 점수를 Least Requested라고 함) 이렇게 다양한 로직의 알고리즘을 거쳐 합산된 점수 중 가장 점수가 높은 노드 하나를 선정해 파드를 할당하게 된다.
 
일반적으로, 위 2가지 단계 중 우리가 직접적으로 제어하기 쉬운 영역은 노드 필터링 단계이다. 노드 스코어링 단계를 물론 커스텀하게 조절할 수 없는 것은 아니지만, 소스코드 레벨에서 조작이 필요하므로 단순한 YAML 파일 형태로 조작은 불가능하다. 따라서 우리가 앞으로 살펴볼 것들은 위 2가지 단계 중 노드 필터링를 정의하는 여러가지 조건 또는 기준에 대해 배워볼 것이고, 이런 것들은 모두 YAML 형식의 매니페스트 파일에 직접 명시를 하여 적용해준다.

2-1. 노드의 이름을 직접 명시하거나 노드에 붙혀진 레이블을 이용하자 : nodeName, nodeSelector

가장 먼저 알아볼 키워드는 nodeName과 nodeSelector이다. nodeName은 가장 직관적으로, 파드 매니페스트에 해당 파드가 할당될 노드 이름을 직접적으로 명시하는 것이다. nodeName을 이용한 파드 매니페스트 예시는 다음과 같다.
 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-node-name
spec:
  nodeName: ip-10-43-0-30.ap-northeast-2.compute.internal
  containers:
    - name: nginx
      image: nginx:latest

 
위처럼 nodeName에 노드 이름을 명시하면 된다. 이렇게 하면 해당 파드는 반드시 해당 노드에 생성된다. 하지만 이렇게 노드 이름을 직접적으로 명시하는 것은 좋지 않다. 왜냐하면 다른 환경에서 해당 매니페스트를 보편적으로 사용할 수 없을 뿐더러 만약 해당 노드에 장애가 발생한다면 해당 파드는 다른 노드로 이동해 생성될 수도 없으며 그대로 서비스 다운으로 이어질 수 밖에 없다.
 
그래서 좀 더 발전적인 방법으로 nodeSelector가 등장한다. nodeSelector는 노드에 붙혀진 레이블을 이용해서 해당 레이블을 가지고 있는 노드들 중 하나에 파드를 할당하는 것이다. 물론 여기서 노드에 붙혀지는 '레이블'이라는 것은 기본적으로 쿠버네티스가 만든 레이블들이 있기도 하지만, 사용자가 직접 레이블을 만들 수도 있다. 
 
현재 생성된 노드의 레이블을 보기 위해서는 아래 명령어를 실행해보면 된다.

kubectl get nodes --show-labels

 
위 명령어 결과의 예시 자료를 가져와봤다.
 

 
위 사진 속 LABELS 항목을 보면 이 레이블도 <key>=<value> 형태로 되어 있는 것을 볼 수 있다. 위 사진 속에서는 해당 노드의 아키텍처가 amd64 라는 것을 의미하는 beta.kubernetes.io/arch=amd64 라는 레이블이 존재하는 것을 볼 수 있다. key 값에서 유추할 수 있듯이 kubernetes.io 라는 키워드가 들어가면 쿠버네티스가 기본적으로 만든 레이블임을 의미한다.
 
만약 사용자가 직접 노드의 레이블을 만들고 싶다면 아래 형식으로 레이블을 생성할 수 있다.
 

kubectl label nodes $NODE_NAME <key>=<value>

 
만약 노드에 설정된 레이블을 삭제하고 싶다면 레이블의 <key> 값에 대쉬(-)를 추가하면 된다. 예를 들어, 아래와 같이 말이다.
 

kubectl label nodes $NODE_NAME <key>-

 
nodeSelector를 사용해서 파드를 생성하는 매니페스트 예시는 다음과 같다.
 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-node-name
spec:
  nodeSelector:
    appName/label: appTest
  containers:
    - name: nginx
      image: nginx:latest

 
그런데 만약 위 매니페스트에서 정의한 레이블 즉, appName/label=appTest 라는 레이블을 갖는 노드가 2개 이상이라면 어떻게 될까? 당연히 여러 노드 중 하나의 노드만 선택되어 해당 노드에 파드가 생성이 된다. 물론 이 여러 개의 노드 중 최종적으로 하나의 노드로 무엇을 선택할지는 노드 필터링 이후의 노드 스코어링 단계에서 결정이 될 것이다.
 
하지만 주의할 점은 파드가 1개가 아닌 여러 개의 파드가 생성될 때이다. 다시 말해, 디플로이먼트라 레플리카셋을 생성할 때는 보통 여러 개의 파드가 한꺼번에 생성된다. 디플로이먼트나 레플리카셋을 활용해서 여러 개의 파드를 한꺼번에 생성한다고 해도 파드들의 스케쥴링은 각 파드마다 독립적으로 스케쥴링된다. 그래서 디플로이먼트나 레플리카셋을 생성하는 매니페스트에 nodeSelector를 이용한다면 모든 파드들이 하나의 노드에만 파드가 생성되는 것은 아님에 주의하자.(물론 명시한 레이블을 갖는 노드가 1개 밖에 없다면 당연히 그 노드에만 파드가 할당된다)

2-2. 좀 더 확장된 노드 선택 방법 : nodeAffinity, podAffinity, podAntiAffinity

위에서 알아본 nodeSelector는 매니페스트에 명시한 레이블을 갖는 노드에만 할당이 가능하다. 이보다 좀 더 다양한 스케쥴링 방법을 제공하기 위해 nodeSelector에 약간 기능을 추가한 nodeAffinity가 등장한다. nodeAffinity는 반드시 충족해야 하는 Hard 조건이라는 것과 꼭 충족은 하지 않아도 되는 이른바 선호되는 조건인 Soft 조건이라는 것을 별도로 정의할 수 있다. 이 Hard 조건과 Soft 조건은 아래의 2가지 키워드로 매니페스트에 명시할 수 있다.
 

• Hard 조건 : requiredDuringScheduingIgnoredDuringExecution
• Soft 조건 : preferredDuringScheduingIgnoredDuringExecution

이름이 길어서 헷갈릴 수 있으나, 우린 일단 가장 맨앞의 단어들인 required 와 preferred에만 주목하자. 이 키워드만 보면 어떤게 필수 조건인 Hard 조건에 해당하는지 눈치챌 수 있다. 일단, Hard 조건을 명시하는 requiredDuringScheduingIgnoredDuringExecution을 사용한 매니페스트 예시를 하나 살펴보자.
 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-hard-condition
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: appName/label
                operator: In
                values:
                  - appTest
                  - appTest2
  containers:
    - name: nginx
      image: nginx:latest

 
 
위 매니페스트에서 affinity 키워드 영역을 보자. 사실 매니페스트에 이제 점점 익숙해졌으면 어느 정도 의미가 무엇인지 이해가 갈 것이다. 반드시 충족해야 하는 조건을 명시했는데, 그 조건은 노드가 갖는 레이블 중 appName/label 이라는 것을 key 값으로 하는 것의 value에 해당하는 것들이 appTest 또는 appTest2 인 노드에 파드를 생성하라는 뜻이다. 여기서는 Operator의 종류로 In을 사용했지만 그외 NotIn, Exists, Gt, Lt 등이 존재한다.
 
이번엔 Soft 조건인 preferredDuringScheduingIgnoredDuringExecution에 대해서 살펴보자. preferredDuringScheduingIgnoredDuringExecution는 반드시 만족해야 하는 조건은 아니며 해당 조건을 만족하는 노드가 있다면 그 노드에 파드를 할당하는 쪽으로 할 것을 의미한다. 여기서 "파드를 할당하는 쪽으로 할 것"이 참 애매하지 않은가? 이를 정량적으로 나타내기 위해서 weight 라는 키워드로 0과 100 사이의 값을 명시할 수 있다. 당연히 100일수록 해당 노드에 할당할 가능성이 높아지도록 할 수 있다. preferredDuringScheduingIgnoredDuringExecution를 사용한 예시 매니페스트는 다음과 같다.
 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-hard-condition
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - preference:
            matchExpressions:
              - key: appName/label
                operator: In
                values:
                  - appTest
                  - appTest2
          weight: 80
  containers:
    - name: nginx
      image: nginx:latest

 
 
명시한 이 weight 값은 노드 필터링 단계 이후인 노드 스코어링 단계에서 점수를 계산할 때 사용하게 된다. 
 
그런데 여기서 Hard 조건과 Soft 조건 모두 주의해야할 부분이 있다. 바로 이 조건들은 파드를 할당할 때만 유효한 조건이다. 다시 Hard 조건과 Soft 조건의 키워드를 살펴보자. 이번엔 뒷부분의 단어에 주목해보자.
 

• Hard 조건 : requiredDuringScheduingIgnoredDuringExecution
• Soft 조건 : preferredDuringScheduingIgnoredDuringExecution

모두 공통적으로 "DuringScheduingIgnoredDuringExecution" 이 존재한다. 즉, 스케쥴링 동안만 유효하고, 실행할 동안에는 무시된다는 뜻이다. 다시 말해, 위 조건들로 명시해서 파드를 할당한 뒤, 갑자기 노드의 레이블 값을 바꾸더라도 그 변경된 노드에 맞게 파드가 퇴거하거나 다른 노드에 재생성되거나 하는게 아니라는 뜻이다.
 
다음으로 알아볼 키워드는 podAffinity이다. podAffinity는 nodeAffinity 와는 다르게 노드를 선택하는 기준이 "노드가 아니라 파드"라는 것이다. 즉, podAffinity에 명시한 조건을 만족하는 파드와 함께 스케쥴링되도록 한다. 사용하는 방법 자체는 nodeAffinity와 동일하며 위에서 설명한 Hard 조건, Soft 조건의 키워드도 동일하다. 다만, podAffinity에서는 nodeAffinity 와 달리 다른 키워드가 추가로 등장한다. 아래 예시 매니페스트를 살펴보자.
 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-hard-condition
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - topologyKey: kubernetes.io/zone
          labelSelector:
            matchExpressions:
              - key: appName/label
                operator: In
                values:
                  - appTest
  containers:
    - name: nginx
      image: nginx:latest

 
topologyKey 라는 키워드와 labelSelector 키워드가 추가되었다. labelSelector는 사실 우리가 이전에 쿠버네티스 기초 포스팅 중 레플리카셋과 파드의 느슨할 연결을 수행하는 라벨 셀렉터라는 개념을 배웠었는데, 그때의 그것이 바로 여기 다시 등장한다. 이게 등장하는 이유는 간단하다. 방금 이야기했듯이 podAffinity는 "특정 조건을 만족하는 파드와 함께 실행되도록 하기 위함"이기 때문이므로 이 '특정 조건을 만족' 하는 조건을 명시하기 위해 라벨 셀렉터(labelSelector)를 이용하는 것이다.
 
또 등장한 다른 키워드로는 topologyKey가 있다. topolgy는 사전적인 단어로 '위상'이라는 뜻인데, 쉽게 이야기하면 '어떤 기준의 또 다른 그룹' 이라고 보면 된다. topologyKey는 위 매니페스트를 예시로 이해해보자. 매니페스트에서 topologyKey 값에는 kubernetes.io/zone 을 명시했는데, 이는 AWS나 GCP에서의 가용 영역(AZ, Availability Zone) 또는 멀티 리젼을 의미한다. 즉, topologyKey에 kubernetes.io/zone을 명시했다는 것은 곧 "가용 영역을 기준으로 또 다른 그룹"을 형성했다고 보면 된다. 가용 영역을 기준으로 쿠버네티스 클러스터의 노드를 그룹핑한 예시는 다음과 같다.
 

 
먼저 쿠버네티스 클러스터 내에서 topologyKey에 명시된 것처럼 토폴로지가 가용 영역 기준으로 2개 그룹으로 나뉘었다고 가정해보자. 그리고 생성할 파드의 매니페스트에는 appName/label=appTest 라는 레이블을 갖는 파드와 함께 실행되도록 명시했다. 현재 해당 레이블을 갖는 파드는 ap-northeast-2a 라는 가용영역인 toplogy 1 내의 worker node 1에서 실행되고 있다. 이럴 경우 새롭게 생성할 파드는 어디에 생성될까? 당연히 topology 1이다. 물론 topology 1 이내에 worker node 1과 3 중에 1에 할당될 수도, 3에 할당될 수도 있다. 그 최종적인 선택 과정은 그 이후의 노드 스코어링 단계에서 정해질 것이다.
 
이러한 podAffinity는 주로 두 개 또는 그 이상의 파드들 간의 통신 응답 시간을 최대한 줄이기 위해 동일한 가용영역의 노드에 할당하는 경우에 자주 활용될 수 있다. 
 
다음으로 알아볼 키워드는 podAntiAffinity이다. podAntiAffinity를 소개하기 전에 방금 위에서 알아본 topologyKey에 명시하는 또 다른 종류의 값에 대해서 잠시 살펴보자. 위에서는 kubernetes.io/zone 이라는 값으로 가용영역을 토폴로지 키로 명시했지만, 쿠버네티스 노드의 호스트 이름인 kubernetes.io/hostname으로도 명시할 수 있다. 이 hostname 레이블은 각 노드마다 자동으로 생성되는데, 특징은 각 노드마다 고유한 이름을 갖고 있다는 것이다.
 
이제 kubernetes.io/hostname을 토폴로지 키로 명시하는 것을 활용하는 podAntiAffinity를 살펴보자. podAntiAffinity는 "Anti" 라는 단어의 어근이 against 라는 뜻에서 알 수 있듯이 podAffinity의 정반대 기능을 수행한다. 즉, 특정 조건을 만족하는 파드와 같은 토폴로지의 노드를 선정하지 않는다는 뜻이다. 결론부터 말하면 이 podAntiAffinity를 잘 활용하면 고가용성을 보장하기 위해 파드를 여러 가용영역에 멀리 퍼뜨리는 전략을 세울 수 있다. 왜냐하면 호스트 네임은 노드마다 고유한 이름을 갖는데, 이 고유한 이름에 대해 podAntiAffinity를 적용한다는 것은 그 고유한 호스트네임을 갖는 노드가 아닌 모든 노드들에 파드를 할당하라는 뜻이기 때문이다.
 
조금 더 응용해서 여러 개의 파드를 생성하는 디플로이먼트 매니페스트를 정의할 때, 파드의 라벨 셀렉터를 정의하는 부분의 레이블을 podAntiAffinity의 라벨 셀렉터의 레이블과 동일시하면 어떻게 될까? 일단 아래 매니페스트 예시를 살펴보자.
 
 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-anti-affinity-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      appName: testApp
  template:
    metadata:
      name: pod-anti-affinity-pod
      labels:
        appName: testApp
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - topologyKey: kubernetes.io/hostname
              labelSelector:
                matchExpressions:
                  - key: appName
                    operator: In
                    values:
                      - testApp
      containers:
        - name: nginx
          image: nginx:latest

 
 
우선 먼저 podAntiAffinity 부분을 해석해보자. Hard 조건을 명시했고, 토폴로지 키는 hostname으로 명시했다. 따라서 appName=testApp 을 레이블을 갖는 파드가 실행되는 노드의 호스트네임과 동일한 호스트네임을 갖는 노드에는 반드시 생성하지 말라는 뜻이다. 즉, 다른 노드에다가 해당 파드를 생성하라는 것이다. 그런데 매니페스트의 spec.selector.matchLabels 영역을 보자. 해당 영역을 보니 디플로이먼트 리소스를 생성할 때 파드의 레이블을 appName=testApp으로 지정했다. 즉, 다른 노드에다가 생성되는 파드도 appName=testApp 레이블을 갖게 한 것이다. 이렇게 되면 연쇄적으로 이후에 생성되는 파드들은 방금 생성된 파드가 할당된 노드와 다른 노드에 할당될 수 밖에 없다.(위에서 언급했듯이 디플로이먼트, 레플리카셋으로 여러 개의 파드를 생성하더라도 스케쥴링은 파드 각각 독립적으로 이루어진다고 했다!) 이렇게 연쇄적으로 계속 수행하다 보면 결국 모든 노드에 파드를 하나씩 할당하는 마치 데몬셋과 비슷한 디플로이먼트를 생성할 수 있게 된다.
 
참고로 podAffinity, podAntiAffinity 모두 nodeAffinity 처럼 Soft 조건도 명시할 수 있다. 당연히 Soft 조건을 명시하면 weight 값을 명시해야 하고, 결국 토폴로지 키를 기준으로 나누어진 그룹 내의 노드에 파드가 할당될 수 있지만 다른 토폴로지 키 그룹 내의 노드에 파드가 할당될 수 있는 가능성은 조금이라도 있다는 것을 알아두도록 하자.

2-3. 노드와 파드를 함께 지정하기 : Taints 와 Tolerations

다음으로 알아볼 노드 선택 방법은 Taints와 Tolerations을 활용하는 방법이다. Taints는 노드에 지정하는 것이고, Tolerations는 파드에 지정하는 것이다. 그래서 이 Taints와 Tolerations를 함께 활용할 수 있다. 하나씩 살펴보자.
 
먼저 Taints의 사전적 의미는 '얼룩'이라는 의미로, 노드에 '얼룩'을 묻힌다라고 비유할 수 있다. 즉, 얼룩이 묻은 노드에는 파드가 할당될 수 없도록 하는 기능이 바로 Taints이다. Tolerations은 방금 소개한 Taints 즉, 얼룩이 묻은 노드지만 해당 노드에 파드를 할당할 수 있도록 해주는 기능이다. 그래서 Tolerations의 사전적 의미가 '용인하다'의 '용인'을 의미하는데, 마치 "얼룩이 묻은 노드긴 하지만 어떤 파드 너 만큼은 할당도록 용인해줄게!"와 같다. 이와 같은 기능적인 의미 때문에 Taints는 노드에 명시하는 것이고, Tolerations는 파드에 지정하는 것이다.
 
Taints의 종류는 매우 여러가지로, 쿠버네티스를 사용하는 개발자가 직접 Taints를 설정할 수도 있고, 파드 생성과 같이 쿠버네티스에서 발생하는 특정 이벤트로 인해 쿠버네티스가 기본적으로 특정 노드에 Taints를 설정해주기도 한다. Taints도 위에서 알아본 nodeSelector, nodeAffinity, podAffinity 등의 레이블 처럼 <key>=<value> 형태로 사용할 수 있다. 다만, 앞서 알아본 레이블과는 다르게 Taints에는 Effect 라는 것을 추가로 명시해준다. 아래는 kubectl 명령어로 Taints를 특정 노드에 설정하는 예시이다.
 

kubectl taint node $NODE_NAME <key>=<value>:$Effect

 
Effect가 의미하는 바는 Taint의 효과를 의미한다. 즉, 어떤 노드에 파드가 할당되었을 때 발생할 효과를 의미한다. 이 Effect에 명시할 수 있는 종류는 NoSchedule(파드를 스케쥴링하지 않음), NoExecute(파드 실행 자체를 허용하지 않음), PreferNoSchedule(가능하면 스케쥴링 하지 않음)이 있다. 예를 들어, 아래와 같은 명령어로 특정 노드에 Taint를 설정한다고 해보자.
 

kubectl taint node zedd-node app/label=AppTest:NoSchedule

 
위 명령어의 의미를 해석해보면 "zedd-node" 라는 이름을 갖는 노드에는 "app/label=AppTest" 라는 레이블을 갖는 파드들을 스케쥴링 할 수 없다!"이다.
 
그러면 이제 위에서 설정한 Taint를 갖는 노드에 파드를 할당할 수 있도록 하기 위해서 해당 파드의 매니페스트에 Tolerations을 명시해보자. Tolerations가 명시된 파드 매니페스트 예시는 다음과 같다.
 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-tolerations
spec:
  tolerations:
    - key: app/label
      value: AppTest
      operator: Equal
      effect: NoSchedule
  containers:
    - name: nginx
      image: nginx:latest

 
tolerations 영역을 보면 Taints를 설정할 때 명시했던 key, value 값을 명시해준다. 그리고 operator로 해당 value 값이 정확일 일치(Equal)할 때만 적용하며 Taint의 효과는 NoSchedule을 명시함으로써 위에서 설정한 Taint의 효과와 동일하게 명시해준다.
 
이렇게 파드에 Tolerations을 명시해주면 해당 파드는 위에서 Taint를 설정한 노드에 생성될 수도 있다. 여기서 '생성될 수도 있다'라고 한 점에 잠시 주목하자. 위처럼 파드에 Tolerations을 명시한다고 해서 반드시 해당 Tolerations에 대응되는 Taint를 갖는 노드에만 파드가 생성되는 것은 아니다. 단지, 해당 Taint를 갖는 노드에 생성될 수 있다라고 가능성만 명시한 셈이다. 따라서 정말 명시적으로 해당 Taint를 갖는 노드에 파드를 생성하도록 의도하기 위해서는 위에서 배운 nodeSelector 와 같은 것을 함께 이용해서 지정해주어야 한다.
 
그리고 위에서 Taint를 설정할 때 <key>=<value> 값을 명시해주었는데, <value> 값을 따로 명시해주지 않아도 상관은 없다. 별도로 명시하지 않으면 빈 문자열("")로 간주된다. 실제로 마스터 노드에 설정되어 있는 Taint를 보면 <key>만 존재하는 것을 볼 수 있다. 만약 Taint에 <value>가 명시되어 있지 않으면 이 Taint에 대한 Tolerations을 명시할 때도 당연히 value: 영역에는 빈 문자열("")을 명시해주면 된다.
 
또한 Taint 설정 시, <key> 값 마저도 생략하고, Effect 만 정의하는 것도 가능하다. 실제로, kube api server 파드의 매니페스트를 살펴보면 Tolerations에 Effect 만 명시되어 있는 것을 볼 수 있다.
 

QoS Class:         Burstable
Tolerations:       :NoExecute
...

 
이런 경우, 이 Tolerations는 Taint의 <key>, <value>가 무엇이든지 상관없이 모든 :NoExecute 종류의 Taint를 용인할 수 있음을 의미한다. 즉, 해당 Tolerations를 갖는 파드들은 NoExecute 라는 Effect 조건만 충족하는 노드이면  그 노드이 파드를 생성될 수 있다는 뜻이다.
 
참고로 위 파드 매니페스트의 tolerations 항목에 operator로 Equal이 정의되어 있는데, 또 다른 operator 종류로 Exists도 존재한다. Exists로 만약 설정된 경우, Taint에 대한 와일드카드로 수행된다. 즉, 만약 아래와 같이 매니페스트가 정의되어 있다고 해보자.
 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-tolerations
spec:
  tolerations:
    - operator: Exists
  containers:
    - name: nginx
      image: nginx:latest

 
이럴 경우, <key>, <value>, 심지어 Effect 종류에 상관없이 모든 노드에 파드를 할당할 수 있다는 것을 의미한다.

 

추가적으로, Taint의 효과 중 NoSchedule 과는 다른 종류에 대해서 알아보도록 하자. 대표적으로 PreferNoSchedule, NoExecute가 있다. 이 중 NoExecute에 대해서 알아보자. NoExecute 효과를 가진 Taint를 갖는 노드는 해당 노드에서 파드가 스케쥴링 되지 않는 것 뿐만 아니라 파드가 아예 실행조차 되지 못하게 된다. 그러면 NoSchedule과 NoExecute 효과 간의 차이는 무엇일까? NoSchedule 효과가 노드에서 설정되더라도 NoSchedule 효과가 설정되기 이전의 파드들은 노드에서 정상적으로 동작한다. 반면에 NoExecute 효과는 노드에 설정되는 순간 이전에 생성되었던 파드들이더라도 가차없이 종료시켜버린다.(물론 NoExecute 효과를 갖는 Taint에 대한 Toleration을 갖는 파드는 당연히 NoExecute 효과의 Taint를 갖는 노드더라도 파드 생성이 가능하다)

 

만약 NoExecute 효과인 Taint를 갖는 노드에 단일 파드로 생성했다면 해당 파드는 바로 종료되고 아무일도 일어나지 않는다. 반면에, 디플로이먼트나 레플리카셋 등과 같은 리소스 오브젝트로 파드를 함께 생성한다면 NoExecute 효과인 Taint를 갖는 노드에서 파드가 종료되고, 다른 노드를 찾아 그곳에서 생성되는 Eviction을 수행한다. 이유는 간단하다. 레플리카셋과 디플로이먼트는 매니페스트에 명시해준 파드 개수를 반드시 지켜야 하기 때문에 어떻게든 다른 노드를 찾아 그 개수를 맞춰주기 때문이다. 

 

이 NoExecute 효과는 직접 사용자가 명시할 수도 있긴 하지만 사실 파드가 생성될 때 파드에 쿠버네티스가 기본적으로 만드는 Toleration에 포함되어 있다. 이유는 바로 파드가 할당된 노드에 어떤 문제가 발생할 것임을 대비하기 위함이다.

 

우선 생성된 파드에 기본적으로 명시되어 있는 Toleration 예시를 하나 보자. 아래처럼 명시되어 있다.

 

node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s

 

만약 위 Toleration이 파드에 명시되어 있다면 무슨 뜻일까? 바로 "노드의 상태가 not-ready 이거나 unreachable일 때, 300초 동안은 NoExecute 효과인 Taint를 갖는 노드에도 할당은 될 수 있다"는 뜻이다. 만약 노드에 문제가 발생하면 쿠버네티스는 자동으로 해당 노드에 위와 같은 종류의 Taint를 추가한다. 그리고 위 Toleration은 이런 노드들이 준비되지 않았거나 네트워크 통신이 불가능한 상황이지만 약간의 시간이 지나서 혹시라도 노드의 상태가 정상으로 돌아올 것을 대비하기 위함이다.

 

위 Toleration의 300초를 예시로 들면, 노드가 정상 상태로 돌아와서 NoExecute 효과를 갖는 Taint가 없어질 수도 있으니 300초 동안은 일단 파드를 해당 노드에 계속 할당시켜보자는 것이다. 만약 300초가 지나도 노드가 정상 상태로 돌아오지 않는다면 여전히 해당 노드에는 NoExecute 효과를 갖는 Taint가 존재할 것이지만, 파드들은 300초가 지난 뒤 NoExecute에 대한 Toleration이 없어지게 되니 해당 노드에 할당되지 못하고, 다른 노드로 옮겨 생성(Eviction)되게 된다. 이 때, '300초'라는 단위의 옵션을 tolerationSeconds 라고 부른다.

2-4. NoSchedule, NoExecute의 효과와 같다! : cordon, drain

직전에서 알아본 Taint의 효과 종류들이었던 NoSchedule과 NoExecute 효과와 각각 비슷한 cordon, drain 명령어에 대해서 알아보도록 하자. 이 두 명령어는 Taint, Toleration을 사용해 간접적으로 효과를 명시하는 NoSchedule과 NoExecute과는 달리 좀 더 명시적이라고 할 수 있다.

 

먼저, cordon 명령어는 NoSchedule과 효과가 동일하다. 아래의 명령어를 사용해서 특정 노드에 cordon을 할 적용할 수 있다.

 

kubectl cordon $NODE_NAME

 

이렇게 cordon이 적용된 노드는 해당 노드에 더 이상 파드가 스케쥴링되지 않는다. 이렇게 하면 해당 노드의 상태에 SchedulingDisabled 라는 값이 추가가 된다. 그리고 해당 노드의 Taint를 보면 실제로 NoSchedule 이라는 효과가 붙어있음을 볼 수 있다. cordon도 NoSchedule과 마찬가지로 cordon을 적용하기 전 이미 노드에서 실행 중이었던 파드를 종료하지는 않는다.

 

반면에 drain 명령어는 NoExecute 효과와 동일하다. 즉, drain이 적용된 노드에는 더 이상 파드 스케쥴링을 실행시키지 않는 셈이다. 파드를 더 이상 스케쥴링하지도 않고, 이미 해당 노드에 실행 중이었던 파드들도 다른 노드로 Eviction 시켜버린다. 보통 drain 명령어는 노드의 커널 버전 업그레이드, 유지 보수 등의 이유로 인해서 노드를 잠시 중지해야 할 때 주로 사용한다. drain을 특정 노드에 적용하는 예시 명령어는 다음과 같다.

 

kubectl drain $NODE_NAME

 

참고로 drain을 적용하려는 노드에 데몬셋 파드가 존재하거나, 디플로이먼트나 레플리카셋, 잡, StatefulSet 등과 같은 파드를 함께 생성하는 리소스 프로젝트가 아닌 즉, 단일 파드가 존재하는 노드라면 drain을 적용시킬 수 없다. 만약 그럼에도 강제로 drain을 적용시키고 싶다면, 데몬셋 파드가 존재할 때는 --ignore-daemonsets 옵션을, 단일 파드가 존재할 때는 --force 옵션을 함께 사용해야 한다.

2-5. 무중단 퇴거(Eviction)를 만들게 해주는 것! : PodDisruptionBudget(PDB)

다음으로 알아볼 내용은 직전에 배운 drain 명령어나 Taint의 NoExecute 효과처럼 이런 것들로 인해 파드가 퇴거(Eviction)를 할 때 주로 사용하는 PodDistruptionDudget(이하 PDB)에 대해서 알아보려고 한다. PDB는 무중단 퇴거 상황을 만들기 위해 등장했다. 예를 들어보자. 아래처럼 노드 A에 파드가 운영 중이다가, 노드 A에 장애가 생기거나 노드 A에 대한 유지보수를 해야 하는 등의 상황이 발생해서 파드가 노드 A로부터 퇴거되어 노드 B에 다시 생성된다고 해보자.

 

 

위와 같은 상황이 발생한다면 파드가 노드 B로 재생성되는 몇십초, 몇분 간은 서비스 중단이 발생하게 된다. 물론 저 파드를 여러 노드에다가 분산해서 생성했다고 한다면 서비스 중단까지 발생하는 것은 아니지만, 퇴거하고 있는 파드는 요청을 받지 못하는 상태가 되므로 다른 노드들에 분산되어 있는 파드들에 요청의 부하가 발생할 것이다. 

 

이러한 상황에 대응하기 위해 PDB가 등장한다. PDB는 drain 명령어와 같은 것들로 인해 노드로부터 파드의 퇴거가 발생했을 때, 해당 노드에 특정 개수 또는 특정 비율만큼의 파드는 반드시 정상적인 상태를 유지하기 위해 사용된다. 이 PDB도 쿠버네티스 리소스 오브젝트의 종류 중 하나로서 아래와 같이 매니페스트를 작성해서 생성할 수 있다.

 

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: test-pdb
spec:
  maxUnavailable: 1
  # minAvailable: 2
  selector:
    matchLabels:
      app: TestApp

 

PDB 매니페스트에는 maxUnavailable과 minAvailable 이라는 키워드 중 하나만을 사용해 파드의 어느 정도 개수 또는 비율로 유지할 것인지를 명시한다. maxUnavailable은 노드에서 파드가 종료될 때, 최대 몇 개까지 동시에 종료될 수 있는지를 명시한다. 만약 위처럼 1로 명시한다면 노드 내의 파드는 반드시 1개만 종료되어 다른 노드에 생성되고, 또 1개만 종료되어 다른 노드에 생성되고, ...(반복)를 수행할 것이다. 비슷하게 minAvailable은 파드가 퇴거가 발생할 때 퇴거가 발생하는 노드에서 최소 몇 개의 파드가 정상 상태를 유지해야 하는지를 의미한다. 이 두 키워드는 맥락상 비슷한 기능을 하므로, 반드시 두개 중 하나만 사용해 매니페스트에 명시해야 한다.

 

그리고 이런 PDB를 적용할 파드를 지정하기 위해 또 라벨 셀렉터를 사용한다. 다만 주의할 점은 이 라벨 셀렉터를 파드 템플릿 내의 파드 레이블에 입력해야 한다. 예를 들어, 디플로이먼트 매니페스트를 정의하고, 이 디플로이먼트가 생성하는 파드들에 PDB를 적용하고 싶다면, 디플로이먼트 레벨의 레이블이 아닌 파드 템플릿 레벨의 레이블에 명시해야 한다.

 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: zedd-nginx-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: zedd-nginx-pods-label  # 여기는 디플로이먼트 레벨의 레이블
  template:
    metadata:
      name: zedd-nginx-pod
      labels:
        app: zedd-nginx-pods-label # 여기는 파드 템플릿 레벨의 레이블 => PDB 레이블은 여기에!
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

 

참고로 PDB는 퇴거할 때만 적용되는 기능이므로, 만약 직접적으로 파드를 삭제, 예를 들어, kubectl delete pod 와 같은 명령어를 수행해서 파드를 삭제하면 PDB는 적용되지 않는다. 왜냐하면 이러한 파드 삭제 명령어는 말 그대로 파드를 삭제하고 끝이기 때문이다.