k8s) Scheduling - 5. Scheduler

Scheduler

쿠버네티스는 확장이 용이해서 별도의 스케쥴러를 만들어 배포함으로써 이를 기본 스케쥴러로 사용할 수도 있고, 추가적인 스케쥴러로 사용할 수도 있다.

• 스케쥴러들은 중복되는 이름을 가질 수 없다. (기본 스케쥴러의 이름은 default-scheduler)

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: [scheduler-name]

Multiple Scheduler(Deploy Additional Scheduler)

각 스케줄러는 별도의 구성(config) 파일을 사용하고, 고유한 스케쥴러 이름을 가짐

1. kube-scheduler 바이너리 파일을 다운받아 여러 옵션과 함께 서비스로 실행할 수 있음(Cf. default-scheduler와 다른 이름으로 생성해야 한다.)

# 1-1. controlplane인 경우(다른 경로에서 수정 후 해당 경로에 옮겨야 함 - 자동으로 생성되지 않게 하기 위해)
cp /etc/kubernetes/manifests/[기본 스케쥴러 정의 파일명] [새로운 파일명]
# 1-2. 파일 수정 후 staticPodPath로 이동
mv [새로운 파일명] /etc/kubernetes/manifests/[새로운 파일명]

# 2-1. worker node인 경우(해당 노드에 접속)
ssh [node-name]
# 2-2. staticPodPath 찾기
cat /lib/var/kubelete/kubeconfig.yaml | grep staticPodPath
# 2-3. 파일 복사
cp [staticPodPath + 기본 스케쥴러 정의 파일명] [새로운 파일명]
# 2-4. 파일 수정 후 staticPodPath로 이동
mv [새로운 파일명] [staticPodPath + 새로운 파일명]

1. 커스텀 스케줄러 manifest 파일(.yaml)을 생성해 이를 이용하는 서비스로 실행할 수 있음

ExecStart=/usr/local/bin/kube-scheduler
	--config=/etc/kubernetes/config/scheduler-definition.yaml

파드 배포시 스케쥴러 지정

spec.schedulerName 의 값으로 스케쥴러명을 전달할 수 있다. 만약 일치하는 스케쥴러명이 없는 경우 파드는 Pending 상태에 그칠 것이다.(정상적으로 매핑된다면 Running 상태가 될 것이다.)

apiVersion: v1
kind: Pod
metadata:
  name: [pod-name]
spec:
  containers:
  - name: [container-name]
    image: [image-name]
  schedulerName: [scheduler-name]

특정 파드의 스케쥴링을 어떤 스케쥴러가 수행했는지 조회

사실상 해당 네임스페이스의 모든 이벤트 조회

kubectl get events -o wide

특정 스케쥴러의 로그 조회

kubectl logs [scheduler-name]

Cf. default namespace가 아니면 네임스페이스 명시

Configuring Scheduler Profiles

• 각 지점마다 확장 지점이 존재해 여기에 플러그인을 배치하여 스케쥴러의 동작을 커스텀할 수 있음

스케쥴링 단계(확장 지점)

queueSort를 제외하고 각 확장 지점에는 전후로 pre extension, post extension 존재 가능

ex. preFilter, postFilter, preScore, preBind, postBind

• Schedulering Queue(queueSort): 우선순위에 따라 파드 순서 정렬
  • spec.priorityClass 값에 따라 파드의 스케쥴링 우선순위 상이
  • #PriorityClass example apㄷiVersion: schedulering.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false : "This priority class should be used for XY2 service pods only."ㄱㄱㄱㄱ
  • 동작 플러그인: PrioritySort
• Filtering(filter): 파드의 필요한 리소스 양을 고려하여 배치가 불가능한 노드 필터
  • 동작 플러그인: NodeResourcesFit(파드가 배치되기에 부족한 리소스를 가지고 있는 노드들 제외), NodeName(필드 유무 확인), NodeUnschedulerable(스케쥴링이 계획되지 않음 플래그가 Y인 노드 필터링)
• Scoring(score): 파드가 배치된 후에 남을 리소스를 기준으로 각 노드에 점수를 매김
  • 동작 플러그인: NodeResourcesFit(노드 우선순위 매김), ImageLocality(이미지 지역 플래그 - 파드가 실행하는 컨테이너 이미지가 존재하는 노드 선호)
• Binding(bind): 점수가 가장 높은 노드에 파드 배치
  • 동작 플러그인: DefaultBinder

Extension Points

• 전체 나열: queueSort - preFilter - filter - postFilter - preScore - score - reserve - permit - preBind - bind - postBind
• 플러그인들은 확장 지점 하나 내에 존재할 수도 있고 여러 확장 지점에 걸쳐있을 수도 있음
• 확장 지점마다 플러그인을 활성화할 수 있는 사용자 지정 코드를 얻을 수 있어 플러그인 연결 가능

KubeSchedulerConfiguration

개별 스케쥴러의 구성 정보를 생성하는 경우: 각 스케쥴러는 서로가 어떤 작업을 하는지 인식하지 못함(각각의 프로세스로 돌아가게 됨)

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: [scheduler-name1]
  plugins:
    score:
      disabled:
       - name: TaintToleration
      enabled:
       - name: MyCustomPluginA
       - name: MyCustomPluginB
- schedulerName: [scheduler-name2]
  plugins:
    preScore:
      disabled:
       - name: '*' # 모두 비활성화
    reserve:
      enabled:
       - name: '*' # 모두 활성화

다수의 스케쥴러 구성 정보를 하나의 바이너리 파일 내에서 정의할 수 있다. 이럴 경우 하나의 프로세스로 동작하게 된다. 즉 단일 스케쥴러가 다중 프로필을 지원하는 기능이다.