파드 스펙의 노드 셀렉터를 통해 특정 노드로 스케줄링되는 것을 수행할 수 있지만, 이것만으로는 특정 니즈를 처리할 수 없기 때문에 쿠버네티스에서는 이를 확장하는 매커니즘을 제공한다.

테인트와 톨러레이션을 사용해 특정 노드에서 파드 실행 제한

노드 테인트와 테인트에 대한 파드 톨러레이션은 어떤 파드가 특정 노드를 사용할 수 있는지를 제한할 수 있는 기능이다.
노드의 테인트가 허용된 경우에만 파드가 노드에 스케줄링 될수 있음을 뜻한다.

테인트와 노드 어피니티 규칙의 차이점 이해

노드 어피니티 규칙을 사용하면 특정 정보를 파드에 추가해 파드가 스케줄링되거나 스케줄링될 수 없는 노드를 선택할 수 있다.
테인트는 기존의 파드를 수정하지 않고, 노드에 테인트를 추가하는 것만으로도 파드가 특정 노드에 배포되지 않도록 한다.

테인트와 톨러레이션 소개

$ kubectl describe node master.k8s
Name:         master.k8s
Role:
Labels:       beta.kubernetes.io/arch=amd64
              beta.kubernetes.io/os=linux
              kubernetes.io/hostname=master.k8s
              node-role.kubernetes.io/master=
Annotations:  node.alpha.kubernetes.io/ttl=0
              volumes.kubernetes.io/controller-managed-attach-detach=true
Taints:       node-role.kubernetes.io/master:NoSchedule
...

마스터 노드에는 테인트가 하나 있다. 테인트에는 key, value, effect가 있고 =: 형태로 표시된다. 현재 예시의 경우, node-role.kubernetes.io/mater 가 key, value가 null, effect는 NoScheudle을 갖는다. 노드가 이 테인트를 허용하지 않는 한 마스터 노드에 스케줄링되지 못하게 막는다.

시스템 파드는 톨러레이션과 노드의 테인트가 일치하기 때문에 마스터 노드에 스케줄링된다.
톨러레이션이 없는 일반 파드는 테인트가 없는 노드에 스케줄링된다.

kube-proxy 파드도 마스터 노드에서 실행되며, 이 파드는 마스터 노드에서 실행되게 하려고 적절한 톨러레이션을 포함하고 있다.

$ kubectl describe po kube-proxy-80wqm -n kube-system
Tolerations:    node-role.kubernetes.io/master=:NoSchedule
            node.alpha.kubernetes.io/notReady=:Exists:NoExecute
            node.alpha.kubernetes.io/unreachable=:Exists:NoExecute

파드의 톨러레이션에는 표시되지만 노드의 테인트에는 표시되지 않는 등호는 무시하라. kubectl은 테인트/톨러레이션 값이 null일 때 테인트와 톨러레이션을 다르게 표시한다. (현재는 null일 때 동일하게 표시한다.)

테인트의 세 가지 가능한 효과
- NoSchedule: 파드가 테인트를 허용하지 않는 경우 파드가 노드에 스케쥴링되지 않는다.
- PreferNoSchedule: NoSchedule의 소프트한 버전이다. 즉, 스케쥴러가 파드를 노드에 스케쥴링하지 않으려 하지만 다른 곳에 스케쥴링할 수 없으면 해당 노드에 스케쥴링된다.
- NoExecute: 스케쥴링에만 영향을 주는 NoSchedule이나 PreferNoSchedule과 달리, NoExecute는 노드에서 이미 실행 중인 파드에도 영향을 준다. NoExecute 테인트를 노드에 추가하면 해당 노드에서 이미 실행중이지만 NoExecute 테인트를 허용하지 않는 파드는 노드에서 제거된다.

노드에 사용자 정의 테인트 추가하기

kmg88801@cloudshell:~ (awesome-caster-376906)$ kubectl taint node gke-cluster-1-default-pool-00c2d871-0ihe node-type=production:NoSchedule
node/gke-cluster-1-default-pool-00c2d871-0ihe tainted

위 명령어는 키는 node-type, 값은 production, 효과는 NoSchedule을 갖는 테인트를 추가

파드 4개를 생성했지만, 톨러레이션을 설정하지 않았기 때문에 gke-cluster-1-default-pool-00c2d871-0ihe 노드에는 스케줄링이 안되는 걸 확인할 수 있음

