[Cloud] Kubernetes Volumes III (Downward API, Job, CronJob, DaemonSet)

Downward API

• Pod가 자기 자신의 정보(이름, IP, label 등)를 ConfigMap이나 Secret에 미리 정의하지 않고도 런타임에 가져올 수 있게 해주는 기능
• 핵심 개념: k8s 마스터 서버를 통하지 않고, 환경 변수나 볼륨 파일을 통해 포드/컨테이너의 메타데이터를 주입하는 방식
  • 환경 변수: 개별적인 값을 하나씩 변수에 할당할 때 사용 (가장 흔한 방식)
  • 볼륨 마운트: 정보를 파일 형태로 제공하여 label이나 annotation처럼 내용이 수시로 변할 수 있는 정보를 실시간으로 반영하기에 좋음

• 응용 프로그래머들이 자주 사용함
  • ex1) Redis, MongoDB 같은 분산 시스템을 구축할 때
  • ex2) 모니터링을 위해 여러 Pod에서 로그를 수집할 때
  • ex3) JVM이나 Node.js에서 리소스 제한에 따른 동적 메모리 설정을 할 때

Downward API를 통해 전달할 수 있는 정보

metadata.labels, metadata.annotations는 볼륨 파일로만 접근 가능한 이유

1. labels, annotations는 Key-Value 쌍의 집합이기 때문에, 환경 변수 하나에 이 수많은 목록을 다 집어넣기 힘듦
2. labels는 Pod가 실행 중에도 바뀔 수 있음
   • 환경 변수: 한 번 실행되면, 프로세스를 재시작하지 않는 이상 바꿀 수 없음
   • 볼륨 파일: 쿠버네티스가 파일 내용을 실시간으로 업데이트해 줌

 

Using Downward API with Volume Mount

Pod Field(only Volume Mount)

• labels, annotations로 metadata.labels, metadata.annotations 환경 변수로 설정
• "kubectl exec -it 'pod 이름' -- /bin/bash"로 Pod 안에 들어가서 Volume Mount 경로에 있는 파일 확인

Using Downward API with Environment Variables (1)

Pod Field(Both)

• spec.nodeName을 NODE_NAME에 저장하는 방식
• metadata.name, metadata.namespace, metadata.uid, spec.serviceAccountName, status.hostIP, status.podIP 들은 Volume mount로도 가능
• "kubectl exec -it 'pod 이름' -- env"로 환경변수 확인

Using Downward API with Environment Variables (2)

Container Field(Both)

• 컨테이너 필드 메타데이터(requests.cpu, requests.memory, limits.cpu)는 환경 변수, 볼륨 파일 모두 가능
• "kubectl exec -it 'pod 이름' -- env"로 환경변수 확인

Downward API는 Pod 내의 컨테이너가 자신이 실행 중인 K8s 환경을 스스로 인식할 수 있게 해주는 가장 가볍고 안전한 방법

---

Job, CronJob

• 필요 상황: Pod를 한 번만 돌리고 사라지게 하고 싶을 때 (ex. 백업 한 번 하고 잔여 파일 삭제)
• Job: 일회성 작업을 수행하기 위한 리소스
• CronJob: 주기적인 작업을 수행하기 위한 리소스

 

Job

• 특징
  • 성공적인 실행 보장: 지정된 작업이 성공적으로 완료될 때까지 Pod를 재시작 
  • 동시성 설정: 동시에 실행할 수 있는 Pod 수 조정 가능
  • 완료 상태 관리: 작업 완료 후 상태 확인 가능
• 사용 사례
  
  • 데이터 처리 Batch 작업
  • 백업 및 복원 작업
  • AI/ML Training(학습) Task
  • DB Migration

Job 구조 (시험 X)

• restartPolicy: 실패 시 컨테이너를 다시 살릴 것인가, 아니면 포드를 새로 만들 것인가?
  • OnFailure: 실패 시 재시작 (컨테이너 수준의 재시작)
  • Never: 실패 시 포드 새로 생성 (Pod 수준의 재시작)
• backoffLimit: Job 컨트롤러가 "이 작업은 가망이 없다"라고 판단하고 포기하기 전까지의 재시도 횟수
  • restartPolicy: Never인 경우: 실패한 Pod의 개수가 backoffLimit에 도달하면 종료, Job 실패 처리
  • restartPolicy: OnFailure인 경우: 컨테이너의 재시작 횟수가 backoffLimit에 도달하면 해당 Pod를 종료, Job 실패 처리

 

CronJob

• Job 리소스에 스케줄을 추가하여 주기적으로 실행되는 Job
• Linux의 crontab 기능과 유사하게 특정 시간 및 주기에 맞춰 작업 수행 가능
• 사용 사례
  
  • 정기적인 데이터 백업
  • 로그 파일 정리
  • 정해진 시간에 반복적으로 수행되는 작업
• 특징
  • 지속적으로 주기적인 작업 실행
  • 일정에 맞게 Job을 생성하도록 실행 주기 설정 가능

CronJob 구조

• Scheduling: * * * * * (분 시 일 월 요일) 형식을 사용

 

Job & CronJob이 실패했을 때 어떻게 될 것인가?

---

DaemonSet

• 클러스터 내의 모든(혹은 특정 조건에 맞는) 노드에 Pod를 딱 하나씩 배치하는 리소스
  • Node당 딱 하나만 만들어서 백그라운드에서 돌면서 뭔가 해야 할 일이 주어짐
• 동작 방식
  • 새로운 노드가 클러스터에 추가되면 DaemonSet Pod가 자동으로 그 노드에 생성됨
  • 노드가 삭제되면 해당 Pod는 Garbage Collection으로 작동
  • RollingUpdate를 통해 노드별로 순차적인 업데이트가 가능
• 사용 사례
  • 로그 수집기: 각 노드에서 발생하는 로그를 수집하여 중앙으로 전송
  • 노드 모니터링: 각 노드의 리소스 상태를 감시
  • 네트워크 플러그인: 쿠버네티스 네트워킹을 관리