잡(job) | Notion

잡(Job)과 레플리카셋(ReplicaSet) 차이점

잡과 레플리카셋 간의 큰 차이점은 ‘기동 중인 파드가 정지되는 것을 전제로 만들어졌는’에 있다.
- 레플리카셋의 관점에서 파드의 정지는 예상치 못한 에러다.
- 잡의 관점에서 파드의 정지는 정상 작동이다.
배치 처리와 같은 일에 사용하기 용이하다.

잡(Job) 생성

kubectl get으로 잡을 확인해보면 레플리카셋 등에서는 READY 상태의 컨테이너 수를 표시하지만, 잡에서는 정상 종료한 파드 수(COMPLETIONS)를 표시한다.

apiVersion: batch/v1
kind: Job
metadata:
	name: sample-job
spec:
	completions: 1
	parallelism: 1
	backoffLimit: 10
	template:
		spec:
			containers:
			- name: tools-container
				image: amsy810/tools:v2.0
				command: ["sleep"]
				args: ["60"]
			restartPolicy: Never

restartPolicy에 따른 동작 차이

잡의 매니페스트에는 spec.template.spec.restartPolicy에 Onfailure 또는 Never 중 하나를 지정해야 한다.
- Never : 파드에 장애가 발생하면 신규 파드가 생성된다.
  - 내부 프로세스가 정지되면 신규 파드를 생성하여 잡을 계속 실행하려고 한다.
```
apiVersion: batch/v1
kind: Job
metadata:
	name: sample-job-never-restart
spec:
	completions: 1
	parallelism: 1
	backoffLimit: 10
	template:
		spec:
			containers:
			- name: tools-container
				image: amsy810/tools:v2.0
				command: ["sh", "-c"]
				args: ["$(sleep 3600)"]
			restartPolicy: Never
```
- OnFailure : 동일한 파드를 사용하여 잡을 다시 시작한다.
  - 내부 프로세스가 정지되면 RESTARTS 카운터가 증가하고, 사용했던 파드를 다시 사용하여 잡을 실행하려고 한다.
  - 파드가 기동하는 노드나 파드 IP 주소는 변경되지 않지만, 영구 볼륨이나 쿠버네티스 노드의 영역(hostPath)을 마운트하지 않은 경우라면 데이터 자체가 유실된다.
```
apiVersion: batch/v1
kind: Job
metadata:
	name: sample-job-onfailure-restart
spec:
	completions: 1
	parallelism: 1
	backoffLimit: 10
	template:
		spec:
			containers:
			- name: tools-container
				image: amsy810/tools:v2.0
				command: ["sh", "-c"]
				args: ["$(sleep 3600)"]
			restartPolicy: OnFailure
```

태스크와 작업 큐 병렬 실행

completions/parallelism/backoffLimit는 아주 중요한 파라미터들이며 잡의 워크로드에 따라 적절히 설정하여 사용해야 한다.
- completions : 목표 성공 치
  - 성공 후 종료
- parallelism : 병렬 처리 횟수
- backoffLimit : 실패 허용 횟수
병렬 잡과 작업 큐 파라미터 설정
- 1회만 실행하는 태스크 (One Shot Task)
  - completions : 1
  - parallelism : 1
  - backoffLimit : 0
- N개 병렬로 실행시키는 태스크 (Multi Task)
  - 병렬 수(parallelism)를 성공 횟수(completions) 이상으로 설정하더라도 성공 횟수만큼만 파드가 생성된다.
  - completions : N
  - parallelism : M
  - backoffLimit : P
- 한 개씩 실행하는 작업 큐 (Single WorkQueue)
  
  <aside> 💡 실행 중 parallelism을 변경하여 N개의 Multi WorkQueue로 변경할 수 있다. Parallelism 변경은 kubectl patch 명령어를 사용하거나 매니페스트를 적용하여 변경할 수 있다.
  
  </aside>
  - completions : 미지정
  - parallelism : 1
  - backoffLimit : P
- N개 병렬로 실행하는 작업 큐 (Multi WorkQueue)
  
  <aside> 💡 [ 동작원리 ]
  - 정상 종료가 completions에 도달할 때까지 실행하는 것이 아닌, 큰 처리 전체가 정상 종료할 때까지 병렬 수로 계속 실행하고자 할 때 사용
  - 병렬로 생성된 파드 중 하나라도 정상 종료하면 그 이후에는 파드를 생성하지 않는다.
  - 기존에 생성된 나머지 파드는 강제로 정지하지 않고 개별 처리가 종료할 때까지 계속 동작
  </aside>
  
  <aside> 💡 - 작업 큐의 잡을 사용하려면 처리 전체의 진행을 관리하기 위한 메시지 큐를 사용해야 한다.
  - 파드 내의 애플리케이션에는 그 메시지로부터 반복하여 데이터를 계속 가져오는 처리를 구현한다.
  - 메시지 큐가 빈 것을 확인하면 그 파드를 정상 종료하도록 구현해 둠으로써 작업 큐의 잡에서 처리 전체를 정지시킬 수 있게 된다.
  - 메시지 큐의 Topic(큐의 송신자)에 공통으로 정상 종료 후에도 새로운 데이터가 큐에 들어오는 경우 등은 잡을 정기적으로 시작하는 크론잡 리소스 등과 조합하도록 구현이 필요하다.
  - 메시지 큐에 모인 메시지 양에 따라 병렬 수를 늘리는 구조를 만들면 작업 큐의 잡을 자동으로 스케일 하는 것도 가능하다.
  </aside>
  - completions : 미지정
  - parallelism : N
  - backoffLimit : P
```
apiVersion: batch/v1
kind: Job
metadata:
	name: sample-multi-workqueue-job
spec:
	# completions: 1 지정하지 않는다.
	parallelism: 3
	backoffLimit: 1
	template:
		spec:
			containers:
			- name: tools-container
				image: amsy810/tools:v2.0
				command: ["sleep"]
				args: ["30"]
			restartPolicy: Never
```
  - 태스크와 작업 큐는 잡을 표시할 때 COMPLETIONS의 출력 형식이 다르다.
  - Multi Task의 경우 : completions: 5, parallelism: 3 ⇒ COMPLETIONS 3/5 로 표기
  - Multi WorkQueue의 경우 : parallelism: 3 ⇒ COMPLETIONS 0/1 of 3
    - 3개 중 하나만 정상 종료하면 되기 때문에 0/1 of 3로 나타난다.

일정 기간 후 잡 삭제

잡은 종료 후에 삭제되지 않고 계속 남는다.
spec.ttlSecondsAfterFinished를 설정하여 잡이 종료한 후에 일정 기간 경과 후 삭제하도록 설정 가능

apiVersion: batch/v1
kind: Job
metadata:
	name: sample-job-ttl
spec:
	ttlSecondsAfterFinished: 30
	completions: 1
	parallelism: 1
	backoffLimit: 10
	template:
		spec:
			containers:
			- name: tools-container
				image: amsy810/tools:v2.0
				command: ["sleep"]
				args: ["60"]
			restartPolicy: Never

60초 후에 잡이 종료되고, 종료 이후 30초가 지나면 잡이 삭제 된다.