kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #30203 from gochist/ko-controllers 

[ko] Update concepts/workloads/controllers
pull/30358/head
Kubernetes Prow Robot 2021-11-03 11:46:32 -07:00 committed by GitHub
parent 55f1be7728 70c42572af
commit e8d6117d3e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 120 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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에 대해 이해한다.

22
content/ko/docs/concepts/workloads/controllers/daemonset.md
View File

@ -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" >}}
오브젝트 정의를 읽는다.

32
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -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/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

23
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -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}
## {{% heading "whatsnext" %}}
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다.
* [파드](/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/)에 대해 읽는다.

13
content/ko/docs/concepts/workloads/controllers/replicaset.md
View File

@ -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/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

11
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
View File

@ -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" >}}
오브젝트 정의를 읽는다.

16
content/ko/docs/concepts/workloads/controllers/statefulset.md
View File

@ -297,3 +297,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* 스테이트풀셋을 사용하는 방법을 알아본다.
* [스테이트풀셋 애플리케이션 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/) 예제를 따라한다.
* [스테이트풀셋으로 카산드라 배포](/ko/docs/tutorials/stateful-application/cassandra/) 예제를 따라한다.
* [복제된 스테이트풀셋 애플리케이션 구동하기](/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다.
* [스테이트풀셋 확장하기](/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
* [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다.
* [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다.
* [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
* `StatefulSet`은 쿠버네티스 REST API의 상위-수준 리소스이다.
스테이트풀셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/stateful-set-v1" >}}
오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.