Second Korean l10n work for release 1.18
* Translate /concepts/cluster-administration/kubelet-garbage-collection in Korean (#20274) * Translate cluster-administration/logging.md in Korean (#20409) * Translate tasks/configure-pod-container/assign-memory-resource.md in … (#20167) * Translate community/_index.html in Korean. (#20317) * Translate storage/storage-classes.md in Korean. (#20310) * Translate configuration/resource-bin-packing.md in Korean. (#20276) * Translate extend-kubernetes/compute-storage-net/device-plugins.md (#20406) * Translate compute-storage-net/network-plugins.md in Korean (#20407) * Translate concepts/cluster-administration/certificates.md (#20330) * Translate assign-pods-nodes-using-node-affinity to Korean (#20307) * Translate cluster-administration/manage-deployment.md in Korean (#20366) * Translate configuration/taint-and-toleration.md in Korean (#20404) * Translate logging-elasticsearch-kibana.md in Korean (#20300) * add anchors of subtitle in ko/docs/concepts/policy/pod-security-policy (#20399) * Translate task/scheduling-gpus in Korean (#20212) * Translate conceps/storage/volume-snapshots in Korean (#19955) * Translate network/validate-dual-stack.md in Korean (#20271) * Update to Outdated files in the dev-1.18-ko.2 branch. (#20244) * Update to a link to the newly translated document. (#20247) Co-Authored-By: bluefriday <bluefriday86@gmail.com> Co-Authored-By: cometrojan <d.gweon@samsung.com> Co-Authored-By: coolguyhong <podolsmith@naver.com> Co-Authored-By: DongMoon Kim <dmoons.kim@gmail.com> Co-Authored-By: Jerry Park <jaehwa@gmail.com> Co-Authored-By: jmyung <jesang.myung@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-Authored-By: seokho-son <shsongist@gmail.com> Co-Authored-By: sunminjeon <sunmin.jeon@samsung.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
This commit is contained in:
June Yi
@@ -8,7 +8,7 @@ weight: 70
|
||||
|
||||
{{< feature-state for_k8s_version="1.14" state="beta" >}}
|
||||
|
||||
[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
|
||||
[kube-scheduler](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
|
||||
는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
|
||||
노드에 파드를 배치하는 역할을 한다.
|
||||
|
||||
@@ -26,25 +26,69 @@ API 서버에 해당 결정을 통지한다.
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 점수를 측정할 노드의 비율
|
||||
큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간
|
||||
(새 파드가 빠르게 배치됨)과 정확도(스케줄러가 배치 결정을 잘 못하는 경우가 드물게 됨)
|
||||
사이에서의 스케줄링 결과를 균형 잡을 수 있다.
|
||||
|
||||
쿠버네티스 1.12 이전 버전에서, Kube-scheduler는 클러스터의 모든 노드에
|
||||
대한 적합성(feasibility)을 확인한 후에 적합한 노드들에 대해서 점수를 측정했다.
|
||||
쿠버네티스 1.12는 새로운 특징을 추가했으며, 이 특징은 스케줄러가 특정
|
||||
숫자의 적합한 노드를 찾은 이후에 추가적인 적합 노드를 찾는 것을 중단하게 한다.
|
||||
이것은 대규모 클러스터에서 스케줄러 성능을 향상시킨다. 해당 숫자는 클러스터
|
||||
크기에 대한 비율로 지정된다. 그 비율은 `percentageOfNodesToScore` 구성
|
||||
옵션으로 제어될 수 있다. 값의 범위는 1과 100 사이여야 한다. 더 높은 값은
|
||||
100%로 간주된다. 0은 구성 옵션을 제공하지 않는 것과 동일하다.
|
||||
점수를 측정할 노드의 비율이 구성 옵션에 명시되지 않은 경우를 대비하여, 쿠버네티스 1.14는
|
||||
클러스터의 크기에 기반하여 해당 비율 값을 찾는 로직을 가지고 있다. 이 로직은
|
||||
100-노드 클러스터에 대해 50%를 값으로 출력하는 선형 공식을 사용한다. 해당 공식은 5000-노드
|
||||
클러스터에 대해서는 10%를 값으로 출력한다. 자동으로 지정되는 값의 하한값은 5%이다. 다시
|
||||
말해, 사용자가 구성 옵션에 5 보다 낮은 값은 지정하지 않은 한, 스케줄러는
|
||||
클러스터의 크기와 무관하게 적어도 5%의 클러스터에 대해서는 항상 점수를
|
||||
측정한다.
|
||||
kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
|
||||
이 튜닝을 구성 한다. 이 KubeSchedulerConfiguration 설정에 따라 클러스터의
|
||||
노드를 스케줄링할 수 있는 임계값이 결정된다.
|
||||
|
||||
아래는 `percentageOfNodesToScore`를 50%로 설정하는 구성 예제이다.
|
||||
### 임계값 설정하기
|
||||
|
||||
`percentageOfNodesToScore` 옵션은 0과 100 사이의 값을
|
||||
허용한다. 값 0은 kube-scheduler가 컴파일 된 기본값을
|
||||
사용한다는 것을 나타내는 특별한 숫자이다.
|
||||
`percentageOfNodesToScore` 를 100 보다 높게 설정해도 kube-scheduler는
|
||||
마치 100을 설정한 것처럼 작동한다.
|
||||
|
||||
값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml`
|
||||
일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.
|
||||
|
||||
이를 변경한 후에 다음을 실행해서
|
||||
```bash
|
||||
kubectl get componentstatuses
|
||||
```
|
||||
kube-scheduler 컴포넌트가 정상인지 확인할 수 있다. 출력은 다음과 유사하다.
|
||||
```
|
||||
NAME STATUS MESSAGE ERROR
|
||||
controller-manager Healthy ok
|
||||
scheduler Healthy ok
|
||||
...
|
||||
```
|
||||
|
||||
## 노드 스코어링(scoring) 임계값 {#percentage-of-nodes-to-score}
|
||||
|
||||
스케줄링 성능을 향상시키기 위해 kube-scheduler는 실행 가능한
|
||||
노드가 충분히 발견되면 이를 찾는 것을 중단할 수 있다. 큰 규모의 클러스터에서는
|
||||
모든 노드를 고려하는 고지식한 접근 방식에 비해 시간이 절약된다.
|
||||
|
||||
클러스터에 있는 모든 노드의 정수 백분율로 충분한 노두의 수에
|
||||
대한 임계값을 지정한다. kube-scheduler는 이 값을 노드의
|
||||
정수 값(숫자)로 변환 한다. 스케줄링 중에 kube-scheduler가 구성된
|
||||
비율을 초과 할만큼 충분히 실행 가능한 노드를 식별한 경우, kube-scheduler는
|
||||
더 실행 가능한 노드를 찾는 검색을 중지하고
|
||||
[스코어링 단계](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation)를 진행한다.
|
||||
|
||||
[스케줄러가 노드 탐색을 반복(iterate)하는 방법](#스케줄러가-노드-탐색을-반복-iterate-하는-방법)
|
||||
은 이 프로세스를 자세히 설명한다.
|
||||
|
||||
### 기본 임계값
|
||||
|
||||
임계값을 지정하지 않으면 쿠버네티스는 100 노드 클러스터인
|
||||
경우 50%, 5000 노드 클러스터인 경우 10%를 산출하는
|
||||
선형 공식을 사용하여 수치를 계산한다. 자동 값의 하한선은 5% 이다.
|
||||
|
||||
즉, `percentageOfNodesToScore` 를 명시적으로 5보다 작게 설정하지
|
||||
않은 경우 클러스터가 아무리 크더라도 kube-scheduler는
|
||||
항상 클러스터의 최소 5%를 스코어링을 한다.
|
||||
|
||||
스케줄러가 클러스터의 모든 노드에 스코어링을 하려면
|
||||
`percentageOfNodesToScore` 를 100으로 설정 한다.
|
||||
|
||||
## 예시
|
||||
|
||||
아래는 `percentageOfNodesToScore`를 50%로 설정하는 구성 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1alpha1
|
||||
@@ -57,38 +101,37 @@ algorithmSource:
|
||||
percentageOfNodesToScore: 50
|
||||
```
|
||||
|
||||
{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히
|
||||
모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한
|
||||
노드의 수가 충분하지 않기 때문이다. {{< /note >}}
|
||||
|
||||
**이 특징을 비활성화하려면**, `percentageOfNodesToScore`를 100으로 지정한다.
|
||||
|
||||
### percentageOfNodesToScore 튜닝
|
||||
|
||||
`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며
|
||||
기본 값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된
|
||||
최소 값도 있다. 이는 수백 개 정도의 노드가 있는
|
||||
클러스터에서는 해당 옵션을 더 낮은 값으로 변경하더라도 스케줄러가
|
||||
찾으려는 적합한 노드의 개수에는 크게 영향을 주지 않는다는 뜻이다.
|
||||
이것은 규모가 작은 클러스터에서는 이 옵션의 조정이 성능을 눈에 띄게 향상시키지 않는
|
||||
것을 감안하여 의도적으로 설계되었다. 1000 노드 이상의 큰 규모의 클러스터에서는 이 값을
|
||||
낮은 수로 설정하면 눈에 띄는 성능 향상을 보일 수도 있다.
|
||||
최소 값도 있다.
|
||||
|
||||
이 값을 세팅할 때 중요하게 고려해야 할 사항은, 클러스터에서
|
||||
{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히
|
||||
모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한
|
||||
노드의 수가 충분하지 않기 때문이다.
|
||||
|
||||
규모가 작은 클러스터에서는 `percentageOfNodesToScore` 에 낮은 값을 설정하면,
|
||||
비슷한 이유로 변경 사항이 거의 또는 전혀 영향을 미치지 않게 된다.
|
||||
|
||||
클러스터에 수백 개 이하의 노드가 있는 경우 이 구성 옵션을
|
||||
기본값으로 둔다. 이는 변경사항을 적용하더라도 스케줄러의
|
||||
성능이 크게 향상되지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서
|
||||
적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서
|
||||
일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데
|
||||
가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지
|
||||
않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다.
|
||||
그 이유로, 이 값은 너무 낮은 비율로 설정되면 안 된다. 대략의 경험적 법칙은 10 이하의
|
||||
값으로는 설정하지 않는 것이다. 더 낮은 값은 사용자의 애플리케이션에서 스케줄러의
|
||||
처리량이 치명적이고 노드의 점수가 중요하지 않을 경우에만 사용해야 한다. 다시 말해서, 파드의
|
||||
실행에 적합하기만 하다면 어느 노드가 선택되어도 사용자에게 상관없는 경우를 말한다.
|
||||
|
||||
만약 사용자의 클러스터가 단지 백여 개 또는 더 적은 노드를 가지고 있는 경우, 이 구성 옵션의
|
||||
기본 값보다 낮은 값으로의 변경을 추천하지 않는다. 그것이 스케줄러의 성능을 크게
|
||||
향상시키지는 않을 것이다.
|
||||
`percentageOfNodesToScore` 를 매우 낮게 설정해서 kube-scheduler가
|
||||
파드 배치 결정을 잘못 내리지 않도록 해야 한다. 스케줄러의 처리량에
|
||||
대해 애플리케이션이 중요하고 노드 점수가 중요하지 않은 경우가 아니라면
|
||||
백분율을 10% 미만으로 설정하지 말아야 한다. 즉, 가능한 한
|
||||
모든 노드에서 파드를 실행하는 것이 좋다.
|
||||
|
||||
### 스케줄러가 노드 탐색을 반복(iterate)하는 방법
|
||||
## 스케줄러가 노드 탐색을 반복(iterate)하는 방법
|
||||
|
||||
이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을
|
||||
위해 작성되었다.
|
||||
|
||||
Reference in New Issue
Block a user