이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

스케줄링

1: 스케줄러 구성
2: 스케줄링 정책

1 - 스케줄러 구성

기능 상태: Kubernetes v1.19 [beta]

구성 파일을 작성하고 해당 경로를 커맨드 라인 인수로 전달하여 kube-scheduler 의 동작을 사용자 정의할 수 있다.

스케줄링 프로파일(Profile)을 사용하면 kube-scheduler에서 여러 단계의 스케줄링을 구성할 수 있다. 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.

KubeSchedulerConfiguration (v1beta2 또는 v1beta3) 구조에 맞게 파일을 작성하고, kube-scheduler --config <filename>을 실행하여 스케줄링 프로파일을 지정할 수 있다.

최소 구성은 다음과 같다.

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig

프로파일

스케줄링 프로파일을 사용하면 kube-scheduler에서 여러 단계의 스케줄링을 구성할 수 있다. 각 단계는 익스텐션 포인트에 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.

kube-scheduler 의 단일 인스턴스를 구성하여 여러 프로파일을 실행할 수 있다.

익스텐션 포인트

스케줄링은 다음 익스텐션 포인트를 통해 노출되는 일련의 단계에서 발생한다.

queueSort: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를 정렬하는 데 사용되는 정렬 기능을 제공한다. 대기열 정렬 플러그인은 한 번에 단 하나만 활성화될 수 있다. 사용할 수 있다.
preFilter: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를 사전 처리하거나 확인하는 데 사용된다. 이 플러그인은 파드를 unschedulable로 표시할 수 있다.
filter: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며 파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 필터는 구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로 표시된다.
postFilter: 이 플러그인은 파드의 실행 가능한 노드를 찾을 수 없을 때, 구성된 순서대로 호출된다. postFilter 플러그인이 파드 schedulable 을 표시하는 경우, 나머지 플러그인은 호출 되지 않는다.
preScore: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는 정보성 익스텐션 포인트이다.
score: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를 제공한다. 그런 다음 스케줄러는 가중치 합계가 가장 높은 노드를 선택한다.
reserve: 지정된 파드에 리소스가 예약된 경우 플러그인에 알리는 정보성 익스텐션 포인트이다. 플러그인은 또한 Reserve 도중 또는 이후에 실패한 경우 호출 되는 Unreserve 호출을 구현한다.
permit: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다.
preBind: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다.
bind: 플러그인은 파드를 노드에 바인딩한다. bind 플러그인은 순서대로 호출되며 일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. bind 플러그인은 적어도 하나 이상 필요하다.
postBind: 파드가 바인드된 후 호출되는 정보성 익스텐션 포인트이다.
multiPoint: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해 플러그인들을 동시에 활성화하거나 비활성화할 수 있게 하는 환경 설정 전용 필드이다.

각 익스텐션 포인트에 대해 특정 기본 플러그인을 비활성화하거나 자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다.

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: PodTopologySpread
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1

비활성화된 배열의 이름으로 * 를 사용하여 해당 익스텐션 포인트에 대한 모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데 사용할 수도 있다.

스케줄링 플러그인

기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중 하나 이상을 구현한다.

ImageLocality: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를 선호한다. 익스텐션 포인트: score.
TaintToleration: 테인트(taint)와 톨러레이션(toleration)을 구현한다. 익스텐션 포인트 구현: filter, preScore, score.
NodeName: 파드 명세 노드 이름이 현재 노드와 일치하는지 확인한다. 익스텐션 포인트: filter.
NodePorts: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다. 익스텐션 포인트: preFilter, filter.
NodeAffinity: 노드 셀렉터와 노드 어피니티를 구현한다. 익스텐션 포인트: filter, score.
PodTopologySpread: 파드 토폴로지 분배 제약 조건을 구현한다. 익스텐션 포인트: preFilter, filter, preScore, score.
NodeUnschedulable: .spec.unschedulable 이 true로 설정된 노드를 필터링한다. 익스텐션 포인트: filter.
NodeResourcesFit: 노드에 파드가 요청하는 모든 리소스가 있는지 확인한다. 점수는 LeastAllocated(기본값), MostAllocated, RequestedToCapacityRatio 등 3가지 전략 중 하나를 사용할 수 있다. 익스텐션 포인트: preFilter, filter, score.
NodeResourcesBalancedAllocation: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을 얻을 수 있는 노드를 선호한다. 익스텐션 포인트: score.
VolumeBinding: 노드에 요청된 볼륨이 있는지 또는 바인딩할 수 있는지 확인한다. 익스텐션 포인트: preFilter, filter, reserve, preBind, score.
참고: score 익스텐션 포인트는 VolumeCapacityPriority 기능이 활성화되어 있어야 활성화되며, 요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다.
VolumeRestrictions: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한 제한 사항을 충족하는지 확인한다. 익스텐션 포인트: filter.
VolumeZone: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지 확인한다. 익스텐션 포인트: filter.
NodeVolumeLimits: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: filter.
EBSLimits: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: filter.
GCEPDLimits: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: filter.
AzureDiskLimits: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: filter.
InterPodAffinity: 파드 간 어피니티 및 안티-어피니티를 구현한다. 익스텐션 포인트: preFilter, filter, preScore, score.
PrioritySort: 기본 우선 순위 기반 정렬을 제공한다. 익스텐션 포인트: queueSort.
DefaultBinder: 기본 바인딩 메커니즘을 제공한다. 익스텐션 포인트: bind.
DefaultPreemption: 기본 선점 메커니즘을 제공한다. 익스텐션 포인트: postFilter.

기본으로 활성화되지 않는 다음의 플러그인을 컴포넌트 구성 API를 통해 활성화할 수도 있다.

SelectorSpread: Services, ReplicaSets와 StatefulSets에 속하는 파드의 경우, 노드간에 퍼지는 것을 선호한다. 익스텐션 포인트: preScore, score.
CinderLimits: 노드에 대해 OpenStack Cinder 볼륨 제한이 충족될 수 있는지 확인한다. 익스텐션 포인트: filter.

여러 프로파일

둘 이상의 프로파일을 실행하도록 kube-scheduler 를 구성할 수 있다. 각 프로파일에는 연관된 스케줄러 이름이 있으며 익스텐션 포인트에 구성된 다른 플러그인 세트를 가질 수 있다.

다음의 샘플 구성을 사용하면, 스케줄러는 기본 플러그인이 있는 프로파일과 모든 스코어링 플러그인이 비활성화된 프로파일의 두 가지 프로파일로 실행된다.

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

특정 프로파일에 따라 스케줄하려는 파드는 .spec.schedulerName 에 해당 스케줄러 이름을 포함할 수 있다.

기본적으로, 스케줄러 이름 default-scheduler 를 가진 하나의 프로파일이 생성된다. 이 프로파일에는 위에서 설명한 기본 플러그인이 포함되어 있다. 둘 이상의 프로파일을 선언할 때, 각각에 대한 고유한 스케줄러 이름이 필요하다.

파드가 스케줄러 이름을 지정하지 않으면, kube-apiserver는 이를 default-scheduler 로 설정한다. 따라서, 해당 파드를 스케줄하려면 이 스케줄러 이름을 가진 프로파일이 있어야 한다.

참고: 파드의 스케줄링 이벤트에는 ReportingController로 .spec.schedulerName 이 있다. 리더 선출을 위한 이벤트는 목록에서 첫 번째 프로파일의 스케줄러 이름을 사용한다.

참고: 모든 프로파일은 queueSort 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며 동일한 구성 파라미터(해당하는 경우)를 가져야 한다. 그 이유는 스케줄러가 보류 중 상태인 파드 대기열을 단 하나만 가질 수 있기 때문이다.

다수의 익스텐션 포인트에 플러그인 적용하기

kubescheduler.config.k8s.io/v1beta3 부터, 다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나 비활성화할 수 있게 하는 프로파일 환경 설정 multiPoint 가 추가되었다. 이를 사용하여 사용자와 관리자가 커스텀 프로파일을 사용할 때 환경 설정을 간소화할 수 있다.

preScore, score, preFilter, filter 익스텐션 포인트가 있는 MyPlugin 이라는 플러그인이 있다고 가정하자. 모든 사용 가능한 익스텐션 포인트에 대해 MyPlugin 을 활성화하려면, 다음과 같은 프로파일 환경 설정을 사용한다.

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: MyPlugin