kmg88801@cloudshell:~ (awesome-caster-376906)$ kubectl get po -o wide
NAME    READY   STATUS              RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
test    1/1     Running             0          58s   10.120.1.5   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
test1   1/1     Running             0          12s   10.120.1.6   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
test2   1/1     Running             0          7s    10.120.1.7   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
test3   0/1     ContainerCreating   0          2s    <none>       gke-cluster-1-default-pool-00c2d871-tyej   <none>           <none>

파드에 톨러레이션 추가

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      name: kubia
      labels:
        app: kubia
    spec:
      containers:
      - image: luksa/kubia:v1
        name: nodejs
        resources:
          requests:
            cpu: 100m # 파드당 100밀리코어의 CPU 요청
      tolerations:
      - key : node-type
        operator: Equal
        value: production
        effect: NoSchedule

위 디플로이먼트를 배포하면 프로덕션 노드에도 배포되고, 프로덕션 노드가 아닌 곳에도 배포가 된다.

kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl get po -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP             NODE                                       NOMINATED NODE   READINESS GATES
kubia-bd7db89-g94d4   1/1     Running   0          24s   10.120.1.8     gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
kubia-bd7db89-n5jpl   1/1     Running   0          24s   10.120.2.6     gke-cluster-1-default-pool-00c2d871-tyej   <none>           <none>
kubia-bd7db89-sdsdm   1/1     Running   0          24s   10.120.1.138   gke-cluster-1-default-pool-00c2d871-0ihe   <none>           <none>

프로덕션이 아닌 노드에 node-type=non-production:NoSchedule과 같은 테인트를 추가하면 프로덕션이 아닌 노드에는 배포되지 않는다.

테인트와 톨러레이션의 활용 방안 이해

노드는 하나 이상의 테인트를 가질 수 있고, 파드는 하나 이상의 톨러레이션을 가질 수 있다.
테인트는 키와 효과만 갖고 있고, 값은 꼭 필요로 하지 않는다.
톨러레이션은 Equal 연산자를 지정(디폴트가 Equal)해 특정 값을 허용하거나, Exists 연산자를 사용해 특정 테인트 키에 여러 값을 허용할 수 있다.
테인트는 새 파드의 스케줄링을 방지하고(NoSchedule), 선호하지 않는 노드를 정의하고(PreferNoSchedule), 노드에서 기존 파드를 제거(NoExecute)하는 데에도 사용할 수 있다.
kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl get po kubia-bd7db89-g94d4 -o yaml
아래 pod 분석을 보면, 노드가 준비되지 않은 상태에서 파드는 재스케줄링되기 전에 300초 동안 기다리는 정책을 볼 수 있다.
도달할 수 없는 노드에도 동일하게 적용된다.
아래 두개 톨러레이션은 이 파드가 notReady 또는 unreachable 상태를 300초 동안 허용한다는 것을 의미한다.

쿠버네티스 컨트롤 플레인은 노드가 더 이상 준비되지 않았거나 더 이상 도달할 수 없다는 것을 감지하면, 파드를 삭제하고 다른 노드로 다시 스케줄링하기까지 300초 동안 기다린다.

tolerations:
- effect: NoSchedule
key: node-type
operator: Equal
value: production
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300

노드 어피니티를 사용해 파드를 특정 노드로 유인하기

테인트는 파드를 특정 노드에서 떨어뜨려 놓는 데 사용한다.
노드 셀렉터와 유사하게 각 파드는 고유한 노드 어피니티 규칙을 정의할 수 있다.
선호도를 지정하는 방식으로 쿠버네티스에게 어떤 노드가 특정한 파드를 선호한다는 것을 알려주면, 쿠버네티스는 해당 노드 중 하나에 파드를 스케줄링하려고 시도하게 된다.
노드 어피니티는 노드 셀렉터와 같은 방식으로 레이블 기반으로 노드를 선택한다.

노드에는 많은 레이블이 있지만 노드 어피니티와 파드 어피니에 있어서는 아래 세 개 레이블이 가장 중요하다.

failure-domain.beta.kubernetes.io/region=asia-northeast3 : 노드가 위치한 지리적 리전을 지정
failure-domain.beta.kubernetes.io/zone=asia-northeast3-c : 노드가 있는 가용 영역을 지정

kubernetes.io/hostname=gke-cluster-1-default-pool-00c2d871-0ihe : 노드의 호스트 이름

kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl describe node gke-cluster-1-default-pool-00c2d871-0ihe
Name:               gke-cluster-1-default-pool-00c2d871-0ihe
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
            beta.kubernetes.io/instance-type=e2-medium
            beta.kubernetes.io/os=linux
            cloud.google.com/gke-boot-disk=pd-balanced
            cloud.google.com/gke-container-runtime=containerd
            cloud.google.com/gke-cpu-scaling-level=2
            cloud.google.com/gke-logging-variant=DEFAULT
            cloud.google.com/gke-max-pods-per-node=50
            cloud.google.com/gke-nodepool=default-pool
            cloud.google.com/gke-os-distribution=cos
            cloud.google.com/machine-family=e2
            cloud.google.com/private-node=false
            failure-domain.beta.kubernetes.io/region=asia-northeast3
            failure-domain.beta.kubernetes.io/zone=asia-northeast3-c
            kubernetes.io/arch=amd64
            kubernetes.io/hostname=gke-cluster-1-default-pool-00c2d871-0ihe
            kubernetes.io/os=linux
            node.kubernetes.io/instance-type=e2-medium
            topology.gke.io/zone=asia-northeast3-c
            topology.kubernetes.io/region=asia-northeast3
            topology.kubernetes.io/zone=asia-northeast3-c

파드 노드 어피니티 규칙 지정

아래와 같이 파드를 생성하게 되면 노드 셀렉터를 사용해 파드는 gpu=true라는 레이블이 있는 노드에만 스케줄링된다.

apiVersion: v1
kind: Pod
metadata:
name: kubia-gpu
spec:
nodeSelector:
gpu: "true"
containers:
- image: luksa/kubia
name: kubia
ports:
- containerPort: 8080
  protocol: TCP

노드 셀렉터를 노드 어피니티 규칙으로 바꾼 yaml 예제는 아래와 같다.

apiVersion: v1
kind: Pod
metadata:
  name: kubia-gpu
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: gpu
            operator: In
            values:
            - "true"
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

requiredDuringScheduling : 이 필드 아래에 정의된 규칙은 파드가 노드로 스케줄링되고자 가져야 하는 레이블을 지정한다.
IgnoredDuringExecution : 이 필드 아래에 정의된 규칙은 노드에서 이미 실행중인 파드에는 영향을 미치지 않는다.
현재 시점에는 어피니티가 파드 스케줄링에만 영향을 미치며, 파드가 노드에서 제거되지 않는다. (IgnoredDuringExecution로 끝났기에)

파드의 스케줄링 시점에 노드 우선순위 지정

preferredDuringSchedulingIgnoredDuringExecution : 새로 도입된 노드 어피니티 기능의 가장 큰 장점은 특정 파드를 스케줄링할 때 스케줄러가 선호할 노드를 지정하는 필드
노드 레이블링

kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl get nodes
NAME                                       STATUS   ROLES    AGE   VERSION
gke-cluster-1-default-pool-00c2d871-0ihe   Ready    <none>   46h   v1.24.9-gke.2000
gke-cluster-1-default-pool-00c2d871-mrz4   Ready    <none>   46h   v1.24.9-gke.2000
gke-cluster-1-default-pool-00c2d871-tyej   Ready    <none>   46h   v1.24.9-gke.2000
kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl label node gke-cluster-1-default-pool-00c2d871-0ihe availability-zone=zone1
node/gke-cluster-1-default-pool-00c2d871-0ihe labeled
kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl label node gke-cluster-1-default-pool-00c2d871-0ihe share-type=dedicated
node/gke-cluster-1-default-pool-00c2d871-0ihe labeled
kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl label node gke-cluster-1-default-pool-00c2d871-mrz4 availability-zone=zone2
node/gke-cluster-1-default-pool-00c2d871-mrz4 labeled
kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl label node gke-cluster-1-default-pool-00c2d871-mrz4 share-type=shared
node/gke-cluster-1-default-pool-00c2d871-mrz4 labeled
kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl get nodes -L availability-zone -L share-type
NAME                                       STATUS   ROLES    AGE   VERSION            AVAILABILITY-ZONE   SHARE-TYPE
gke-cluster-1-default-pool-00c2d871-0ihe   Ready    <none>   46h   v1.24.9-gke.2000   zone1               dedicated
gke-cluster-1-default-pool-00c2d871-mrz4   Ready    <none>   46h   v1.24.9-gke.2000   zone2               shared
gke-cluster-1-default-pool-00c2d871-tyej   Ready    <none>   46h   v1.24.9-gke.2000

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      name: kubia
      labels:
        app: kubia
    spec:
      containers:
      - image: luksa/kubia:v1
        name: nodejs
        resources:
          requests:
            cpu: 100m # 파드당 100밀리코어의 CPU 요청
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 80
            preference:
              matchExpressions:
              - key: availability-zone
                operator: In
                values:
                - zone1
          - weight: 20
            preference:
              matchExpressions:
              - key: share-type
                operator: In
                values:
                - dedicated

