controller/ cronJob

# 개념

job을 일정시각마다 실행하게 하는거다.

예를들어 매일 정각에 한번씩 job을 실행하게 하는거거나.. 뭐 이런거다.

매일 로그를 백업한다거나 점검 프로세스를 job으로 넣어두고 하는데 쓰면 좋을것 같다.

 

 

# yaml양식

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

공식문서에서 발췌한 job양식이다.

아래 jobTemplate부분은 일반 job부분에서 spec필드 이하부분이랑 똑같다.

apiVersion: batch/v1
kind: Job
metadata:
  name: muzzi-good-job
spec:
  template:
    spec:
      containers:
      - name: centos-con
        image: centos:7
        command: ["bash"]
        args:
        - "-c"
        - "echo 'hello muzzi'; sleep 10; echo 'muzzi bye'"
      restartPolicy: Never
    #backoffLimit: 4

 

 

 

# schedule필드

cronJob에서 가장 중요한 부분이다. 위에서 설명했듯이 cronJob은 매 시간마다 특정 job을 실행시켜주는 컨트롤러인데 이 주기를 어떻게 정할거인지 정하는거다.

대충 "x x x x x"으로 생겼는데 각각은 분 시 일 월 요일 순서이다.

리눅스의 crontab이랑 똑같은데 난 이거 찍먹한 수준이라.. 

간단하게 이해한것들을 소개하자면,

 

- * 매번

그림으로는 별표를 썼는데 저렇게 별표가 있는건 매 시간단위당 실행시켜준다는거다.

분에 *이 있으면 1분마다, 시에 *는 매시간마다, *매일마다, *매월마다, *모든 요일마다 등등이로 해석 가능하다.

 

-n 해당 시간단위

예를들어 0 5 * * *이렇게 되어있으면, 매일 다섯시 0분마다 라는 뜻이다.

 

 

- */n 매 n(시간단위)마다

예를들어 */5가 분에 있다면, 매 5분 마다 라는 뜻이다.

 

- n-m n(시간단위) 부터 m(시간단위)까지 매번

요일필드에서는 0부터 6까지 쓸 수 있고 0부터 일요일, 6은 토요일이다.

예를들어 0-2이라고 적혀있으면 일요일, 월요일, 화요일에만 job을 동작시켜주는 cronJob이다.

 

- n,m n(시간단위) and m(시간단위)

 

 

 

예시로 받아들이는게 더 편하더라.

- 0 9 15 * *

매월 15일날 오전 9시 정각에 월급보내는 job실행해줘~

 

- 0 18 * * 5 

매번 금요일 저녁 6시에 칼퇴알람보내는 job실행해줘~

 

- 0 9 * * 1-5 

매번 평일 오전 아홉시에 지각자들 체크하는 job 실행해줘~

 

- 0 21 * * 0,6 

매 주말마다 친구한테 저녁아홉시에 술먹자는 문자 보내는 job실행해줘~

 

 

 

그냥 gpt한테 물어보는게 더 빠를거같다. 

 

 

# 실험해보자.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

해당 yaml파일로 cronjob을 만들었다.

schedule을 보면 매분마다 실행되는 job이 된다.

kubectl create -f test-crj.yaml

실행후 한 3분 지났는데 pod의 목록이 이렇게 된다.

AGE컬럼을 보면 2분전에 한번 pod가 생겨났고, 72초전에 한번, 12초전에 한번 이렇게 생성되고 completed가 되었다.

난 cronJob이 생성되자마자 바로 하나 생성될 줄 알았는데, 이 시간기준으로 몇분 정각에 생성된다.

저부분에서 12부분이 초인데, 저게 00으로 되는 순간 pod가 생겨난다.

 

 

 

# cronJob은 job을 만들어낸다. (deployment와 replicaSet과 비슷함)

이전에 controller를 포스팅할때 쿠버네티스에는 저렇게 일곱가지의 controller가 있다고 소개했다.

