[TIL]Kubernetes 핵심 컴포넌트 & 워크로드 컨트롤러-2025.09.05

한 줄 요약:
Control Plane(ETCD, API Server, Controller, CoreDNS) 흐름과 kube-proxy 역할을 이해하고, Job / CronJob / DaemonSet / Headless Service / StatefulSet의 “언제, 왜, 어떻게”를 실무 관점으로 정리.

목차

1. 클러스터 핵심 컴포넌트 흐름 이해
2. Job / CronJob / DaemonSet / Headless Service / StatefulSet
3. 실습 루틴(명령 스니펫)
4. 헷갈리는 포인트 정리
5. 현업 연결 포인트
6. 내일 실습 로드맵
7. 셀프 체크 퀴즈

 

1) 클러스터 핵심 컴포넌트 흐름 이해

• API Server: 모든 요청의 관문(인증/인가/검증).
• etcd: 클러스터 상태 저장소(키-값).
• Controller Manager: 원하는 상태(스펙)와 실제 상태의 차이를 감시하고 조치(Watch 루프).
• CoreDNS: 서비스명 → IP 해석.
• kube-proxy: Pod 트래픽을 실제 백엔드로 라우팅(iptables/IPVS 규칙 구성).

이해 포인트: “요청 → API Server → 상태는 etcd → Controller가 보정 → 네트워크는 CoreDNS+kube-proxy로 연결”

 

2) 워크로드 컨트롤러

A. Job — 끝이 있는 작업 실행기

• 언제 쓰나? ETL, 백업, 배치 메일처럼 “성공 후 종료”가 목표일 때.
• 핵심 스펙
  • completions: 총 성공 횟수
  • parallelism: 동시 실행 개수
  • backoffLimit: 실패 재시도 횟수
  • restartPolicy: OnFailure 또는 Never
• 메모: Job이 만든 Pod는 완료 후에도 남아 로그/결과 확인에 유용(자동 정리 정책 별도).

B. CronJob — 스케줄러가 Job을 주기적으로 생성

• 언제 쓰나? “매일 02:00 백업” 같은 주기 작업 자동화.
• 핵심 스펙
  • schedule: Cron 표현식 ("0 2 * * *" 등)
  • concurrencyPolicy: Allow / Forbid / Replace
  • successfulJobsHistoryLimit / failedJobsHistoryLimit: 히스토리 관리
• 팁: 중복 실행 위험이 있으면 Forbid 또는 Replace로 제어.

C. DaemonSet — 모든(또는 특정) 노드마다 1개씩

• 언제 쓰나? 로그 수집기, 모니터링 에이전트, CNI/스토리지 데몬.
• 특징: 새 노드가 합류하면 자동으로 해당 노드에도 Pod 생성.
• 실무 팁: 컨트롤 플레인 노드에도 돌리고 싶으면 tolerations/nodeSelector 조합.

D. Headless Service — 로드밸런싱 없이 Pod 개별 식별

• 정의: spec.clusterIP: None → VIP 없이, DNS 질의 시 각 Pod의 실제 IP 목록 반환.
• 언제 쓰나?
  • StatefulSet과 결합해 고유 DNS로 각 Pod 직접 접근
  • 분산 시스템 피어 디스커버리
  • 클라이언트 사이드 로드밸런싱 구현

E. StatefulSet — 상태 있는 앱을 위한 3가지 보장

1. 안정적 네트워크 신원: <name>-<ordinal> (예: db-0, db-1) 유지
2. 안정적 스토리지: Pod별 고유 PVC 자동 생성/재연결
3. 순차적 롤아웃/종료: 0→1→2…로 올라오고 역순으로 내려감

• 보통 필수: Headless Service(serviceName)와 함께 사용
• 적합 사례: DB, 메시지 큐, 상태 저장 분산 시스템
• 비유: Deployment는 “가축(Cattle)”, StatefulSet은 “반려동물(Pets)”.

 

3) 실습 루틴(명령 스니펫)

