From bfa6e7dfded7b2d42c41d1479f0c4b35c9afd469 Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sat, 2 Jul 2022 20:00:24 +0900 Subject: [PATCH] Enhance translation for assign-pod-node in dev-1.24-ko.1 Signed-off-by: seokho-son --- .../scheduling-eviction/assign-pod-node.md | 92 +++++++++---------- 1 file changed, 46 insertions(+), 46 deletions(-) diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index 771ebc483a..51ecff20b4 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/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,13 +32,13 @@ 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/)에서 널리 사용되는 노드 레이블의 목록을 확인한다. {{}} -이러한 레이블에 대한 값은 클라우드 제공자별로 다르며 정확하지 않을 수 있다. +이러한 레이블에 대한 값은 클라우드 제공자별로 다르며 정확하지 않을 수 있다. 예를 들어, `kubernetes.io/hostname`에 대한 값은 특정 환경에서는 노드 이름과 동일할 수 있지만 다른 환경에서는 다른 값일 수도 있다. {{}} @@ -46,11 +46,11 @@ weight: 20 ### 노드 격리/제한 {#node-isolation-restriction} 노드에 레이블을 추가하여 -파드를 특정 노드 또는 노드 그룹에 스케줄링되도록 지정할 수 있다. +파드를 특정 노드 또는 노드 그룹에 스케줄링되도록 지정할 수 있다. 이 기능을 사용하여 특정 파드가 특정 격리/보안/규제 속성을 만족하는 노드에서만 실행되도록 할 수 있다. -노드 격리를 위해 레이블을 사용할 때, {{}}이 변경할 수 없는 레이블 키를 선택한다. +노드 격리를 위해 레이블을 사용할 때, {{}}이 변경할 수 없는 레이블 키를 선택한다. 그렇지 않으면 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`: - 스케줄러는 조건을 만족하는 노드를 찾으려고 노력한다. + 스케줄러는 조건을 만족하는 노드를 찾으려고 노력한다. 해당되는 노드가 없더라도, 스케줄러는 여전히 파드를 스케줄링한다. {{}} @@ -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` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.