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

Fourth Korean l10n work for release-1.15 (#16063)

Browse Source 
* ko: update translation in reference/glossary/* (#15776)
* Update outdated files partly in dev-1.15-ko.4 (#15856)
* ko: update translation in tasks/debug-application-cluster/resource-metrics-pipeline (#15798)
* ko: translate setup/production-environment/tools/control-plane-flags (#15820)
* ko: translate user-guide-windows-containers (#15730)
* ko: update translation in reference/glossary/* (#15761)
* ko: Update outdated files partly in dev-1.15-ko.4 (#15790)
* ko: fix corrupt date in glossary/static-pod (#15911)
* ko: translate user-guide-windows-nodes (#15759)
* Translate /docs/concepts/configuration/overview/ in Korean (#15803)
* ko: translate setup/production-environment/tools/ha-topology (#15819)
* ko: translate tasks/administer-cluster/network-policy-provider (#15846)
* Translate tasks/inject-data-application/define-command-argument-container in Korea (#15933)
* ko: translate concepts/configuration/organize-cluster-access-kubeconfig (#15871)
* Translate working-with-objects/common-labels.md in Korean (#15832)
* Translate concepts/workloads/pods/disruptions.md in Korean (#15926)
* Translate tasks/access-application-cluster/web-ui/dashboard in Korean (#15852)
* Translate concepts/overview/working-with-objects/labels.md in Korean (#15831)
* ko: translate guestbook-logs-metrics-with-elk (#15894)
* ko: translate tasks/administer-cluster/highly-available-master (#15928)

Co-Authored-By: Yoon <learder@gmail.com>
Co-Authored-By: Eden <longlg88@naver.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: Lawrence Kay <lkay9495@hotmail.com>
Co-Authored-By: alice_k106 <alice_k106@naver.com>
Co-Authored-By: Cheolgu Kim <lapee79@gmail.com>
This commit is contained in:
Seokho Son
2019-08-25 20:10:21 +09:00
committed by Kubernetes Prow Robot
parent 270aaf1f16
commit c82a912e29
57 changed files with 2893 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+156
View File
@@ -0,0 +1,156 @@
---
title: kubeconfig 파일을 사용하여 클러스터 접근 구성하기
content_template: templates/concept
weight: 60
---
{{% capture overview %}}
kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스 및 인증 메커니즘에 대한 정보를 관리하자.
`kubectl` 커맨드라인 툴은 kubeconfig 파일을 사용하여
클러스터의 선택과
클러스터의 API 서버와의 통신에 필요한 정보를 찾는다.
{{< note >}}
클러스터에 대한 접근을 구성하는 데 사용되는 파일을 *kubeconfig 파일* 이라 한다.
이는 구성 파일을 참조하는 일반적인 방법을 의미한다.
`kubeconfig`라는 이름의 파일이 있다는 의미는 아니다.
{{< /note >}}
기본적으로 `kubectl`은 `$HOME/.kube` 디렉터리에서 `config`라는 이름의 파일을 찾는다.
`KUBECONFIG` 환경 변수를 설정하거나
[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) 플래그를 지정해서
다른 kubeconfig 파일을 사용할 수 있다.
kubeconfig 파일을 생성하고 지정하는 단계별 지시사항은
[다중 클러스터로 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)를 참조한다.
{{% /capture %}}
{{% capture body %}}
## 다중 클러스터, 사용자와 인증 메커니즘 지원
여러 클러스터가 있고, 사용자와 구성 요소가 다양한 방식으로 인증한다고 가정하자.
예를 들면 다음과 같다.
- 실행 중인 kubelet은 인증서를 이용하여 인증할 수 있다.
- 사용자는 토큰으로 인증할 수 있다.
- 관리자는 개별 사용자에게 제공하는 인증서 집합을 가지고 있다.
kubeconfig 파일을 사용하면 클러스터와 사용자와 네임스페이스를 구성할 수 있다.
또한 컨텍스트를 정의하여
빠르고 쉽게 클러스터와 네임스페이스 간에 전환할 수 있다.
## 컨텍스트
kubeconfig에서 *컨텍스트* 요소는 편리한 이름으로 접속 매개 변수를 묶는데 사용한다.
각 컨텍스트는 클러스터, 네임스페이스와 사용자라는 세 가지 매개 변수를 가진다.
기본적으로 `kubectl` 커맨드라인 툴은 *현재 컨텍스트* 의 매개 변수를
사용하여 클러스터와 통신한다.
현재 컨택스트를 선택하려면 다음을 실행한다.
```
kubectl config use-context
```
## KUBECONFIG 환경 변수
`KUBECONFIG` 환경 변수는 kubeconfig 파일 목록을 보유한다.
Linux 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다.
Windows는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다.
`KUBECONFIG` 환경 변수가 없으면,
`kubectl`은 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다.
`KUBECONFIG` 환경 변수가 존재하면, `kubectl`은
`KUBECONFIG` 환경 변수에 나열된 파일을 병합한 결과 형태의
효과적 구성을 이용한다.
## kubeconfig 파일 병합
구성을 보려면, 다음 커맨드를 입력한다.
```shell
kubectl config view
```
앞서 설명한 것처럼, 이 출력 내용은 단일 kubeconfig 파일이나
여러 kubeconfig 파일을 병합한 결과 일 수 있다.
다음은 kubeconfig 파일을 병합할 때에 `kubectl`에서 사용하는 규칙이다.
1. `--kubeconfig` 플래그를 설정했으면, 지정한 파일만 사용한다. 병합하지 않는다.
이 플래그는 오직 한 개 인스턴스만 허용한다.
그렇지 않고, `KUBECONFIG` 환경 변수를 설정하였다면
병합해야 하는 파일의 목록으로 사용한다.
`KUBECONFIG` 환경 변수의 나열된 파일은
다음 규칙에 따라 병합한다.
* 빈 파일명은 무시한다.
* 역 직렬화 불가한 파일 내용에 대해서 오류를 일으킨다.
* 특정 값이나 맵 키를 설정한 첫 번째 파일을 우선한다.
* 값이나 맵 키를 변경하지 않는다.
예: `현재 컨텍스트`를 설정할 첫 번째 파일의 컨택스트를 유지한다.
예: 두 파일이 `red-user`를 지정했다면, 첫 번째 파일의 `red-user` 값만을 사용한다.
두 번째 파일의 `red-user` 하위에 충돌하지 않는 항목이 있어도 버린다.
`KUBECONFIG` 환경 변수 설정의 예로,
[KUBECONFIG 환경 변수 설정](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)를 참조한다.
그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다.
1. 이 체인에서 첫 번째를 기반으로 사용할 컨텍스트를 결정한다.
1. 커맨드라인 플래그의 `--context`를 사용한다.
1. 병합된 kubeconfig 파일에서 `current-context`를 사용한다.
이 시점에서는 빈 컨텍스트도 허용한다.
1. 클러스터와 사용자를 결정한다. 이 시점에서는 컨텍스트가 있을 수도 있고 없을 수도 있다.
사용자에 대해 한 번, 클러스터에 대해 한 번 총 두 번에 걸친
이 체인에서 첫 번째 것을 기반으로 클러스터와 사용자를 결정한다.
1. 커맨드라인 플래그가 존재하면, `--user` 또는 `--cluster`를 사용한다.
1. 컨텍스트가 비어있지 않다면, 컨텍스트에서 사용자 또는 클러스터를 가져온다.
이 시점에서는 사용자와 클러스터는 비워둘 수 있다.
1. 사용할 실제 클러스터 정보를 결정한다.
이 시점에서 클러스터 정보가 있을 수 있고 없을 수도 있다.
이 체인을 기반으로 클러스터 정보를 구축한다. 첫 번째 것을 사용한다.
1. 커맨드라인 플래그가 존재하면, `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`를 사용한다.
1. 병합된 kubeconfig 파일에서 클러스터 정보 속성이 있다면 사용한다.
1. 서버 위치가 없다면 실패한다.
1. 사용할 실제 사용자 정보를 결정한다.
사용자 당 하나의 인증 기법만 허용하는 것을 제외하고는
클러스터 정보와 동일한 규칙을 사용하여 사용자 정보를 작성한다.
1. 커맨드라인 플래그가 존재하면, `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`을 사용한다.
1. 병합된 kubeconfig 파일에서 `user` 필드를 사용한다.
1. 충돌하는 두 가지 기법이 있다면 실패한다.
1. 여전히 누락된 정보는 기본 값을 사용하고
인증 정보를 묻는 메시지가 표시될 수 있다.
## 파일 참조
kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치와 관련 있다.
커맨드라인 상에 파일 참조는 현재 디렉터리를 기준으로 한다.
`$HOME/.kube/config`에서 상대 경로는 상대적으로, 절대 경로는
절대적으로 저장한다.
{{% /capture %}}
{{% capture whatsnext %}}
* [다중 클러스터 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
{{% /capture %}}
content/ko/docs/concepts/configuration/overview.md
+107
View File
@@ -0,0 +1,107 @@
---
title: 구성 모범 사례
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된 구성 모범 사례를 강조하고 통합한다.
이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면, 새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다.
{{% /capture %}}
{{% capture body %}}
## 일반적인 구성 팁
- 구성을 정의할 때, 안정된 최신 API 버전을 명시한다.
- 구성 파일들은 클러스터에 적용되기 전에 버전 컨트롤에 저장되어 있어야 한다. 이는 만약 필요하다면 구성의 변경 사항을 빠르게 되돌릴 수 있도록 해준다. 이는 또한 클러스터의 재-생성과 복원을 도와준다.
- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
- 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.
- 불필요하게 기본 값을 명시하지 않는다. 간단하고 최소한의 설정은 에러를 덜 발생시킨다.
- 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다.
## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡
- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
## 서비스
- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
```shell
FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
```
*이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드` 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. DNS는 이러한 제한을 가지고 있지 않다.
- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/docs/concepts/cluster-administration/addons/)은 DNS 서버이다.
DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, 모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다.
- 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다.
만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다.
- `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다.
- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-
services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
## 레이블 사용하기
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카 셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다.
## 컨테이너 이미지
[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/admin/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다.
- `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다.
- `imagePullPolicy: Always`: 파드가 시작될 때마다 이미지가 풀(Pull) 된다.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `IfNotPresent`가 적용된다.
- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
{{< note >}}
컨테이너가 항상 같은 버전의 이미지를 사용하도록 만들기 위해, `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`와 같은 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다.
{{< /note >}}
{{< note >}}
운영 환경에서 컨테이너를 생성할 때 `:latest` 태그의 사용을 피하는 것이 좋은데, 이는 어떠한 버전의 이미지가 실행 중인지 추적하기가 어렵고, 적절히 롤백하기가 더 어려워지기 때문이다.
{{< /note >}}
{{< note >}}
기반이 되는 이미지 제공자의 캐시 방법은 `imagePullPolicy: Always`를 효율적으로 만든다. 예를 들어, 도커에서는 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
{{< /note >}}
## kubectl 사용하기
- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다.
- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다.
- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
{{% /capture %}}
content/ko/docs/concepts/configuration/scheduler-perf-tuning.md
-115
View File
@@ -1,115 +0,0 @@
---
title: 스케줄러 성능 튜닝
content_template: templates/concept
weight: 70
---
{{% capture overview %}}
{{< feature-state for_k8s_version="1.14" state="beta" >}}
Kube-scheduler는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는
클러스터의 노드를 파드에 "적합한(feasible)" 노드라고 한다. 스케줄러는
파드에 대해 적합한 노드를 찾고 기능 셋을 실행하여 해당 노드의 점수를
측정한다. 그리고 스케줄러는 파드를 실행하는데 적합한 모든 노드 중 가장
높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 "바인딩"이라는 프로세스로
API 서버에 해당 결정을 통지한다.
{{% /capture %}}
{{% capture body %}}
## 점수를 측정할 노드의 비율
쿠버네티스 1.12 이전 버전에서, Kube-scheduler는 클러스터의 모든 노드에
대한 적합성(feasibility)을 확인한 후에 적합한 노드들에 대해서 점수를 측정했다.
쿠버네티스 1.12는 새로운 특징을 추가했으며, 이 특징은 스케줄러가 특정
숫자의 적합한 노드를 찾은 이후에 추가적인 적합 노드를 찾는 것을 중단하게 한다.
이것은 대규모 클러스터에서 스케줄러 성능을 향상시킨다. 해당 숫자는 클러스터
크기에 대한 비율로 지정된다. 그 비율은 `percentageOfNodesToScore` 구성
옵션으로 제어될 수 있다. 값의 범위는 1과 100 사이여야 한다. 더 높은 값은
100%로 간주된다. 0은 구성 옵션을 제공하지 않는 것과 동일하다.
점수를 측정할 노드의 비율이 구성 옵션에 명시되지 않은 경우를 대비하여, 쿠버네티스 1.14는
클러스터의 크기에 기반하여 해당 비율 값을 찾는 로직을 가지고 있다. 이 로직은
100-노드 클러스터에 대해 50%를 값으로 출력하는 선형 공식을 사용한다. 해당 공식은 5000-노드
클러스터에 대해서는 10%를 값으로 출력한다. 자동으로 지정되는 값의 하한값은 5%이다. 다시
말해, 사용자가 구성 옵션에 5 보다 낮은 값은 지정하지 않은 한, 스케줄러는
클러스터의 크기와 무관하게 적어도 5%의 클러스터에 대해서는 항상 점수를
측정한다.
아래는 `percentageOfNodesToScore`를 50%로 설정하는 구성 예제이다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
algorithmSource:
provider: DefaultProvider
...
percentageOfNodesToScore: 50
```
{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히
모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한
노드의 수가 충분하지 않기 때문이다. {{< /note >}}
**이 특징을 비활성화하려면**, `percentageOfNodesToScore`를 100으로 지정한다.
### percentageOfNodesToScore 튜닝
`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며
기본 값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된
최소 값도 있다. 이는 수백 개 정도의 노드가 있는
클러스터에서는 해당 옵션을 더 낮은 값으로 변경하더라도 스케줄러가
찾으려는 적합한 노드의 개수에는 크게 영향을 주지 않는다는 뜻이다.
이것은 규모가 작은 클러스터에서는 이 옵션의 조정이 성능을 눈에 띄게 향상시키지 않는
것을 감안하여 의도적으로 설계되었다. 1000 노드 이상의 큰 규모의 클러스터에서는 이 값을
낮은 수로 설정하면 눈에 띄는 성능 향상을 보일 수도 있다.
이 값을 세팅할 때 중요하게 고려해야 할 사항은, 클러스터에서
적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서
일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데
가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지
않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다.
그 이유로, 이 값은 너무 낮은 비율로 설정되면 안 된다. 대략의 경험적 법칙은 10 이하의
값으로는 설정하지 않는 것이다. 더 낮은 값은 사용자의 애플리케이션에서 스케줄러의
처리량이 치명적이고 노드의 점수가 중요하지 않을 경우에만 사용해야 한다. 다시 말해서, 파드의
실행에 적합하기만 하다면 어느 노드가 선택되어도 사용자에게 상관없는 경우를 말한다.
만약 사용자의 클러스터가 단지 백여 개 또는 더 적은 노드를 가지고 있는 경우, 이 구성 옵션의
기본 값보다 낮은 값으로의 변경을 추천하지 않는다. 그것이 스케줄러의 성능을 크게
향상시키지는 않을 것이다.
### 스케줄러가 노드 탐색을 반복(iterate)하는 방법
이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을
위해 작성되었다.
클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를
가지도록, 스케줄러는 라운드 로빈(round robin) 방식으로 모든 노드에 대해서 탐색을
반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의
시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를
찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가
이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막
포인트부터 확인을 재개한다.
만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성
확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서
탐색을 반복한다. 예제로, 2개의 영역에 있는 6개의 노드를 생각해보자.
```
영역 1: 노드 1, 노드 2, 노드 3, 노드 4
영역 2: 노드 5, 노드 6
```
스케줄러는 노드의 적합성 평가를 다음의 순서로 실행한다.
```
노드 1, 노드 5, 노드 2, 노드 6, 노드 3, 노드 4
```
모든 노드를 검토한 후, 노드 1로 돌아간다.
{{% /capture %}}