[14] Kubernetes Scheduler

AWS Cloud 환경에서 EKS를 사용한다면
아래와 같이 직접 스케쥴러를 구현하거나 관리할 필요는 없습니다.

다만 Pod를 어떤 노드에 우선적으로 띄울지에 대한 의사결정(Policy)는 직접 정의해야 하므로,
전체적인 흐름에 집중해서 학습하시면 됩니다.

 

1. Scheduling 이란?

 쿠버네티스의 스케쥴링(Scheduling)이란 "새로 생성된 파드(Pod)를 어떤 노드에 배치할지 결정하는 작업"이다. 이 작업은 컨트롤 플레인의 구성 요소인 `kube-scheduler`가 담당한다. 스케줄러는 파드에 설정된 조건 유무에 따라 다음과 같이 동작한다.

[1] 조건이 정의되지 않은 경우
스케줄러는 할당되지 않은 파드를 찾아, 스케줄링이 가능한 노드들 중 최적의 노드를 선택해 파드를 자동으로 배치한다. 이때 고려되는 기준은 CPU/Memory 사용 가능량, Affinity, Taints/Tolerations, 우선순위(Priority), Persistent Volume 적합성 등이 있다.

[2] 조건이 정의된 경우
개발자가 Pod 명세에 스케줄링 조건을 설정한 경우, 스케줄러는 해당 조건을 기준으로 적합한 노드를 찾는다. 예를 들어 `nodeSelector`, `nodeAffinity`, `tolerations` 등은 노드의 라벨이나 제약 조건을 기반으로 필터링하거나 배치를 제한하는 방식이다. 단, `nodeName`이 명시된 경우에는 스케줄러가 작동하지 않고 해당 노드로 직접 배치된다.

 

---

 

2. Scheduling 동작 과정

Scheduling은 내부적으로 매우 복잡한 인터페이스를 거치지만 크게 1)Filtering, 2)Scoring, 3)Binding 단계로 요약할 수 있다.

2.1.Filtering

 Pod가 생성되면 자동으로 스케쥴링 큐(Scheduling Queue)에 추가된다. Filtering 단계에서는 Pod를 실행할 수 있는 노드들을 선별하는 작업이 수행된다. 노드의 리소스(CPU/Memory), 라벨/셀렉터 매칭, 테인트(taint) 허용 여부 등의 조건이 있을 수 있고 Pod를 수용할 수 없는 노드는 후보군에서 제외된다.

 

아래 그림과 같이 파드의 CPU 요청량이 10 코어인 경우, 여유 CPU가 10 코어 미만인 노드들(Node1, Node2)는 필터링되어 제외된다. 결국 스케쥴링 큐에는 여유 CPU가 10 코어 이상인 노드들(Node3, Node4)만 남게된다.

 

2.2. Scoring

Filtering을 통과한 노드들에 대해 최적의 노드를 선택하기 위한 점수(Score)를 부여하는 단계이다. 리소스의 여유량, affinity 등이 고려되어 가장 높은 점수를 받은 노드가 최종 선택된다.

 

2.3. Binding Event

Filtering과 Scoring을 거쳐 최적의 노드가 선택되면, Binding 단계에서 해당 노드와 Pod를 바인딩(연결)한다. 이후 상태 변경 기록 및 모니터링을 위해 Event 단계가 수행된다.

 

✅ 정리

📌 Filtering: 이 Pod를 수용할 수 있는 노드 후보를 찾는다 (리소스 충분한지, taint/toleration 맞는지, affinity 맞는지 등)
📌 Scoring: 여러 후보 노드 중 점수를 매긴다 (분산 정도, 사용률 등)
📌 Binding: 최종적으로 선택한 노드에 Pod를 실제로 바인딩

 

---

 

3. 스케쥴링(Scheduling) 종류

쿠버네티스는 Pod를 어떤 노드에 배치할지 결정할 수 있는 다양한 스케줄링 방식을 제공하는데, 대표적으로 1)NodeSelector, 2)NodeName, 3)Affinity / Anti-Affinity, 4) Taints & Tolerations가 있다. 각 스케쥴링 방식에 대해 자세히 알아보자.

 

3.1. NodeSelector: 라벨을 기준으로 노드 선택

NodeSelector는 Pod를 특정 라벨이 붙은 노드에만 스케줄링하도록 제한하는 방식이다. 가장 기본적이고 단순한 방식이지만, 유연성이 부족해 실무에서는 잘 쓰이지 않는다.

