Translate concepts/configuration/assign-pod-node.md in Korean #18845

KimMJ · 2020-01-24T11:32:44Z

`송신` -> `이그레스` `위장` -> `마스커레이딩` from #18666 /language ko

* Update to Outdated files in dev-1.17-ko.3 branch. ### 6 out of 9 files to be modified - [x] content/ko/docs/concepts/services-networking/connect-applications-service.md - [ ] content/ko/docs/concepts/services-networking/dual-stack.md > 오타 수정으로, 한글문서에서는 반영되어있음. - [ ] content/ko/docs/concepts/services-networking/service-topology.md > 오타 수정으로, 한글문서에서는 반영되어있음. - [x] content/ko/docs/concepts/workloads/controllers/cron-jobs.md - [x] content/ko/docs/concepts/workloads/pods/pod-overview.md - [x] content/ko/docs/reference/glossary/customresourcedefinition.md - [x] content/ko/docs/reference/kubectl/cheatsheet.md - [x] content/ko/docs/setup/_index.md - [ ] content/ko/docs/tasks/access-application-cluster/access-cluster.md > #18243 에서 반영됨. from #18577 /language ko * Update kubectl/cheatsheet.md in dev-1.17-ko.3 branch. Co-authored-by: Claudia J.Kang <[email protected]>

k8s-ci-robot · 2020-01-24T11:32:52Z

Welcome @KimMJ!

It looks like this is your first PR to kubernetes/website 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/website has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

KimMJ · 2020-01-24T11:33:44Z

/language ko

netlify · 2020-01-24T11:43:45Z

Deploy preview for k8s-dev-ko ready!

Built with commit 1d756c8

https://deploy-preview-18845--k8s-dev-ko.netlify.com

ysyukr · 2020-01-28T15:30:51Z

/assgin

gochist · 2020-01-29T00:36:13Z

/assign @ysyukr

ysyukr · 2020-01-29T08:55:32Z

@KimMJ 님, PR 감사합니다.
리뷰에 앞서서 번역된 문서의 라인정리가 우선되어야할 것으로 보입니다.
원문에서 리뷰어 부분을 제외한다면 마지막이 400 입니다.

번역된 문서의 마지막이 348로 확인이 되며, 추후에 원문 업데이트에 따른 번역 문서 업데이트 진행시 해당 위치를 찾는 것이 어려워 집니다.

이와 관련하여 쿠버네티스 문서 한글화 가이드 - 가로폭은 원문을 따름을 참고 하시어 라인수 맞춤을 부탁드리겠습니다.

ysyukr

리뷰가 늦어져서 죄송합니다.

우선, 리뷰를 절반정도 진행했습니다.
참고하시어 업데이트 부탁드리겠습니다.

남은 절반에 대해서는 빠르게 진행하겠습니다.