위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 MyPlugin 을 수동으로 활성화하는 것과 동일한 효과를 갖는다.

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      preScore:
        enabled:
        - name: MyPlugin
      score:
        enabled:
        - name: MyPlugin
      preFilter:
        enabled:
        - name: MyPlugin
      filter:
        enabled:
        - name: MyPlugin

여기서 multiPoint 를 사용했을 때의 이점은, 추후 MyPlugin 이 다른 익스텐션 포인트에 대한 구현을 추가했을 때, 새로운 익스텐션에 대해서도 multiPoint 환경 설정이 자동으로 활성화될 것이라는 점이다.

disabled 필드를 사용하여, MultiPoint 확장으로부터 특정 익스텐션 포인트를 제외할 수 있다. 기본 플러그인을 비활성화하거나, 기본이 아닌(non-default) 플러그인을 비활성화하거나, 와일드카드('*')를 사용하여 모든 플러그인을 비활성화할 수 있다. 다음은 Score 와 PreScore 에 대해 비활성화하는 예시이다.

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'MyPlugin'
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

v1beta3 에서, MultiPoint 필드를 통해 내부적으로 모든 기본 플러그인이 활성화된다. 그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다. 예를 들어, 2개의 Score 플러그인 DefaultScore1 과 DefaultScore2 가 있고 각각의 가중치가 1 이라고 하자. 이 때, 다음과 같이 가중치를 다르게 설정하여 순서를 바꿀 수 있다.

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      score:
        enabled:
        - name: 'DefaultScore2'
          weight: 5

이 예제에서, 이 플러그인들을 MultiPoint 에 명시할 필요는 없는데, 이는 이 플러그인들이 기본 플러그인이기 때문이다. 그리고 Score 에는 DefaultScore2 플러그인만 명시되었다. 이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 MultiPoint 플러그인보다 우선순위가 높기 때문이다. 결론적으로, 위의 예시에서는 두 플러그인을 모두 명시하지 않고도 두 플러그인의 순서를 조정하였다.

MultiPoint 플러그인을 설정할 때, 일반적인 우선 순위는 다음과 같다.

명시된 익스텐션 포인트가 먼저 실행되며, 여기에 명시된 환경 설정은 다른 모든 곳에 설정된 내용보다 우선한다.
MultiPoint 및 플러그인 설정을 통해 수동으로 구성된 플러그인
기본 플러그인 및 기본 플러그인의 기본 설정

위의 우선 순위를 설명하기 위해, 다음과 같은 예시를 가정한다.

플러그인	익스텐션 포인트
`DefaultQueueSort`	`QueueSort`
`CustomQueueSort`	`QueueSort`
`DefaultPlugin1`	`Score`, `Filter`
`DefaultPlugin2`	`Score`
`CustomPlugin1`	`Score`, `Filter`
`CustomPlugin2`	`Score`, `Filter`

이들 플러그인에 대한 유효한 예시 환경 설정은 다음과 같다.

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'CustomQueueSort'
        - name: 'CustomPlugin1'
          weight: 3
        - name: 'CustomPlugin2'
        disabled:
        - name: 'DefaultQueueSort'
      filter:
        disabled:
        - name: 'DefaultPlugin1'
      score:
        enabled:
        - name: 'DefaultPlugin2'

명시한 익스텐션 포인트 내에 MultiPoint 플러그인을 재정의해도 에러가 발생하지 않음에 유의한다. 명시한 익스텐션 포인트의 우선 순위가 더 높으므로, 이 재정의는 무시되고 로그에만 기록된다.

대부분의 환경 설정을 한 곳에서 관리하는 것 말고도, 이 예시는 다음과 같은 내용을 포함한다.

커스텀 queueSort 플러그인을 활성화하고 기존의 기본 플러그인을 비활성화한다
CustomPlugin1 과 CustomPlugin2 플러그인을 활성화하며, 이 플러그인에 연결된 모든 익스텐션 포인트를 위해 이 플러그인들이 먼저 실행된다
filter 에 대해서만 DefaultPlugin1 을 비활성화한다
score 에 대해, DefaultPlugin2 플러그인이 (심지어 커스텀 플러그인보다도) 가장 먼저 실행되도록 순서를 조정한다

