[ko] Update outdated files in dev-1.24-ko.3 (M9-M13)

Signed-off-by: Nayeon Keum <rmaskdus0208@gmail.com>

content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -8,21 +8,29 @@ card:
 ---
 
 <!-- overview -->
-이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를 어떻게 `.yaml` 형식으로 표현할 수 있는지에 대해 설명한다.
-
+이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를 
+어떻게 `.yaml` 형식으로 표현할 수 있는지에 대해 설명한다.
 
 <!-- body -->
 ## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}
 
-*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.
+*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 
+나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.
 
 * 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
 * 그 애플리케이션이 이용할 수 있는 리소스
 * 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
 
-쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
+쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 
+그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 
+워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 
+클러스터에 대해 *의도한 상태* 가 된다.
 
-생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
+생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, 
+[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, 
+`kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 
+또한, 여러분은 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 
+이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
 
 ### 오브젝트 명세(spec)와 상태(status)
 
@@ -48,11 +56,17 @@ spec에 일치되도록 상태를 업데이트하여 3개의 의도한
 경우에는 대체 인스턴스를 시작하여)을 통해
 spec과 status간의 차이에 대응한다.
 
-오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
+오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, 
+[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
 
 ### 쿠버네티스 오브젝트 기술하기
 
-쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. **대부분의 경우 정보를 .yaml 파일로 `kubectl`에 제공한다.** `kubectl`은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.
+쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 
+의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해
+(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 
+JSON 형식으로 정보를 포함시켜 줘야만 한다. **대부분의 경우 정보를 .yaml 파일로 `kubectl`에 
+제공한다.** `kubectl`은 API 요청이 이루어질 때, JSON 형식으로 정보를 
+변환시켜 준다.
 
 여기 쿠버네티스 디플로이먼트를 위한 필수 필드와 오브젝트 spec을 보여주는 `.yaml` 파일 예시가 있다.
 
@@ -81,7 +95,9 @@ deployment.apps/nginx-deployment created
 * `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스`를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
 * `spec` - 오브젝트에 대해 어떤 상태를 의도하는지
 
-오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
+오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 
+중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 
+쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
 
 예를 들어, 파드 API 레퍼런스를 보려면 
 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)를 참조한다. 

content/ko/docs/concepts/overview/working-with-objects/object-management.md

@@ -169,9 +169,9 @@ kubectl apply -R -f configs/
 ## {{% heading "whatsnext" %}}
 
 - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
-- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
-- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
-- [Kustomize를 사용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)
+- [구성파일을 이용한 명령형 쿠버네티스 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [Kustomize를 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)
 - [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubectl 서적](https://kubectl.docs.kubernetes.io)
 - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

content/ko/docs/concepts/scheduling-eviction/_index.md

@@ -23,6 +23,7 @@ no_list: true
 * [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)
 * [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)
 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
+* [파드 토폴로지 분배 제약 조건](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 * [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)
 * [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)

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

@@ -11,12 +11,14 @@ weight: 20
 
 <!-- overview -->
 
-특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하도록
-{{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다.
+특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 
+동작하거나 특정한 노드 집합에서 동작하는 것을 선호하도록 {{< glossary_tooltip text="파드" term_id="pod" >}}를 
+제한할 수 있다.
 이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다.
-보통은 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록 
-노드 간에 파드를 분배)를 수행하기에 이러한 제약 조건은 필요하지 않다.
+보통은 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}가 
+자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록 
+노드 간에 파드를 분배)를 수행하기에 이러한 제약 조건을 설정할 필요는 없다.
 그러나, 예를 들어 SSD가 장착된 머신에 파드가 배포되도록 하거나 또는 
 많은 통신을 하는 두 개의 서로 다른 서비스의 파드를 동일한 가용성 영역(availability zone)에 배치하는 경우와 같이, 
 파드가 어느 노드에 배포될지를 제어해야 하는 경우도 있다.
@@ -29,6 +31,7 @@ weight: 20
   * [노드 레이블](#built-in-node-labels)에 매칭되는 [nodeSelector](#nodeselector) 필드
   * [어피니티 / 안티 어피니티](#affinity-and-anti-affinity)
   * [nodeName](#nodename) 필드
+  * [파드 토폴로지 분배 제약 조건](#pod-topology-spread-constraints)
 
 ## 노드 레이블 {#built-in-node-labels}
 
@@ -169,7 +172,7 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
 
 {{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
 
-`requiredDuringSchedulingIgnoredDuringExecution` 규칙을 만족하는 노드가 2개 있고, 
+`preferredDuringSchedulingIgnoredDuringExecution` 규칙을 만족하는 노드가 2개 있고, 
 하나에는 `label-1:key-1` 레이블이 있고 다른 하나에는 `label-2:key-2` 레이블이 있으면, 
 스케줄러는 각 노드의 `weight`를 확인한 뒤 
 해당 노드에 대한 다른 점수에 가중치를 더하고, 
@@ -336,16 +339,18 @@ null 또는 빈 `namespaces` 목록과 null `namespaceSelector` 는 규칙이 
 
 파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은 
 상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다.
-이러한 규칙을 사용하여, 워크로드 집합이 예를 들면 '동일한 노드'와 같이 
-동일하게 정의된 토폴로지와 같은 위치에 배치되도록 쉽게 구성할 수 있다.
+이러한 규칙을 사용하면, 워크로드 집합이 예를 들면 
+서로 연관된 두 개의 파드를 동일한 노드에 배치하는 것과 같이 동일하게 정의된 토폴로지와 
+같은 위치에 배치되도록 쉽게 구성할 수 있다.
 
-redis와 같은 인-메모리 캐시를 사용하는 웹 애플리케이션을 실행하는 세 개의 노드로 구성된 클러스터를 가정한다.
+세 개의 노드로 구성된 클러스터를 상상해 보자. 이 클러스터에서 redis와 같은 인-메모리 캐시를 이용하는 웹 애플리케이션을 실행한다.
+또한 이 예에서 웹 애플리케이션과 메모리 캐시 사이의 대기 시간은 될 수 있는 대로 짧아야 한다고 가정하자.
 이 때 웹 서버를 가능한 한 캐시와 같은 위치에서 실행되도록 하기 위해 
 파드간 어피니티/안티-어피니티를 사용할 수 있다.
 
 다음의 redis 캐시 디플로이먼트 예시에서, 레플리카는 `app=store` 레이블을 갖는다.
 `podAntiAffinity` 규칙은 스케줄러로 하여금 
-`app=store` 레이블이 있는 레플리카를 한 노드에 여러 개 배치하지 못하도록 한다.
+`app=store` 레이블을 가진 복수 개의 레플리카를 단일 노드에 배치하지 않게 한다.
 이렇게 하여 캐시 파드를 각 노드에 분산하여 생성한다.
 
 ```yaml
@@ -430,6 +435,10 @@ spec:
 | *webserver-1*        |   *webserver-2*     |    *webserver-3*   |
 |  *cache-1*           |     *cache-2*       |     *cache-3*      |
 
+전체적인 효과는 각 캐시 인스턴스를 동일한 노드에서 실행 중인 단일 클라이언트가 액세스하게 될 것 같다는 것이다.
+이 접근 방식은 차이(불균형 로드)와 대기 ​​시간을 모두 최소화하는 것을 목표로 한다.
+
+파드간 안티-어피니티를 사용해야 하는 다른 이유가 있을 수 있다.
 [ZooKeeper 튜토리얼](/ko/docs/tutorials/stateful-application/zookeeper/#노드-실패-방지)에서 
 위 예시와 동일한 기술을 사용해 
 고 가용성을 위한 안티-어피니티로 구성된 스테이트풀셋의 예시를 확인한다.
@@ -468,6 +477,13 @@ spec:
 
 위 파드는 `kube-01` 노드에서만 실행될 것이다.
 
+## 파드 토폴로지 분배 제약 조건
+
+_토폴로지 분배 제약 조건_을 사용하여 지역(regions), 영역(zones), 노드 또는 사용자가 정의한 다른 토폴로지 도메인과 같은 장애 도메인 사이에서 {{< glossary_tooltip text="파드" term_id="Pod" >}}가 클러스터 전체에 분산되는 방식을 제어할 수 있다. 성능, 예상 가용성 또는 전체 활용도를 개선하기 위해 이 작업을 수행할 수 있다.
+
+[파드 토폴로지 분배 제약 조건](/docs/concepts/scheduling-eviction/topology-spread-constraints/)에서 
+작동 방식에 대해 더 자세히 알아볼 수 있다.
+
 ## {{% heading "whatsnext" %}}
 
 * [테인트 및 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)에 대해 더 읽어본다.

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

@@ -83,7 +83,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 ## {{% heading "whatsnext" %}}
 
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
-* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
+* [파드 토폴로지 분배 제약 조건](/docs/concepts/scheduling-eviction/topology-spread-constraints/)에 대해 읽기
 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
 * [kube-scheduler 구성(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기