💡 동작 방식
1. 노드에 라벨을 부여하고,
2. Pod의 명세에서 그 라벨을 nodeSelector로 지정하면,
3. kube-scheduler가 해당 라벨을 가진 노드에만 Pod를 배치한다.

 

[1] 각 노드에 라벨 추가

kubectl label node k8s-worker1 name=k8s-worker1
kubectl label node k8s-worker2 name=k8s-worker2

 

[2] 파드(Pod)에 nodeSelector 설정

vi node-selector-deployment-01.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-selector-deploy-01
spec:
  replicas: 2
  selector:
    matchLabels:
      name: web
  template:
    metadata:
      labels:
        name: web
    spec:
      containers:
      - name: node-selector-container
        image: nginx:1.25
      nodeSelector:    # 📌 주요 설정
        name: k8s-worker1

✅ 이 설정을 하면 Pod는 name=k8s-worker1 라벨이 붙은 노드에서만 실행된다.

---

3.2. NodeName: 아예 스케줄러를 생략하고 강제 배치

nodeName을 사용하면 kube-scheduler는 작동하지 않는다. Pod는 지정된 노드에 바로 강제 배치되며, 이 방식은 스케줄링이 아니라 수동 할당에 가깝다.

💡 동작 방식
1. spec.nodeName을 지정하면, 스케줄러는 이 Pod를 무시하고,
2. 해당 노드에 직접 Pod가 생성된다.

 

[1] Deployment 메니페스트 정의

vi node-name-deployment-01.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-name-deploy-01
spec:
  replicas: 2
  selector:
    matchLabels:
      name: web
  template:
    metadata:
      labels:
        name: web
    spec:
      containers:
      - name: node-name-container
        image: nginx:1.25
      nodeName: k8s-worker2   # 📌 주요 설정

✅ 이 설정은 스케줄러를 거치지 않고 바로 k8s-worker2에 Pod를 배치한다.

---

3.3. Affinity / Anti-Affinity: 좀 더 유연한 스케줄링

3.3.1. 기존 방식과의 차이점

기본적인 NodeSelector는 특정 라벨을 가진 노드에만 Pod를 배치할 수 있게 해주는 단순한 방식이다. 현실에서는 좀 더 유연한 조건이 필요할 수 있다. 예를 들어,

[1] 어떤 노드에는 GPU가 있으니까 가능한 한 그쪽에 배치하고 싶다.
[2] 어떤 Pod는 같은 App의 다른 Pod와 같은 노드에 있어야 성능이 좋다.
[3] 혹은 같은 노드에 있으면 안 되는 Pod도 있다.

 

이처럼 다양한 조건을 세밀하게 설정할 수 있도록 해주는 것이 Affinity / Anti-Affinity이다.

---

3.3.2. 구성요소

Affinity에는 아래 두 가지 조건 방식이 있다.

구성 요소	의미
requiredDuringSchedulingIgnoredDuringExecution	반드시 조건을 만족해야만 스케쥴링 됨 (강제 조건)
preferredDuringSchedulingIgnoredDuringExecution	가능하면 만족하는 것이 좋음 (우선 조건, soft)

 

[1] requiredDuringSchedulingIgnoredDuringExecution

# Pod가 반드시 node01이라는 label01이라는 label을 가진 Node에만 스케쥴링
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: # 📌
        nodeSelectorTerms:
        - matchExpressions:
          - key: node
            operator: In
            values:
            - node01

 

[2] preferredDuringSchedulingIgnoredDuringExecution

# 가능하면 node01에 배치하되, 안 되면 다른 노드에 배치
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution: 📌
      - weight: 1
        preference:
          matchExpressions:
          - key: node
            operator: In
            values:
            - node01

---

3.3.3. Affinity / Anti-Affinity 유형

Node와 Pod 작업 단위에 따라 Affinity와 Anti-Affinity를 적용할 수 있으며, 총 4개의 조합이 나올 수 있다.

유형	설명
Node Affinity	특정 라벨을 가진 노드에만 (또는 우선적으로) 배치
Node Anti-Affinity	특정 조건의 노드에는 배치되지 않도록 설정
Pod Affinity	특정 라벨의 Pod가 있는 노드에 함께 배치
Pod Anti-Affinity	특정 라벨의 Pod와 같은 노드에 배치되지 않도록

 

3.3.4. Node Affinity

말 그대로 특정 Node에 Pod를 배치하고 싶을 때 사용한다. 가중치(weight)는 0~100까지 줄 수 있으며 아무리 preferred에 가까운 Pod라고 하더라도 required에 만족되지 않으면 스케쥴링에서 제외된다.

 

[1] 노드 라벨 지정

kubectl label node k8s-worker1 disk=ssd gpu=true
kubectl label node k8s-worker2 disk=hdd gpu=false

 

[2] Node Affinity 파드 메니페스트 정의

vi node-affinity-pod-01.yaml

# node-affinity-pod-01.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-affinity-pod-01
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk
            operator: In
            values:
            - ssd
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: gpu
            operator: In
            values:
            - "true"
  containers:
  - name: nginx
    image: nginx:1.25

 

[3] 리소스 확인 후 지정 노드에서만 실행 확인

kubectl apply -f node-affinity-pod-01.yaml
kubectl delete -f node-affinity-pod-01.yaml

 

 

vi node-affinity-pod-02.yaml
# node-selector-pod-02.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-affinity-pod-02
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk
            operator: In
            values:
            - ssd
            - hdd
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 30
        preference:
          matchExpressions:
          - key: cpu
            operator: In
            values:
            - amd
      - weight: 50
        preference:
          matchExpressions:
          - key: gpu
            operator: In
            values:
            - "true"
  containers:
  - name: node-affinity-pod-container-02
    image: nginx:1.25
    
---------------------------

# 리소스 실행 확인
kubectl apply -f node-affinity-pod-02.yaml
kubectl delete -f node-affinity-pod-02.yaml

---------------------------

# 직접해보기
# 라벨이 cpu=amd 가중치가 높은경우 결과는 ?
# 파드가 10개이상 실행되는 경우 결과는?

vi node-affinity-deployment-03.yaml
# node-affinity-deployment-03.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-affinity-deployment-03
spec:
  replicas: 10
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 30
            preference:
              matchExpressions:
              - key: cpu
                operator: In
                values:
                - amd
          - weight: 50
            preference:
              matchExpressions:
              - key: gpu
                operator: In
                values:
                - "true"
      containers:
      - name: node-affinity-pod-container-03
        image: nginx:1.25

-----------------------------------------------------
---------------------------

vi node-anti-affinity-deployment-01.yaml
# node-anti-affinity-deployment-01.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-anti-affinity-deployment-01
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: name
                operator: DoesNotExist
      containers:
      - name: node-anti-affinity-deployment-container-01
        image: nginx:1.25
        
---------------------------

# 리소스 실행 확인
kubectl apply -f anti-affinity-deployment-01.yaml

kubectl delete all --all

 

 

[3] Pod Affinity / Anti-Affinity

Pod Affinity는 특정 조건을 가진 Pod와 함께 같은 Node에 배치되길 원할 때 사용한다. 예를 들어, 같은 App을 구성하는 여러 컴포넌트를 하나의 Node에 함께 두고 싶을 때 유용하다.

vi pod-affinity-pod-01.yaml
# pod-affinity-pod-01.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity-pod-01
  labels:
    status: stable 
spec:
  containers:
  - image: nginx:1.25
    name: pod-affinity-pod-container-01
    ports:
    - containerPort: 80
      protocol: TCP
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk
            operator: In
            values:
            - ssd

---------------------------

vi pod-affinity-pod-02.yaml
# pod-affinity-pod-02.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity-pod-02
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: status
            operator: In
            values:
            - stable
        topologyKey: kubernetes.io/hostname
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: status
              operator: In
              values:
              - unstable
          topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity-pod-container-02
    image: nginx:1.25

##
topologyKey: kubernetes.io/hostname
노드 레이블의 키 (호스트 네임으 기준으로 파드 스케쥴링)
파드의 분산 배치나 그룹화를 더 세밀하게 제어
NodeSelector보다 더 유연하게 규칙 설정 정의 가능

---------------------------

# 리소스 실행 확인
kubectl apply -f pod-affinity-pod-01.yaml
kubectl apply -f pod-affinity-pod-02.yaml

kubectl delete -f pod-affinity-pod-01.yaml
kubectl delete -f pod-affinity-pod-02.yaml

-----------------------------------------------------

 

[4] Pod Anti-Affinity

반대로, 같은 Node에 배치되지 않게 하고 싶은 경우에는 Anti-Affinity를 사용한다. 이는 장애 분산, 고가용성을 고려할 때 매우 유용하다.

