[ko] Update outdated files in dev-1.20-ko.8 (p3)

content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -11,18 +11,17 @@ weight: 20
 
 <!-- overview -->
 
-{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나,
-특정 노드들을 선호하도록 제한할 수 있다.
-이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두
-[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다.
-보통 스케줄러가 자동으로 합리적인 배치(예: 노드들에 걸쳐 파드를 분배하거나,
-자원이 부족한 노드에 파드를 배치하지 않는 등)를 수행하기에 이런 제약 조건은 필요하지 않지만
-간혹 파드가 배치되는 노드에 대해 더 많은 제어를 원할 수 있는 상황이 있다.
+특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하도록
+{{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다.
+이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
+[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다.
+보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록
+노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만
+간혹 파드가 배포할 노드를 제어해야 하는 경우가 있다.
 예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서
 많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다.
 
 
-
 <!-- body -->
 
 ## 노드 셀렉터(nodeSelector)
@@ -120,13 +119,13 @@ spec:
 
 여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는
 두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시*
-규칙을 만족해야 하는 것(`nodeSelector` 와 같으나 보다 표현적인 구문을 사용해서)을 지정하고,
+규칙을 만족해야 하는 것(`nodeSelector` 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고,
 후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서
 이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
 이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의
-레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 여전히 그 노드에서
+레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서
 동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는
-점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 같은 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
+점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
 
 따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이
 될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고

content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -86,6 +86,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 * [스케줄러 성능 튜닝](/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/) 읽기
+* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기

content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md

@@ -24,8 +24,6 @@ API 서버에 해당 결정을 통지한다.
 본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝
 최적화에 대해 설명한다.
 
-
-
 <!-- body -->
 
 큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간
@@ -44,8 +42,10 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 `percentageOfNodesToScore` 를 100 보다 높게 설정해도 kube-scheduler는
 마치 100을 설정한 것처럼 작동한다.
 
-값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml`
-일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.
+값을 변경하려면,
+[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
+편집한 다음 스케줄러를 재시작한다.
+대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.
 
 이를 변경한 후에 다음을 실행해서
 
@@ -99,7 +99,6 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```
 
-
 ### percentageOfNodesToScore 튜닝
 
 `percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며
@@ -159,3 +158,7 @@ percentageOfNodesToScore: 50
 ```
 
 모든 노드를 검토한 후, 노드 1로 돌아간다.
+
+## {{% heading "whatsnext" %}}
+
+* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인