필수 요구사항이 아닌, 선호도를 명시한다.
파드가 zone1에 스케줄링되는 것을 더 선호한다.
파드가 dedicated 노드로 스케줄링되는 것을 선호하지만 이는 영역 선호도보다는 네 배가 덜 중요하다.
노드의 어피니티 우선순위 지정 기능 외에도 다른 우선순위 지정기능이 있는데, 그 중 하나가 Selector-SpreadPriority 기능이 있다.
이 기능은 동일한 레플리카셋 또는 서비스에 속하는 파드를 여러 노드에 분산시켜 노드 장애로 인해 전체 서비스가 중단되지 않도록 하는 기능이다.

파드 어피니티와 안티-어피니티를 이용해 파드 함께 배치하기

프론트엔드 파드와, 백엔드 파드가 있을때 이 파드들을 가까이 배치하면 대기 시간이 줄어들고 애플리케이션 성능이 향상된다. (네트워크 홉 개선)

kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl run backend -l app=backend --image=busybox -- sleep 999999
pod/backend created

파드 정의에 파드 어피니티 지정

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      name: kubia
      labels:
        app: kubia
    spec:
      containers:
      - image: luksa/kubia:v1
        name: nodejs
        resources:
          requests:
            cpu: 100m # 파드당 100밀리코어의 CPU 요청
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - topologyKey: kubernetes.io/hostname
            labelSelector:
              matchLabels:
                app: backend

아래 그림과 같이 app=backend 레이블이 있는 파드와 동일한 노드에 배포되도록 하는 필수 요구 사항을 갖는 파드가 생성되는 것을 확인할 수 있다.

kmg88801@cloudshell:~/chapter16 (awesome-caster-376906)$ kubectl get po -o wide
NAME                        READY   STATUS    RESTARTS   AGE     IP            NODE                                       NOMINATED NODE   READINESS GATES
backend                     1/1     Running   0          2m4s    10.120.1.11   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
frontend-5f944bb797-95g7x   1/1     Running   0          26s     10.120.1.13   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
frontend-5f944bb797-h54wc   1/1     Running   0          26s     10.120.1.15   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
frontend-5f944bb797-r76g7   1/1     Running   0          26s     10.120.1.16   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
frontend-5f944bb797-tw57l   1/1     Running   0          26s     10.120.1.14   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
frontend-5f944bb797-x4bpt   1/1     Running   0          26s     10.120.1.12   gke-cluster-1-default-pool-00c2d871-mrz4   <none>           <none>
kubia-5f475fb4bd-hbld2      1/1     Running   0          7m36s   10.120.2.8    gke-cluster-1-default-pool-00c2d871-tyej   <none>           <none>

흥미로운 점은, 파드 어피니티 규칙을 정의하지 않은 백엔드 파드를 삭제하더라도, 스케줄러가 백엔드 파드를 gke-cluster-1-default-pool-00c2d871-mrz4 에만 스케줄링한다.
백엔드 파드가 실수로 삭제돼서 다른 노드로 다시 스케줄링된다면, 프론트엔드 파드의 어피니티 규칙이 깨지기 때문에 같은 노드에 스케줄링되는 것이다.
동일한 가용 영역에 파드 함께 배포하기
- topologyKey 속성을 failure-domain.beta.kubernetes.io/zone으로 변경하면 된다.
  
  같은 노드에 전부 배치하는 것보다는 같은 가용 영역이 안전하다고 생각함
같은 리전에 파드를 함께 배포하기
- topologyKey 속성을 failure-domain.beta.kubernetes.io/region으로 변경하면 된다.

topologyKey 작동 방법 이해

모든 노드에 rack 레이블을 추가
파드의 podAffinity 정의할때 topologyKey를 rack으로 설정
스케줄러가 파드를 배포할 위치를 결정할 때 파드의 podAffinity 구성 확인하고 레이블 셀렉터와 일치하는 파드를 찾은 다음 파드가 실행 중인 노드를 찾는다.
특히 podAffinity에 지정된 topologyKey 필드와 일치하는 키를 갖는 노드 레이블을 찾는다.
레이블이 이전에 찾은 파드의 값과 일치하는 모든 노드를 선택
레이블 셀렉터는 app:backend와 일치하고, 해당 노드의 랙 레이블값이 rack2이기 때문에 프론트엔드 파드를 스케줄링할 때 스케줄러는 rack=rack2 레이블이 있는 노드 중 하나를 선택한다.

kmg28801 / kubernetes-study

Chapter 16. 고급 스케줄링 #17