Merge pull request #30203 from gochist/ko-controllers

[ko] Update concepts/workloads/controllers

Author: k8s-ci-robot

content/ko/docs/concepts/workloads/controllers/cron-jobs.md

@@ -17,6 +17,8 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="
 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다.
 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
 
+추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=<time zone>"을 추가해서 타임존을 명기할 수 있으며, 항상 `CRON_TZ`를 설정하는 것을 권장한다.
+
 {{< caution >}}
 모든 **크론잡** `일정:` 시간은
 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다.
@@ -53,15 +55,16 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 ### 크론 스케줄 문법
 
 ```
-# ┌───────────── 분 (0 - 59)
-# │ ┌───────────── 시 (0 - 23)
-# │ │ ┌───────────── 일 (1 - 31)
-# │ │ │ ┌───────────── 월 (1 - 12)
-# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
-# │ │ │ │ │                                   특정 시스템에서는 7도 일요일)
-# │ │ │ │ │
-# │ │ │ │ │
-# * * * * *
+#      ┌────────────────── 타임존 (옵션)
+#      |      ┌───────────── 분 (0 - 59)
+#      |      │ ┌───────────── 시 (0 - 23)
+#      |      │ │ ┌───────────── 일 (1 - 31)
+#      |      │ │ │ ┌───────────── 월 (1 - 12)
+#      |      │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
+#      |      │ │ │ │ │                           특정 시스템에서는 7도 일요일)
+#      |      │ │ │ │ │
+#      |      │ │ │ │ │
+# CRON_TZ=UTC * * * * *
 ```
 
 
@@ -74,9 +77,9 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 | @hourly 									| 매시 0분에 시작                          								       | 0 * * * * 		|
 
 
-예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
+예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
 
-`0 0 13 * 5`
+`CRON_TZ=UTC 0 0 13 * 5`
 
 크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
 
@@ -132,8 +135,14 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
 
 ## {{% heading "whatsnext" %}}
 
