Merge pull request #34768 from seokho-son/dev-1.24-ko.1

[ko] Enhance translation for assign-pod-node in dev-1.24-ko.1

Author: k8s-ci-robot

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

@@ -16,7 +16,7 @@ weight: 20
 이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다.
 보통은 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록 
-노드 간에 파드를 분배)를 수행하기에 이러한 제약 조건은 필요하지 않다. 
+노드 간에 파드를 분배)를 수행하기에 이러한 제약 조건은 필요하지 않다.
 그러나, 예를 들어 SSD가 장착된 머신에 파드가 배포되도록 하거나 또는 
 많은 통신을 하는 두 개의 서로 다른 서비스의 파드를 동일한 가용성 영역(availability zone)에 배치하는 경우와 같이, 
 파드가 어느 노드에 배포될지를 제어해야 하는 경우도 있다.
@@ -32,25 +32,25 @@ weight: 20
 
 ## 노드 레이블 {#built-in-node-labels}
 
-다른 쿠버네티스 오브젝트와 마찬가지로, 노드도 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 가진다. 
-[레이블을 수동으로 추가](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/#노드에-레이블-추가)할 수 있다. 
-또한 쿠버네티스도 클러스터의 모든 노드에 표준화된 레이블 집합을 적용한다. 
+다른 쿠버네티스 오브젝트와 마찬가지로, 노드도 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 가진다.
+[레이블을 수동으로 추가](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/#노드에-레이블-추가)할 수 있다.
+또한 쿠버네티스도 클러스터의 모든 노드에 표준화된 레이블 집합을 적용한다.
 [잘 알려진 레이블, 어노테이션, 테인트](/ko/docs/reference/labels-annotations-taints/)에서 널리 사용되는 노드 레이블의 목록을 확인한다.
 
 {{<note>}}
-이러한 레이블에 대한 값은 클라우드 제공자별로 다르며 정확하지 않을 수 있다. 
+이러한 레이블에 대한 값은 클라우드 제공자별로 다르며 정확하지 않을 수 있다.
 예를 들어, `kubernetes.io/hostname`에 대한 값은 특정 환경에서는 노드 이름과 동일할 수 있지만 
 다른 환경에서는 다른 값일 수도 있다.
 {{</note>}}
 
 ### 노드 격리/제한 {#node-isolation-restriction}
 
 노드에 레이블을 추가하여 
-파드를 특정 노드 또는 노드 그룹에 스케줄링되도록 지정할 수 있다. 
+파드를 특정 노드 또는 노드 그룹에 스케줄링되도록 지정할 수 있다.
 이 기능을 사용하여 특정 파드가 특정 격리/보안/규제 속성을 만족하는 노드에서만 
 실행되도록 할 수 있다.
 
-노드 격리를 위해 레이블을 사용할 때, {{<glossary_tooltip text="kubelet" term_id="kubelet">}}이 변경할 수 없는 레이블 키를 선택한다. 
+노드 격리를 위해 레이블을 사용할 때, {{<glossary_tooltip text="kubelet" term_id="kubelet">}}이 변경할 수 없는 레이블 키를 선택한다.
 그렇지 않으면 kubelet이 해당 레이블을 변경하여 노드가 사용 불가능(compromised) 상태로 빠지고 
 스케줄러가 이 노드에 워크로드를 스케줄링하는 일이 발생할 수 있다.
 
@@ -66,9 +66,9 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
 
 ## 노드셀렉터(nodeSelector) {#nodeselector}
 
-`nodeSelector`는 노드 선택 제약사항의 가장 간단하면서도 추천하는 형태이다. 
+`nodeSelector`는 노드 선택 제약사항의 가장 간단하면서도 추천하는 형태이다.
 파드 스펙에 `nodeSelector` 필드를 추가하고, 
-타겟으로 삼고 싶은 노드가 갖고 있는 [노드 레이블](#built-in-node-labels)을 명시한다. 
+타겟으로 삼고 싶은 노드가 갖고 있는 [노드 레이블](#built-in-node-labels)을 명시한다.
 쿠버네티스는 사용자가 명시한 레이블을 갖고 있는 노드에만 
 파드를 스케줄링한다.
 
@@ -78,11 +78,11 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
 ## 어피니티(affinity)와 안티-어피니티(anti-affinity) {#affinity-and-anti-affinity}
 
 `nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 가장 간단한 방법이다.
-어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 
+어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다.
 주요 개선 사항은 다음과 같다.
 
-* 어피니티/안티-어피니티 언어가 더 표현적이다. 
-  `nodeSelector`로는 명시한 레이블이 있는 노드만 선택할 수 있다. 
+* 어피니티/안티-어피니티 언어가 더 표현적이다.
+  `nodeSelector`로는 명시한 레이블이 있는 노드만 선택할 수 있다.
   어피니티/안티-어피니티는 선택 로직에 대한 좀 더 많은 제어권을 제공한다.
 * 규칙이 "소프트(soft)" 또는 "선호사항(preference)" 임을 나타낼 수 있으며, 
   이 덕분에 스케줄러는 매치되는 노드를 찾지 못한 경우에도 파드를 스케줄링할 수 있다.
@@ -100,14 +100,14 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
 ### 노드 어피니티 {#node-affinity}
 
 노드 어피니티는 개념적으로 `nodeSelector` 와 비슷하며, 
-노드의 레이블을 기반으로 파드가 스케줄링될 수 있는 노드를 제한할 수 있다. 
+노드의 레이블을 기반으로 파드가 스케줄링될 수 있는 노드를 제한할 수 있다.
 노드 어피니티에는 다음의 두 종류가 있다.
 
   * `requiredDuringSchedulingIgnoredDuringExecution`: 
-    규칙이 만족되지 않으면 스케줄러가 파드를 스케줄링할 수 없다. 
+    규칙이 만족되지 않으면 스케줄러가 파드를 스케줄링할 수 없다.
     이 기능은 `nodeSelector`와 유사하지만, 좀 더 표현적인 문법을 제공한다.
   * `preferredDuringSchedulingIgnoredDuringExecution`: 
-    스케줄러는 조건을 만족하는 노드를 찾으려고 노력한다. 
+    스케줄러는 조건을 만족하는 노드를 찾으려고 노력한다.
     해당되는 노드가 없더라도, 스케줄러는 여전히 파드를 스케줄링한다.
 
 {{<note>}}
@@ -130,10 +130,10 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
     갖고 있는 노드를 *선호한다* .
 
 `operator` 필드를 사용하여 
-쿠버네티스가 규칙을 해석할 때 사용할 논리 연산자를 지정할 수 있다. 
+쿠버네티스가 규칙을 해석할 때 사용할 논리 연산자를 지정할 수 있다.
 `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` 및 `Lt` 연산자를 사용할 수 있다.
 
-`NotIn` 및 `DoesNotExist` 연산자를 사용하여 노드 안티-어피니티 규칙을 정의할 수 있다. 
+`NotIn` 및 `DoesNotExist` 연산자를 사용하여 노드 안티-어피니티 규칙을 정의할 수 있다.
 또는, 특정 노드에서 파드를 쫓아내는 
 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다.
 
@@ -156,12 +156,12 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
 #### 노드 어피니티 가중치(weight) {#node-affinity-weight}
 
 각 `preferredDuringSchedulingIgnoredDuringExecution` 어피니티 타입 인스턴스에 대해 
-1-100 범위의 `weight`를 명시할 수 있다. 
+1-100 범위의 `weight`를 명시할 수 있다.
 스케줄러가 다른 모든 파드 스케줄링 요구 사항을 만족하는 노드를 찾으면, 
 스케줄러는 노드가 만족한 모든 선호하는(preferred) 규칙에 대해 
 합계 계산을 위한 `weight` 값을 각각 추가한다.
 
-최종 합계는 해당 노드에 대한 다른 우선 순위 함수 점수에 더해진다. 
+최종 합계는 해당 노드에 대한 다른 우선 순위 함수 점수에 더해진다.
 스케줄러가 파드에 대한 스케줄링 판단을 할 때, 
 총 점수가 가장 높은 노드가 우선 순위를 갖는다.
 
@@ -215,12 +215,12 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
 파드의 `.spec.NodeAffinity`를 충족해야 한다.
 
 `addedAffinity`는 엔드 유저에게 표시되지 않으므로, 
-예상치 못한 동작이 일어날 수 있다. 
+예상치 못한 동작이 일어날 수 있다.
 스케줄러 프로파일 이름과 명확한 상관 관계가 있는 노드 레이블을 사용한다.
 
 {{< note >}}
 [데몬셋 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는 
-스케줄링 프로파일을 지원하지 않는다. 
+스케줄링 프로파일을 지원하지 않는다.
 데몬셋 컨트롤러가 파드를 생성할 때, 기본 쿠버네티스 스케줄러는 해당 파드를 배치하고 
 데몬셋 컨트롤러의 모든 `nodeAffinity` 규칙을 준수한다.
 {{< /note >}}
@@ -238,13 +238,13 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
 Y는 쿠버네티스가 충족할 규칙이다.
 
 이러한 규칙(Y)은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 형태로 작성하며, 
-연관된 네임스페이스 목록을 선택적으로 명시할 수도 있다. 
+연관된 네임스페이스 목록을 선택적으로 명시할 수도 있다.
 쿠버네티스에서 파드는 네임스페이스에 속하는(namespaced) 오브젝트이므로, 
-파드 레이블도 암묵적으로 특정 네임스페이스에 속하게 된다. 
+파드 레이블도 암묵적으로 특정 네임스페이스에 속하게 된다.
 파드 레이블에 대한 모든 레이블 셀렉터는 쿠버네티스가 해당 레이블을 어떤 네임스페이스에서 탐색할지를 명시해야 한다.
 
 `topologyKey`를 사용하여 토폴로지 도메인(X)를 나타낼 수 있으며, 
-이는 시스템이 도메인을 표시하기 위해 사용하는 노드 레이블의 키이다. 
+이는 시스템이 도메인을 표시하기 위해 사용하는 노드 레이블의 키이다.
 이에 대한 예시는 [잘 알려진 레이블, 어노테이션, 테인트](/ko/docs/reference/labels-annotations-taints/)를 참고한다.
 
 {{< note >}}
@@ -254,8 +254,8 @@ Y는 쿠버네티스가 충족할 규칙이다.
 {{< /note >}}
 
 {{< note >}}
-파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. 
-즉, 클러스터의 모든 노드는 `topologyKey` 와 매칭되는 적절한 레이블을 가지고 있어야 한다. 
+파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다.
+즉, 클러스터의 모든 노드는 `topologyKey` 와 매칭되는 적절한 레이블을 가지고 있어야 한다.
 일부 또는 모든 노드에 지정된 `topologyKey` 레이블이 없는 경우에는 
 의도하지 않은 동작이 발생할 수 있다.
 {{< /note >}}
@@ -270,12 +270,12 @@ Y는 쿠버네티스가 충족할 규칙이다.
 
 예를 들어, `requiredDuringSchedulingIgnoredDuringExecution` 어피니티를 사용하여 
 서로 통신을 많이 하는 두 서비스의 파드를 
-동일 클라우드 제공자 존에 배치하도록 스케줄러에게 지시할 수 있다. 
+동일 클라우드 제공자 존에 배치하도록 스케줄러에게 지시할 수 있다.
 비슷하게, `preferredDuringSchedulingIgnoredDuringExecution` 안티-어피니티를 사용하여 
 서비스의 파드를 
 여러 클라우드 제공자 존에 퍼뜨릴 수 있다.
 
-파드간 어피니티를 사용하려면, 파드 스펙에 `affinity.podAffinity` 필드를 사용한다. 
+파드간 어피니티를 사용하려면, 파드 스펙에 `affinity.podAffinity` 필드를 사용한다.
 파드간 안티-어피니티를 사용하려면, 
 파드 스펙에 `affinity.podAntiAffinity` 필드를 사용한다.
 
@@ -286,18 +286,18 @@ Y는 쿠버네티스가 충족할 규칙이다.
 {{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
 
 이 예시는 하나의 파드 어피니티 규칙과 
-하나의 파드 안티-어피니티 규칙을 정의한다. 
+하나의 파드 안티-어피니티 규칙을 정의한다.
 파드 어피니티 규칙은 "하드" `requiredDuringSchedulingIgnoredDuringExecution`을, 
 안티-어피니티 규칙은 "소프트" `preferredDuringSchedulingIgnoredDuringExecution`을 사용한다.
 
 위의 어피니티 규칙은 `security=S1` 레이블이 있는 하나 이상의 기존 파드의 존와 동일한 존에 있는 노드에만 
-파드를 스케줄링하도록 스케줄러에 지시한다. 
+파드를 스케줄링하도록 스케줄러에 지시한다.
 더 정확히 말하면, 만약 `security=S1` 파드 레이블이 있는 하나 이상의 기존 파드를 실행하고 있는 노드가 
 `zone=V`에 하나 이상 존재한다면, 
 스케줄러는 파드를 `topology.kubernetes.io/zone=V` 레이블이 있는 노드에 배치해야 한다.
 
 위의 안티-어피니티 규칙은 `security=S2` 레이블이 있는 하나 이상의 기존 파드의 존와 동일한 존에 있는 노드에는 
-가급적 파드를 스케줄링하지 않도록 스케줄러에 지시한다. 
+가급적 파드를 스케줄링하지 않도록 스케줄러에 지시한다.
 더 정확히 말하면, 만약 `security=S2` 파드 레이블이 있는 파드가 실행되고 있는 `zone=R`에 
 다른 노드도 존재한다면, 
 스케줄러는 `topology.kubernetes.io/zone=R` 레이블이 있는 노드에는 가급적 해당 파드를 스케줄링하지 않야아 한다.
@@ -316,37 +316,37 @@ Y는 쿠버네티스가 충족할 규칙이다.
   `requiredDuringSchedulingIgnoredDuringExecution` 및 `preferredDuringSchedulingIgnoredDuringExecution` 내에 허용되지 않는다.
 * `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티 규칙에 대해, 
   `LimitPodHardAntiAffinityTopology` 어드미션 컨트롤러는 
-  `topologyKey`를 `kubernetes.io/hostname`으로 제한한다. 
+  `topologyKey`를 `kubernetes.io/hostname`으로 제한한다.
   커스텀 토폴로지를 허용하고 싶다면 어드미션 컨트롤러를 수정하거나 비활성화할 수 있다.
 
 `labelSelector`와 `topologyKey`에 더하여 선택적으로, 
 `labelSelector`가 비교해야 하는 네임스페이스의 목록을 
-`labelSelector` 및 `topologyKey` 필드와 동일한 계위의 `namespaces` 필드에 명시할 수 있다. 
+`labelSelector` 및 `topologyKey` 필드와 동일한 계위의 `namespaces` 필드에 명시할 수 있다.
 생략하거나 비워 두면, 
 해당 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스를 기본값으로 사용한다.
 
 #### 네임스페이스 셀렉터 {#namespace-selector}
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
-네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다. 
-`namespaceSelector` 또는 `namespaces` 필드에 의해 선택된 네임스페이스 모두에 적용된다. 
+네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다.
+`namespaceSelector` 또는 `namespaces` 필드에 의해 선택된 네임스페이스 모두에 적용된다.
 빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, 
 null 또는 빈 `namespaces` 목록과 null `namespaceSelector` 는 규칙이 적용된 파드의 네임스페이스에 매치된다.
 
 #### 더 실제적인 유스케이스 {#more-practical-use-cases}
 
 파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은 
-상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다. 
+상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다.
 이러한 규칙을 사용하여, 워크로드 집합이 예를 들면 '동일한 노드'와 같이 
 동일하게 정의된 토폴로지와 같은 위치에 배치되도록 쉽게 구성할 수 있다.
 
-redis와 같은 인-메모리 캐시를 사용하는 웹 애플리케이션을 실행하는 세 개의 노드로 구성된 클러스터를 가정한다. 
+redis와 같은 인-메모리 캐시를 사용하는 웹 애플리케이션을 실행하는 세 개의 노드로 구성된 클러스터를 가정한다.
 이 때 웹 서버를 가능한 한 캐시와 같은 위치에서 실행되도록 하기 위해 
 파드간 어피니티/안티-어피니티를 사용할 수 있다.
 
-다음의 redis 캐시 디플로이먼트 예시에서, 레플리카는 `app=store` 레이블을 갖는다. 
+다음의 redis 캐시 디플로이먼트 예시에서, 레플리카는 `app=store` 레이블을 갖는다.
 `podAntiAffinity` 규칙은 스케줄러로 하여금 
-`app=store` 레이블이 있는 레플리카를 한 노드에 여러 개 배치하지 못하도록 한다. 
+`app=store` 레이블이 있는 레플리카를 한 노드에 여러 개 배치하지 못하도록 한다.
 이렇게 하여 캐시 파드를 각 노드에 분산하여 생성한다.
 
 ```yaml
@@ -379,10 +379,10 @@ spec:
         image: redis:3.2-alpine
 ```
 
-웹 서버를 위한 다음의 디플로이먼트는 `app=web-store` 레이블을 갖는 레플리카를 생성한다. 
-파드 어피니티 규칙은 스케줄러로 하여금 `app=store` 레이블이 있는 파드를 실행 중인 노드에 각 레플리카를 배치하도록 한다. 
+웹 서버를 위한 다음의 디플로이먼트는 `app=web-store` 레이블을 갖는 레플리카를 생성한다.
+파드 어피니티 규칙은 스케줄러로 하여금 `app=store` 레이블이 있는 파드를 실행 중인 노드에 각 레플리카를 배치하도록 한다.
 파드 안티-어피니티 규칙은 스케줄러로 하여금 `app=web-store` 레이블이 있는 서버 파드를 
-한 노드에 여러 개 배치하지 못하도록 한다. 
+한 노드에 여러 개 배치하지 못하도록 한다.
 
 ```yaml
 apiVersion: apps/v1
@@ -437,11 +437,11 @@ spec:
 
 ## nodeName {#nodename}
 
-`nodeName`은 어피니티 또는 `nodeSelector`보다 더 직접적인 형태의 노드 선택 방법이다. 
-`nodeName`은 파드 스펙의 필드 중 하나이다. 
+`nodeName`은 어피니티 또는 `nodeSelector`보다 더 직접적인 형태의 노드 선택 방법이다.
+`nodeName`은 파드 스펙의 필드 중 하나이다.
 `nodeName` 필드가 비어 있지 않으면, 스케줄러는 파드를 무시하고, 
-명명된 노드의 kubelet이 해당 파드를 자기 노드에 배치하려고 시도한다. 
-`nodeName`은 `nodeSelector` 또는 어피니티/안티-어피니티 규칙이 무시된다.
+명명된 노드의 kubelet이 해당 파드를 자기 노드에 배치하려고 시도한다.
+`nodeName`은 `nodeSelector` 또는 어피니티/안티-어피니티 규칙보다 우선적으로 적용(overrule)된다.
 
 `nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.