whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[ko] Update outdated files in dev-1.23-ko.1 M55-61

Browse Source
This commit is contained in:
Jihoon Seo
2021-12-20 15:28:55 +09:00
parent 0a2da8cb46
commit 615ff586b2
7 changed files with 253 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/reference/scheduling/config.md
+193 -29
View File
@@ -18,8 +18,8 @@ weight: 20
각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
KubeSchedulerConfiguration ([v1beta1](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
또는 [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/))
KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/))
구조에 맞게 파일을 작성하고,
`kube-scheduler --config <filename>`을 실행하여
스케줄링 프로파일을 지정할 수 있다.
@@ -78,6 +78,8 @@ clientConnection:
플러그인은 적어도 하나 이상 필요하다.
1. `postBind`: 파드가 바인드된 후 호출되는
정보성 익스텐션 포인트이다.
1. `multiPoint`: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해
플러그인들을 동시에 활성화하거나 비활성화할 수 있게 하는 환경 설정 전용 필드이다.
각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나
자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다.
@@ -101,7 +103,7 @@ profiles:
모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데
사용할 수도 있다.
### 스케줄링 플러그인
### 스케줄링 플러그인 {#scheduling-plugins}
기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중
하나 이상을 구현한다.
@@ -178,30 +180,6 @@ profiles:
- `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/)
볼륨 제한이 충족될 수 있는지 확인한다.
익스텐션 포인트: `filter`.
다음 플러그인은 더 이상 사용되지 않으며 `v1beta1`에서만
사용할 수 있다.
- `NodeResourcesLeastAllocated`: 리소스 할당이 낮은 노드를
선호한다.
Extension points: `score`.
- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를
선호한다.
익스텐션 포인트: `score`.
- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를
선호한다.
익스텐션 포인트: `score`.
- `NodeLabel`: 설정된 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라
노드를 필터링하거나 스코어링한다.
익스텐션 포인트: `Filter`, `Score`.
- `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에
속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지
확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에
분산하는 것을 선호한다.
익스텐션 포인트: `preFilter`, `filter`, `score`.
- `NodePreferAvoidPods`: 노드 주석 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라
노드의 우선 순위를 지정한다.
익스텐션 포인트: `score`.
### 여러 프로파일
@@ -251,6 +229,186 @@ profiles:
단 하나만 가질 수 있기 때문이다.
{{< /note >}}
### 다수의 익스텐션 포인트에 플러그인 적용하기 {#multipoint}
`kubescheduler.config.k8s.io/v1beta3` 부터,
다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나
비활성화할 수 있게 하는 프로파일 환경 설정 `multiPoint` 가 추가되었다.
이를 사용하여 사용자와 관리자가 커스텀 프로파일을 사용할 때 환경 설정을 간소화할 수 있다.
`preScore`, `score`, `preFilter`, `filter` 익스텐션 포인트가 있는 `MyPlugin` 이라는 플러그인이 있다고 가정하자.
모든 사용 가능한 익스텐션 포인트에 대해 `MyPlugin` 을 활성화하려면,
다음과 같은 프로파일 환경 설정을 사용한다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: MyPlugin
```
위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 `MyPlugin` 을 수동으로 활성화하는 것과
동일한 효과를 갖는다.
```yaml
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` 에 대해 비활성화하는 예시이다.
```yaml
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` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다.
그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다.
예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고
각각의 가중치가 `1` 이라고 하자.
이 때, 다음과 같이 가중치를 다르게 설정하여 순서를 바꿀 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
score:
enabled:
- name: 'DefaultScore2'
weight: 5
```
이 예제에서, 이 플러그인들을 `MultiPoint` 에 명시할 필요는 없는데,
이는 이 플러그인들이 기본 플러그인이기 때문이다.
그리고 `Score` 에는 `DefaultScore2` 플러그인만 명시되었다.
이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 `MultiPoint` 플러그인보다 우선순위가 높기 때문이다.
결론적으로, 위의 예시에서는 두 플러그인을 모두 명시하지 않고도 두 플러그인의 순서를 조정하였다.
`MultiPoint` 플러그인을 설정할 때, 일반적인 우선 순위는 다음과 같다.
1. 명시된 익스텐션 포인트가 먼저 실행되며, 여기에 명시된 환경 설정은 다른 모든 곳에 설정된 내용보다 우선한다.
2. `MultiPoint` 및 플러그인 설정을 통해 수동으로 구성된 플러그인
3. 기본 플러그인 및 기본 플러그인의 기본 설정
위의 우선 순위를 설명하기 위해, 다음과 같은 예시를 가정한다.
| 플러그인 | 익스텐션 포인트 |
|---|---|
|`DefaultQueueSort`|`QueueSort`|
|`CustomQueueSort`|`QueueSort`|
|`DefaultPlugin1`|`Score`, `Filter`|
|`DefaultPlugin2`|`Score`|
|`CustomPlugin1`|`Score`, `Filter`|
|`CustomPlugin2`|`Score`, `Filter`|
이들 플러그인에 대한 유효한 예시 환경 설정은 다음과 같다.
```yaml
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` 이전 버전의 환경 설정에서는, 위의 스니펫을 다음과 같이 표현할 수 있다.
```yaml
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` 환경 설정의 유연성과
기존 방법과의 끊김없는 통합을 확인할 수 있다.
## 스케줄러 설정 전환
{{< tabs name="tab_with_md" >}}
@@ -284,8 +442,14 @@ profiles:
* v1beta2 설정 파일에서 활성화된 플러그인은 해당 플러그인의 기본 설정값보다 v1beta2 설정 파일의 값이 우선 적용된다.
* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port`가 잘못 설정되면 검증 실패를 유발한다.
* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port` 가 잘못 설정되면 검증 실패를 유발한다.
{{% /tab %}}
{{% tab name="v1beta2 → v1beta3" %}}
* 세 플러그인의 가중치 기본값이 다음과 같이 증가한다.
* `InterPodAffinity`: 1 에서 2 로
* `NodeAffinity`: 1 에서 2 로
* `TaintToleration`: 1 에서 3 으로
{{% /tab %}}
{{< /tabs >}}
@@ -293,5 +457,5 @@ profiles:
* [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
* [kube-scheduler 설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
* [kube-scheduler 설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기
* [kube-scheduler 설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽어보기
content/ko/docs/reference/scheduling/policies.md
+6 -88
View File
@@ -1,102 +1,20 @@
---
title: 스케줄링 정책
content_type: concept
weight: 10
sitemap:
priority: 0.2 # Scheduling priorities are deprecated
---
<!-- overview -->
스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다.
쿠버네티스 v1.23 이전 버전에서는, *단정(predicates)* 및 *우선순위(priorities)* 프로세스를 지정하기 위해 스케줄링 정책을 사용할 수 있다.
예를 들어, `kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>` 명령을 실행하여 스케줄링 정책을 설정할 수 있다.
`kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>`을 실행하고 [정책 유형](/docs/reference/config-api/kube-scheduler-policy-config.v1/)을 사용하여 스케줄링 정책을 설정할 수 있다.
<!-- body -->
## 단정 {#predicates}
다음의 *단정* 은 필터링을 구현한다.
- `PodFitsHostPorts`: 파드가 요청하는 파드의 포트에 대해 노드에 사용할 수 있는
포트(네트워크 프로토콜 종류)가 있는지 확인한다.
- `PodFitsHost`: 파드가 호스트 이름으로 특정 노드를 지정하는지 확인한다.
- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는
리소스(예: CPU 및 메모리)가 있는지 확인한다.
- `MatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가
노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다.
- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면
파드가 요청하는 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 노드에서 사용할 수 있는지
평가한다.
- `NoDiskConflict`: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해
파드가 노드에 적합한지 평가한다.
- `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와
구성된 제한을 초과하는지 여부를 결정한다.
- `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이
노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다.
- `CheckVolumeBinding`: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다.
이는 바인딩된 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}와
바인딩되지 않은 PVC 모두에 적용된다.
## 우선순위 {#priorities}
다음의 *우선순위* 는 스코어링을 구현한다.
- `SelectorSpreadPriority`: 동일한 {{< glossary_tooltip text="서비스" term_id="service" >}},
{{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는
{{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}에 속하는
파드를 고려하여, 파드를 여러 호스트에 파드를 분산한다.
- `InterPodAffinityPriority`: 선호된
[파드간 어피니티와 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 구현한다.
- `LeastRequestedPriority`: 요청된 리소스가 적은 노드를 선호한다. 즉,
노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가
많을수록 이 정책이 부여하는 순위가 낮아진다.
- `MostRequestedPriority`: 요청된 리소스가 가장 많은 노드를 선호한다.
이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된
파드를 맞춘다.
- `RequestedToCapacityRatioPriority`: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다.
- `BalancedResourceAllocation`: 균형 잡힌 리소스 사용의 노드를 선호한다.
- `NodePreferAvoidPodsPriority`: 노드 어노테이션 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라
노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가
동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다.
- `NodeAffinityPriority`: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링
설정에 따라 노드의 우선순위를 지정한다.
이에 대한 자세한 내용은 [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)에서 확인할 수 있다.
- `TaintTolerationPriority`: 노드에서 용인할 수 없는 테인트 수를 기반으로,
모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을
고려하여 노드의 순위를 조정한다.
- `ImageLocalityPriority`: 해당 파드의
{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}가 이미 로컬로 캐시된
노드를 선호한다.
- `ServiceSpreadingPriority`: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한
파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한
파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는
서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다.
- `EqualPriority`: 모든 노드에 동일한 가중치를 부여한다.
- `EvenPodsSpreadPriority`: 선호된
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다.
이러한 스케줄링 정책은 쿠버네티스 v1.23 버전부터 지원되지 않는다. 관련된 플래그인 `policy-config-file`, `policy-configmap`, `policy-configmap-namespace`, `use-legacy-policy-config` 플래그도 지원되지 않는다. 대신, 비슷한 효과를 얻기 위해 [스케줄러 구성](/ko/docs/reference/scheduling/config/)을 사용한다.
## {{% heading "whatsnext" %}}
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
* [kube-scheduler configuration 레퍼런스 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2) 읽어보기
* [kube-scheduler configuration 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3) 읽어보기
* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기