4.2. 작업을 사용하여 Pod에서 작업 실행
작업은 OpenShift Container Platform 클러스터에서 작업을 실행합니다.
작업에서는 작업의 전반적인 진행률을 추적하고 활성 상태에 있거나 성공 또는 실패한 Pod에 대한 정보를 사용하여 해당 상태를 업데이트합니다. 작업을 삭제하면 생성된 Pod 복제본이 모두 정리됩니다. 작업은 Kubernetes API의 일부이며 다른 오브젝트 유형과 같이 oc
명령으로 관리할 수 있습니다.
작업 사양 샘플
apiVersion: batch/v1 kind: Job metadata: name: pi spec: parallelism: 1 1 completions: 1 2 activeDeadlineSeconds: 1800 3 backoffLimit: 6 4 template: 5 metadata: name: pi spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: OnFailure 6
작업에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.
4.2.1. 작업 및 cron 작업 이해
작업에서는 작업의 전반적인 진행률을 추적하고 활성 상태에 있거나 성공 또는 실패한 Pod에 대한 정보를 사용하여 해당 상태를 업데이트합니다. 작업을 삭제하면 작업에서 생성한 Pod가 모두 정리됩니다. 작업은 Kubernetes API의 일부이며 다른 오브젝트 유형과 같이 oc
명령으로 관리할 수 있습니다.
OpenShift Container Platform에는 한 번 실행 오브젝트를 생성할 수 있는 두 가지 리소스 유형이 있습니다.
- Job
- 일반적인 작업은 작업을 생성하고 작업이 완료되는지 확인하는 한 번 실행 오브젝트입니다.
다음은 작업으로 실행하는 데 적합한 세 가지 주요 작업 유형입니다.
비병렬 작업:
- Pod가 실패하지 않는 한 하나의 Pod만 시작하는 작업입니다.
- Pod가 성공적으로 종료되면 작업이 완료됩니다.
완료 횟수가 고정된 병렬 작업:
- 여러 Pod를 시작하는 작업입니다.
-
이 작업은 전체 작업을 나타내며
1
에서completions
값 사이의 각 값에 대해 하나의 성공적인 Pod가 있을 때 완료됩니다.
작업 큐가 있는 병렬 작업:
- 지정된 Pod에 여러 병렬 작업자 프로세스가 있는 작업입니다.
- OpenShift Container Platform은 Pod를 조정하여 각각의 작업을 결정하거나 외부 대기열 서비스를 사용합니다.
- 각 Pod는 모든 피어 Pod가 완료되었는지 및 전체 작업이 수행되었는지를 독립적으로 확인할 수 있습니다.
- 작업에서 성공적으로 종료된 Pod가 있는 경우 새 Pod가 생성되지 않습니다.
- 하나 이상의 Pod가 성공으로 종료되고 모든 Pod가 종료되면 작업이 성공적으로 완료됩니다.
- 성공으로 종료된 Pod가 있는 경우 다른 Pod에서 이 작업에 대해 작업을 수행하거나 출력을 작성해서는 안 됩니다. Pod는 모두 종료 프로세스에 있어야 합니다.
다양한 유형의 작업을 사용하는 방법에 대한 자세한 내용은 Kubernetes 설명서의 작업 패턴을 참조하십시오.
- cron 작업
- cron 작업을 사용하여 작업이 여러 번 실행되도록 예약할 수 있습니다.
cron 작업은 작업 실행 방법을 지정할 수 있도록 허용하여 일반 작업을 기반으로 빌드됩니다. cron 작업은 Kubernetes API의 일부이며 다른 오브젝트 유형과 같이 oc
명령으로 관리할 수 있습니다.
cron 작업은 백업 실행 또는 이메일 전송과 같은 주기적이고 반복적인 작업을 생성하는 데 유용합니다. cron 작업에서는 활동이 적은 기간에 작업을 예약하려는 경우와 같이 개별 작업을 특정 시간에 예약할 수도 있습니다. cron 작업은 cronjob 컨트롤러를 실행하는 컨트롤 플레인 노드에 구성된 시간대에 따라 Job
오브젝트를 생성합니다.
cron 작업에서는 Job
오브젝트를 대략적으로 일정 실행 시간당 한 번 생성하지만, 작업을 생성하지 못하거나 두 개의 작업이 생성되는 상황이 있습니다. 따라서 작업이 idempotent여야 하고 기록 제한을 구성해야 합니다.
4.2.1.1. 작업 생성 방법 이해
두 리소스 유형 모두 다음 주요 부분으로 구성되는 작업 구성이 필요합니다.
- Pod 템플릿: OpenShift Container Platform에서 생성하는 Pod를 설명합니다.
parallelism
매개변수: 작업을 실행해야 하는 임의의 시점에 병렬로 실행되는 Pod 수를 지정합니다.-
비병렬 작업의 경우 설정되지 않은 상태로 둡니다. 설정되지 않은 경우 기본값은
1
입니다.
-
비병렬 작업의 경우 설정되지 않은 상태로 둡니다. 설정되지 않은 경우 기본값은
completions
매개변수: 작업을 완료하는 데 필요한 성공적인 Pod 완료 횟수를 지정합니다.-
비병렬 작업의 경우 설정되지 않은 상태로 둡니다. 설정되지 않은 경우 기본값은
1
입니다. - 완료 횟수가 고정된 병렬 작업의 경우 값을 지정합니다.
-
작업 큐가 있는 병렬 작업의 경우 설정되지 않은 상태로 둡니다. 값을 설정하지 않는 경우 기본값은
parallelism
입니다.
-
비병렬 작업의 경우 설정되지 않은 상태로 둡니다. 설정되지 않은 경우 기본값은
4.2.1.2. 최대 작업 기간 설정 방법 이해
작업을 정의할 때 activeDeadlineSeconds
필드를 설정하여 최대 기간을 정의할 수 있습니다. 이는 초 단위로 지정되며 기본적으로 설정되어 있지 않습니다. 설정하지 않으면 최대 기간이 적용되지 않습니다.
최대 기간은 시스템에서 첫 번째 Pod가 예약되는 시점부터 계산되며 작업을 활성 상태로 유지할 수 있는 기간을 정의합니다. 전체 실행 시간을 추적합니다. 지정된 타임아웃에 도달하면 OpenShift Container Platform에서 작업을 종료합니다.
4.2.1.3. Pod가 실패하는 경우 작업 백오프 정책을 설정하는 방법 이해
구성의 논리적 오류 또는 기타 유사한 이유로 인해 설정된 재시도 횟수를 초과하면 작업이 실패한 것으로 간주될 수 있습니다. 작업과 연결된 실패한 Pod는 급격한 백오프 지연(10s
, 20s
, 40s
…)을 6분으로 제한하여 컨트롤러에서 다시 생성합니다. 컨트롤러 확인 중 실패한 새 Pod가 표시되지 않으면 제한이 재설정됩니다.
spec.backoffLimit
매개변수를 사용하여 작업의 재시도 횟수를 설정합니다.
4.2.1.4. 아티팩트를 제거하도록 cron 작업을 구성하는 방법
cron 작업에서는 작업 또는 Pod와 같은 아티팩트 리소스를 남겨 둘 수 있습니다. 사용자는 이전 작업과 Pod가 올바르게 정리되도록 기록 제한을 구성하는 것이 중요합니다. cron 작업 사양 내에는 이러한 리소스를 담당하는 다음 두 필드가 있습니다.
-
.spec.successfulJobsHistoryLimit
. 유지해야 하는 성공적으로 완료한 작업의 수입니다(기본값: 3). -
.spec.failedJobsHistoryLimit
. 유지해야 하는 실패한 작업의 수입니다(기본값: 1).
더 이상 필요하지 않은 cron 작업을 삭제합니다.
$ oc delete cronjob/<cron_job_name>
이렇게 하면 불필요한 아티팩트가 생성되지 않습니다.
-
spec.suspend
를 true로 설정하여 추가 실행을 중단할 수 있습니다. 모든 후속 실행은false
로 재설정할 때까지 일시 중단됩니다.
4.2.1.5. 알려진 제한 사항
작업 사양 재시작 정책은 작업 컨트롤러가 아닌Pod에만 적용됩니다. 그러나 작업 컨트롤러는 작업을 완료할 때까지 계속 재시도하도록 하드 코딩되어 있습니다.
이와 같이 restartPolicy: never
또는 --restart=Never
는 restartPolicy와 동일한 동작을 수행합니다. OnFailure
또는 --restart=OnFailure
. 즉 작업이 실패하면 작업이 성공할 때까지 (또는 작업을 수동으로 삭제할 때까지) 자동으로 재시작됩니다. 이 정책은 재시작을 수행하는 하위 시스템만 설정합니다.
Never
정책에서는 작업 컨트롤러에서 재시작을 수행합니다. 시도할 때마다 작업 컨트롤러에서 작업 상태의 실패 수를 늘리고 새 Pod를 생성합니다. 즉 실패할 때마다 Pod 수가 증가합니다.
OnFailure
정책에서는 kubelet에서 재시작을 수행합니다. 시도할 때마다 작업 상태의 실패 횟수가 늘어나는 것은 아닙니다. 또한 kubelet은 동일한 노드에서 Pod를 시작하여 실패한 작업을 재시도합니다.