Create a Real Failure and Read It

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

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번에서 두 프로브를 한 파드에 함께 거는 것. 그러면 어느 프로브 때문에 재시작했는지 구분되지 않습니다.

이미지를 못 받을 때

ts-image — 없는 이미지로 ImagePullBackOff 를 만들고, 이벤트에서 실제 사유를 읽어 /root/cka/imagepull.txt 에 담으세요. 그리고 고친 판을 ts-image-fixed 로 띄우세요.

없는 태그를 지정하면 됩니다. 상태만 보지 말고 describe 의 Events 에서 실제 사유를 읽으세요.

이미 죽은 컨테이너의 로그를 읽는다

ts-crash — 곧바로 죽는 명령으로 CrashLoopBackOff 를 만들고, 이미 죽은 컨테이너의 로그를 읽어 /root/cka/crashloop.txt 에 담으세요. 재시작 횟수도 함께 적습니다.

kubectl logs <파드> 는 지금 컨테이너를 봅니다. 방금 죽은 것을 보려면 --previous 가 필요합니다.

메모리를 넘기면 137 로 죽는다

ts-oom — 메모리 limits 를 넘게 쓰는 컨테이너로 OOMKilled 를 만들고, 종료 코드와 함께 /root/cka/oom.txt 에 담으세요.

limits.memory 를 작게 주고 그보다 많이 쓰게 하세요. 종료 코드가 무엇을 뜻하는지 함께 적습니다.

두 프로브는 결과가 다르다

ts-liveness 와 ts-readiness — 각각 실패하는 프로브를 하나씩만 걸고, 결과가 어떻게 다른지를 /root/cka/probe.txt 에 담으세요.

한 파드에는 프로브 하나만 거세요. 둘을 함께 걸면 어느 쪽 때문에 재시작했는지 구분되지 않습니다.

Pending 은 스케줄러의 문제다

ts-pending — 스케줄될 수 없는 파드를 만들고 스케줄러가 남긴 사유를 /root/cka/pending.txt 에 담으세요. Pending 과 ContainerCreating 의 차이도 적습니다.

노드가 줄 수 없는 자원을 요청하면 됩니다. 스케줄러는 왜 못 놓았는지를 이벤트에 남깁니다.

같은 원인, 다른 증상

ts-config(env 참조)와 ts-volume(볼륨 참조) — 둘 다 없는 ConfigMap 을 가리키게 하고, 상태가 왜 다른지를 /root/cka/configref.txt 에 담으세요.

없는 ConfigMap 을 envFrom 으로 참조한 파드와 볼륨으로 참조한 파드를 각각 만들어 상태를 비교하세요.

표 하나로 정리한다

/root/cka/triage.md 에 증상 다섯 가지의 분류표를 만드세요. 각 행은 증상 · 어디를 볼까 · 흔한 원인 입니다.

각 행은 증상 · 어디를 볼까 · 흔한 원인 입니다. 시험장에서 3초 안에 다음 행동이 떠오르게 만드는 것이 목적입니다.

무엇을 배웠나

/root/cka/report.md 에 oom_exit_code=, liveness_restarts=, readiness_restarts=, broken_pods= 네 줄과 무엇을 먼저 보는지를 쓰세요.

oom_exit_code=, liveness_restarts=, readiness_restarts=, broken_pods= 네 줄과 함께 조사 순서를 쓰세요.