Merge pull request #34768 from seokho-son/dev-1.24-ko.1
[ko] Enhance translation for assign-pod-node in dev-1.24-ko.1pull/34796/head
Kubernetes Prow Robot
GitHub
commit
e0c2b2f036
|
|
@ -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/)에서 널리 사용되는 노드 레이블의 목록을 확인한다.
|
||||
|
||||
{{<note>}}
|
||||
이러한 레이블에 대한 값은 클라우드 제공자별로 다르며 정확하지 않을 수 있다.
|
||||
이러한 레이블에 대한 값은 클라우드 제공자별로 다르며 정확하지 않을 수 있다.
|
||||
예를 들어, `kubernetes.io/hostname`에 대한 값은 특정 환경에서는 노드 이름과 동일할 수 있지만
|
||||
다른 환경에서는 다른 값일 수도 있다.
|
||||
{{</note>}}
|
||||
|
|
@ -46,11 +46,11 @@ weight: 20
|
|||
### 노드 격리/제한 {#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` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue