[Kubernetes] DeamonSet & Job, Cronjob

DaemonSet

데몬셋 (DaemonSet)은 Kubernetes에서 각 노드에서 파드(pod)를 하나씩 실행하도록 보장하는 리소스이다. 일반적으로 각 노드에서 실행되어야 하는 서비스나 데몬을 배치할 때 사용된다. 예를 들어, 로그 수집, 모니터링, 클러스터 관리 서비스 등이 데몬셋으로 실행될 수 있다.

데몬셋의 주요 개념

파드의 자동 배치: 데몬셋은 클러스터의 모든 노드(또는 일부 선택된 노드)에 특정 파드를 자동으로 배치한다. 새로운 노드가 클러스터에 추가되면 해당 노드에도 자동으로 파드가 배치되고, 노드가 제거되면 해당 파드도 삭제된다.
- 자동 배치: 클러스터의 노드가 변경되면 데몬셋에 의해 자동으로 파드가 배치되거나 제거된다.
- 노드 선택: 데몬셋은 특정 노드 셀렉터를 사용하여 어떤 노드에서 파드를 실행할지 제어할 수 있습니다. 예를 들어, 특정 레이블이 있는 노드에서만 파드를 실행하게 할 수 있다.
수동 관리: 데몬셋을 삭제하면, 해당 데몬셋에서 생성된 모든 파드도 자동으로 삭제된다.

데몬셋의 사용 사례

로그 수집: 예를 들어, Fluentd 또는 Filebeat와 같은 로그 수집 데몬을 모든 노드에서 실행하려는 경우 데몬셋을 사용한다.
노드 모니터링: Prometheus Node Exporter와 같은 모니터링 도구를 사용하여 모든 노드에서 메트릭을 수집하려는 경우.
클러스터 관리: Kubernetes 관리 에이전트(예: kube-proxy, 네트워크 플러그인 등)를 각 노드에 배포하기 위한 용도로 사용.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: myweb-ds
spec:
  selector:
    matchExpressions:
      - key: app
        operator: In
        values:
          - myweb
      - key: env
        operator: Exists
  template:
    metadata:
      labels:
        app: myweb
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP

Job

Job은 Kubernetes에서 특정 작업을 한 번 실행하고 완료하는 데 사용되는 리소스이다. 예를 들어, 데이터 처리, 백업, 일괄 처리와 같은 작업을 일정 횟수만큼 실행하고, 완료된 후에는 더 이상 실행되지 않도록 할 때 사용된다. Job은 Pod를 생성하여 작업을 실행하고, 작업이 끝나면 자동으로 종료된다. 만약 Job이 실패하면, 실패한 Pod를 다시 실행하여 작업을 재시도할 수 있다.

단일 작업 실행: Job은 지정된 작업을 한 번 실행하고, 해당 작업이 끝나면 종료된다. 주로 배치 작업에 사용된다.
재시도 전략: Job은 작업이 실패한 경우 자동으로 재시도할 수 있다. 실패한 Pod에 대해 최대 재시도 횟수를 설정할 수 있다..
병렬 실행: Job은 여러 개의 Pod를 병렬로 실행할 수 있다. 예를 들어, 데이터 처리 작업에서 여러 Pod가 병렬로 실행되도록 할 수 있다.
완료 상태 추적: Job은 완료 상태를 추적하고, 지정된 수의 Pod가 성공적으로 완료되면 Job이 완료된 것으로 간주된다.

Job Spec 필드

apiVersion: API 버전 (예: batch/v1).
kind: 리소스 종류 (예: Job).
metadata: 메타데이터로, Job의 이름, 레이블 등을 포함한다.
spec: Job의 동작을 정의하는 필드로, template, completions, parallelism 등이 포함된다.

작업 큐와 병렬 실행

단일 실행 작업 (Single Execution Job)

단일 파드 실행: 기본적으로 파드가 실패하지 않으면 하나의 파드만 실행된다.
완료 조건: 파드가 성공적으로 종료되면 즉시 잡이 완료된다. 이 방식은 병렬 처리를 사용하지 않고 순차적으로 작업을 처리하는 경우에 유용하다.

고정 완료 작업 (Fixed Completion Job)

.spec.completions: 이 설정에 양수 값을 지정하면, 지정된 개수만큼의 성공적인 파드 실행이 필요하다. 예를 들어 .spec.completions: 3으로 설정하면 3개의 성공적인 파드 실행이 완료되어야 잡이 종료된다.
completionMode 설정이 "Indexed"일 경우, 생성된 파드는 0부터 .spec.completions - 1 범위 내에서 고유한 인덱스를 갖게 됩니다. 예를 들어, .spec.completions=3이라면, 생성되는 파드는 index 0, index 1, index 2로 식별된다.
.spec.parallelism 값을 크게 설정해도, 남은 작업 수보다 더 많은 파드는 실행되지 않음

작업 큐 기반 병렬 작업 (Queue-based Parallel Job)

이 설정은 .spec.completions를 명시하지 않고, 대신 .spec.parallelism을 사용하여 파드를 병렬로 실행하며 각 파드는 독립적으로 작업을 수행한다.

.spec.parallelism: 병렬로 실행할 파드의 수를 지정한다. 이 값을 설정하면, 해당 수만큼의 파드가 동시에 실행된다.
작업 큐: 파드는 작업 큐에서 작업을 가져와 처리한다. 예를 들어, 큐에서 최대 N개의 항목을 일괄로 가져와 처리할 수 있다. 각 파드는 작업을 처리한 후 완료된 작업을 보고하고, 이 작업이 끝나면 다음 작업을 받아온다.
파드 간의 독립성: 각 파드는 다른 파드가 완료된 작업을 기다리지 않고, 독립적으로 자신이 맡은 작업을 수행한다. 작업이 완료되면 결과적으로 잡이 종료된다.
작업 완료 조건:
- 성공적인 종료: 모든 파드가 성공적으로 종료되면 잡이 완료되고, 더 이상 새로운 파드는 생성되지 않는다. 예를 들어, 5개의 파드가 병렬로 작업을 처리하고 있다고 할 때, 만약 5개의 파드가 모두 성공적으로 작업을 완료하면, 더 이상 추가로 파드를 만들지 않고 작업을 끝낸다
- 하나 이상의 파드가 성공적으로 종료된 경우:다른 파드들은 더 이상 작업을 계속하지 않으며, 출력도 작성하지 않아야 한다. 예를 들어, 만약 5개의 파드가 있고, 그 중 한 파드가 작업을 성공적으로 끝냈다면, 나머지 4개의 파드는 그 작업을 반복하지 않으며, 출력을 생성하지 않아야 한다는 규칙이다. 즉, 다른 파드들은 더 이상 실행할 일이 없으므로, 종료 상태로 들어가게 된다. 하지만 이미 실행 중인 다른 파드들은 자기 작업을 끝낼 떄까지 계속 실행된다.
- 모든 파드가 종료되면: 잡은 성공적으로 완료된 것으로 간주된다. 예를 들어, 5개의 파드가 있다고 할 때, 각 파드가 작업을 처리하고 종료되면, 모든 파드가 종료되었을 때 잡이 성공적으로 완료된 것으로 인정된다.

가정

5개의 파드가 있고, 각각은 작업 큐에서 데이터를 처리합니다.
만약 하나의 파드가 작업을 처리하고 끝내면, 그 파드는 종료되고, 다른 파드들은 더 이상 그 작업을 하지 않게 됩니다.

동작 순서

파드 1이 작업을 성공적으로 처리하고 종료됩니다.
파드 2는 파드 1이 끝난 후에는 더 이상 작업을 하지 않으며, 종료됩니다.
같은 방식으로 파드 3, 4, 5도 각각 종료된다.

결국 모든 파드가 종료되면 잡은 성공적으로 완료된 것이고, 더 이상 새로운 파드는 생성되지 않으며, 작업을 반복하지 않도록 한다.

이 방식은 병렬로 작업을 처리하면서도, 각 파드가 독립적으로 작업을 판단하고 처리하는 방식으로, 병렬 처리와 큐 기반 작업을 조합할 수 있다. Job이 완료되면 파드는 더 이상 생성되지 않지만, 기본적으로 Job 자체는 삭제되지 않는다. Job이 완료된 후 파드 로그를 통해 에러나 경고 메시지를 계속 확인할 수 있다. 필요시 kubectl delete 명령어로 Job을 삭제할 수 있다.