-[크론 표현 포맷](https://ko.wikipedia.org/wiki/Cron)은
-크론잡 `schedule` 필드의 포맷을 문서화 한다.
-
-크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
-예는 [크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
+* 크론잡이 의존하고 있는 [파드](/ko/docs/concepts/workloads/pods/)와
+  [잡](/ko/docs/concepts/workloads/controllers/job/) 두 개념에
+  대해 배운다.
+* 크론잡 `.spec.schedule` 필드의 [형식](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)에
+  대해서 읽는다.
+* 크론잡을 생성하고 다루기 위한 지침 및
+  크론잡 매니페스트의 예제로
+  [크론잡으로 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 읽는다.
+* `CronJob`은 쿠버네티스 REST API의 일부이다.
+  {{< api-reference page="workload-resources/cron-job-v1" >}}
+  오브젝트 정의를 읽고 쿠버네티스 크론잡 API에 대해 이해한다.

content/ko/docs/concepts/workloads/controllers/daemonset.md

@@ -185,7 +185,7 @@ nodeAffinity:
 필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는
 다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다.
 
-사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면
+사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=orphan` 를 명시하면
 파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면,
 새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은
 `updateStrategy` 에 따라 파드를 교체한다.
@@ -213,7 +213,7 @@ nodeAffinity:
 어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를
 생성하는 것보다는 데몬 셋을 사용해야 한다.
 
-### 스태틱(static) 파드
+### 스태틱(static) 파드 {#static-pods}
 
 Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
 [스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
@@ -233,3 +233,21 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
 
 예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
+
+## {{% heading "whatsnext" %}}
+
+* [파드](/ko/docs/concepts/workloads/pods/)에 대해 배운다.
+  * 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}
+    컴포넌트를 기동하는데 유용한
+    [스태틱 파드](#static-pods)에 대해 배운다. 
+* 데몬셋을 어떻게 사용하는지 알아본다.
+  * [데몬셋 롤링 업데이트 수행하기](/ko/docs/tasks/manage-daemon/update-daemon-set/)
+  * [데몬셋 롤백하기](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)
+    (예를 들어, 롤 아웃이 예상대로 동작하지 않은 경우).
+* [쿠버네티스가 파드를 노드에 할당하는 방법](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 이해한다.
+* 데몬셋으로 구동되곤 하는, [디바이스 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)과
+  [애드온](/ko/docs/concepts/cluster-administration/addons/)에 대해 배운다.
+* `DaemonSet`은 쿠버네티스 REST API에서 상위-수준 리소스이다.
+  데몬셋 API에 대해 이해하기 위해 
+  {{< api-reference page="workload-resources/daemon-set-v1" >}}
+  오브젝트 정의를 읽는다.

content/ko/docs/concepts/workloads/controllers/deployment.md

@@ -73,10 +73,6 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
 kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 ```
 
-  {{< note >}}
-  `--record` 플래그를 지정해서 실행된 명령을 `kubernetes.io/change-cause` 리소스 어노테이션에 작성할 수 있다.
-  기록된 변경사항은 향후 인트로스펙션(introspection)에 유용하다. 예를 들면, 디플로이먼트의 각 수정 버전에서 실행된 명령을 볼 수 있다.
-  {{< /note >}}
 
 
 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
@@ -167,13 +163,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 1. `nginx:1.14.2` 이미지 대신 `nginx:1.16.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다.
 
     ```shell
-    kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+    kubectl deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
     ```
 
     또는 다음의 명령어를 사용한다.
 
     ```shell
-    kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
+    kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
     ```
 
     다음과 유사하게 출력된다.
@@ -368,7 +364,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
 * 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.16.1` 이 아닌 `nginx:1.161` 로 입력해서 오타를 냈다고 가정한다.
 
     ```shell
-    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
+    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 
     ```
 
     이와 유사하게 출력된다.
@@ -483,15 +479,14 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
     ```
     deployments "nginx-deployment"
     REVISION    CHANGE-CAUSE
-    1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
-    2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
-    3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
+    1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
+    2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+    3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
     ```
 
     `CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다.
 
     * 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
-    * `kubectl` 명령어 이용시 `--record` 플래그를 추가해서 리소스 변경을 저장한다.
     * 수동으로 리소스 매니페스트 편집.
 
 2. 각 수정 버전의 세부 정보를 보려면 다음을 실행한다.
@@ -504,7 +499,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
     deployments "nginx-deployment" revision 2
       Labels:       app=nginx
               pod-template-hash=1159050644
-      Annotations:  kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
+      Annotations:  kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
       Containers:
        nginx:
         Image:      nginx:1.16.1
@@ -565,7 +560,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
     CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
     Labels:                 app=nginx
     Annotations:            deployment.kubernetes.io/revision=4
-                            kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
+                            kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
     Selector:               app=nginx
     Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
     StrategyType:           RollingUpdate
@@ -1174,3 +1169,14 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
 일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은
 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다.
 디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다.
+
+## {{% heading "whatsnext" %}}
+
+* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
+* [디플로이먼트를 사용해서 상태를 유지하지 않는 애플리케이션을 구동한다](/ko/docs/tasks/run-application/run-stateless-application-deployment/).
+* `Deployment`는 쿠버네티스 REST API에서 상위-수준 리소스이다.
+  디플로이먼트 API를 이해하기 위해서
+  {{< api-reference page="workload-resources/deployment-v1" >}}
+  오브젝트 정의를 읽는다.
+* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
+  이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

content/ko/docs/concepts/workloads/controllers/job.md

@@ -25,6 +25,8 @@ weight: 50
 
 잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
 
+잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
+
 <!-- body -->
 
 ## 예시 잡 실행하기
@@ -294,7 +296,7 @@ spec:
 `restartPolicy` 는 잡 자체에 적용되는 것이 아니라 파드에 적용된다는 점을 유념한다. 잡의 상태가 `type: Failed` 이 되면, 잡의 자동 재시작은 없다.
 즉, `.spec.activeDeadlineSeconds` 와 `.spec.backoffLimit` 로 활성화된 잡의 종료 메커니즘은 영구적인 잡의 실패를 유발하며 이를 해결하기 위해 수동 개입이 필요하다.
 
-## 완료된 잡을 자동으로 정리
+## 완료된 잡을 자동으로 정리 {#clean-up-finished-jobs-automatically}
 
 완료된 잡은 일반적으로 시스템에서 더 이상 필요로 하지 않는다. 시스템 내에
 이를 유지한다면 API 서버에 부담이 된다.
@@ -522,7 +524,7 @@ Events:
 실행되기를 원하지만, 잡이 생성한 나머지 파드에는 다른
 파드 템플릿을 사용하고 잡으로 하여금 새 이름을 부여하기를 원한다.
 그러나 관련된 필드들은 업데이트가 불가능하기 때문에 잡을 업데이트할 수 없다.
-따라서 `kubectl delete jobs/old --cascade=false` 를 사용해서
+따라서 `kubectl delete jobs/old --cascade=orphan` 명령을 사용해서
 잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_.
 삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다.
 
@@ -638,6 +640,19 @@ API 서버에서 파드가 제거되면 이를 알아챈다.
 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
 파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다.
 
-## 크론잡 {#cron-jobs}
-
-[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다.
+## {{% heading "whatsnext" %}}
+
+* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
+* 다른 방식으로 잡을 구동하는 방법에 대해서 읽는다.
+  * [작업 대기열을 사용한 거친 병렬 처리](/ko/docs/tasks/job/coarse-parallel-processing-work-queue/)
+  * [작업 대기열을 사용한 정밀 병렬 처리](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)
+  * [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/docs/tasks/job/indexed-parallel-processing-static/)(베타) 사용
+  * 템플릿 기반으로 복수의 잡 생성: [확장을 사용한 병렬 처리](/ko/docs/tasks/job/parallel-processing-expansion/)
+* [완료된 잡을 자동으로 정리](#clean-up-finished-jobs-automatically) 섹션 내 링크를 따라서
+  클러스터가 완료되거나 실패된 태스크를 어떻게 정리하는지에 대해 더 배운다.
+* `Job`은 쿠버네티스 REST API의 일부이다.
+  잡 API에 대해 이해하기 위해
+  {{< api-reference page="workload-resources/job-v1" >}}
+  오브젝트 정의를 읽은다.
+* 스케줄을 기반으로 실행되는 일련의 잡을 정의하는데 사용할 수 있고, 유닉스 툴 `cron`과 유사한
+  [`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)에 대해 읽는다.

content/ko/docs/concepts/workloads/controllers/replicaset.md

@@ -408,3 +408,16 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
 이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에
 설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
 따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
+
+
+## {{% heading "whatsnext" %}}
+
+* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
+* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 배운다.
+* 레플리카셋에 의존해서 동작하는 [디플로이먼트로 스테이트리스 애플리케이션을 실행한다](/ko/docs/tasks/run-application/run-stateless-application-deployment/).
+* `ReplicaSet`는 쿠버네티스 REST API의 상위-수준 리소스이다.
+  레플리카셋 API에 대해 이해하기 위해
+  {{< api-reference page="workload-resources/replica-set-v1" >}}
+  오브젝트 정의를 읽는다.
+* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
+  이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

content/ko/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -193,7 +193,7 @@ 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=orphan`을 지정하라.
 
 REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
 
@@ -285,6 +285,11 @@ API 오브젝트에 대한 더 자세한 것은
 다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
 머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
 
-## 더 자세한 정보는
+## {{% heading "whatsnext" %}}
 
-[스테이트리스 애플리케이션 디플로이먼트 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)를 참고한다.
+* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
+* 레플리케이션 컨트롤러를 대신하는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 배운다.
+* `ReplicationController`는 쿠버네티스 REST API의 일부이다.
+  레플리케이션 컨트롤러 API에 대해 이해하기 위해
+  {{< api-reference page="workload-resources/replication-controller-v1" >}}
+  오브젝트 정의를 읽는다.