설정과 동작 사이

한 줄 요약

프로브·Job·QoS·설정 주입은 전부 kubelet 이 하는 일입니다. kubelet 이 없으면 YAML 을 쓰는 연습은 되지만 그것이 무엇을 하는지는 끝까지 못 봅니다.

왜 동작으로 봐야 하나

CKAD 는 "애플리케이션이 클러스터 위에서 어떻게 살아가는가" 를 묻습니다. 프로브, Job, QoS, 설정 주입이 전부 그 이야기입니다.

그런데 앞 모듈들이 도는 가짜 클러스터에는 kubelet 이 없어서 그 중 어느 것도 실제로 일어나지 않습니다. 프로브를 걸어도 돌지 않고, Job 을 만들어도 완료되지 않으며, ConfigMap 은 마운트되지 않습니다.

프로브 세 가지의 관계

| 프로브 | 묻는 것 | 실패하면 |
|---|---|---|
| startupProbe | 기동이 끝났나 | 나머지 둘을 계속 미룬다 |
| livenessProbe | 살아 있나 | 컨테이너를 다시 만든다 |
| readinessProbe | 요청을 받을 수 있나 | 엔드포인트에서 뺀다 |

startupProbe 가 성공할 때까지 나머지 둘은 아예 시작하지 않습니다. 이것이 없으면 선택지가 둘뿐입니다.

• liveness 를 느슨하게 → 진짜로 죽었을 때 오래 방치됩니다
• liveness 를 촘촘하게 → 기동 중에 죽어 영원히 재시작합니다

Job 의 두 값

completions 는 몇 번 성공해야 하나, parallelism 은 몇 개를 동시에 돌리나 입니다. 헷갈리면 Job 이 영영 안 끝나거나 필요 이상으로 자원을 씁니다.

backoffLimit 은 재시도 간격이 지수적으로 늘어나므로, 기본값 6 이면 포기하기까지 몇 분이 걸립니다. 그 사이 실패한 파드가 계속 쌓입니다.

QoS 는 지정하는 것이 아니다

qosClass 필드를 직접 쓸 수 없습니다. requests 와 limits 의 조합으로 kubelet 이 매깁니다. 그리고 노드에 메모리가 모자라면 BestEffort 부터 쫓겨납니다.

실무에서 진짜 중요한 것

기동이 느린 앱에는 startupProbe 를 답으로 씁니다. 이것이 없으면 선택지가 둘뿐입니다 — liveness 를 느슨하게 해서 진짜 죽었을 때 오래 방치하거나, 촘촘하게 해서 기동 중에 죽여 영원히 재시작하거나. 세 번째 프로브가 그 딜레마를 없애려고 생겼습니다.

backoffLimit 기본값 6 은 생각보다 깁니다. 재시도 간격이 지수적으로 늘어나 포기하기까지 몇 분이 걸리고, 그 사이 실패한 파드가 계속 쌓입니다. 빨리 실패해야 하는 Job 은 값을 낮춰야 합니다.

QoS 는 쓰는 것이 아니라 매겨지는 것입니다. requests 와 limits 의 조합으로 kubelet 이 정하고, 노드에 메모리가 모자라면 BestEffort 부터 쫓겨납니다. 중요한 워크로드에 requests 를 안 적는 것은 "먼저 죽여도 된다" 고 적는 것과 같습니다.

다음 실습에서 이것들을 전부 동작으로 확인합니다.