cronJob과 job은 짝꿍인데 이전에 deployment와 replicaSet을 소개하면서 종속관계를 소개했던것과 비슷하다.

kubectl get cronjob

해당명령어를 치면 현재 존재하는 cronJob이 나오는데,

아까만든 hello cronJob이 리스트에 뜬다.

suspend컬럼이 특이해서 gpt한테 물어봤더니, 이 작업이 여전히 동작중일때 false가 뜬다고 한다.

 

암튼 이제 이 cronJob이 만든 job을 보자

kubectl get job

이렇게 hello cronJob이 만든 job리스트가 뜨게된다.

 

 

 

 

 

# startingDeadlineSeconds필드

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  startingDeadlineSeconds: 300
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

저기 schedule부분 필드에 동급인 라인에 startingDeadlineSecopnds: 300으로 되어있다.

이 job이 300초동안 실행되지 않으면 취소시키겠다는 거다.

뭐 그러려니 하고..

 

 

 

# concurrencyPolicy

기본값은 Allow이다.

Allow로 되어있다면 한번에 여러개의 job이 러닝중이어도 된다는거다. 만약 Forbid로 설정하면 이전의 pod가 completed되어야 새로운 pod가 생겨난다는거다.

실험해볼까? 

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  #concurrencyPolicy: Allow
  #concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; sleep 70; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

 

- Allow일 경우

커맨드에 sleep 70을 해놨음. 즉 실행되면 running중이다가, 70초가 지나야 job이 completed가 된다. 하지만 매분 job이 실행되게 해놨으니 이 job이 실행되는 시간보다 running중인 시간이 더 길것이다.

실행시켜보면 첫번째 pod가 running중인데도 두번째 pod가 생성되었다.

 

- Forbid인경우

60초가 넘었지만 해당 pod는 running중이다. 그리고 새로운 pod가 생겨나지 않는다. 매분 실행하게 해놨지만 말이다.

약 70초에 첫번째 pod가 completed상태가 되었고, 좀 있다가 두번째 pod가 생겨났다.

난 00분에 Forbid로 안생겨났으니 다음 00분에 생겨날줄 알았는데 첫번쨰 pod가 completed가 되니 생기는것 같다. 뭔가 쌓이는거려나..?

 

kubectl describe cronjob hello

저렇게 이전 execution이 running중이라 새로운 job이 실행되지 않았다고 나온다.

 

 

 

# successfulJobsHistoryLimit

kubectl get cronjobs.batch hello -o yaml

이걸치면 cronJob에 대해서 yaml형식으로 나오는데

저기에 보인다.

이 successfulJobsHistoryLimit은 성공한 job이 최대 쌓이는 갯수를 의미한다. 기본값인가 보다.

 

이전 Forbid실험했을때 

이렇게 네개가 보였다. forbid를 의도적으로 유도해서 세개가 아니라 네개인것 같은데 원래 세개가 쌓이는게 맞다.

저 상태에서 더 늘지 않는다.

근데 이 cronJob을 edit으로 successfulJobsHistoryLimit의 값을 3에서 5로 바꿨는데

kubectl edit cronjob hello

원래 3이었는데 5로 바뀌었다.

저장하고 나왔다.

2분정도 더 기다리니까 쌓이던 job이

 

요렇게 더 쌓이는걸 볼 수 있따.

사실 저건 pod본거고 job에서 하나의 pod가 생기니 저렇게 되는거다.

 

kubectl get job

이렇게 job리스트를 보는게 맞긴하다.

 

 

 

++ batch 처리는 뭐야?

배치 처리는 일련의 작업이나 프로세스를 자동화하여 일괄적으로 실행하는 것을 말해요. 여러 작업을 모아서 일괄적으로 처리함으로써 효율성을 높일 수 있어요. 주로 데이터 처리, 작업 스케줄링, 백업 등에 사용되며, 일괄 처리 작업은 보통 스크립트나 특수한 소프트웨어를 사용해 자동화됩니다.

 

뭐 이렇다고 한다.. 람다같은 느낌적인느낌