Second Korean l10n work for release-1.19
- Fix issue with links to already translated documents (#23829) - Update outdated files in the dev-1.19-ko.2 branch (#23827) - Fix issue with links to already translated documents (#23999) - Translate tasks/configure-pod-container/configure-persistent-volume-storage in Korean (#23867) - Translate reference/access-authn-authz/service-accounts-admin/ into Korean (#23974) - Translate reference/access-authn-authz/controlling-access/ into Korean (#23955) - Translate tasks/job/automated-tasks-with-cron-jobs.md into Korean (#23543) - Translate reference/access-authn-authz/authorization/ into Korean (#23989) - Update Ko localization guide (#24023) - Translate tasks/job/fine-parallel-processing-work-queue/ into Korean (#23841) - Translate setup/production-environment/windows/intro-windows-in-kubernetes and reflect reviews (#23879) - Translate tasks/debug-application-cluster/debug-pod-replication-controller in Korean (#23896) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: markruler <csu0414@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com>
This commit is contained in:
Jerry Park
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "잡(Job) 실행"
|
||||
description: 병렬 처리를 사용하여 잡을 실행한다.
|
||||
weight: 50
|
||||
---
|
||||
@@ -0,0 +1,208 @@
|
||||
---
|
||||
title: 크론잡(CronJob)으로 자동화된 작업 실행
|
||||
min-kubernetes-server-version: v1.8
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다.
|
||||
이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
|
||||
|
||||
크론 잡은 백업을 수행하거나 이메일을 보내는 것과 같이 주기적이고 반복적인 작업들을 생성하는 데 유용하다.
|
||||
크론 잡은 시스템 사용이 적은 시간에 잡을 스케줄하려는 경우처럼 특정 시간에 개별 작업을 스케줄할 수도 있다.
|
||||
|
||||
크론 잡에는 제한 사항과 특이점이 있다.
|
||||
예를 들어, 특정 상황에서는 하나의 크론 잡이 여러 잡을 생성할 수 있다.
|
||||
따라서, 잡은 멱등성을 가져야 한다.
|
||||
|
||||
제한 사항에 대한 자세한 내용은 [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 크론 잡 생성
|
||||
|
||||
크론 잡은 구성 파일이 필요하다.
|
||||
아래의 크론 잡 구성 `.spec` 파일의 예제는 매 분마다 현재 시간과 hello 메시지를 출력한다.
|
||||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
|
||||
다음 명령을 사용하여 크론잡 예제를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
cronjob.batch/hello created
|
||||
```
|
||||
|
||||
크론 잡을 생성한 후, 다음 명령을 사용하여 상태를 가져온다.
|
||||
|
||||
```shell
|
||||
kubectl get cronjob hello
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
|
||||
hello */1 * * * * False 0 <none> 10s
|
||||
```
|
||||
|
||||
명령의 결과에서 알 수 있듯이, 크론 잡은 아직 잡을 스케줄하거나 실행하지 않았다.
|
||||
약 1분 내로 잡이 생성되는지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get jobs --watch
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
NAME COMPLETIONS DURATION AGE
|
||||
hello-4111706356 0/1 0s
|
||||
hello-4111706356 0/1 0s 0s
|
||||
hello-4111706356 1/1 5s 5s
|
||||
```
|
||||
|
||||
이제 "hello" 크론 잡에 의해 스케줄된 실행 중인 작업을 확인했다.
|
||||
잡 감시를 중지한 뒤에 크론 잡이 다시 스케줄되었는지를 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get cronjob hello
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
|
||||
hello */1 * * * * False 0 50s 75s
|
||||
```
|
||||
|
||||
크론 잡 `hello` 가 `LAST SCHEDULE` 에 지정된 시간에 성공적으로 잡을 스케줄했는지 확인해야 한다. 현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
|
||||
|
||||
이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다.
|
||||
|
||||
{{< note >}}
|
||||
잡 이름과 파드 이름은 다르다.
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
# "hello-4111706356"을 사용자의 시스템에 있는 잡 이름으로 바꾼다
|
||||
pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name})
|
||||
```
|
||||
파드의 로그를 출력한다.
|
||||
|
||||
```shell
|
||||
kubectl logs $pods
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
Fri Feb 22 11:02:09 UTC 2019
|
||||
Hello from the Kubernetes cluster
|
||||
```
|
||||
|
||||
## 크론 잡 삭제
|
||||
|
||||
더 이상 크론 잡이 필요하지 않으면, `kubectl delete cronjob <cronjob name>` 명령을 사용해서 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete cronjob hello
|
||||
```
|
||||
|
||||
크론 잡을 삭제하면 생성된 모든 잡과 파드가 제거되고 추가 잡 생성이 중지된다.
|
||||
[가비지(garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
|
||||
|
||||
## 크론 잡 명세 작성
|
||||
|
||||
다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일
|
||||
작업에 대한 일반적인 정보는 [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)와
|
||||
[kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
|
||||
|
||||
크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
|
||||
|
||||
{{< note >}}
|
||||
크론 잡, 특히 해당 잡의 `.spec` 에 대한 모든 수정 사항은 다음 번 실행에만 적용된다.
|
||||
{{< /note >}}
|
||||
|
||||
### 스케줄
|
||||
|
||||
`.spec.schedule` 은 `.spec` 의 필수 필드이다.
|
||||
이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
|
||||
|
||||
이 형식은 확장된 `vixie cron` 스텝(step) 값도 포함한다. 이 내용은
|
||||
[FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
|
||||
|
||||
> 스텝 값은 범위(range)와 함께 사용할 수 있다. 범위 뒤에 `/<number>` 를
|
||||
> 지정하여 범위 내에서 숫자만큼의 값을 건너뛴다. 예를 들어,
|
||||
> 시간 필드에 `0-23/2` 를 사용하여 매 2시간마다 명령 실행을
|
||||
> 지정할 수 있다(V7 표준의 대안은 `0,2,4,6,8,10,12,14,16,18,20,22`
|
||||
> 이다). 별표(asterisk) 뒤에 붙이는 스텝도 허용되며,
|
||||
> "2시간마다"라고 지정하고 싶으면, 간단히 `*/2` 를 사용하면 된다.
|
||||
|
||||
{{< note >}}
|
||||
스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
|
||||
{{< /note >}}
|
||||
|
||||
### 잡 템플릿
|
||||
|
||||
`.spec.jobTemplate` 은 잡에 대한 템플릿이며, 이것은 필수 필드다.
|
||||
이것은 중첩되고 `apiVersion` 이나 `kind` 가 없는 것을 제외하고 [잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
|
||||
잡 `.spec` 을 작성하는 것에 대한 내용은 [잡 명세 작성하기](/ko/docs/concepts/workloads/controllers/job/#잡-사양-작성하기)를 참고한다.
|
||||
|
||||
### 시작 기한
|
||||
|
||||
`.spec.startingDeadlineSeconds` 필드는 선택 사항이다.
|
||||
어떤 이유로든 스케줄된 시간을 놓친 경우 잡의 시작 기한을 초 단위로 나타낸다.
|
||||
기한이 지나면, 크론 잡이 잡을 시작하지 않는다.
|
||||
이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다.
|
||||
이 필드를 지정하지 않으면, 잡에 기한이 없다.
|
||||
|
||||
크론잡 컨트롤러는 크론 잡에 대해 얼마나 많은 스케줄이 누락되었는지를 계산한다. 누락된 스케줄이 100개를 초과 한다면, 크론 잡은 더이상 스케줄되지 않는다. `.spec.startingDeadlineSeconds` 이 설정되지 않았다면, 크론잡 컨트롤러는 `status.lastScheduleTime` 부터 지금까지 누락된 스케줄을 계산한다.
|
||||
|
||||
예를 들어, 하나의 크론 잡이 1분마다 실행되도록 설정되어 있고, 크론잡의 `status.lastScheduleTime` 은 새벽 5:00시이지만, 지금은 오전 7:00시라고 가정하자. 즉 120개의 스케줄이 누락되었다는 것이고, 그래서 크론 잡은 더이상 스케줄되지 않는다.
|
||||
|
||||
`.spec.startingDeadlineSeconds` 필드가 (null이 아닌) 값으로 설정되어 있다면, 크론잡 컨트롤러는 `.spec.startingDeadlineSeconds` 의 값으로부터 지금까지 얼마나 많은 잡이 누락되었는지를 계산한다.
|
||||
|
||||
예를 들어, `200` 으로 설정되었다면, 지난 200초 동안 누락된 스케줄이 몇 번 발생했는지 계산한다. 이 경우, 지난 200초 동안 누락된 스케줄이 100개가 넘으면, 크론 잡이 더이상 스케줄되지 않는다.
|
||||
|
||||
### 동시성 정책
|
||||
|
||||
`.spec.concurrencyPolicy` 필드도 선택 사항이다.
|
||||
이것은 이 크론 잡에 의해 생성된 잡의 동시 실행을 처리하는 방법을 지정한다.
|
||||
명세는 다음의 동시성 정책 중 하나만 지정할 수 있다.
|
||||
|
||||
* `Allow`(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다.
|
||||
* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
|
||||
* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
|
||||
|
||||
참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다.
|
||||
크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다.
|
||||
|
||||
### 일시 정지
|
||||
|
||||
`.spec.suspend` 필드도 선택 사항이다.
|
||||
`true` 로 설정되면, 모든 후속 실행이 일시 정지된다.
|
||||
이 설정은 이미 시작된 실행에는 적용되지 않는다.
|
||||
기본값은 false이다.
|
||||
|
||||
{{< caution >}}
|
||||
스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다.
|
||||
[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, 누락된 잡들이 즉시 스케줄된다.
|
||||
{{< /caution >}}
|
||||
|
||||
### 잡 히스토리 한도
|
||||
|
||||
`.spec.successfulJobsHistoryLimit` 와 `.spec.failedJobsHistoryLimit` 필드는 선택 사항이다.
|
||||
이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다.
|
||||
기본적으로, 각각 3과 1로 설정된다. 한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.
|
||||
@@ -0,0 +1,233 @@
|
||||
---
|
||||
title: 작업 대기열을 사용한 정밀 병렬 처리
|
||||
content_type: task
|
||||
min-kubernetes-server-version: v1.8
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 예에서는, 지정된 파드에서 여러 병렬 워커 프로세스가 있는
|
||||
쿠버네티스 잡(Job)을 실행한다.
|
||||
|
||||
이 예에서는, 각 파드가 생성될 때, 작업 대기열에서 하나의 작업 단위를
|
||||
선택하여, 처리하고, 대기열이 비워질 때까지 반복한다.
|
||||
|
||||
이 예에서의 단계에 대한 개요는 다음과 같다.
|
||||
|
||||
1. **작업 대기열을 보관할 스토리지 서비스를 시작한다.** 이 예에서는, Redis를 사용하여
|
||||
작업 항목을 저장한다. 이전 예에서는, RabbitMQ를 사용했다. 이 예에서는, AMQP가 길이가
|
||||
정해져 있는 작업 대기열이 비어있을 때 클라이언트가 이를 감지할 수 있는 좋은 방법을 제공하지
|
||||
않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는
|
||||
Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다.
|
||||
1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. 이
|
||||
예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
|
||||
1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는
|
||||
메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
[잡](/ko/docs/concepts/workloads/controllers/job/)의 기본적이고,
|
||||
병렬 작업이 아닌, 사용법에 대해 잘 알고 있어야 한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Redis 시작
|
||||
|
||||
이 문서의 예시에서는, 단순함을 위해, Redis의 단일 인스턴스를 시작한다.
|
||||
Redis를 확장 가능하고 중복적으로 배포하는 예에 대해서는
|
||||
[Redis 예시](https://github.com/kubernetes/examples/tree/master/guestbook)를 참고한다.
|
||||
|
||||
다음 파일을 직접 다운로드할 수도 있다.
|
||||
|
||||
- [`redis-pod.yaml`](/examples/application/job/redis/redis-pod.yaml)
|
||||
- [`redis-service.yaml`](/examples/application/job/redis/redis-service.yaml)
|
||||
- [`Dockerfile`](/examples/application/job/redis/Dockerfile)
|
||||
- [`job.yaml`](/examples/application/job/redis/job.yaml)
|
||||
- [`rediswq.py`](/examples/application/job/redis/rediswq.py)
|
||||
- [`worker.py`](/examples/application/job/redis/worker.py)
|
||||
|
||||
|
||||
## 작업으로 대기열 채우기
|
||||
|
||||
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제의 작업은 문자열을 출력하는
|
||||
것이다.
|
||||
|
||||
Redis CLI를 실행하기 위한 임시 대화형 파드를 시작한다.
|
||||
|
||||
```shell
|
||||
kubectl run -i --tty temp --image redis --command "/bin/sh"
|
||||
Waiting for pod default/redis2-c7h78 to be running, status is Pending, pod ready: false
|
||||
Hit enter for command prompt
|
||||
```
|
||||
|
||||
이제 엔터 키를 누르고, redis CLI를 시작하고, 몇몇 작업 항목이 포함된 목록을 생성한다.
|
||||
|
||||
```
|
||||
# redis-cli -h redis
|
||||
redis:6379> rpush job2 "apple"
|
||||
(integer) 1
|
||||
redis:6379> rpush job2 "banana"
|
||||
(integer) 2
|
||||
redis:6379> rpush job2 "cherry"
|
||||
(integer) 3
|
||||
redis:6379> rpush job2 "date"
|
||||
(integer) 4
|
||||
redis:6379> rpush job2 "fig"
|
||||
(integer) 5
|
||||
redis:6379> rpush job2 "grape"
|
||||
(integer) 6
|
||||
redis:6379> rpush job2 "lemon"
|
||||
(integer) 7
|
||||
redis:6379> rpush job2 "melon"
|
||||
(integer) 8
|
||||
redis:6379> rpush job2 "orange"
|
||||
(integer) 9
|
||||
redis:6379> lrange job2 0 -1
|
||||
1) "apple"
|
||||
2) "banana"
|
||||
3) "cherry"
|
||||
4) "date"
|
||||
5) "fig"
|
||||
6) "grape"
|
||||
7) "lemon"
|
||||
8) "melon"
|
||||
9) "orange"
|
||||
```
|
||||
|
||||
자, 키 `job2` 가 있는 목록이 작업 대기열이 된다.
|
||||
|
||||
참고: Kube DNS를 올바르게 설정하지 않은 경우, 위 블록의
|
||||
첫 번째 단계를 `redis-cli -h $REDIS_SERVICE_HOST` 로 변경해야 할 수 있다.
|
||||
|
||||
|
||||
## 이미지 생성
|
||||
|
||||
이제 실행할 이미지를 만들 준비가 되었다.
|
||||
|
||||
redis 클라이언트와 함께 python 워커 프로그램을 사용하여
|
||||
메시지 큐에서 메시지를 읽는다.
|
||||
|
||||
rediswq.py([다운로드](/examples/application/job/redis/rediswq.py))라는
|
||||
간단한 Redis 작업 대기열 클라이언트 라이브러리가 제공된다.
|
||||
|
||||
잡의 각 파드에 있는 "워커" 프로그램은 작업 대기열
|
||||
클라이언트 라이브러리를 사용하여 작업을 가져온다. 다음은 워커 프로그램이다.
|
||||
|
||||
{{< codenew language="python" file="application/job/redis/worker.py" >}}
|
||||
|
||||
[`worker.py`](/examples/application/job/redis/worker.py),
|
||||
[`rediswq.py`](/examples/application/job/redis/rediswq.py) 및
|
||||
[`Dockerfile`](/examples/application/job/redis/Dockerfile) 파일을 다운로드할 수 있고, 그런 다음
|
||||
이미지를 만들 수도 있다.
|
||||
|
||||
```shell
|
||||
docker build -t job-wq-2 .
|
||||
```
|
||||
|
||||
### 이미지 푸시
|
||||
|
||||
[도커 허브(Docker Hub)](https://hub.docker.com/)를 위해, 아래 명령으로
|
||||
사용자의 username과 앱 이미지에 태그하고 허브에 푸시한다. `<username>` 을
|
||||
사용자의 허브 username으로 바꾼다.
|
||||
|
||||
```shell
|
||||
docker tag job-wq-2 <username>/job-wq-2
|
||||
docker push <username>/job-wq-2
|
||||
```
|
||||
|
||||
공용 저장소로 푸시하거나 [개인 저장소에 접근할 수 있도록
|
||||
클러스터를 구성](/ko/docs/concepts/containers/images/)해야 한다.
|
||||
|
||||
[Google Container
|
||||
Registry](https://cloud.google.com/tools/container-registry/)를 사용하는 경우,
|
||||
사용자의 프로젝트 ID로 앱 이미지에 태그를 지정하고 GCR로 푸시한다. `<project>` 를
|
||||
사용자의 프로젝트 ID로 바꾼다.
|
||||
|
||||
```shell
|
||||
docker tag job-wq-2 gcr.io/<project>/job-wq-2
|
||||
gcloud docker -- push gcr.io/<project>/job-wq-2
|
||||
```
|
||||
|
||||
## 잡 정의
|
||||
|
||||
다음은 잡 정의이다.
|
||||
|
||||
{{< codenew file="application/job/redis/job.yaml" >}}
|
||||
|
||||
사용자 자신의 경로로 `gcr.io/myproject` 를
|
||||
변경하려면 잡 템플릿을 편집해야 한다.
|
||||
|
||||
이 예에서, 각 파드는 대기열의 여러 항목에 대해 작업한 다음 더 이상 항목이 없을 때 종료된다.
|
||||
워커는 작업 대기열이 비어있을 때를 감지하고 잡 컨트롤러는 작업 대기열에 대해
|
||||
알지 못하기 때문에, 작업이 완료되면 워커에게 신호를 보낸다.
|
||||
워커는 성공적으로 종료하여 대기열이 비어 있음을 알린다. 따라서, 워커가 성공적으로
|
||||
종료하자마자, 컨트롤러는 작업이 완료되었음을 인식하고, 파드가 곧 종료된다.
|
||||
따라서, 잡 완료 횟수를 1로 설정했다. 잡 컨트롤러는 다른 파드도 완료될 때까지
|
||||
기다린다.
|
||||
|
||||
## 잡 실행
|
||||
|
||||
이제 잡을 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./job.yaml
|
||||
```
|
||||
|
||||
이제 조금 기다린 다음, 잡을 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl describe jobs/job-wq-2
|
||||
Name: job-wq-2
|
||||
Namespace: default
|
||||
Selector: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
|
||||
Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
|
||||
job-name=job-wq-2
|
||||
Annotations: <none>
|
||||
Parallelism: 2
|
||||
Completions: <unset>
|
||||
Start Time: Mon, 11 Jan 2016 17:07:59 -0800
|
||||
Pods Statuses: 1 Running / 0 Succeeded / 0 Failed
|
||||
Pod Template:
|
||||
Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
|
||||
job-name=job-wq-2
|
||||
Containers:
|
||||
c:
|
||||
Image: gcr.io/exampleproject/job-wq-2
|
||||
Port:
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
33s 33s 1 {job-controller } Normal SuccessfulCreate Created pod: job-wq-2-lglf8
|
||||
|
||||
|
||||
kubectl logs pods/job-wq-2-7r7b2
|
||||
Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
|
||||
Initial queue state: empty=False
|
||||
Working on banana
|
||||
Working on date
|
||||
Working on lemon
|
||||
```
|
||||
|
||||
보시다시피, 사용자의 파드 중 하나가 여러 작업 단위에서 작업했다.
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## 대안
|
||||
|
||||
대기열 서비스를 실행하거나 작업 대기열을 사용하도록 컨테이너를 수정하는 것이 불편한 경우, 다른
|
||||
[잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)
|
||||
중 하나를 고려할 수 있다.
|
||||
|
||||
만약 실행할 백그라운드 처리 작업의 연속 스트림이 있는 경우,
|
||||
`ReplicaSet` 이 있는 백그라운드 워커를 실행하는 것과,
|
||||
[https://github.com/resque/resque](https://github.com/resque/resque)와 같은
|
||||
백그라운드 처리 라이브러리를 실행하는 것이 좋다.
|
||||
Reference in New Issue
Block a user