Scheduling - Multiple Schedulers(Custom Scheduler)

기본 스케줄러는 파드를 노드에 고르게 분산시키고, taints/tolerations, node affinity 같은 조건을 고려해 최적의 노드를 고릅니다.
하지만 어떤 워크로드는 “우리만의 배치 규칙”이 필요할 수 있습니다. 예를 들어:

• 특정 노드군에만 배치하되, 추가 검증/체크를 통과한 경우에만 배치
• 비용/성능/라이선스 제약을 반영한 스케줄링 로직
• GPU/스토리지/네트워크 토폴로지 등 특수한 정책

쿠버네티스는 확장 가능하므로, 스케줄러를 직접 작성(또는 kube-scheduler를 재사용)해서 기본 스케줄러와 동시에 운영할 수 있습니다.

---

1) “여러 개의 스케줄러”가 가능하다는 의미

• 기본 스케줄러 이름은 보통 default-scheduler
• 추가 스케줄러는 각자 고유한 이름이 필요
• 파드(또는 Deployment)를 만들 때 어떤 스케줄러가 처리할지 지정할 수 있음

즉,

• 대부분의 앱은 기본 스케줄러가 처리하고
• 특정 앱만 커스텀 스케줄러가 처리하도록 분리할 수 있습니다.

---

2) 파드가 특정 스케줄러를 쓰게 하려면: schedulerName

Pod/Deployment 템플릿에 아래 필드를 넣으면 됩니다.

spec:
  schedulerName: my-custom-scheduler

이렇게 하면 해당 파드는 기본 스케줄러가 아니라 my-custom-scheduler가 스케줄링 대상으로 가져가서 노드를 선택합니다.

---

3) 스케줄러 이름은 “스케줄러 config”에서 결정된다

다중 스케줄러를 운영하려면 스케줄러를 서로 구분할 수 있도록 스케줄러 config 파일에 고유 이름을 박아야 합니다.
이 이름이 곧 Pod의 spec.schedulerName과 매칭되는 키가 됩니다.

3-1) 기본 스케줄러 스타일(개념 예시)

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: default-scheduler

3-2) 추가 스케줄러(커스텀 이름) + leader election 예시

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: my-custom-scheduler

leaderElection:
  leaderElect: true
  resourceName: my-custom-scheduler
  resourceNamespace: kube-system

• profiles[].schedulerName: 이 스케줄러의 이름(식별자)
• leaderElection: 동일 스케줄러를 여러 복제본(replica)으로 띄우는 HA 구성이면 리더 선출이 필요
  • 한 번에 하나만 active 스케줄링을 하도록 보장

3-3) 단일 replica용 “최소 구성”(시험/실습 친화)

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: my-scheduler

leaderElection:
  leaderElect: false

---

4) 커스텀 스케줄러를 배포하는 방법(강의 흐름)

방법 A) 바이너리를 서비스로 실행(옛 방식/개념 설명용)

• kube-scheduler 바이너리를 노드에서 직접 실행
• 스케줄러별로 별도의 config 파일을 주고
• 그 config에 스케줄러 이름을 다르게 지정

강의에서도 언급하듯, 요즘은 컨트롤 플레인 컴포넌트 자체가 파드로 올라가는 환경이 많아 이 방식은 덜 일반적입니다.

방법 B) 스케줄러를 Pod/Deployment로 실행(현실적인 방식)

• 스케줄러 컨테이너(보통 kube-scheduler 이미지 또는 커스텀 이미지)를
• kube-system 같은 네임스페이스에 Pod/Deployment로 띄움
• config 파일을 전달(예: ConfigMap + volumeMount)
• API 서버 접근을 위한 인증/권한(RBAC)을 갖추면 동작

---

5) (예시) ConfigMap으로 스케줄러 config 전달하기

5-1) ConfigMap 생성

로컬 파일 kube-scheduler-config.yaml에 위 config를 저장해둔 뒤:

kubectl -n kube-system create configmap my-scheduler-config \
  --from-file=kube-scheduler-config.yaml

5-2) Deployment에 마운트해서 --config로 전달

(핵심 흐름만 담은 최소 예시)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-scheduler
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-scheduler
  template:
    metadata:
      labels:
        app: my-scheduler
    spec:
      serviceAccountName: my-scheduler-sa
      containers:
      - name: kube-scheduler
        image: registry.k8s.io/kube-scheduler:v1.29.0
        command:
          - kube-scheduler
          - --config=/etc/kubernetes/my-scheduler/kube-scheduler-config.yaml
        volumeMounts:
          - name: config
            mountPath: /etc/kubernetes/my-scheduler
            readOnly: true
      volumes:
        - name: config
          configMap:
            name: my-scheduler-config

실제로는 RBAC(ServiceAccount/ClusterRole/Binding)가 필요합니다. 강의에서도 “서비스 계정 및 클러스터 역할 바인딩 같은 전제 조건”을 언급합니다.

 

---

6) “커스텀 스케줄러를 사용하도록” 파드/디플로이먼트를 구성

파드 스펙에 schedulerName만 맞춰주면 됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: use-my-scheduler
spec:
  schedulerName: my-scheduler
  containers:
  - name: nginx
    image: nginx

스케줄러가 정상 동작하면 파드는 Running으로 가고, 스케줄러 구성이 문제면 Pending에 머물 수 있습니다.

---

7) 어떤 스케줄러가 이 파드를 스케줄했는지 확인

7-1) 이벤트에서 확인

kubectl get events --sort-by=.metadata.creationTimestamp

Scheduling 관련 이벤트의 source/from에 스케줄러 이름이 찍히는 것을 확인할 수 있습니다.

7-2) 스케줄러 로그 확인

kubectl -n kube-system logs <scheduler-pod-name>

---

8) 운영 관점 핵심 정리

• 다중 스케줄러는 “정책 분리”를 위한 장치
• 대부분은 기본 스케줄러 사용, 일부 워크로드만 schedulerName으로 커스텀 스케줄러로 라우팅
• 스케줄러 이름은 config의 profiles[].schedulerName과 파드의 spec.schedulerName이 정확히 매칭되어야 함
• HA면 leader election을 이해해야 함
• 문제 발생 시 이벤트/로그로 “누가 스케줄했는지” 추적

 

Practice Test: https://uklabs.kodekloud.com/topic/practice-test-multiple-schedulers-2/