multiPoint 필드가 없는 v1beta3 이전 버전의 환경 설정에서는, 위의 스니펫을 다음과 같이 표현할 수 있다.

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:

      # 기본 QueueSort 플러그인을 비활성화한다
      queueSort:
        enabled:
        - name: 'CustomQueueSort'
        disabled:
        - name: 'DefaultQueueSort'

      # 커스텀 Filter 플러그인을 활성화한다
      filter:
        enabled:
        - name: 'CustomPlugin1'
        - name: 'CustomPlugin2'
        - name: 'DefaultPlugin2'
        disabled:
        - name: 'DefaultPlugin1'

      # 커스텀 score 플러그인을 활성화하고 순서를 조정한다
      score:
        enabled:
        - name: 'DefaultPlugin2'
          weight: 1
        - name: 'DefaultPlugin1'
          weight: 3

다소 복잡한 예시를 통해, 익스텐션 포인트를 설정함에 있어서 MultiPoint 환경 설정의 유연성과 기존 방법과의 끊김없는 통합을 확인할 수 있다.

설정 버전 v1beta2 에서는, NodeResourcesFit 플러그인을 위한 새로운 스코어링 확장을 이용할 수 있다. 새 확장은 NodeResourcesLeastAllocated, NodeResourcesMostAllocated, RequestedToCapacityRatio 플러그인의 기능을 통합하여 제공한다. 예를 들어, 이전에 NodeResourcesMostAllocated 플러그인을 사용했다면, 대신 NodeResourcesFit(기본적으로 활성화되어 있음)을 사용하면서 다음과 같이 scoreStrategy를 포함하는 pluginConfig를 추가할 수 있다.
```
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
  - args:
      scoringStrategy:
        resources:
        - name: cpu
          weight: 1
        type: MostAllocated
    name: NodeResourcesFit
```
스케줄러 플러그인 NodeLabel은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 NodeAffinity 플러그인(기본적으로 활성화되어 있음)을 사용한다.
스케줄러 플러그인 ServiceAffinity은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 InterPodAffinity 플러그인(기본적으로 활성화되어 있음)을 사용한다.
스케줄러 플러그인 NodePreferAvoidPods은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 노드 테인트를 사용한다.
v1beta2 설정 파일에서 활성화된 플러그인은 해당 플러그인의 기본 설정값보다 v1beta2 설정 파일의 값이 우선 적용된다.
스케줄러 healthz와 metrics 바인드 주소에 대해 host 또는 port 가 잘못 설정되면 검증 실패를 유발한다.

세 플러그인의 가중치 기본값이 다음과 같이 증가한다.
- InterPodAffinity: 1 에서 2 로
- NodeAffinity: 1 에서 2 로
- TaintToleration: 1 에서 3 으로

다음 내용

kube-scheduler 레퍼런스 읽어보기
스케줄링에 대해 알아보기
kube-scheduler 설정 (v1beta2) 레퍼런스 읽어보기
kube-scheduler 설정 (v1beta3) 레퍼런스 읽어보기

2 - 스케줄링 정책

쿠버네티스 v1.23 이전 버전에서는, 단정(predicates) 및 우선순위(priorities) 프로세스를 지정하기 위해 스케줄링 정책을 사용할 수 있다. 예를 들어, kube-scheduler --policy-config-file <filename> 또는 kube-scheduler --policy-configmap <ConfigMap> 명령을 실행하여 스케줄링 정책을 설정할 수 있다.

이러한 스케줄링 정책은 쿠버네티스 v1.23 버전부터 지원되지 않는다. 관련된 플래그인 policy-config-file, policy-configmap, policy-configmap-namespace, use-legacy-policy-config 플래그도 지원되지 않는다. 대신, 비슷한 효과를 얻기 위해 스케줄러 구성을 사용한다.

다음 내용

스케줄링에 대해 배우기
kube-scheduler 프로파일에 대해 배우기
kube-scheduler configuration 레퍼런스 (v1beta3) 읽어보기