whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

First Korean l10n work for release-1.19

Browse Source 
- Translate tasks/job/parallel-processing-expansion.md into Korean (#23544)
- Fix issue with ko/docs/concepts/workloads/controllers/job.md (#23720)
- Translate reference/scheduling/policies.md in Korean (#23690)
- Update outdated files in the dev-1.19-ko.1 branch (#23702)
- Modify translation access by Korean glossary (#23627)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: junghyeonsu <54893898+junghyeonsu@users.noreply.github.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
This commit is contained in:
June Yi
2020-09-11 23:21:22 +09:00
parent 94b2f857bb
commit 986be3462d
102 changed files with 1943 additions and 2452 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/controllers/daemonset.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: 데몬셋
content_type: concept
weight: 50
weight: 40
---
<!-- overview -->
content/ko/docs/concepts/workloads/controllers/deployment.md
+6 -6
View File
@@ -6,7 +6,7 @@ feature:
쿠버네티스는 애플리케이션 또는 애플리케이션의 설정 변경시 점진적으로 롤아웃하는 동시에 애플리케이션을 모니터링해서 모든 인스턴스가 동시에 종료되지 않도록 보장한다. 만약 어떤 문제가 발생하면 쿠버네티스는 변경 사항을 롤백한다. 성장하는 디플로이먼트 솔루션 생태계를 이용한다.
content_type: concept
weight: 30
weight: 10
---
<!-- overview -->
@@ -82,7 +82,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다.
```shell
```
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
@@ -98,21 +98,21 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다.
다음과 유사하게 출력된다.
```shell
```
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다.
다음과 유사하게 출력된다.
```shell
```
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다.
5. 디플로이먼트로 생성된 레플리카셋(`rs`)을 보려면, `kubectl get rs` 를 실행한다. 다음과 유사하게 출력된다.
```shell
```
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
@@ -129,7 +129,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
6. 각 파드에 자동으로 생성된 레이블을 보려면, `kubectl get pods --show-labels` 를 실행한다.
다음과 유사하게 출력된다.
```shell
```
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: 가비지(Garbage) 수집
content_type: concept
weight: 70
weight: 60
---
<!-- overview -->
content/ko/docs/concepts/workloads/controllers/job.md
+4 -6
View File
@@ -1,11 +1,11 @@
---
title: 잡 - 실행부터 완료까지
title: 잡
content_type: concept
feature:
title: 배치 실행
description: >
쿠버네티스는 서비스 외에도 배치와 CI 워크로드를 관리할 수 있으며, 원하는 경우 실패한 컨테이너를 교체할 수 있다.
weight: 70
weight: 50
---
<!-- overview -->
@@ -116,6 +116,7 @@ kubectl logs $pods
`.spec.template` 은 `.spec` 의 유일한 필수 필드이다.
`.spec.template` 은 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 `apiVersion` 또는 `kind` 가 없다는 것을 제외한다면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 같은 스키마를 가지고 있다.
추가로 파드의 필수 필드 외에도 잡의 파드 템플릿은 적절한
@@ -129,7 +130,7 @@ kubectl logs $pods
[자신의 파드 셀렉터를 지정하기](#자신의-파드-셀렉터를-지정하기) 섹션을 참고한다.
### 병렬 잡
### 잡에 대한 병렬 실행 {#parallel-jobs}
잡으로 실행하기에 적합한 작업 유형은 크게 세 가지가 있다.
@@ -212,9 +213,6 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프
카운트가 재설정된다.
{{< note >}}
1.12 이전 버전의 쿠버네티스 버전에 대해 여전히 [#54870](https://github.com/kubernetes/kubernetes/issues/54870) 이슈가 있다.
{{< /note >}}
{{< note >}}
만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에
도달하면 잡을 실행 중인 컨테이너가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
content/ko/docs/concepts/workloads/controllers/replicaset.md
+4 -3
View File
@@ -1,7 +1,7 @@
---
title: 레플리카셋
content_type: concept
weight: 10
weight: 20
---
<!-- overview -->
@@ -241,9 +241,10 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)이다.
[앞서](#레플리카-셋의-작동-방식) 논의한 것처럼 이 레이블은 소유될 가능성이 있는 파드를 식별하는데 사용된다.
우리 `frontend.yaml` 예제에서의 셀렉터는 다음과 같다.
```shell
```yaml
matchLabels:
tier: frontend
tier: frontend
```
레플리카셋에서 `.spec.template.metadata.labels`는 `spec.selector`과 일치해야 하며
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+17 -17
View File
@@ -7,7 +7,7 @@ feature:
오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다.
content_type: concept
weight: 20
weight: 90
---
<!-- overview -->
@@ -112,20 +112,20 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
레플리케이션 컨트롤러 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/).
컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다.
레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
### 파드 템플릿
`.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿) 이다. 정확하게 {{< glossary_tooltip text="파드" term_id="pod" >}} 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 정확하게 {{< glossary_tooltip text="파드" term_id="pod" >}} 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와
중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라.
오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 만 허용되며, 특별히 지정되지 않으면 기본값이다.
오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)만 허용되며, 특별히 지정되지 않으면 기본값이다.
로컬 컨테이너의 재시작의 경우, 레플리케이션 컨트롤러는 노드의 에이전트에게 위임한다.
예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) 혹은 도커이다.
@@ -139,7 +139,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
### 파드 셀렉터
`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나
삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고
레플리케이션 컨트롤러를 교체할 수 있다.
@@ -181,14 +181,14 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적
해당 파드에 영향을 주지 않고 레플리케이션 컨트롤러를 삭제할 수 있다.
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 에 옵션으로 `--cascade=false`를 지정하라.
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라.
REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 레플리케이션 컨트롤러 오브젝트를 삭제하라.
원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면,
새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
새로운 파드 템플릿과 일치시키려는 노력은 하지 않을 것이다.
새로운 spec에 대한 파드를 제어된 방법으로 업데이트하려면 [롤링 업데이트](#롤링-업데이트) 를 사용하라.
새로운 spec에 대한 파드를 제어된 방법으로 업데이트하려면 [롤링 업데이트](#롤링-업데이트)를 사용하라.
### 레플리케이션 컨트롤러에서 파드 격리
@@ -208,7 +208,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
레플리케이션 컨트롤러는 파드를 하나씩 교체함으로써 서비스에 대한 롤링 업데이트를 쉽게 하도록 설계되었다.
[#1353](https://issue.k8s.io/1353) 에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다.
[#1353](https://issue.k8s.io/1353)에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다.
이상적으로 롤링 업데이트 컨트롤러는 애플리케이션 준비 상태를 고려하며 주어진 시간에 충분한 수의 파드가 생산적으로 제공되도록 보장할 것이다.
@@ -229,15 +229,15 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
## 레플리케이션을 위한 프로그램 작성
레플리케이션 컨트롤러에 의해 생성된 파드는 해당 구성이 시간이 지남에 따라 이질적이 될 수 있지만 균일하고 의미상 동일하도록 설계되었다. 이는 레플리카된 상태 스테이트리스 서버에 적합하지만 레플리케이션 컨트롤러를 사용하여 마스터 선출, 샤드 및 워크-풀 애플리케이션의 가용성을 유지할 수도 있다. [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html) 와 같은 애플리케이션은 안티패턴으로 간주되는 각 파드의 구성에 대한 정적/일회성 사용자 정의와 반대로 동적 작업 할당 메커니즘을 사용해야 한다. 리소스의 수직 자동 크기 조정 (예 : CPU 또는 메모리)과 같은 수행된 모든 파드 사용자 정의는 레플리케이션 컨트롤러 자체와 달리 다른 온라인 컨트롤러 프로세스에 의해 수행되어야 한다.
레플리케이션 컨트롤러에 의해 생성된 파드는 해당 구성이 시간이 지남에 따라 이질적이 될 수 있지만 균일하고 의미상 동일하도록 설계되었다. 이는 레플리카된 상태 스테이트리스 서버에 적합하지만 레플리케이션 컨트롤러를 사용하여 마스터 선출, 샤드 및 워크-풀 애플리케이션의 가용성을 유지할 수도 있다. [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)와 같은 애플리케이션은 안티패턴으로 간주되는 각 파드의 구성에 대한 정적/일회성 사용자 정의와 반대로 동적 작업 할당 메커니즘을 사용해야 한다. 리소스의 수직 자동 크기 조정 (예 : CPU 또는 메모리)과 같은 수행된 모든 파드 사용자 정의는 레플리케이션 컨트롤러 자체와 달리 다른 온라인 컨트롤러 프로세스에 의해 수행되어야 한다.
## 레플리케이션 컨트롤러의 책임
레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다.
레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된) 가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019)) 을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170)) 까지도 고려해야 한다.
레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된)가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019))을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170))까지도 고려해야 한다.
레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) 와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
## API 오브젝트
@@ -250,14 +250,14 @@ API 오브젝트에 대한 더 자세한 것은
### 레플리카셋
[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건)이다.
이것은 주로 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
### 디플로이먼트 (권장되는)
[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
[`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
### 베어 파드
@@ -266,12 +266,12 @@ API 오브젝트에 대한 더 자세한 것은
### 잡
자체적으로 제거될 것으로 예상되는 파드 (즉, 배치 잡)의 경우
레플리케이션 컨트롤러 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라.
레플리케이션 컨트롤러 대신 [`Job`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라.
### 데몬셋
머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신
[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
[`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
content/ko/docs/concepts/workloads/controllers/statefulset.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: 스테이트풀셋
content_type: concept
weight: 40
weight: 30
---
<!-- overview -->
content/ko/docs/concepts/workloads/pods/_index.md
+1 -1
View File
@@ -255,7 +255,7 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
* [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
* [PodDisruptionBudget](https://kubernetes.io/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
* 파드는 쿠버네티스 REST API의 최상위 리소스이다.
[파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
오브젝트 정의는 오브젝트를 상세히 설명한다.
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+3 -3
View File
@@ -45,7 +45,7 @@ ID([UID](/ko/docs/concepts/overview/working-with-objects/names/#uids))가
상대적으로 일회용인 파드 인스턴스를 관리하는 작업을 처리한다.
UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되지 않는다. 대신,
해당 파드는 사용자가 원하는 이름은 같지만, UID가 다른, 거의 동일한 새 파드로
해당 파드는 사용자가 원한다면 이름은 같지만, UID가 다른, 거의 동일한 새 파드로
대체될 수 있다.
{{< glossary_tooltip term_id="volume" text="볼륨" >}}과
@@ -118,7 +118,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
### `Running` {#container-state-running}
`Running` 상태는 컨테이너가 문제없이 실행되고 있음을 나타낸다. `postStart` 훅이
구성되어 있었다면, 이미 실행이 완료되었다. `kubectl` 을
구성되어 있었다면, 이미 실행되고 완료되었다. `kubectl` 을
사용하여 컨테이너가 `Running` 인 파드를 쿼리하면, 컨테이너가 `Running` 상태에 진입한 시기에 대한
정보도 볼 수 있다.
@@ -341,7 +341,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
적용되면, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 정상
종료를 시도한다.
일반적으로, 컨테이너 런타임은 TERM 시그널을 각 컨테이너의 기본 프로세스로
일반적으로, 컨테이너 런타임은 각 컨테이너의 기본 프로세스에 TERM 신호를
전송한다. 일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
전송되고, 그런 다음 파드는
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}로부터 삭제된다. 프로세스가
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+57 -21
View File
@@ -6,8 +6,6 @@ weight: 40
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
@@ -16,13 +14,6 @@ weight: 40
## 필수 구성 요소
### 기능 게이트 활성화
를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와**
{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해
`EvenPodsSpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
활성화되어야 한다.
### 노드 레이블
토폴로지 분배 제약 조건은 노드 레이블을 의지해서 각 노드가 속한 토폴로지 도메인(들)을 인식한다. 예를 들어, 노드에 다음과 같은 레이블을 가지고 있을 수 있다. `node=node1,zone=us-east-1a,region=us-east-1`
@@ -53,7 +44,7 @@ node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
### API
`pod.spec.topologySpreadConstraints` 필드는 1.16에서 다음과 같이 도입되었다.
API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다.
```
apiVersion: v1
@@ -70,7 +61,15 @@ spec:
사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다.
- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. 이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는 파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야 한다.
- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는
파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야
한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
- `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 사이에
허용되는 최대 차이이다.
- `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
- **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
- **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다.
- `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
@@ -186,7 +185,7 @@ spec:
### 클러스터 수준의 기본 제약 조건
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본
토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.
@@ -194,7 +193,7 @@ spec:
- `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서
기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서
`PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
@@ -203,7 +202,7 @@ spec:
예시 구성은 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1alpha2
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
@@ -212,18 +211,49 @@ profiles:
args:
defaultConstraints:
- maxSkew: 1
topologyKey: failure-domain.beta.kubernetes.io/zone
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
```
{{< note >}}
기본 스케줄링 제약 조건에 의해 생성된 점수는
[`DefaultPodTopologySpread` 플러그인](/docs/reference/scheduling/profiles/#scheduling-plugins)에
[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에
의해 생성된 점수와 충돌 할 수 있다.
`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
이 플러그인을 비활성화 하는 것을 권장한다.
{{< /note >}}
#### 내부 기본 제약
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
`DefaultPodTopologySpread` 기능 게이트를 활성화하면, 기존
`SelectorSpread` 플러그인이 비활성화된다.
kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은
기본 토폴로지 제약 조건을 사용한다.
```yaml
defaultConstraints:
- maxSkew: 3
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: ScheduleAnyway
- maxSkew: 5
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
```
또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인이
비활성화된다.
{{< note >}}
노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는
대신 자체 제약 조건을 정의한다.
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
없는 노드에 점수를 매기지 않는다.
{{< /note >}}
## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교
쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
@@ -234,13 +264,19 @@ profiles:
- `PodAntiAffinity` 로는, 단일 토폴로지 도메인에
단 하나의 파드만 스케줄 될 수 있다.
"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서
고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 참조한다.
더 세밀한 제어를 위해, 토폴로지 분배 제약 조건을 지정하여 다양한 토폴로지 도메인에 파드를
분배해서 고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을
제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
더 자세한 내용은
[모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를
참고한다.
## 알려진 제한사항
1.18을 기준으로 이 기능은 베타(Beta)이며, 몇 가지 알려진 제한사항이 있다.
- 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다.
- 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
## {{% heading "whatsnext" %}}
- [블로그: PodTopologySpread 소개](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/)에서는
`maxSkew` 에 대해 자세히 설명하고, 몇 가지 고급 사용 예제를 제공한다.