Merge pull request #29998 from kubernetes/dev-1.22-ko.1

[ko] 1st Korean localization work for v1.22
2021-10-09 06:54:36 -07:00
parent 1cd35c2a42 14e5fe697f
commit 38be851062
105 changed files with 3053 additions and 648 deletions
@@ -36,9 +36,10 @@ kube-controller-manager 컨테이너에 설정된 시간대는

 ## 크론잡

-크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인
-작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을
-스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다.
+크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다. 
+각 작업은 무기한 반복되도록 구성해야 한다(예: 
+1일/1주/1달마다 1회). 
+작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다.

 ### 예시

@@ -229,5 +229,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를

 파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
 업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
-디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
-다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
+디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면, 
+파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
+
+예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
@@ -6,6 +6,18 @@ weight: 60

 <!-- overview -->

+
+{{< note >}}
+이 한글 문서는 더 이상 관리되지 않습니다.
+
+이 문서의 기반이 된 영어 원문은 삭제되었으며,
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
+
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
+이 문서는 삭제될 수 있습니다.
+{{< /note >}}
+
+
 쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
 소유자가 없는 오브젝트들을 삭제하는 역할을 한다.

@@ -187,14 +187,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고

 ### 완료 모드

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
-
-{{< note >}}
-인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
-및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
-`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다.
-{{< /note >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

 완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
 `.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
@@ -203,8 +196,14 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
  완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드
  완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는
  잡은 암시적으로 `NonIndexed` 이다.
- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index`
-  어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다.
+- `Indexed`: 잡의 파드는 연결된 완료 인덱스를 0에서 `.spec.completions-1` 까지 
+  가져온다. 이 인덱스는 다음의 세 가지 메카니즘으로 얻을 수 있다.
+  - 파드 어노테이션 `batch.kubernetes.io/job-completion-index`.
+  - 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태). 인덱스된(Indexed) 잡과 
+    {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 
+    있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 
+    호스트네임을 사용할 수 있다.
+  - 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
  각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
  간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
  [정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@@ -255,7 +254,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고

 ## 잡의 종료와 정리

-잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다.  이를 유지하면
+잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다.  
+이를 유지하면
 완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
 잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
 `kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.
@@ -402,14 +402,12 @@ spec:

 ### 잡 일시 중지

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

 {{< note >}}
-잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을
-사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
-및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
-`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다.
+이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며, 
+이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다. 
+[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다.
 {{< /note >}}

 잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
@@ -568,6 +566,46 @@ spec:
 `manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
 불일치를 허용한다.

+### 종료자(finalizers)를 이용한 잡 추적
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+{{< note >}}
+이 기능을 이용하기 위해서는 
+[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와 
+[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해 
+`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 
+기본적으로는 비활성화되어 있다.
+
+이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. 
+기존에 존재하던 잡은 영향을 받지 않는다. 
+사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
+{{< /note >}}
+
+이 기능이 활성화되지 않으면, 잡 
+{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 
+`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다. 
+그런데, 파드는 다음과 같은 이유로 제거될 수 있다.
+- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거
+- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를 
+  일정 임계값 이후에 제거
+- 잡에 속한 파드를 사용자가 임의로 제거
+- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나 
+  교체
+
+클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면, 
+컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고 
+API 서버에서 파드가 제거되면 이를 알아챈다. 
+이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다. 
+컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로, 
+이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다.
+
+잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다. 
+이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다. 
+잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여, 
+잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다. 
+이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**.
+
 ## 대안

 ### 베어(Bare) 파드
@@ -594,7 +632,7 @@ spec:
 시작하기에는 다소 복잡할 수 있으며 쿠버네티스와의 통합성이 낮아진다.

 이 패턴의 한 예시는 파드를 시작하는 잡이다. 파드는 스크립트를 실행해서
-스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)를 본다)를 시작하고,
+스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)를 본다)를 시작하고,
 스파크 드라이버를 실행한 다음, 정리한다.

 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
@@ -323,9 +323,9 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.

 ### 파드 삭제 비용
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

-[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 
+[`controller.kubernetes.io/pod-deletion-cost`](/ko/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 
 레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다.

 이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다.
@@ -335,9 +335,9 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다.
 유효하지 않은 값은 API 서버가 거부한다.

-이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다. 
-kube-apiserver와 kube-controller-manager에서 `PodDeletionCost` 
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다.
+이 기능은 베타 상태이며 기본적으로 활성화되어 있다. 
+kube-apiserver와 kube-controller-manager에 대해 `PodDeletionCost` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다.

 {{< note >}}
 - 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.
@@ -32,7 +32,7 @@ weight: 30

 ## 제한사항

-* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
+* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
 * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
 * 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
 * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
@@ -223,27 +223,31 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가

 ## 업데이트 전략

-쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
+스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
 파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를
-구성하거나 비활성화 할 수 있다.
+구성하거나 비활성화할 수 있다. 두 가지 가능한 전략이 있다.

-### 삭제 시(On Delete)
-
-`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의
-`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는
-스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의
+`OnDelete`(삭제시)
+: 스테이트풀셋의 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 
+스테이트풀셋 컨트롤러는 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 
+사용자는 컨트롤러가 스테이트풀셋의
 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.

-### 롤링 업데이트
+`RollingUpdate`(롤링 업데이트)
+: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
+구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.

-`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
-구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
-스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이
-순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지),
-각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될
-때까지 기다린다.
+## 롤링 업데이트

-#### 파티션(Partition)
+스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
+스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성한다. 이 과정에서 똑같이
+순차적으로 파드가 종료되고(가장 큰 순서 색인에서부터에서 작은 순서 색인쪽으로),
+각 파드의 업데이트는 한 번에 하나씩 한다.
+
+쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
+`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
+
+### 파티션 롤링 업데이트 {#partitions}

 `롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition`
 를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가
@@ -255,7 +259,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.

-#### 강제 롤백
+### 강제 롤백

 기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
 함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우
@@ -273,8 +277,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가

 템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로
 실행하려고 시도한 모든 파드를 삭제해야 한다.
-그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다.
+그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다.

+### 최소 준비 시간 초 {#minimum-ready-seconds}
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록 
+컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
+기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
+파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
+[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
+
+이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.

 ## {{% heading "whatsnext" %}}