# Pod Anti-Affinity 테스트 

vi pod-anti-affinity-pod-01.yaml
# pod-anti-affinity-pod-01
apiVersion: v1
kind: Pod
metadata:
  name: pod-anti-affinity-pod-01
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: status
            operator: In
            values:
            - stable
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-anti-affinity-pod-container-01
    image: nginx:1.25
    
---------------------------

#
kubectl run pod-anti-affinity-pod-02 --image=nginx:1.25 --labels="status=stable"

    
---------------------------

#
AntiAffinity 적용되었다면! 서로 다른 노드에 스케쥴링 되는지 확인!

 

---

 

3.4.  Taints & Tolerations

Taints(테인트)와 Tolerations(톨러레이션)은 특정 노드에 아무 파드나 스케줄되지 않도록 제어하는 메커니즘이다.

Taints : 노드가 걸어두는 "출입 금지" 표시
"이 노드에는 특정 조건을 만족하는 파드만 들어올 수 있어!"

Tolerations : 파드가 제출하는 "출입 허가증"
"나 이 조건 충족해요! 들어가도 되죠?"

 

즉, 노드는 자신에게 오는 파드를 차단(Taint) 하고, 파드는 자신이 특정 조건을 견딜 수 있음을(Toleration) 선언함으로써 스케줄링 가능 여부가 결정된다.

 

📌 Taints 구성 요소

Taints는 노드 단위에 설정되며 key, value, effect로 구성된다.

key: 조건 키
value: 조건 값
effect: 적용 효과 (다음 세 가지 중 하나)

Effect	설명
NoSchedule	조건을 견디지 못하는 파드는 절대 스케줄되지 않음
PreferNoSchedule	가능하면 스케줄하지 않으나, 강제는 아님 (soft)
NoExecute	조건을 견디지 못하는 파드는 기존에 실행 중이어도 퇴출됨 (Eviction)

# 기본 구조
<key>=<value>:<effect>
# 예시
key=dedicated, value=web, effect=NoSchedule

 

 

📌 Tolerations(톨러레이션) 구성 요소

Operator	Description	Effect	Description
Equal	테인트의 키-값 쌍과 일치 → 용인	NoSchedule	NoSchedule 설정 무시
Exists	테인트의 키만 일치 → 용인	NoExecute	NoExecute 설정 무시

# 예시
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"

 

 

 

📌 실습

-----------------------------------------------------
cd $HOME/manifest

# 테인트 확인
kubectl describe node <node_name>
kubectl describe node <node_name> | grep Taint

# 테인트 설정 및 삭제
kubectl taint nodes <node_name> key1=value1:Effects
kubectl taint nodes <node_name> key1=value1:Effects-

## 테인트만으로 파드 스케쥴링 불가능 -> 톨러레이션 설정이 필요

---------------------------

vi taints-toleration-pod-01.yaml
# taints-toleration-pod-01.yaml
apiVersion: v1
kind: Pod
metadata:
  name: taints-toleration-pod-01
spec:
  containers: 
  - name: nginx-container
    image: nginx:1.25
  nodeName: k8s-worker1

---------------------------

# taints 추가
kubectl taint nodes k8s-worker1 app=web:NoSchedule

# 확인
kubectl get pods -o wide

# 다른 터미널 k8s-master 에서 아래 명령 실행
kubectl get pods -o wide --watch

# 원래 터미널 아래 명령 실행
kubectl taint node k8s-worker1 app=web:NoExecute
# 결과 확인

---------------------------

# 리소스 해제 후 toleration 규칙 추가
# taints-toleration-pod-01.yaml
apiVersion: v1
kind: Pod
metadata:
  name: taints-toleration-pod-01
spec:
  containers: 
  - name: nginx-container
    image: nginx:1.25
  nodeName: k8s-worker1
  tolerations:
  - key: app
    operator: Equal
    value: web
    effect: NoExecute
  - key: app
    operator: Equal
    value: web
    effect: NoSchedule

---------------------------

# 리소스 실행 -> 결과 확인

 

 

📌 실무 팁

시나리오	Taint	Toleration
특정 노드 전용 워크로드	dedicated=gpu:NoSchedule	해당 키/값 toleration
문제 노드 Pod 퇴출	disk=full:NoExecute	tolerationSeconds 로 제한 유지 가능
노드 유지보수 시 특정 Pod만 유지	maintenance=planned:NoExecute	유지 필요한 Pod toleration

 

 

