Sixth Korean l10n work for release 1.18

- Update outdated files in dev-1.18-ko.6 partly (#21714) - Translate StorageClass to Korean word (#21805) - Translate StatefulSet to Korean word in pods.md (#21794) - Translate tasks/run-application/delete-stateful-set/ in Korean (#21686) - Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801) - update outdated docs (#21940) - Modify spacing term StatefulSet in Korean (#21871) - Translate /tasks/administer-cluster/coredns in Korean (#21876) - Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975) - Translation error correction in /concepts/containers/runtime-class.md (#21868) - Translate tasks/tls/certificate-rotation/ in Korean (#21838) - Translate /tasks/configure-pod-container/static-pod in Korean (#21798) - Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911) - Fix English bugs in Korean documentation (#21994) - Update outdated dev-1.18-ko.6 partly (#22067) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Jordy Ruiter <jordy.ruiter@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com> Co-authored-by: Dajin Gwon <d.gweon@samsung.com> Co-authored-by: Hyungseok Lee <hs0426.lee@samsung.com> Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com>
2020-06-14 01:11:06 +09:00
parent a78456d87c
commit 34be3c1d39
133 changed files with 2074 additions and 1226 deletions
@@ -151,7 +151,7 @@ spec:

 예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
 `NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나,
-특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/docs/concepts/configuration/taint-and-toleration/)를 설정할 수 있다.
+특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다.

 `nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는
 *둘 다* 반드시 만족해야 한다.
@@ -206,13 +206,11 @@ spec:
 `preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값
 "S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다.
 (보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키
-`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, 노드 N이 키
-`failure-domain.beta.kubernetes.io/zone` 와 일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.)
-파드 안티-어피니티 규칙에 의하면 노드가 이미 키 "security"와 값 "S2"인 레이블을 가진 파드를
-실행하고 있는 파드는 노드에 스케줄되는 것을 선호하지 않는다.
-(만약 `topologyKey` 가 `failure-domain.beta.kubernetes.io/zone` 라면 노드가 키
-"security"와 값 "S2"를 레이블로 가진 파드와
-동일한 영역에 있는 경우, 노드에 파드를 예약할 수 없음을 의미한다.)
+`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고,
+노드 N이 키 `failure-domain.beta.kubernetes.io/zone` 와
+일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.)
+파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와
+동일한 영역의 노드에 스케줄되지 않는다.
 [디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)를 통해
 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 의
 파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다.
@@ -222,10 +220,11 @@ spec:
 원칙적으로, `topologyKey` 는 적법한 어느 레이블-키도 될 수 있다.
 하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다.

-1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해
-`topologyKey` 가 비어있는 것을 허용하지 않는다.
-2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다.
-3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 `topologyKey` 가 비어있는 것을 허용하지 않는다.
+1. 파드 어피니티에서 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는
+`topologyKey` 의 빈 값을 허용하지 않는다.
+2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는
+`topologyKey` 의 빈 값을 허용하지 않는다.
+3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 간단히 이를 비활성화해야 한다.
 4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다.

 `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
@@ -388,7 +387,7 @@ spec:
 ## {{% heading "whatsnext" %}}