완료 모드 (Completion Mode)

완료 모드는 잡의 작업이 어떻게 완료될지를 결정한다.

completions: 3 일 경우에는 첫 번째 파드를 만들어서 실행한 후 종료하고, 두 번째 파드를 만들고 실행한 후 종료하고, 세 번 째 파드를 만들고 실행한 후 종료한다. 즉 작업의 완료 횟수가 3번 이라는 뜻이다.

completions 의 수는 parallelism 의 수 보다 많아야 한다.

완료 횟수가 고정적인 완료 횟수 즉, null이 아닌 .spec.completions 가 있는 잡은 .spec.completionMode 에 지정된 완료 모드를 가질 수 있다.

NonIndexed (기본값): .spec.completions 값에 명시된 완료 횟수에 대해 각 파드의 완료가 동등(homologous)하게 취급된다. 즉, 파드들이 순차적으로 완료되면 작업이 완료된 것으로 간주된다. .spec.completions가 명시되지 않으면 기본적으로 이 모드가 사용된다.
Indexed: 각 파드는 0에서 .spec.completions - 1까지의 인덱스를 부여받는다. 이 인덱스는 작업을 완료한 파드를 추적하는 데 사용되며, 각 파드가 인덱스 번호를 기준으로 완료 상태를 관리된다. 예를 들어, .spec.completions: 3일 경우, 첫 번째 파드는 0번 인덱스를, 두 번째 파드는 1번, 세 번째 파드는 2번 인덱스를 부여받는다. 각 파드가 성공적으로 완료되면 작업이 끝난 것으로 간주된다.
- 파드 어노테이션: batch.kubernetes.io/job-completion-index를 통해 인덱스를 확인할 수 있다.
- 호스트네임: 파드의 호스트네임 형식이 $(job-name)-$(index) 형태일 수 있다.
- 환경 변수: JOB_COMPLETION_INDEX라는 환경 변수를 통해 인덱스를 전달할 수도 있다.

정리

completions 설정
- .spec.completions: 3일 경우, 작업이 완료될 횟수는 3번이다.
- 첫 번째 파드를 실행하고 종료, 두 번째 파드를 실행하고 종료, 세 번째 파드를 실행하고 종료하는 방식으로 진행된다.
completions 값과 parallelism의 관계
- completions 값은 parallelism 값보다 크거나 같아야 한다.
- 예를 들어, completions: 3, parallelism: 2일 경우 2개의 파드가 동시에 실행되며, 3개의 작업을 완료하기 위해 순차적으로 진행된다.
고정적인 완료 횟수
- 고정적인 완료 횟수는 .spec.completions 값이 null이 아닌 경우를 말한다.
- 이 경우, 작업을 완료하는 파드의 수가 정해져 있으며, 각 파드가 완료될 때마다 작업이 끝났다고 판단한다.
완료 모드 (.spec.completionMode)
- .spec.completions가 설정된 잡은 .spec.completionMode에 따라 작업을 완료하는 방식이 달라진다.
  - NonIndexed (기본값): 각 파드가 완료될 때마다 작업이 완료된 것으로 간주한다.
  - Indexed: 각 파드에 인덱스를 부여하여 해당 인덱스의 파드가 완료될 때 작업이 완료된 것으로 간주한다.

파드와 컨테이너 장애 처리

파드 내에서 컨테이너가 장애를 겪을 수 있는 다양한 이유가 있다. 예를 들어, 컨테이너의 프로세스가 비정상적으로 종료되거나, 메모리 제한을 초과하여 종료되는 경우이다.

컨테이너 재시작 정책 (restartPolicy)

restartPolicy: "OnFailure":
- 컨테이너가 실패하면 해당 파드는 계속 노드에 남아있지만, 컨테이너는 재시작된다. 이는 파드 내에서 프로그램이 실패할 때, 이를 로컬에서 처리할 수 있도록 해준다.
- 예를 들어, 컨테이너가 종료 코드가 0이 아닌 값으로 종료되거나, 메모리 제한을 초과하면 컨테이너는 자동으로 재시작된다.
restartPolicy: "Never":
- 컨테이너가 실패하면 더 이상 재시작되지 않으며, 파드 자체도 삭제되지 않는다. 즉, 파드는 더 이상 재시작되지 않지만, 종료된 상태로 남는다.
주의: restartPolicy: "Never"로 설정하면 파드가 실패한 후, 잡 컨트롤러가 새로운 파드를 시작합니다. 이때, 새로운 파드에서 애플리케이션을 재시작할 때 이전 실행에서 발생한 임시 파일, 잠금, 불완전한 출력 등을 처리해야 할 수 있다.

동시성 관리 (spec.parallelism과 spec.completions)

spec.parallelism과 spec.completions가 1보다 큰 값으로 설정되면 여러 개의 파드가 동시에 실행될 수 있다. 이 경우, 파드는 동시성을 고려한 설계를 해야 한다. 즉, 여러 파드가 동시에 실행되더라도 안전하게 동작하도록 처리해야 한다.

파드 백오프(Backoff) 실패 정책

백오프 제한 (spec.backoffLimit): 잡의 실패 파드가 일정 횟수까지 재시도되도록 설정할 수 있다. 기본값은 6으로 설정되어 있으며, 잡은 최대 6번까지 재시도를 시도하고 실패하면 종료됩니다.
- 백오프 시간은 기하급수적으로 증가한다. 예를 들어 10초, 20초, 40초 등으로 시간이 늘어난다.
- 만약 잡에 실패한 파드가 존재하면, 잡 컨트롤러는 재시도를 시도하다가 백오프 한계에 도달하면 해당 파드의 실행을 중지한다.
주의 사항:
- restartPolicy = "OnFailure"로 설정된 경우, 백오프 한도에 도달하면 잡이 실패한 파드를 종료합니다. 이는 디버깅을 어렵게 만들 수 있다.
- 실패한 작업의 결과가 손실되지 않도록 하려면 restartPolicy = "Never"로 설정하고 로깅 시스템을 사용하는 것이 좋다.

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    metadata:
      labels:
        app: my-job
    spec:
      containers:
      - name: my-container
        image: busybox
        command: ["sh", "-c", "echo Hello Kubernetes! && sleep 30"]
      restartPolicy: Never
  completions: 3
  parallelism: 2
  backoffLimit: 4

spec.template: 파드 템플릿을 정의하는 필드로, 이 안에 파드의 컨테이너 정의가 포함된다. 여기서 restartPolicy: Never로 설정하여 파드가 실패해도 다시 시작되지 않게 설정한다.
completions: Job이 완료되기 위해 필요한 파드의 성공적인 완료 수를 설정한다. 여기서는 3번을 설정했다..
parallelism: 병렬로 실행할 파드의 최대 수를 설정한다. 여기서는 2로 설정하여 동시에 최대 2개의 파드가 실행된다.
backoffLimit: 실패한 파드를 재시도할 최대 횟수를 설정한다. 기본값은 6이며, 이는 재시도 횟수가 6번에 도달하면 Job이 실패한 것으로 간주된다는 의미를 가진다.

완료된 잡 정리

잡 완료 후 파드 상태
잡이 완료되면 새로운 파드가 생성되지 않지만, 파드는 일반적으로 삭제되지 않는다. 완료된 파드를 그대로 두면 로그를 계속 확인할 수 있어 에러, 경고, 진단 출력을 확인할 수 있다. 상태 확인 후 이전 잡을 삭제하는 것은 사용자의 몫이다. 삭제는 kubectl delete jobs/<job-name> 명령어로 할 수 있다. 이때 해당 잡에서 생성된 모든 파드도 함께 삭제된다.
잡의 실패와 재시도
잡은 기본적으로 실패하지 않는 한 계속 실행된다. 실패 조건은 restartPolicy=Never로 설정된 파드의 실패 또는 restartPolicy=OnFailure로 종료된 컨테이너이다. restartPolicy=OnFailure로 종료된 경우 잡은 .spec.backoffLimit에 설정된 최대 재시도 횟수까지 재시도하며, 백오프 제한에 도달하면 잡은 실패 상태로 표시되고 실행 중인 모든 파드는 종료된다.
잡의 종료 조건
유효 데드라인 설정: .spec.activeDeadlineSeconds를 설정하면, 잡의 유효 시간이 초 단위로 제한된다. 이 시간에 도달하면 실행 중인 모든 파드가 종료되고, 잡의 상태는 reason: DeadlineExceeded와 함께 type: Failed가 된다. activeDeadlineSeconds는 .spec.backoffLimit보다 우선한다. 즉, 백오프 한도에 도달하지 않았더라도, 유효 시간(activeDeadlineSeconds)이 도달하면 추가 파드를 배포하지 않는다.

apiVersion: batch/v1
kind: Job
metadata:
  name: node-app-with-timeout
spec:
  backoffLimit: 3
  activeDeadlineSeconds: 120
  template:
    spec:
      containers:
      - name: node-app
        image: node:14
        command: ["node", "-e", "setInterval(() => console.log('Running...'), 1000);"]
      restartPolicy: Never

backoffLimit: 3으로 설정되어 있어, 잡이 최대 3번까지 실패할 때까지 재시도한다.
activeDeadlineSeconds: 120으로 설정되어 있어, 잡이 120초(2분) 동안 실행되면 종료된다. 이 시간이 지나면 실행 중인 모든 파드는 종료되고, 잡의 상태는 Failed로 표시된다.
restartPolicy: Never로 설정되어 있어, 컨테이너가 종료되면 자동으로 재시작되지 않는다.

완료된 잡을 자동으로 정리(TTL 메커티즘)

완료된 잡은 더 이상 시스템에서 필요하지 않으므로, 이를 유지하는 것은 API 서버에 불필요한 부담을 주게 된다.크론잡(CronJob)과 같은 상위 레벨 컨트롤러가 잡을 직접 관리하는 경우, 지정된 용량 기반 정리 정책에 따라 잡을 정리할 수 있다.

완료된 잡을 자동으로 정리하는 또 다른 방법은 ttlSecondsAfterFinished 필드를 사용하는 것이다. 이 필드를 설정하면, 잡이 완료된 후 일정 시간이 지나면 자동으로 정리되도록 TTL(Time To Live) 컨트롤러가 관리한다. TTL 컨트롤러는 잡을 삭제하면서 해당 잡에 종속된 리소스들(예: 파드)을 계단식으로 삭제한다. 즉, 잡을 삭제하면 파드와 같은 관련된 리소스들이 함께 정리됩니다. TTL 컨트롤러는 finalizer와 같은 라이프사이클 보증을 보장한다. 즉, 정리 작업이 끝날 때까지 리소스들이 정상적으로 삭제된다.

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processing-job
spec:
  ttlSecondsAfterFinished: 60
  template:
    spec:
      containers:
      - name: data-processor
        image: ubuntu
        command: ["bash", "-c", "echo 'Processing data...'; sleep 30; echo 'Data processed'"]
      restartPolicy: Never

ttlSecondsAfterFinished: 60: 이 잡은 60초가 지난 후 자동으로 삭제된다. 즉, 잡이 완료되고 60초가 지나면 TTL 컨트롤러가 이 잡을 정리한다.

activeDeadlineSeconds vs ttlSecondsAfterFinished

activeDeadlineSeconds: 잡이 실행된 후, 설정된 시간 내에 완료되지 않으면 강제로 종료되며, 그 상태는 Failed가 된다. 잡이 시작된 시점부터 경과한 시간으로 종료 여부가 결정된다.

ttlSecondsAfterFinished: 잡이 완료된 후, 지정된 시간이 지나면 자동으로 삭제된다. 잡의 상태가 Complete 또는 Failed로 변경된 후 경과한 시간으로 리소스 삭제 여부가 결정된다.

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    metadata:
      labels:
        app: my-job
    spec:
      containers:
      - name: my-container
        image: busybox
        command: ["sh", "-c", "echo Hello Kubernetes! && sleep 30"]
      restartPolicy: Never
  completions: 3
  parallelism: 2
  backoffLimit: 4

spec.template: 파드 템플릿을 정의하는 필드로, 이 안에 파드의 컨테이너 정의가 포함된다. 여기서 restartPolicy: Never로 설정하여 파드가 실패해도 다시 시작되지 않게 설정한다.
completions: Job이 완료되기 위해 필요한 파드의 성공적인 완료 수를 설정한다. 여기서는 3번을 설정했다..
parallelism: 병렬로 실행할 파드의 최대 수를 설정한다. 여기서는 2로 설정하여 동시에 최대 2개의 파드가 실행된다.
backoffLimit: 실패한 파드를 재시도할 최대 횟수를 설정한다. 기본값은 6이며, 이는 재시도 횟수가 6번에 도달하면 Job이 실패한 것으로 간주된다는 의미를 가진다.

CronJob

CronJob은 Kubernetes에서 주기적으로 실행되는 잡을 관리하는 리소스이다. 리눅스의 cron과 유사하게, 특정 시간이나 주기로 작업을 자동으로 실행할 수 있도록 해준다. 예를 들어, 매일 자정에 특정 작업을 실행하거나, 매주 월요일에 백업을 실행하는 등의 작업을 설정할 수 있다. CronJob은 Job 리소스를 주기적으로 실행시키는 역할을 하며, cron 표현식을 사용해 주기적인 실행 스케줄을 설정할 수 있다. CronJob은 주어진 시간에 잡을 생성하고 실행시키며, Job 리소스의 특성을 그대로 가진다.

CronJob의 주요 필드

schedule: cron 표현식으로, 작업이 실행될 주기를 설정한다.
jobTemplate: 실행할 잡의 템플릿으로, Job의 사양을 포함한다.
successfulJobsHistoryLimit: 성공적으로 완료된 잡의 개수를 보관할 수 있는 한도를 설정한다.
failedJobsHistoryLimit: 실패한 잡의 개수를 보관할 수 있는 한도를 설정한다.
startingDeadlineSeconds: CronJob이 시작해야 할 최대 지연 시간이다. 지정된 시간 내에 시작하지 않으면 건너뛰게 된다.

Cron 표현식

CronJob의 schedule 필드는 Cron 표현식을 사용하여 설정한다. 예시로, 아래와 같은 형식으로 주기를 지정할 수 있다.

* * * * *
| | | | |
| | | | +---- 주 (0 - 6) (0 = 일요일)
| | | +------ 월 (1 - 12)
| | +-------- 일 (1 - 31)
| +---------- 시 (0 - 23)
+------------ 분 (0 - 59)

예를 들어

*/5 * * * * : 5분마다 실행
0 0 * * * : 매일 자정에 실행
0 12 * * 1 : 매주 월요일 12시에 실행

예시: 매일 자정에 백업 실행

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
spec:
  schedule: "0 0 * * *"  # 매일 자정에 실행
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup-container
            image: my-backup-image
            command: ["bash", "-c", "echo 'Running daily backup'"]
          restartPolicy: OnFailure
  successfulJobsHistoryLimit: 3  # 성공적인 잡은 최대 3개까지 보관
  failedJobsHistoryLimit: 1      # 실패한 잡은 최대 1개까지 보관

schedule: "0 0 * * *": 이 CronJob은 매일 자정(00:00)에 실행된다.
restartPolicy: OnFailure: 컨테이너가 실패했을 때만 재시작하도록 설정됩니다.
successfulJobsHistoryLimit와 failedJobsHistoryLimit: 각각 성공적인 잡과 실패한 잡의 보관 개수를 설정한다. successfulJobsHistoryLimit이 3이면, 가장 최근의 3번의 성공한 잡만 보관되고, 그 이상은 삭제된다.

예시: 매주 월요일에 시스템 점검 작업 실행

apiVersion: batch/v1
kind: CronJob
metadata:
  name: weekly-system-check
spec:
  schedule: "0 0 * * 1"  # 매주 월요일 자정에 실행
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: system-check
            image: my-system-check-image
            command: ["bash", "-c", "echo 'Running weekly system check'"]
          restartPolicy: OnFailure
  successfulJobsHistoryLimit: 2  # 성공적인 잡은 최대 2개까지 보관
  failedJobsHistoryLimit: 1      # 실패한 잡은 최대 1개까지 보관

schedule: "0 0 * * 1": 이 CronJob은 매주 월요일 자정(00:00)에 실행된다.

'kubernetes' 카테고리의 다른 글

[Kubernetes] StatefulSet (0)	2024.12.10
[kubernetes] deployment (0)	2024.12.10
[Kubernetes] Ambassador Pod Design Pattern (0)	2024.12.05
[Kubernetes] Configmap & Secret (0)	2024.12.05
[Kubernetes] Volume(PV, PVC) (0)	2024.12.04