진짜 고장을 만들고 읽는다

이 실습은 진짜 고장이 나는 클러스터에서 돕니다

VM 안에 진짜 k3s 가 떠 있습니다. kubelet 과 containerd 가 실제로 돌기
때문에, 이미지를 못 받으면 ImagePullBackOff 가 뜨고, 프로세스가 죽으면
CrashLoopBackOff 가 되며, 메모리를 넘기면 정말로 OOMKilled 됩니다.

CKA 과정의 다른 실습이 도는 가짜 클러스터에서는 **이 증상들을 만들 수조차
없습니다.** 그래서 지금까지는 글로만 배웠습니다.

처음 뜨는 데 2분쯤 걸립니다.

목표

고장 여섯 가지를 일부러 만들고, 각각을 어디서 어떻게 읽어 내는지
손으로 익힙니다. 마지막에 분류표 하나로 정리합니다.

왜 중요한가

문제 해결은 지식이 아니라 반사 신경입니다. kubectl get pod 에 뜬 글자를
보고 3초 안에 "다음에 볼 곳" 이 떠올라야 합니다.

그리고 비슷해 보이는 증상들이 원인은 완전히 다릅니다.

• Pending 과 ContainerCreating 은 둘 다 "아직 안 떴다" 지만, 전자는 스케줄러의 문제이고 후자는 kubelet 의 문제입니다.
• liveness 실패와 readiness 실패는 둘 다 "프로브가 실패했다" 지만, 전자는 재시작을 부르고 후자는 트래픽에서만 뺍니다.
• 없는 ConfigMap 을 env 로 참조하면 CreateContainerConfigError 이고, 같은 것을 볼륨으로 참조하면 Pending 입니다.

이 구분들은 외워지지 않습니다. 직접 만들어 봐야 몸에 남습니다.

단계

모든 파드는 broken 네임스페이스에 만듭니다. 이름은 정해져 있습니다.

1. ts-image — 없는 이미지로 ImagePullBackOff 를 만들고, 이벤트에서 실제 사유를 읽어 /root/cka/imagepull.txt 에 담으세요. 그리고 고친 판을 ts-image-fixed 로 띄우세요.
2. ts-crash — 곧바로 죽는 명령으로 CrashLoopBackOff 를 만들고, 이미 죽은 컨테이너의 로그를 읽어 /root/cka/crashloop.txt 에 담으세요. 재시작 횟수도 함께 적습니다.
3. ts-oom — 메모리 limits 를 넘게 쓰는 컨테이너로 OOMKilled 를 만들고, 종료 코드와 함께 /root/cka/oom.txt 에 담으세요.
4. ts-liveness 와 ts-readiness — 각각 실패하는 프로브를 하나씩만 걸고, 결과가 어떻게 다른지를 /root/cka/probe.txt 에 담으세요.
5. ts-pending — 스케줄될 수 없는 파드를 만들고 스케줄러가 남긴 사유를 /root/cka/pending.txt 에 담으세요. Pending 과 ContainerCreating 의 차이도 적습니다.
6. ts-config(env 참조)와 ts-volume(볼륨 참조) — 둘 다 없는 ConfigMap 을 가리키게 하고, 상태가 왜 다른지를 /root/cka/configref.txt 에 담으세요.
7. /root/cka/triage.md 에 증상 다섯 가지의 분류표를 만드세요. 각 행은 증상 · 어디를 볼까 · 흔한 원인 입니다.
8. /root/cka/report.md 에 oom_exit_code=, liveness_restarts=, readiness_restarts=, broken_pods= 네 줄과 무엇을 먼저 보는지를 쓰세요.

참고

• 이벤트는 kubectl -n broken describe pod <이름> 의 아래쪽 Events: 에 있습니다. kubectl get events --sort-by=.lastTimestamp 로 전체를 시간순으로 볼 수도 있습니다.
• 이미 죽은 컨테이너의 로그는 kubectl logs <파드> --previous 입니다. 이것을 모르면 CrashLoopBackOff 를 영영 진단하지 못합니다 — 지금 컨테이너는 아직 로그를 남기기 전이니까요.
• 종료 이유와 코드는 kubectl get pod <이름> -o jsonpath='{.status.containerStatuses[0].lastState.terminated}' 에 있습니다.
• 메모리를 일부러 쓰려면 dd if=/dev/zero of=/dev/shm/x bs=1M count=<큰 수> 가 간단합니다.
• 흔한 실수 1: 3번에서 requests 만 주고 limits 를 안 주는 것. OOM 은 limits 를 넘을 때 일어납니다.
• 흔한 실수 2: 4번에서 두 프로브를 한 파드에 함께 거는 것. 그러면 어느 프로브 때문에 재시작했는지 구분되지 않습니다.

단계 8개

1. 이미지를 못 받을 때
2. 이미 죽은 컨테이너의 로그를 읽는다
3. 메모리를 넘기면 137 로 죽는다
4. 두 프로브는 결과가 다르다
5. Pending 은 스케줄러의 문제다
6. 같은 원인, 다른 증상
7. 표 하나로 정리한다
8. 무엇을 배웠나