LabHub

KCNA — 쿠버네티스·클라우드 네이티브 입문 · 컨테이너 오케스트레이션과 워크로드 · 실습

파드에서 셀프힐링까지

LabHub 에서 이어서 보기

목표

파드 하나를 손으로 띄우는 것에서 시작해 Deployment·Job·CronJob·DaemonSet 을 각각 만들어 보고,
소유 관계(ownerReferences)를 따라가 본 뒤, 파드를 일부러 지워 셀프힐링이 실제로 도는 것을
삭제 전후 목록으로 증명합니다.

왜 중요한가

현장에서 파드를 직접 만드는 일은 거의 없습니다. 그런데도 파드를 이해해야 하는 이유는,
모든 워크로드 컨트롤러가 결국 파드 템플릿을 들고 있는 껍데기이기 때문입니다.
Deployment 의 문제는 대부분 파드 템플릿의 문제입니다.

컨트롤러를 고르는 기준은 하나로 요약됩니다 — 이 프로세스는 스스로 끝나는가. 끝나지 않는 서비스에
Job 을 쓰면 영원히 완료되지 않고, 끝나는 배치에 Deployment 를 쓰면 종료할 때마다 재시작되어
CrashLoopBackOff 처럼 보입니다. 실제로 신입이 가장 자주 만드는 사고입니다.

마지막 단계가 이 실습의 핵심입니다. "파드를 지우면 다시 생긴다"는 말은 다들 알지만, **돌아온 파드가
같은 파드가 아니라는 것**을 눈으로 본 사람은 적습니다. 이름이 달라진다는 사실 하나가
"파드 이름에 의존하지 마라", "상태를 파드 안에 두지 마라" 같은 원칙 전부의 근거입니다.

단계

1. 네임스페이스 kcna-work 를 만들고 그 안에 이미지 nginx:1.27-alpine 인 파드 hello 를 만들어 Running 까지 갑니다.
2. 같은 네임스페이스에 Deployment web 을 만듭니다. 이미지는 nginx:1.27-alpine, replicas 는 3, 파드 템플릿 라벨은 app=web 입니다.
3. web 의 replicas 를 5 로 늘리고 5 개가 모두 Ready 가 될 때까지 기다립니다.
4. web 이 만든 ReplicaSet 의 이름을 /root/kcna-work/rs-name.txt 에 한 줄로 저장하고, web 의 파드 하나를 골라 그 파드의 metadata.ownerReferences[0].kind 값을 /root/kcna-work/owner.txt 에 한 줄로 저장합니다.
5. 같은 네임스페이스에 Job report 를 만듭니다 — 이미지 busybox:1.36, completions 는 3. 그리고 CronJob nightly 를 만듭니다 — schedule 은 매일 03:00 (0 3 * * *).
6. 같은 네임스페이스에 DaemonSet node-agent 를 만듭니다. 이미지는 busybox:1.36 이고, 컨테이너가 바로 종료되지 않도록 오래 도는 명령을 주세요.
7. 셀프힐링을 증명합니다. (a) web 의 파드 이름 5 개를 /root/kcna-work/before.txt 에 저장하고, (b) 그중 하나를 지운 뒤 지운 이름을 /root/kcna-work/deleted.txt 에 한 줄로 저장하고, (c) 새 파드가 Ready 가 된 다음 파드 이름 5 개를 /root/kcna-work/after.txt 에 저장합니다.

참고

단계 7개

  1. 첫 파드 띄우기
  2. Deployment 로 파드 관리 맡기기
  3. 레플리카 수 바꾸기
  4. 소유 관계 따라가기
  5. 끝나는 일: Job 과 CronJob
  6. 노드마다 하나: DaemonSet
  7. 파드를 지워 셀프힐링 증명하기