Job

 

kubectl apply -f my-job.yaml
kubectl get jobs,pods
kubectl logs <job-pod>

CronJob

 

kubectl apply -f my-cronjob.yaml
kubectl get cronjobs
kubectl get jobs --watch
# 예: 매일 02:00 실행 (로컬 타임존 기준 설정 확인)
# schedule: "0 2 * * *"

DaemonSet

 

kubectl apply -f daemonset-example.yaml
kubectl get pods -o wide -l app=my-daemon
# 노드 추가/삭제 시 파드 증감 확인

Headless Service + StatefulSet

 

kubectl apply -f statefulset-svc.yaml # spec.clusterIP: None
kubectl apply -f statefulset.yaml # spec.serviceName: statefulset-svc
kubectl get endpoints statefulset-svc
# Pod 내부에서 DNS 확인
nslookup statefulset-svc
nslookup statefulset-0.statefulset-svc.default.svc.cluster.local

StatefulSet 스케일/순서 관찰

 

kubectl scale --replicas=4 statefulset/my-app
watch kubectl get pods kubectl scale --replicas=2
statefulset/my-app

4) 헷갈리는 포인트 정리

• Deployment vs StatefulSet
  • 교체 가능(무상태) 복제 서비스면 Deployment
  • 고유 신원/스토리지/순차 롤아웃이 필요하면 StatefulSet
• ClusterIP Service vs Headless Service
  • 단일 진입점+LB 필요: ClusterIP
  • Pod 개별 식별/직접 연결: Headless
• DaemonSet vs Deployment
  • “노드마다 하나” 에이전트: DaemonSet
  • 일반 앱 복제/확장: Deployment
• CronJob 동시 실행 제어
  • 이미 돌고 있으면 막기: concurrencyPolicy: Forbid
  • 새 작업이 이전 것을 대체: Replace
• Job 실패/재시도
  • backoffLimit, activeDeadlineSeconds로 제어

 

5) 현업 연결 포인트

• 로그/모니터링 표준 패턴: DaemonSet(fluent-bit/Vector/Node Exporter) + 중앙 수집기
• DB 운영 패턴: StatefulSet + Headless Service + PVC로 안정적 신원/데이터 보장
• 운영 자동화: CronJob으로 백업, 리포트, 캐시 청소, 인증서 갱신

 

6) 실습 로드맵 

1. nginx StatefulSet + PVC
   • Pod별 pod.html에 서로 다른 텍스트 기록 → 재스케줄 후에도 유지 확인
2. Headless DNS 체감
   • 각 Pod FQDN으로 curl → 라운드로빈이 아닌 개별 주소 접근 확인
3. DaemonSet
   • 간단 에이전트 배포 → 노드 추가/삭제 시 파드 자동 증감 관찰
4. CronJob 정책 실험
   • concurrencyPolicy/히스토리 제한 변경 → 동작 비교
5. Job 파라미터 실험
   • completions/parallelism/backoffLimit 조합별 실행 패턴 비교

 

7) 셀프 체크 퀴즈

1. Headless Service가 필요한 대표 이유 2가지(힌트: 디스커버리/직접 연결)는?
2. StatefulSet이 Deployment와 다른 3가지 보장은?
3. CronJob에서 이전 작업이 돌고 있을 때 새 작업을 막으려면 어떤 옵션을 써야 할까?
4. DaemonSet이 “모든 노드 1개씩”을 보장하는 이유와 대표 사용 사례 2개는?
5. Job에서 completions=10, parallelism=2일 때 실행 패턴은? 실패 재시도는 무엇으로 제어하나?

 

마무리(느낀 점)

핵심은 “언제 무엇을 쓰는지 구분”

• 무상태/복제는 Deployment, 상태/고유성은 StatefulSet
• 모든 노드 에이전트는 DaemonSet
• “끝이 있는 일”은 Job, “주기적”이면 CronJob
• “LB 없이 Pod를 직접 찾고 싶다”면 Headless Service