1) Scheduling Procedure
Pod를 생성할 때 스케줄링은 특정 절차를 거치게 됨
Scheduling Queue → Filtering → Scoring → Binding
Scheduling Queue
스케줄러가 Pod를 스케줄링 할 때는 Scheduling Queue에 들어있는 Pod들을 순차적으로 처리
Scheduling Queue에는 우선 순위에 따라 Pod를 재정렬하는데, 우선 순위는 쿠버네티스의 객체로 만들어서 운용할 수 있음
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 10000000
globalDefault: false
description: "This priority class is only for X service pods."
YAML
복사
이처럼 생성된 우선 순위를 Pod를 정의할 때 사용할 수 있음
apiVersion: v1
kind: Pod
metadata:
name: pod-sample
spec:
priorityClassName: high-priority
containers:
- name: pod-sample
image: pod-sample
resources:
requests:
memory: "1Gi"
cpu: 10
YAML
복사
Filtering
Scheduling Queue에서 우선 순위에 따라 정렬된 Pod들은 배정될 수 있는 노드들만 걸러내는 작업을 수행
Scoring
걸러진 노드들을 대상으로 어떤 노드가 적합한지 가중치에 따라 점수를 매김
Binding
Scoring에서 가장 높은 점수를 획득한 노드에 Pod가 배정됨
2) Plugins & Extension Points
위에서 소개된 각 단계는 특정 플러그인으로 수행됨
Scheduling Queue : PrioritySort
Filtering : NodeResourcesFit → NodeName → NodeUnschedulable → NodeResourcesFit → TaintToleration → NodePorts → NodeAffinity
Scoring : NodeResourcesFit → ImageLocality → NodeResourcesFit → TaintToleration → NodeAffinity
Binding : DefaultBinder
쿠버네티스는 확장성이 굉장히 넓기 때문에 각 단계에서 사용할 플러그인들을 조작할 수 있을 뿐만 아니라 커스텀 플러그인을 만들어서 적용하는 것도 가능한데, 이러한 것이 가능한 이유는 플러그인이 특정 지점에 붙기만 하면 동작할 수 있기 때문
각 플러그인들이 붙는 지점을 Extension Point라고 하고, 각 단계별 대표적인 Extension Point는 아래와 같음
Scheduling Queue : queueSort
Filtering : filter
Scoring : score
Binding : bind
** 구체적으로는 더 세세한 Extension Point들이 존재
queueSort → preFilter → filter → postFilter → preScore → score → reserve → permit → preBind → bind → postBind
** 기본 플러그인들이 각 Extension Point에 어떻게 붙는지는 공식 문서를 확인
3) Customization
위에서 소개된 플러그인들은 Extension Point에 어떤 플러그인들을 사용할지 명시함에 따라 적용 여부를 변경할 수 있는데, 이는 커스텀 스케줄러를 만들 때 사용했던 KubeSchedulerConfiguration 객체의 정의 파일에 설정할 수 있음
쿠버네티스 1.18 버전부터는 설정 파일 내에서도 Profile 분리가 가능하여 각 Profile 마다 어떤 플러그인들을 사용할지 다르게 기재할 수 있음 (용도에 따라 구분된 하나의 설정 파일에서 논리적으로 스케줄러를 구분지어 스케줄링 정책을 구성하는 것이 가능)
** 기본적으로 Kube Scheduler 바이너리는 하나의 설정 파일만으로 구동되는데, 설정 파일이 다르다는 것은 이를 소모하는 프로세스가 서로 다르다는 것
** 즉, 설정 파일로 구분하면 별도의 Kube Scheduler 프로세스에서 구동되는 것이고, 설정 파일은 동일하지만 Profile로 구분하면 동일한 Kube Scheduler 프로세스에서 구동된다는 차이가 있음
** Profile을 이용하게 되면 단일 바이너리로 실행되므로 유지보수와 관리에서 많은 득을 보며, 여러 스케줄러를 구동하지 않아도 되므로 시스템의 자원을 덜 사용
이전에 작성했던 설정에서 아주 일부만 추가하면 됨
apiVersion: kubeScheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
leaderElection:
leaderElect: true
resourceNamespace: kube-system
resourceName: lock-object-scheduler-sample
profiles:
- schedulerName: custom-scheduler-1
plugins:
score:
disabled:
- name: TatinToleration
enabled:
- name: CustomPluginA
- name: CustomPluginB
- schedulerName: custom-scheduler-2
plugins:
preScore:
disabled:
- name : # ...
score:
disabled:
- name : # ...
YAML
복사