ysyukr · 2020-01-29T14:57:14Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+
+{{% capture overview %}}
+
+{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드" term_id="node" >}}에서만 동작하도록 하거나 특정 노드를 선호하도록 제한할 수 있다. 


Node(s)를 반영하여 노드(들)로 변경 및 뒷 부분에서도 nodes를 반영하여 복수형으로 했습니다.
또한, 문장을 조금 자연스럽게 쉼표를 추가했습니다.

Suggested change

{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드" term_id="node" >}}에서만 동작하도록 하거나 특정 노드를 선호하도록 제한할 수 있다.

{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나, 특정 노드들을 선호하도록 제한할 수 있다.

ysyukr · 2020-01-29T15:02:10Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+{{% capture overview %}}
+
+{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드" term_id="node" >}}에서만 동작하도록 하거나 특정 노드를 선호하도록 제한할 수 있다. 
+이를 위해서는 몇가지 방법이 있는데 그 중 하나는 선택 시 [레이블 셀렉터(label selector)](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하는 것이다. 


원문이 일부 누락된 듯합니다.
There are several ways to do this, and the recommended approaches all use label selectors to make the selection.

또한, 레이블 셀렉터는 한글과 영문을 병기하지 않으며, 문서의 제목이기 때문에 붙이지 않으셔도 됩니다.

Suggested change

이를 위해서는 몇가지 방법이 있는데 그 중 하나는 선택 시 [레이블 셀렉터(label selector)](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하는 것이다.

이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다.

ysyukr · 2020-01-29T15:19:35Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+스케쥴러가 알아서 합리적인 위치를 고르기 때문에 (예를 들어 파드를 노드에 퍼뜨리고, 리소스가 충분하지 않은 노드에는 파드를 위치시키지 않는 것 등) 일반적으로 이러한 제약은 불필요하지만 
+파드가 SSD가 달려있는 머신에서 동작하도록 하거나 서로 통신을 많이 하는 두개의 각기 다른 서비스와 연결된 파드가 
+동일한 가용성 영역(availability zone)에 위치시켜야 하는 것처럼 
+파드가 위치할 노드에 대해 좀 더 제어가 필요한 몇가지 상황들이 있다.


스케쥴러는 국립국어원 외래어 표기에 따라 스케줄러로 변경했습니다.
또한, 일부 번역된 문장의 위치를 자연스럽게 변경해보았습니다.

Suggested change

스케쥴러가 알아서 합리적인 위치를 고르기 때문에 (예를 들어 파드를 노드에 퍼뜨리고, 리소스가 충분하지 않은 노드에는 파드를 위치시키지 않는 것 등) 일반적으로 이러한 제약은 불필요하지만

파드가 SSD가 달려있는 머신에서 동작하도록 하거나 서로 통신을 많이 하는 두개의 각기 다른 서비스와 연결된 파드가

동일한 가용성 영역(availability zone)에 위치시켜야 하는 것처럼

파드가 위치할 노드에 대해 좀 더 제어가 필요한 몇가지 상황들이 있다.

보통 스케줄러가 자동으로 합리적인 배치를 수행하기에 이런 제약 조건은 필요하지 않지만

(예: 노드들에 걸쳐 파드를 분배하거나, 여유 자원이 부족한 노드에 파드를 배치하는 등)

그러나 간혹 파드가 착륙하는 노드에 대해 더 많은 제어를 원할 수 있는 상황이 있다.

예를 들어 SSD가 장착되어 있는 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서 많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다.

ysyukr · 2020-01-29T15:30:36Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+
+## 노드 셀렉터(nodeSelector)
+
+`nodeSelector`는 가장 간단하고 추천하는 형식의 노드 선택 제약이다.


markdown 코드인 ` 뒤에 단어가 붙어있으면 페이지 변환시 정상적으로 변환되지 않을 수 있습니다.
이에 markdown 코드 뒤에는 가능하면 한칸 띄워주시는 것이 좋습니다.

불필요한 문자(�)가 삽입되었습니다. 또한, 자연스럽게 수정해보았습니다.
constraints의 경우에는 다른 문서에서 제약 조건으로 번역된 선례가 있어 이를 반영했습니다.

Suggested change

`nodeSelector`는 가장 간단하고 추천하는 형식의 노드 선택 제약이다.

`nodeSelector` 는 가장 간단하고 권장하는 노드 선택 제약 조건의 형태이다.

ysyukr · 2020-01-29T15:49:01Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+`nodeSelector`는 파드 스펙의 필드이다. 이는 키-값 쌍의 맵을 지정한다.
+파드가 노드에서 동작할 수 있도록 하려면 노드는 반드시 레이블(물론 이는 추가적인 레이블들을 가질 수도 있다)로 지정된 
+키-값 쌍들을 모두 가지고 있어야 한다. 일반적인 사용법은 단일 키-값 쌍을 사용하는 것이다.


PodSpec은 파드스펙으로 변경이 가능하나, 다른 문서에서 PodSepc으로 그대로 번역된 선례가 있어 동일하게 유지하고자 합니다.
또한, map 의 경우에는 키-값 쌍의 일치하는 것을 의미하기 때문에 매핑으로 변경해보았습니다.
나머지는 원문에서 누락된 부분을 포함하고, 문장을 자연스럽게 다듬어보았습니다.

Suggested change

`nodeSelector`는 파드 스펙의 필드이다. 이는 키-값 쌍의 맵을 지정한다.

파드가 노드에서 동작할 수 있도록 하려면 노드는 반드시 레이블(물론 이는 추가적인 레이블들을 가질 수도 있다)로 지정된

키-값 쌍들을 모두 가지고 있어야 한다. 일반적인 사용법은 단일 키-값 쌍을 사용하는 것이다.

`nodeSelector` 는 PodSpec의 필드이다. 이는 키-값 쌍의 매핑으로 지정한다.

파드가 노드에서 동작할 수 있으려면, 노드는 키-값의 쌍으로 표시되는 레이블을 각자 가지고 있어야 한다(이는 추가 레이블을 가지고 있을 수 있다).

대부분의 일반적인 사용은 하나의 키-값의 쌍이다.

ysyukr · 2020-01-30T08:13:03Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+노드 어피니티는 파드 스펙에서 `affinity`필드 내의 `nodeAffinity` 필드에서 지정된다.
+
+노드 어피니티를 사용하는 파드의 예시이다:


조금 더 자연스럽게 다듬었습니다.

Suggested change

노드 어피니티는 파드 스펙에서 `affinity`필드 내의 `nodeAffinity` 필드에서 지정된다.

노드 어피니티를 사용하는 파드의 예시이다:

노드 어피니티는 PodSpec의 `affinity` 필드의 `nodeAffinity` 필드에서 지정된다.

여기에 노드 어피니티를 사용하는 파드 예시가 있다.

ysyukr · 2020-01-30T08:24:03Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+이 노드 어피니티 규칙은 파드가 `kubernetes.io/e2e-az-name`가 키고 값이 `e2e-az1` 또는 `e2e-az2`인 레이블을 가진 노드에서만 동작할 수 있도록 하는 것이다. 
+추가적으로 이러한 규칙을 만족하는 노드들 중에서 `another-node-label-key`가 키이고 값이 `another-node-label-value`인 레이블을 가진 노드를 선호하도록 되어있다.


원문을 좀 더 반영하고, 더 자연스럽게 다듬었습니다.

Suggested change

이 노드 어피니티 규칙은 파드가 `kubernetes.io/e2e-az-name`가 키고 값이 `e2e-az1` 또는 `e2e-az2`인 레이블을 가진 노드에서만 동작할 수 있도록 하는 것이다.

추가적으로 이러한 규칙을 만족하는 노드들 중에서 `another-node-label-key`가 키이고 값이 `another-node-label-value`인 레이블을 가진 노드를 선호하도록 되어있다.

이 노드 어피니티 규칙은 키가 `kubernetes.io/e2e-az-name` 이고 값이 `e2e-az1` 또는 `e2e-az2` 인 레이블이 있는 노드에만 파드를 배치할 수 있다고 말한다.

또한, 이 기준을 충족하는 노드들 중에서 키가 `another-node-label-key` 이고 값이 `another-node-label-value` 인 레이블이 있는 노드를 선호하도록 한다.

ysyukr · 2020-01-30T08:29:44Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+예시에서 `In`이라는 오퍼레이터를 사용하였다. 
+새로운 노드 어피니티 문법은 다음의 오퍼레이터들을 지원한다: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. 
+`NotIn`과 `DoesNotExist`를 사용하여 안티-어피니티 동작을 할 수 있고 [노드 테인트(node taints)](/docs/concepts/configuration/taint-and-toleration/) 사용하여 특정한 노드에서 파드를 쫓아낼 수 있다.


원문을 좀 더 반영하고, 자연스럽게 다듬었습니다.
operator 의 경우에는 연산자 로 번역된 선례가 있어 이를 반영했습니다.

Suggested change

예시에서 `In`이라는 오퍼레이터를 사용하였다.

새로운 노드 어피니티 문법은 다음의 오퍼레이터들을 지원한다: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.

`NotIn`과 `DoesNotExist`를 사용하여 안티-어피니티 동작을 할 수 있고 [노드 테인트(node taints)](/docs/concepts/configuration/taint-and-toleration/) 사용하여 특정한 노드에서 파드를 쫓아낼 수 있다.

예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다.

새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.

`NotIn` 과 `DoesNotExist` 를 사용해서 노드 안티-어피니티를 수행하거나, 특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/docs/concepts/configuration/taint-and-toleration/)를 할 수 있다.

ysyukr · 2020-01-30T08:47:59Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+`nodeSelector`와 `nodeAffinity`를 모두 지정한다면 파드가 후보 노드에 스케쥴 되기 위해서는 *둘 다* 반드시 만족해야한다.
+
+여러개의 `nodeAffinity` 타입과 관련하여 `nodeSelectorTerms`를 지정하면 파드는 `nodeSelectorTerms` 중에서 **하나라도 만족**하는 노드에 스케쥴될 수 있다. 
+
+`nodeSelectorTerms`와 관련된 `matchExpressions`를 여러개 지정하면 파드는 `matchExpressions`가 **모두 만족**하는 노드에만 스케쥴될 수 있다.
+
+파드가 스케쥴된 노드의 레이블을 지우거나 변경해도 파드는 삭제되지 않는다. 다시 말해, 어피니티 선택은 파드가 스케쥴링 되는 시점에만 작동한다.


좀 더 자연스럽게 다듬었습니다.

Suggested change

`nodeSelector`와 `nodeAffinity`를 모두 지정한다면 파드가 후보 노드에 스케쥴 되기 위해서는 *둘 다* 반드시 만족해야한다.

여러개의 `nodeAffinity` 타입과 관련하여 `nodeSelectorTerms`를 지정하면 파드는 `nodeSelectorTerms` 중에서 **하나라도 만족**하는 노드에 스케쥴될 수 있다.

`nodeSelectorTerms`와 관련된 `matchExpressions`를 여러개 지정하면 파드는 `matchExpressions`가 **모두 만족**하는 노드에만 스케쥴될 수 있다.

파드가 스케쥴된 노드의 레이블을 지우거나 변경해도 파드는 삭제되지 않는다. 다시 말해, 어피니티 선택은 파드가 스케쥴링 되는 시점에만 작동한다.

`nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는 *둘 다* 반드시 만족해야한다.

`nodeAffinity` 유형과 연관된 여러 `nodeSelectorTerms` 를 지정하면, 파드를 `nodeSelectorTerms` 가 지정된 것 중 **한 가지**라도 만족하는 노드에 스케줄 할 수 있다.

`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 를 **모두** 만족하는 노드에 스케줄 할 수 있다.

파드가 스케줄된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다.

ysyukr · 2020-01-30T08:54:28Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+`preferredDuringSchedulingIgnoredDuringExecution`에서 `weight` 필드는 1-100까지의 범위를 가진다. 
+모든 스케쥴링 요구사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해서 스케쥴러는 이 필드를 순회하며 노드가 MatchExpressions에 적합할 때 "weight"를 누적 합계에 추가하여 총합을 계산할 것이다. 
+이 점수는 노드에 대해 다른 우선순위 함수의 점수들과 합쳐진다. 가장 높은 점수를 가진 노드를 가장 선호하게 된다.


조금 더 자연스럽게 다듬었습니다.

Suggested change

`preferredDuringSchedulingIgnoredDuringExecution`에서 `weight` 필드는 1-100까지의 범위를 가진다.

모든 스케쥴링 요구사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해서 스케쥴러는 이 필드를 순회하며 노드가 MatchExpressions에 적합할 때 "weight"를 누적 합계에 추가하여 총합을 계산할 것이다.

이 점수는 노드에 대해 다른 우선순위 함수의 점수들과 합쳐진다. 가장 높은 점수를 가진 노드를 가장 선호하게 된다.

`preferredDuringSchedulingIgnoredDuringExecution` 의 `weight` 필드의 범위는 1-100 이다.

모든 스케줄링 요구사항(리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해 스케줄러는 이 필드의 요소들을 반복해서 합계를 계산하고 노드가 MatchExpressions 에 일치하는 경우 합계에 "가중치(weight)" 를 추가 한다.

이후에 이 점수는 노드에 대한 다른 우선순위 함수의 점수와 합쳐진다. 전체 점수가 가장 높은 노드를 가장 선호한다.

ysyukr

나머지 부분에 대한 리뷰를 마쳤습니다.
최초 문서에 맞추어 리뷰가 완료되었습니다.
확인하시어 업데이트를 부탁드리겠습니다.

늦어서 죄송합니다.

ysyukr · 2020-01-30T16:11:56Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+파드간 어피니티와 안티-어피니티는 파드를 노드의 레이블이 아니라 *노드에서 이미 동작 중인 파드들의 레이블을 기반으로* 동작할 수 있는 노드를 선택하게 할 수 있다. 
+이 규칙은 "이 파드는 반드시 Y 규칙을 만족하는 파드가 하나 이상 동작중인 X에서만 동작할 수 있도록(안티-어피니티의 경우, 동작할수 없도록) 한다"는 형태로 구성되어있다. 
+Y는 네임스페이스와 관련된 선택적 목록을 가진 LabelSelector로 표현된다; 노드와는 다르게 파드는 네임스페이스 기반(이는 파드의 레이블이 네임스페이스 기반임을 내포한다)이고 파트 레이블에 대한 레이블 셀렉터는 반드시 셀렉터가 어느 네임스페이스에 적용되어야 하는지 지정해 주어야 하기 때문이다. 
+개념적으로 X는 노드, 랙, 클라우드 제공자 영역, 클라우드 제공자 리젼 등과 같은 토폴로지 도메인이다. 시스템이 사용하는 토폴로지 도메인을 의미하는 노드 레이블의 키인 `topologyKey`를 사용하여 토폴로지 도메인을 표현할 수 있으며, 예시는 [넘어가기 전에: 빌트인 노드 레이블](#built-in-node-labels) 섹션에 나열된 레이블 키를 보면 된다.


좀 더 자연스럽게 다듬었습니다.

Suggested change

파드간 어피니티와 안티-어피니티는 파드를 노드의 레이블이 아니라 *노드에서 이미 동작 중인 파드들의 레이블을 기반으로* 동작할 수 있는 노드를 선택하게 할 수 있다.

이 규칙은 "이 파드는 반드시 Y 규칙을 만족하는 파드가 하나 이상 동작중인 X에서만 동작할 수 있도록(안티-어피니티의 경우, 동작할수 없도록) 한다"는 형태로 구성되어있다.

Y는 네임스페이스와 관련된 선택적 목록을 가진 LabelSelector로 표현된다; 노드와는 다르게 파드는 네임스페이스 기반(이는 파드의 레이블이 네임스페이스 기반임을 내포한다)이고 파트 레이블에 대한 레이블 셀렉터는 반드시 셀렉터가 어느 네임스페이스에 적용되어야 하는지 지정해 주어야 하기 때문이다.

개념적으로 X는 노드, 랙, 클라우드 제공자 영역, 클라우드 제공자 리젼 등과 같은 토폴로지 도메인이다. 시스템이 사용하는 토폴로지 도메인을 의미하는 노드 레이블의 키인 `topologyKey`를 사용하여 토폴로지 도메인을 표현할 수 있으며, 예시는 [넘어가기 전에: 빌트인 노드 레이블](#built-in-node-labels) 섹션에 나열된 레이블 키를 보면 된다.

파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기존으로하지 않고, *노드에서 이미 실행중인 파드 레이블을 기반으로* 파드가 스케줄될 수 있는 노드를 제한할 수 있다.

규칙은 "X가 규칙 Y를 충족하는 하나 이상의 파드를 이미 실행중인 경우 이 파드는 X에서 실행해야한다(또는 안티-어피니티가 없는 경우에는 동작하면 안된다)는 형태이다.

Y는 선택적으로 연관된 네임스페이스 목록을 가진 LableSelector로 표현된다. 노드와는 다르게 파드는 네임스페이스이기에(그리고 따라서 파드의 레이블은 암암리에 네임스페이스이다) 파드 레이블위의 레이블 셀렉터는 셀렉터가 적용될 네임스페이스를 지정해야만 한다.

개념적으로 X는 노드, 랙, 클라우드 공급자 영역, 클라우드 공급자 지역, 등 과 같은 토폴로지 도메인이다. 시스템이 이런 토폴로지 도메인을 나타내는 데 사용하는 노드 레이블 키인 `topologyKey` 를 사용해서 이를 표현한다. 예: [넘어가기 전에: 빌트인 노드 레이블](#built-in-node-labels) 섹션 위에 나열된 레이블 키를 본다.

ysyukr · 2020-01-30T16:14:59Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+파드간 어피니티와 안티-어피니티는 상당한 양의 연산을 필요로 하여 큰 클러스터에서는 스케쥴링을 상당히 느리게 할 수 있다. 
+수백개의 노드가 넘는 클러스터에서 이를 사용하는 것은 추천하지 않는다.


Suggested change

파드간 어피니티와 안티-어피니티는 상당한 양의 연산을 필요로 하여 큰 클러스터에서는 스케쥴링을 상당히 느리게 할 수 있다.

수백개의 노드가 넘는 클러스터에서 이를 사용하는 것은 추천하지 않는다.

파드간 어피니티와 안티-어피니티에는 상당한 양의 프로세싱이 필요하기에 대규모 클러스터에서는 스케줄링 속도가 크게느려질 수 있다.

수백개의 노드를 넘어가는 클러스터에서 이를 사용하는 것은 추천하지 않는다.

ysyukr · 2020-01-30T16:19:04Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+{{< /note >}}
+
+{{< note >}}
+파드 안티-어피니티는 노드가 일관적으로 레이블을 가지고 있어야 함을 전제로 한다. 예를들어 클러스터의 모든 노드는 `topologyKey`와 매칭되는 적절한 레이블을 가지고 있어야 한다. 일부 또는 모든 노드가 지정된 `topologyKey` 레이블이 없다면 이는 의도치 않은 동작을 일으킬 수 있다.


Suggested change

파드 안티-어피니티는 노드가 일관적으로 레이블을 가지고 있어야 함을 전제로 한다. 예를들어 클러스터의 모든 노드는 `topologyKey`와 매칭되는 적절한 레이블을 가지고 있어야 한다. 일부 또는 모든 노드가 지정된 `topologyKey` 레이블이 없다면 이는 의도치 않은 동작을 일으킬 수 있다.

파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. 즉, 클러스터의 모든 노드는 `topologykey` 와 매칭되는 적절한 레이블이 있어야 한다. 일부 또는 모든 노드에 지정된 `topologyKey` 레이블이 없는 경우에는 의도하지 않은 동작이 발생할 수 있다.

ysyukr · 2020-02-01T19:26:41Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+노드 어피니티처럼 현재 각각 "엄격한"과 "유연한" 제약사항을 나타내는 `requiredDuringSchedulingIgnoredDuringExecution`와 `preferredDuringSchedulingIgnoredDuringExecution`라고 하는 파드 어피니티와 안티 어피니티 두가지 종류가 있다. 
+앞선 노드 어피니티 섹션의 설명을 보면 된다. 
+`requiredDuringSchedulingIgnoredDuringExecution` 어피니티의 예시는 "서비스 A와 서비스 B는 서로 많은 통신을 하기 때문에 각 서비스의 파드들을 동일한 영역에 위치시킨다."이고 `preferredDuringSchedulingIgnoredDuringExecution` 안티 어피니티의 예시는 "서비스를 여러 영역에 걸처 퍼트린다"가 될 것이다
+(엄격한 제약조건은 파드가 영역의 수보다 많을 수 있기 때문에 말이 안된다).


조금 더 자연스럽게 다듬었습니다.

Suggested change

노드 어피니티처럼 현재 각각 "엄격한"과 "유연한" 제약사항을 나타내는 `requiredDuringSchedulingIgnoredDuringExecution`와 `preferredDuringSchedulingIgnoredDuringExecution`라고 하는 파드 어피니티와 안티 어피니티 두가지 종류가 있다.

앞선 노드 어피니티 섹션의 설명을 보면 된다.

`requiredDuringSchedulingIgnoredDuringExecution` 어피니티의 예시는 "서비스 A와 서비스 B는 서로 많은 통신을 하기 때문에 각 서비스의 파드들을 동일한 영역에 위치시킨다."이고 `preferredDuringSchedulingIgnoredDuringExecution` 안티 어피니티의 예시는 "서비스를 여러 영역에 걸처 퍼트린다"가 될 것이다

(엄격한 제약조건은 파드가 영역의 수보다 많을 수 있기 때문에 말이 안된다).

노드 어피니티와 마찬가지로 현재 파드 어피니티와 안티-어피니티로 부르는 "엄격함" 대 "유연함"의 요구사항을 나타내는 ``requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 두가지 종류가 있다.

앞의 노드 어피니티 섹션의 설명을 본다.

`requiredDuringSchedulingIgnoredDuringExecution` 어피니티의 예시는 "서로 많은 통신을 하기 때문에 서비스 A 와 서비스 B 파드를 같은 영역에 함께 위치시키는 것" 이고, `preferredDuringSchedulingIgnoredDuringExecution` 안티-어피니티의 예시는 서비스를 여러 영역에 걸쳐서 분배한다

(엄격한 요구사항은 영역보다 파드가 더 많기 때문에 엄격한 요구사항은 의미가 없다).

(a hard requirement wouldn't make sense, since you probably have more pods than zones).

이 부분은 영역보다 파드가 더 많을 수 있기 때문에 로 해석하는게 어떨까요?

ysyukr · 2020-02-01T19:26:54Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+`requiredDuringSchedulingIgnoredDuringExecution` 어피니티의 예시는 "서비스 A와 서비스 B는 서로 많은 통신을 하기 때문에 각 서비스의 파드들을 동일한 영역에 위치시킨다."이고 `preferredDuringSchedulingIgnoredDuringExecution` 안티 어피니티의 예시는 "서비스를 여러 영역에 걸처 퍼트린다"가 될 것이다
+(엄격한 제약조건은 파드가 영역의 수보다 많을 수 있기 때문에 말이 안된다).
+
+파드간 어피니티는 파드 스펙에서 `affinity` 필드의 `podAffinity` 필드에서 지정할 수 있다. 그리고 파드간 안티-어피니티는 파드 스펙에서 `affinity` 필드의 `podAntiAffinity` 필드에서 지정할 수 있다.


좀 더 자연스럽게 다듬었습니다.

Suggested change

파드간 어피니티는 파드 스펙에서 `affinity` 필드의 `podAffinity` 필드에서 지정할 수 있다. 그리고 파드간 안티-어피니티는 파드 스펙에서 `affinity` 필드의 `podAntiAffinity` 필드에서 지정할 수 있다.

파드간 어피니티는 PodSpec에서 `affinity` 필드 중 `podAffinity` 필드로 지정한다. 그리고 파드간 안티-어피니티는 PodSpec에서 `affinity` 필드 중 `podAntiAffinity` 필드로 지정한다.

ysyukr · 2020-02-01T22:35:44Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+`nodeName` 노드 셀렉션을 하는 가장 간단한 형태이지만 자체의 한계때문에 일반적으로 사용하지는 않는다. 
+`nodeName`은 파드 스펙의 필드이다. 비어있지 않다면 스케쥴러는 이 파트를 무시하게 되고 해당되는 노드에서 동작중인 kubelet이 파드를 실행하려 할 것이다. 
+따라서 `nodeName`이 파드 스펙에 제공되면 노드 셀렉션에 대한 위의 방법들 중 가장 우선시된다.


조금 더 자연스럽게 다듬었습니다.

Suggested change

`nodeName` 노드 셀렉션을 하는 가장 간단한 형태이지만 자체의 한계때문에 일반적으로 사용하지는 않는다.

`nodeName`은 파드 스펙의 필드이다. 비어있지 않다면 스케쥴러는 이 파트를 무시하게 되고 해당되는 노드에서 동작중인 kubelet이 파드를 실행하려 할 것이다.

따라서 `nodeName`이 파드 스펙에 제공되면 노드 셀렉션에 대한 위의 방법들 중 가장 우선시된다.

`nodeName` 은 가장 간단한 형태의 노드 선택 제약 조건이지만, 한계로 인해 일반적으로는 사용하지 않는다.

`nodeName` 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는 파드를 무시하고 명명된 노드에서 실행 중인 kubelet이 파드를 실행하려고 한다.

따라서 만약 PodSpec에 `nodeName` 가 제공된 경우, 노드 선택을 위해 위의 방법보다 우선한다.

ysyukr · 2020-02-01T22:37:05Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+`nodeName`은 파드 스펙의 필드이다. 비어있지 않다면 스케쥴러는 이 파트를 무시하게 되고 해당되는 노드에서 동작중인 kubelet이 파드를 실행하려 할 것이다. 
+따라서 `nodeName`이 파드 스펙에 제공되면 노드 셀렉션에 대한 위의 방법들 중 가장 우선시된다.
+
+`nodeName`으로 노드를 선택하는 것의 제약사항이 몇가지 있다:


조금 더 자연스럽게 다듬었습니다.

Suggested change

`nodeName`으로 노드를 선택하는 것의 제약사항이 몇가지 있다:

`nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.

ysyukr · 2020-02-01T22:40:21Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+-		그 이름을 가진 노드가 없을 경우 파드는 실행되지 않을 것이고 몇몇 경우에는 자동으로 삭제된다.
+-		그 이름을 가진 노드가 파드를 실행하기 위한 충분한 리소스가 없는 경우 파드의 실행은 실패하고 OutOfmemory 또는 OutOfcpu와 같은 이유를 나타낼 것이다.
+-		클라우드 환경에서의 노드 이름은 항상 예측이 가능하거나 안정적인 것이 아니다.
+
+`nodeName` 필드를 사용한 파드 설정 파일의 예시이다:


좀 더 자연스럽고 원문을 반영했습니다.

Suggested change

- 그 이름을 가진 노드가 없을 경우 파드는 실행되지 않을 것이고 몇몇 경우에는 자동으로 삭제된다.

- 그 이름을 가진 노드가 파드를 실행하기 위한 충분한 리소스가 없는 경우 파드의 실행은 실패하고 OutOfmemory 또는 OutOfcpu와 같은 이유를 나타낼 것이다.

- 클라우드 환경에서의 노드 이름은 항상 예측이 가능하거나 안정적인 것이 아니다.

`nodeName` 필드를 사용한 파드 설정 파일의 예시이다:

- 만약 명명된 노드가 없으면, 파드가 실행되지 않고 따라서 자동으로 삭제될 수 있다.

- 만약 명명된 노드에 파드를 수용할 수 있는 리소스가 없는 경우 파드가 실패하고, 그 이유는 다음과 같이 표시된다. 예: OutOfmemory 또는 OutOfcpu.

- 클라우드 환경의 노드 이름은 항상 예측 가능하거나 안정적인 것은 아니다.

여기에 `nodeName` 필드를 사용하는 파드 설정 파일 예시가 있다.

ysyukr · 2020-02-01T22:40:45Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+  nodeName: kube-01
+```
+
+우의 파드는 kube-01 노드에서 동작할 것이다.


Suggested change

우의 파드는 kube-01 노드에서 동작할 것이다.

위 파드는 kube-01 노드에서 실행될 것이다.

ysyukr · 2020-02-01T22:44:44Z

content/ko/docs/concepts/configuration/assign-pod-node.md

+[테인트(Taints)](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다.
+
+[노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서는 이 기능들에 대한 추가적인 배경 정보를 포함한다.
+
+파드가 노드에 할당되고 나면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다. 
+[토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 노드 레벨의 리소스 할당 결정의 일부분이 될 수 있다.


조금 더 자연스럽게 다듬었습니다.

Suggested change

[테인트(Taints)](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다.

[노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서는 이 기능들에 대한 추가적인 배경 정보를 포함한다.

파드가 노드에 할당되고 나면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.

[토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 노드 레벨의 리소스 할당 결정의 일부분이 될 수 있다.

[테인트(Taints)](/docs/concepts/configuration/taint-and-toleration/)는 노드가 파드 집합을 *쫓아내게* 할 수 있다.

[노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md) 와 [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는 이러한 기능에 대한 추가 배경 정보가 있다.

파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.

[토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 노드 수준의 리스소 할당 결정에 참여할 수 있다.

ysyukr · 2020-02-01T23:03:36Z

라인 및 리뷰사항 업데이트가 완료되시면, dev-1.17-ko.4 브랜치로 리베이스 부탁드리겠습니다.

… dev-1.17-ko.3

k8s-ci-robot · 2020-02-02T10:36:00Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign rajakavitha1
You can assign the PR to them by writing /assign @rajakavitha1 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

KimMJ · 2020-02-02T10:40:54Z

rebase 실수해서 다시 올리도록 PR 올리도록 하겠습니다 :(

- issue kubernetes#18108 - regenerate PR kubernetes#18845

* translate assign-pod-node.md - issue #18108 - regenerate PR #18845 * erase spaces and fix translation * fix typo for assign-pod-node.md * fix typo for assign-pod-node.md * update suggestions in assign-pod-node kor. * fix typo in assign-pod-node ko.

ysyukr and others added 3 commits January 13, 2020 19:19

Changed some words in the IPv4/IPv6 dual-stack korean doc. (#18668)

7eafd6e

`송신` -> `이그레스` `위장` -> `마스커레이딩` from #18666 /language ko

translate assign-pod-node.md

1d756c8

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 24, 2020

k8s-ci-robot requested review from ianychoi and seokho-son January 24, 2020 11:33

k8s-ci-robot added language/ko Issues or PRs related to Korean language sig/docs Categorizes an issue or PR as relevant to SIG Docs. labels Jan 24, 2020

k8s-ci-robot assigned ysyukr Jan 29, 2020

ysyukr reviewed Jan 30, 2020

View reviewed changes

claudiajkang force-pushed the dev-1.17-ko.3 branch 2 times, most recently from 2102a06 to f42a592 Compare January 30, 2020 14:07

KimMJ added 3 commits February 2, 2020 03:43

comment 1차 반영

e81689d

띄어쓰기 수정

c3426bb

라인 정리

ff6b72c

ysyukr reviewed Feb 1, 2020

View reviewed changes

KimMJ added 6 commits February 2, 2020 17:25

commnet 2차 반영

6cbd815

translate assign-pod-node.md

a920f58

comment 1차 반영

331a599

띄어쓰기 수정

92a29d8

라인 정리

d3483b8

commnet 2차 반영

dca6210

Merge branch 'dev-1.17-ko.3' of https://github.com/KimMJ/website into…

a546662

… dev-1.17-ko.3

k8s-ci-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Feb 2, 2020

KimMJ changed the base branch from dev-1.17-ko.3 to dev-1.17-ko.4 February 2, 2020 10:39

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Feb 2, 2020

KimMJ closed this Feb 2, 2020

KimMJ added a commit to KimMJ/website that referenced this pull request Feb 2, 2020

translate assign-pod-node.md

5ec5efb

- issue kubernetes#18108 - regenerate PR kubernetes#18845

KimMJ mentioned this pull request Feb 2, 2020

translate assign-pod-node.md #18955

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Translate concepts/configuration/assign-pod-node.md in Korean #18845

Translate concepts/configuration/assign-pod-node.md in Korean #18845

KimMJ commented Jan 24, 2020

k8s-ci-robot commented Jan 24, 2020

KimMJ commented Jan 24, 2020

netlify bot commented Jan 24, 2020

ysyukr commented Jan 28, 2020

gochist commented Jan 29, 2020

ysyukr commented Jan 29, 2020 •

edited

Loading

ysyukr left a comment

ysyukr Jan 29, 2020

ysyukr Jan 29, 2020

ysyukr Jan 29, 2020

ysyukr Jan 29, 2020

ysyukr Jan 29, 2020

ysyukr Jan 30, 2020

ysyukr Jan 30, 2020

ysyukr Jan 30, 2020

ysyukr Jan 30, 2020

ysyukr Jan 30, 2020

ysyukr left a comment •

edited

Loading

ysyukr Jan 30, 2020

ysyukr Jan 30, 2020

ysyukr Jan 30, 2020

ysyukr Feb 1, 2020

KimMJ Feb 2, 2020

ysyukr Feb 1, 2020

ysyukr Feb 1, 2020

ysyukr Feb 1, 2020

ysyukr Feb 1, 2020

ysyukr Feb 1, 2020

ysyukr Feb 1, 2020

ysyukr commented Feb 1, 2020

k8s-ci-robot commented Feb 2, 2020

KimMJ commented Feb 2, 2020


		{{% capture overview %}}

		{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드" term_id="node" >}}에서만 동작하도록 하거나 특정 노드를 선호하도록 제한할 수 있다.

	이를 위해서는 몇가지 방법이 있는데 그 중 하나는 선택 시 [레이블 셀렉터(label selector)](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하는 것이다.
	이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다.


		## 노드 셀렉터(nodeSelector)

		`nodeSelector`는 가장 간단하고 추천하는 형식의 노드 선택 제약이다.

	`nodeSelector`는 가장 간단하고 추천하는 형식의 노드 선택 제약이다.
	`nodeSelector` 는 가장 간단하고 권장하는 노드 선택 제약 조건의 형태이다.

		노드 어피니티는 파드 스펙에서 `affinity`필드 내의 `nodeAffinity` 필드에서 지정된다.

		노드 어피니티를 사용하는 파드의 예시이다:

		이 노드 어피니티 규칙은 파드가 `kubernetes.io/e2e-az-name`가 키고 값이 `e2e-az1` 또는 `e2e-az2`인 레이블을 가진 노드에서만 동작할 수 있도록 하는 것이다.
		추가적으로 이러한 규칙을 만족하는 노드들 중에서 `another-node-label-key`가 키이고 값이 `another-node-label-value`인 레이블을 가진 노드를 선호하도록 되어있다.

		파드간 어피니티와 안티-어피니티는 상당한 양의 연산을 필요로 하여 큰 클러스터에서는 스케쥴링을 상당히 느리게 할 수 있다.
		수백개의 노드가 넘는 클러스터에서 이를 사용하는 것은 추천하지 않는다.

	파드 안티-어피니티는 노드가 일관적으로 레이블을 가지고 있어야 함을 전제로 한다. 예를들어 클러스터의 모든 노드는 `topologyKey`와 매칭되는 적절한 레이블을 가지고 있어야 한다. 일부 또는 모든 노드가 지정된 `topologyKey` 레이블이 없다면 이는 의도치 않은 동작을 일으킬 수 있다.
	파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. 즉, 클러스터의 모든 노드는 `topologykey` 와 매칭되는 적절한 레이블이 있어야 한다. 일부 또는 모든 노드에 지정된 `topologyKey` 레이블이 없는 경우에는 의도하지 않은 동작이 발생할 수 있다.

	파드간 어피니티는 파드 스펙에서 `affinity` 필드의 `podAffinity` 필드에서 지정할 수 있다. 그리고 파드간 안티-어피니티는 파드 스펙에서 `affinity` 필드의 `podAntiAffinity` 필드에서 지정할 수 있다.
	파드간 어피니티는 PodSpec에서 `affinity` 필드 중 `podAffinity` 필드로 지정한다. 그리고 파드간 안티-어피니티는 PodSpec에서 `affinity` 필드 중 `podAntiAffinity` 필드로 지정한다.

	`nodeName`으로 노드를 선택하는 것의 제약사항이 몇가지 있다:
	`nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.

	우의 파드는 kube-01 노드에서 동작할 것이다.
	위 파드는 kube-01 노드에서 실행될 것이다.

Translate concepts/configuration/assign-pod-node.md in Korean #18845

Translate concepts/configuration/assign-pod-node.md in Korean #18845

Conversation

KimMJ commented Jan 24, 2020

k8s-ci-robot commented Jan 24, 2020

KimMJ commented Jan 24, 2020

netlify bot commented Jan 24, 2020

ysyukr commented Jan 28, 2020

gochist commented Jan 29, 2020

ysyukr commented Jan 29, 2020 • edited Loading

ysyukr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ysyukr left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ysyukr commented Feb 1, 2020

k8s-ci-robot commented Feb 2, 2020

KimMJ commented Feb 2, 2020

ysyukr commented Jan 29, 2020 •

edited

Loading

ysyukr left a comment •

edited

Loading