[K8S - CKA] Multiple Schedulers

1. Kube-scheduler

---

- 역할 : 기본 스케줄러이다. 일반적으로 POD, Deployment 배포시 사용 된다.

- 한계점 : 특정 응용 프로그램의 Requirement를 따라 갈 수 있는 특정 Node에만 두어야 한다면 어떨까?

 

 

2. 커스텀 스케줄러의 사용

---

쿠버네티스는 응용이 자유롭다. 그래서 여러개의 스케줄러를 둘 수 있는데 아래 예를 살펴보자

 

default-scheduler : kube-scheduler에서 자동으로 만들어진 스케줄러이다. 기본 스케줄러의 구성 내역은 아래와 같다.

 

scheduler-config.yaml

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler #이름을 설정하지 않으면 기본 스케줄러이다.

 

만일, 사용자가 스케줄러를 직접 지정한다면 아래와 같은 형태로 지정 할 수 있다.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: my-scheduler #이름 설정

 

3. Deploy Additional Scheduler (사용하지 않는 방식)

---

바이너리 셋 패키징 된 것을 가져와서 설정하는 방식

wget https://storage.googleapis.com/kubernetes-release/release/v1.12.0/bin/linux/amd64/kube-scheduler

kube-scheduler.service : 기본 스케줄러의 설정

ExecStart=/usr/local/bin/kube-scheduler \\
  --config=/etc/kubernetes/config/kube-scheduler.yaml \\
  --scheduler-name=default-scheduler

my-scheduler.service : 내 커스터 스케줄러의 설정

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

4. Deploy Additional Scheduler as a Pod 

---

my-custom-scheduler.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-custom-scheduler
  namepsace: kube-system
spec:
  containers:
  - command:
    - kube-scheduler
    - --address=127.0.0.1 #kube-api 서버와 인증 하기 위한 path
    - --kubeconfig=/etc/kubernetes/scheduler.conf #스케줄러 구성 파일의 경로를 지정
    #스케줄러가 클러스터와의 인증 및 구성을 위해 사용하는 설정 정보를 포함
    
    - --config=/etc/kubernetes/my-scheduler-config.yaml
    image: k8s.gcr.io/kube-scheduler-amd64:v1.11.3
    name: kube-scheduler

my-scheduler-config.yaml

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: my-scheduler
leaderElection:
 leaderElect: true
 resourceNamespace: kube-system
 resourceName: look-object-my-scheduler
    - --scheduler-name=my-custom-scheduler
    - --lock-object-name=my-custom-scheduler

leaderElection.leaderElect : 스케줄러 리더를 선택하도록 지시합니다. 여러 스케줄러가 실행 중일 때 리더를 선출하여 작업을 중복 실행하지 않도록 함.

lock-object-name : 리더 선출 시 사용되는 잠금 오브젝트의 이름.

(위 2개 옵션은 커스텀 스케줄러와 기본 스케줄러를 나누기 위해서 사용한다.)

 

실 사용 부근은 아래와 같다. (인증 인가 부분이 추가로 필요하지만, 강의 순서상 넘어가게 된다.)

 

스케줄러 바이너리를 컨테이너 이미지로 만든다.

git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make

kube-scheduler 바이너리를 담은 컨테이너 이미지를 생성하자. 이미지를 빌드 하기 위한 Dockerfile은 다음과 같다.

FROM busybox
ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler

파일을 Dockerfile로 저장하고 이미지를 빌드한 후 레지스트리로 푸시하자. 해당 예제에서는 이미지를 Google Container Registry (GCR)로 푸시하고 있다. 이에 대한 자세한 내용은 GCR 문서를 참고하자.

docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 .
gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0

 

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-scheduler-config
  namespace: kube-system
data:
  my-scheduler-config.yaml: |
    apiVersion: kubescheduler.config.k8s.io/v1beta2
    kind: KubeSchedulerConfiguration
    profiles:
      - schedulerName: my-scheduler
    leaderElection:
      leaderElect: false    
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: scheduler
    tier: control-plane
  name: my-scheduler
  namespace: kube-system
spec:
  selector:
    matchLabels:
      component: scheduler
      tier: control-plane
  replicas: 1
  template:
    metadata:
      labels:
        component: scheduler
        tier: control-plane
        version: second
    spec:
      serviceAccountName: my-scheduler
      containers:
      - command:
        - /usr/local/bin/kube-scheduler
        - --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml
        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10259
            scheme: HTTPS
          initialDelaySeconds: 15
        name: kube-second-scheduler
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10259
            scheme: HTTPS
        resources:
          requests:
            cpu: '0.1'
        securityContext:
          privileged: false
        volumeMounts:
          - name: config-volume
            mountPath: /etc/kubernetes/my-scheduler
      hostNetwork: false
      hostPID: false
      volumes:
        - name: config-volume
          configMap:
            name: my-scheduler-config

 

5. View Schedulers 

---

kubectl get pods --namespace=kube-system : 아래 설정으로 모든 쿠버네티스트 클러스터의 스케줄러를 확인 할 수 있습니다.

 

Pod에서 특정 스케줄러만 쓰는 법

apiVersion: v1
  kind: Pod
  metadata:
    name: annotation-default-scheduler
    labels:
      name: multischeduler-example
  spec:
    schedulerName: my-scheduler #scheduler 이름 지정
    containers:
    - name: pod-with-default-annotation-container
      image: registry.k8s.io/pause:2.0

 

6. View Events

---

kubectl get events -o wide : 해당 명령어로 어떤 스케줄러가 떠있는지 확인 할 수 있다.

 

kubectl logs my-scheduler --namespace=kube-system : 스케줄러 로그 확인 가능하다.

 

7. Configuring Scheduler Profiles

---

우선 순위가 높은 Pod는 스케줄러가 어떻게 인식하고 이는 어떻게 배포가 될까요?

 

과정을 살펴보자.

 

1. Scheduling Queue에 Pod가 담긴다, 그리고 priority의 순서에 의해서 생성이 된다. (priority 순서는 위 클래스 이름으로 지정한 yaml 파일을 실행시키고 아래 pod.yaml 파일시키면 priority Value 값에 의해서 스케줄링의 우선 순위가 매겨진다.)

 

2. 스케줄링 큐에 들어가서 스케줄링 순서를 기다린다. (PrioritySort : pod의 우선 순위로 진행이됨)

 

3. 이후 해당 Pod를 가져갈 Node 선정을 위해서 Filtering Phase에 진입하게 되고 이때 pod의 요청 사항을 만족하지 못하는 Node 들은 걸러진다. (Node Resourse Fit 한 지 검사함 / Node Name / NodeUnschedulable : 스케줄링을 받지 않는 선언을 한 노드)

 

4. Scoring Phase에 진입하게 되면서 Node의 Free Requirements Size(CPU, Memory)를 찾아보고 더 많이 남은 곳에 점수를 부여한다. ( Node Resourse Fit 한 지 검사 / ImageLocality : 이미 같은 이미지가 존재하는 노드에는 배치를 미룰 수 있다.)

 

5. 노드로 바인딩

 

위 순서를 보면 알겠지만 각각의 Phase에 따라서 점수를 직접 커스텀하여 변경 할 수 있는 확장이 존재한다.

 

아래는 단순히 PrioritySort를 위한 작업이다.

 

priorityclass.yaml

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

 

위와 같이 다양한 Phase에서 확장이 가능 함을 알 수 있었다.

 

그래서, 본론으로 돌아가서 하나의 Profile 안에서 다양한 스케줄링을 어떻게 지원하고 어떻게 이를 이용할까에 대해서 생각해보자

 

이렇게 아래와 같이 구성하면 위의 것은 기본 스케줄러이고 아래의 것은 아까 ScoringPhase를 건너 뛰고 Scheduling을 제작 할 수 있는 Profiles이 완성된다.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'