Job, CronJob, initContainer
Job
- Kubernetes는 Pod를 running 중인 상태로 유지
- Batch 처리하는 Pod는 작업이 완료되면 종료됨
- Batch 처리에 적합한 컨트롤러로 Pod의 성공적인 완료를 보장
- 비정상 종료 시 다시 실행
- 정상 종료 시 완료
vi job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
kubectl apply -f job.yaml
watch kubectl get pods
kubectl get job
kubectl logs [job-name]
kubectl delete jobs.batch pi
restartPolicy
파드 내 컨테이너의 프로세스가 0이 아닌 종료 코드로 종료되었거나 컨테이너 메모리 제한을 초과해서 죽는 등의 여러 가지 이유로 실패할 수 있다. 만약 이런 일이 발생하고 .spec.template.spec.restartPolicy = "OnFailure"라면 파드는 노드에 그대로 유지되며 해당 파드에서 컨테이너는 다시 실행된다.
backoffLimit
구성에 논리적 오류가 포함되어 있어서 잡이 실패되도록 만들어야 하는 경우 재시도하는 횟수
vi job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
backoffLimit: 4
# 10초 이내로 실행 - 데드라인 설정
activeDeadlineSeconds: 10
# 순차적으로 최대 5개 실행
completion: 5
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbingnum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
CronJob
- Job 컨트롤러로 실행할 Application Pod를 주기적으로 반복해서 실행
- Linux의 cronjob의 스케줄링 기능을 Job Controller에 추가한 API
- 다음과 같이 반복해서 실행하는 Job을 운영해야 할 때 사용
- Data Backup
- Send email
- Cleaning tasks
- Cronjob Schedule: "0 3 1 * *"
- 매월 1일 3시 정각에 반복해서 실행
이메일의 정기적인 일괄 송신이나 일별/주별/월별 집계 처리 등과 같은 배치 잡을 Kubernetes 클러스터에서 실행하고 싶을 때는 'CronJob'을 사용한다. CronJob은 애플리케이션의 실행 타이밍을 설정할 수도 있다. 설정 방법은 리눅스의 crontab 설정과 동일하다.
schedule: "분 시 일 월 요일"
분: 0 - 59
시: 0 - 23
일: 1 - 31
월: 1 - 12
요일: 0(일요일) 1(월) 2(화) 3(수) 4(목) 5(금) 6(토)
# 특정 시스템에서는 7도 일요일
# 또는 sun, mon, tue, wed, thu, fri, sat
# @yearly 매년 1월 1일 자정에 실행 0 0 0 1 *
# @monthly 매년 1일 자정에 실행 0 0 1 * *
# @weekly 매주 일요일 자정에 실행 0 0 * * 0
# @daily (or @midnight) 매일 자정에 실행 0 0 * * *
# @hourly 매시 0분에 시작 0 * * * *
vi job.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
name: pi
spec:
schedule: "* * * * *"
jobTemplate:
spec:
activeDeadlineSeconds: 10
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
kubectl apply -f job.yaml
date
kubectl get cronjobs.batch
kubectl describe cronjobs.batch pi
kubectl get cronjobs.batch pi -o yaml
kubectl delete cronjobs.batch pi
다음의 조건으로 실행하는 컨테이너를 실행하시오.
- /data/ckad/sample.yaml manifest 파일에 pod가 정의 되어 있다.
- sample.yaml을 수정하여 busybox:stable 컨테이너가 매분마다 실행되어야 한다.
- 10초 내에 완료되거나 kubernetes에 의해 종료되어야 한다.
- cronjob 이름과 container 이름 모두 hello여야 한다.
- hello container가 성공적으로 실행되었는지 확인하세요.
cat /data/ckad/sample.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: my-job
spec:
template:
spec:
containers:
- command:
- sleep
- "5"
image: busybox
name: my-job
restartPolicy: Never
# 수정하기
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: "* * * * *"
jobTemplate:
spec:
activeDeadlineSeconds: 10
template:
spec:
containers:
- command:
- sleep
- "5"
image: busybox:stable
name: hello
restartPolicy: Never
kubectl apply -f /data/ckad/sample.yaml
kubectl get cronjobs.batch
init Container
- 앱 컨테이너 실행 전에 미리 동작 시킬 컨테이너
- 본 Container가 실행되기 전에 사전 작업이 필요할 경우 사용
- 초기화 컨테이너가 모두 실행된 후에 앱 컨테이너를 실행
- 초기화 컨테이너는 항상 완료를 목표로 실행
- 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
- 파드의 초기화 컨테이너가 실패하면, kubelet은 초기화 컨테이너가 성공할 때까지 반복적으로 재시작한다.
/data/ckad/fc-app.yaml을 편집해서 다음의 조건에 맞는 init 컨테이너를 추가하시오.
- fc-app.yaml을 통해 main 컨테이너 애플리케이션이 동작 가능하다.
- init 컨테이너로 busybox:1.28 컨테이너를 추가하고 /workdir/fcdata.txt라는 empty 파일을 생성한다.
- 만약, init 컨테이너가 fcdata.txt 파일을 생성하지 못하면 main 컨테이너는 실행할 수 없다.
- init 컨테이너와 main 컨테이너는 볼륨 마운트를 통해 /workdir 디렉토리를 공유한다.
cat /data/ckad/fc-app.yaml
apiVersion: v1
kind: Pod
metadata:
name: fc-app
spec:
containers:
- image: busybox:1.28
name: main
command: ['sh', '-c', 'if [ !-f /workdir/fcdata.txt ]; then exit 1;else sleep 300; fi']
volumeMounts:
- name: workdir
mountPath: "/workdir"
volumes:
- name: workdir
emptyDir: {}
# 수정
vi /data/ckad/fc-app.yaml
apiVersion: v1
kind: Pod
metadata:
name: fc-app
spec:
containers:
- image: busybox:1.28
name: main
command: ['sh', '-c', 'if [ !-f /workdir/fcdata.txt ]; then exit 1;else sleep 300; fi']
volumeMounts:
- name: workdir
mountPath: "/workdir"
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'touch /workdir/fcdata.txt']
volumeMounts:
- name: workdir
mountPath: "/workdir"
volumes:
- name: workdir
emptyDir: {}
watch kubectl get pods
kubectl apply -f /data/ckad/fc-app.yaml
CronJob의 이름이 ckad를 생성하고 나면 ckad-27954983-k94xt와 같이 파드가 생성되는데 여기서 "-"을 구분자로 첫 번째 ckad는 CronJob 이름을 나타내고 마지막 k94xt는 파드명을 나타내지만 중간 숫자는 타임스탬프를 결합한 것으로 보이지만 유닉스 타임스탬프는 아니다. 그래서 ChatGPT에게 물어보았다.
Question
what's meaning of k8s cronjob middle name separated by "-"
Answer
In Kubernetes, a CronJob is a type of resource that allows you to run a job on a periodic schedule. The "k8s" in "k8s cronjob" is a shorthand way of writing "Kubernetes," with the number 8 representing the eight letters between the "k" and the "s" in "Kubernetes."
When you create a CronJob in Kubernetes, you can give it a name, which can consist of lowercase letters, numbers, and hyphens (-). If you choose to include a hyphen in the name, it's generally used to separate words or parts of words to make the name more readable and descriptive.
For example, if you have a CronJob that runs a backup script every night at midnight, you might name it "backup-job" or "backup-script" to indicate what it does. The hyphen in the name helps to separate the words and make the name more readable.
So, the middle name separated by a hyphen in a k8s CronJob is likely used to provide additional information about the job, such as what it does or what it's for, and is intended to make the name more descriptive and easy to read.
Question
I make k8s cronjob name by ckad, when I execute command that get pods, I see pod named by ckad-27954974-74ttz, but I don't know what's meaning of 27954973
Answer
The name of the pod you mentioned, "ckad-27954974-74ttz," is auto-generated by Kubernetes when the pod is created as part of the CronJob.
The name consists of three parts:
"ckad" - This is the name of the CronJob that created the pod. "27954974" - This is a unique identifier that Kubernetes generates to ensure that each pod has a unique name. The identifier is based on the current timestamp, so it will be different each time the CronJob creates a new pod. "74ttz" - This is a random string of characters that Kubernetes adds to the end of the name to ensure that it is unique. The unique identifier in the middle of the pod name is useful for tracking and identifying pods, especially in large Kubernetes clusters where many pods may be running at the same time. However, it doesn't have any specific meaning beyond that.
If you want to give your pods more meaningful names, you can do so by specifying a "metadata.name" field in the pod spec when you create the CronJob. This will override the auto-generated name with a name of your choice
Question
what kinds of timestamp words that you adverted above answer like "27954974"
Answer
In the previous answer, I mentioned that the unique identifier in the middle of the pod name, "27954974," is generated by Kubernetes and is based on the current timestamp.
To be more precise, the unique identifier is actually a combination of two values:
The number of seconds since January 1, 1970, also known as the Unix timestamp. A random suffix that is added to ensure uniqueness. The Unix timestamp is a standard way of representing a point in time as a single number. It's used widely in computing systems, including Kubernetes, to record and compare times.
When Kubernetes generates a name for a pod, it combines the Unix timestamp with a random suffix to create a unique identifier that is unlikely to clash with other pod names. The resulting name is then used for the pod and can be seen when you list the pods in a Kubernetes cluster.
Question
27954974 is 8 digits, but unix timestamp is consists of 10 digits
Answer
You are correct that the Unix timestamp is represented as a 10-digit number, so my previous response was not accurate in stating that the identifier "27954974" is based on the Unix timestamp. I apologize for the confusion.
To clarify, the unique identifier in the middle of the pod name is actually based on a combination of the Unix timestamp and a random suffix, as I mentioned earlier. The Unix timestamp is a 10-digit number representing the number of seconds since January 1, 1970, so it will be much larger than the 8-digit identifier you mentioned.
The exact algorithm that Kubernetes uses to generate the unique identifier is somewhat complex and may depend on the version of Kubernetes being used. However, the general idea is that it combines the Unix timestamp with a random suffix to create a unique identifier for each pod that is created by the CronJob. The resulting identifier may be of varying length and may contain a mix of letters and numbers, depending on how it was generated.
I hope this clears up any confusion, and please let me know if you have any further questions.
결론은 중간 숫자는 Kubernetes가 고유 식별자를 생성하는 데 사용하는 알고리즘으로 생성되며 사용 중인 Kubernetes 버전에 따라 달라질 수 있지만 일반적으로 Unix 타임스탬프와 임의의 접미사를 결합하여 CronJob에서 생성된 각 포드에 대한 고유 식별자를 의미합니다.