-[테인트](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다.
+[테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아낼* 수 있다.

 [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와
 [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는
@@ -397,5 +396,3 @@ spec:
 파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.
 [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는
 노드 수준의 리소스 할당 결정에 참여할 수 있다.
-
-
@@ -89,10 +89,10 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순

 ## {{% heading "whatsnext" %}}

-* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling/scheduler-perf-tuning/)에 대해 읽기
+* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
-* [파드 오버헤드](/docs/concepts/configuration/pod-overhead/)에 대해 배우기
+* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기

@@ -8,8 +8,8 @@ weight: 70

 {{< feature-state for_k8s_version="1.14" state="beta" >}}

-[kube-scheduler](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
-는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
+[kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)는
+쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
 노드에 파드를 배치하는 역할을 한다.

 파드의 스케줄링 요건을 충족하는
@@ -19,7 +19,7 @@ weight: 70
 높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 _바인딩_ 이라는 프로세스로
 API 서버에 해당 결정을 통지한다.

-본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 
+본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝
 최적화에 대해 설명한다.


@@ -45,7 +45,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml`
 일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.

-이를 변경한 후에 다음을 실행해서 
+이를 변경한 후에 다음을 실행해서
 ```bash
 kubectl get componentstatuses
 ```
@@ -68,7 +68,7 @@ scheduler            Healthy   ok
 정수 값(숫자)로 변환 한다. 스케줄링 중에 kube-scheduler가 구성된
 비율을 초과 할만큼 충분히 실행 가능한 노드를 식별한 경우, kube-scheduler는
 더 실행 가능한 노드를 찾는 검색을 중지하고
-[스코어링 단계](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation)를 진행한다.
+[스코어링 단계](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)를 진행한다.

 [스케줄러가 노드 탐색을 반복(iterate)하는 방법](#스케줄러가-노드-탐색을-반복-iterate-하는-방법)
 은 이 프로세스를 자세히 설명한다.
@@ -101,14 +101,15 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```

+
 ### percentageOfNodesToScore 튜닝

-`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며 
-기본 값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된 
-최소 값도 있다. 
+`percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며
+기본값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된
+최솟값도 있다.

-{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히 
-모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한 
+{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히
+모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한
 노드의 수가 충분하지 않기 때문이다.

 규모가 작은 클러스터에서는 `percentageOfNodesToScore` 에 낮은 값을 설정하면,
@@ -119,10 +120,10 @@ percentageOfNodesToScore: 50
 성능이 크게 향상되지 않는다.
 {{< /note >}}

-이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서 
+이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서
 적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서
-일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데 
-가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지 
+일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데
+가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지
 않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다.

 `percentageOfNodesToScore` 를 매우 낮게 설정해서 kube-scheduler가
@@ -133,19 +134,19 @@ percentageOfNodesToScore: 50

 ## 스케줄러가 노드 탐색을 반복(iterate)하는 방법

-이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을 
+이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을
 위해 작성되었다.

-클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를 
+클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를
 가지도록, 스케줄러는 라운드 로빈(round robin) 방식으로 모든 노드에 대해서 탐색을
-반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의 
-시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를 
-찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가 
-이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막 
+반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의
+시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를
+찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가
+이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막
 포인트부터 확인을 재개한다.

-만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성 
-확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서 
+만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성
+확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서
 탐색을 반복한다. 예제로, 2개의 영역에 있는 6개의 노드를 생각해보자.

 ```
@@ -160,5 +161,3 @@ percentageOfNodesToScore: 50
 ```

 모든 노드를 검토한 후, 노드 1로 돌아간다.
-
-
@@ -6,16 +6,17 @@ weight: 40


 <!-- overview -->
-[여기](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)에 설명된 노드 어피니티는
-노드 셋을 *끌어들이는* (기본 설정 또는 어려운 요구 사항)
-*파드* 속성이다. 테인트는 그 반대로, *노드* 가 파드 셋을
-*제외* 할 수 있다.
+[_노드 어피니티_](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)는
+{{< glossary_tooltip text="노드" term_id="node" >}} 셋을
+(기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다.
+_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다.
+
+_톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에
+스케줄되게 하지만 필수는 아니다.

 테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지
 않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은
 노드가 테인트를 용인하지 않는 파드를 수용해서는 안 되는 것을 나타낸다.
-톨러레이션은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 스케줄되게
-하지만 필수는 아니다.



@@ -61,13 +62,13 @@ tolerations:

 {{< codenew file="pods/pod-with-toleration.yaml" >}}

+지정하지 않으면 `operator` 의 기본값은 `Equal` 이다.
+
 톨러레이션은 키가 동일하고 이펙트가 동일한 경우, 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다.

 * `operator` 가 `Exists` 인 경우(이 경우 `value` 를 지정하지 않아야 함), 또는
 * `operator` 는 `Equal` 이고 `value` 는 `value` 로 같다.

-지정하지 않으면 `operator` 의 기본값은 `Equal` 이다.
-
 {{< note >}}

 두 가지 특별한 경우가 있다.
@@ -198,8 +199,7 @@ tolerations:
 * `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된
  시간 동안 바인딩된 상태로 유지된다.

-덧붙여, 쿠버네티스 1.6 버전에서는 노드 문제를 나타내는 알파 지원이
-도입되었다. 다시 말해, 특정 조건이 참일 때 노드 컨트롤러는 자동으로
+노드 컨트롤러는 특정 조건이 참일 때 자동으로
 노드를 테인트시킨다. 다음은 빌트인 테인트이다.

 * `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition
@@ -221,10 +221,9 @@ tolerations:
 관련 테인트를 제거할 수 있다.

 {{< note >}}
-노드 문제로 인해 파드 축출의 기존 [비율 제한](/ko/docs/concepts/architecture/nodes/)
-동작을 유지하기 위해, 시스템은 실제로 테인트를 비율-제한 방식으로
-추가한다. 이는 마스터가 노드에서 분할되는 등의 시나리오에서
-대규모 파드 축출을 방지한다.
+콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다.
+이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로)
+트리거될 축출 개수를 관리한다.
 {{< /note >}}

 이 기능을 `tolerationSeconds` 와 함께 사용하면, 파드에서
@@ -243,20 +242,15 @@ tolerations:
  tolerationSeconds: 6000
 ```

-쿠버네티스는 사용자가 제공한 파드 구성에 이미 추가된
-`node.kubernetes.io/not-ready` 에 대한 톨러레이션이 없는 경우
-`tolerationSeconds=300` 으로 `node.kubernetes.io/not-ready` 에 대한
-톨러레이션을 자동으로 추가한다.
-마찬가지로 사용자가 제공한 파드 구성에 이미 추가된
-`node.kubernetes.io/unreachable` 에 대한 톨러레이션이 없는 경우
-`tolerationSeconds=300` 으로 `node.kubernetes.io/unreachable` 에 대한
+{{< note >}}
+쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로
+`node.kubernetes.io/not-ready` 와 `node.kubernetes.io/unreachable` 에 대해
+`tolerationSeconds=300` 으로
 톨러레이션을 추가한다.

-자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가
-감지된 후 5분 동안 바인딩 상태로 남아있는 기본 파드
-동작이 유지되도록 한다.
-[DefaultTolerationSecondsadmission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds)
-어드미션 컨트롤러에 의해 두 개의 기본 톨러레이션이 추가된다.
+자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안
+파드가 노드에 바인딩된 상태를 유지함을 의미한다.
+{{< /note >}}

 [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/) 파드는 `tolerationSeconds` 가 없는
 다음 테인트에 대해 `NoExecute` 톨러레이션를 가지고 생성된다.
@@ -273,8 +267,7 @@ tolerations:
 마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다.

 쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을
-모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을
-방지한다.
+모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다.

  * `node.kubernetes.io/memory-pressure`
  * `node.kubernetes.io/disk-pressure`
@@ -284,3 +277,9 @@ tolerations:

 이러한 톨러레이션을 추가하면 이전 버전과의 호환성이 보장된다. 데몬셋에
 임의의 톨러레이션을 추가할 수도 있다.
+
+
+## {{% heading "whatsnext" %}}
+
+* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기
+* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기