3.5. Cordon, Drain

📌 Cordon

cordon 명령은 노드를 "잠금" 상태로 만들어 새로운 파드가 배치되지 않도록 한다. 즉, 스케쥴링 시 노드를 차단하는 기능을 한다. 하지만 기존에 실행 중이던 파드는 계속 실행 된다.

kubectl cordon <node_name>
kubectl uncordon <node_name>

 

📌 Drain

drain 명령은 해당 노드에서 실행 중인 파드들을 안전하게 퇴출시켜 다른 노드로 옮긴다. 일반적으로 노드 점검이나 재시작 전에 사용한다. 해당 노드를 유지보수 또는 다른 목적으로 활용할 때 사용한다.

kubectl drain --ignore-daemonsets <node_name>
kubectl uncordon <node_name>

•  

📌 실습

-----------------------------------------------------
cd $HOME/manifest

---------------------------

vi cordon-drain-deamonSet-01.yaml
# cordon-drain-deamonSet-01.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cordon-drain-deamonset-01
spec:
  selector:
    matchLabels:
      rel: stable
  template:
    metadata:
      labels:
        rel: stable
    spec:
      containers:
      - name: cordon-drain-deamonset-container-01
        image: wordpress
        ports:
        - containerPort: 80
          protocol: TCP

---------------------------

vi cordon-drain-deployment-01.yaml
# cordon-drain-deployment-01.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cordon-drain-deployment-01
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: cordon-drain-deployment-container-01
        image: nginx:1.25
        ports:
        - containerPort: 80
          protocol: TCP


---------------------------

# 리소스 실행
kubectl apply -f cordon-drain-deamonSet-01.yaml
kubectl apply -f cordon-drain-deployment-01.yaml

# cordon 적용
kubectl cordon k8s-worker1
kubectl create -f cordon-drain-daemonSet-01.yaml
kubectl create -f cordon-drain-deployment-01.yaml

# 결과 확인

---------------------------

# cordon 해제, drain 적용
kubectl uncordon k8s-worker1
kubectl drain --ignore-daemonsets k8s-worker2

# 결과 확인

kubectl delete all --all

 

📌 실무 팁

기준	cordon + drain	taint + toleration
목적	노드를 새 Pod 스케줄링에서 제외하고, 기존 Pod 를 안전하게 다른 노드로 이동	유지보수 노드에 기존 Pod 퇴출 + 특정 Pod 는 유지 (조건부)
즉시성/단순성	간단한 명령 한두 줄로 유지보수 준비 가능	Taint + toleration 값 지정 필요 (설계와 관리 필요)
운영 편리성	대부분의 클러스터 관리툴, CI/CD, 자동화에 cordon + drain 내장	taint/toleration 은 주로 특정 Pod 유형 (예: critical pod) 용
일반성	모든 Pod 대상 (특정 toleration 필요 없음)	toleration 없으면 Pod Evict + 조건 지정해야 함

단순 노드 유지보수, 롤링 업데이트 → cordon + drain

특정 Pod 만 노드에 남겨야 하는 유지보수 → taint + toleration
예) 모니터링, 로깅 DaemonSet

 

✅ 최종정리

방법	특징	장점	단점
nodeName	Pod을 특정 노드에 강제 배치 (스케줄러를 거치지 않음)	매우 단순바로 지정 가능	유연성 없음노드 장애 시 복구 어려움스케줄러 무력화
nodeSelector	노드 라벨 기반으로 스케줄링	설정 간단특정 노드 그룹 지정 용이	조건이 단순 (AND 조건만 가능)라벨 조합이 복잡할 경우 어려움
nodeAffinity	라벨 기반 + 다양한 조건(In, NotIn, Exists 등)선호/필수 조건 구분 가능	다양한 논리 조건 사용 가능유연한 스케줄링 가능	nodeSelector보다 복잡조건 관리 필요
podAffinity / podAntiAffinity	특정 Pod와 함께 또는 떨어져 배치	네트워크 최적화장애 격리 가능	조건 충족 노드 부족 시 스케줄링 실패 위험스케줄러 부하 증가
taint + toleration	taint 있는 노드에 toleration 가진 Pod만 스케줄 가능	특정 노드에 특정 Pod만 배치 가능노드 역할 분리 가능	설정 오류 시 Pod Pending 발생설정 및 디버깅 복잡