증상을 읽는 것은 반사 신경이다

한 줄 요약

문제 해결은 글로 배워지지 않습니다. kubectl get pod 에 뜬 글자를 보고 3초 안에 다음에 볼 곳이 떠올라야 하는데, 그건 직접 고장을 만들어 봐야 몸에 남습니다.

왜 진짜 고장이어야 하나

CKA 는 문제 해결이 배점의 큰 몫입니다. 그런데 앞 모듈들이 도는 가짜 클러스터에는 kubelet 도 컨테이너 런타임도 없어서, 고장 자체를 만들 수 없었습니다.

| 증상 | 가짜 클러스터에서는 |
|---|---|
| ImagePullBackOff | 이미지를 받지 않으므로 생기지 않음 |
| CrashLoopBackOff | 프로세스가 없으므로 죽지도 않음 |
| OOMKilled | 메모리를 쓰지 않으므로 넘칠 일이 없음 |
| 프로브 실패 재시작 | 프로브를 돌리지 않음 |
| PVC Bound | 프로비저너가 없어 영원히 Pending |

그래서 "이 증상은 무엇을 뜻하는가" 를 글로만 배울 수 있었습니다. 문제 해결은 그렇게 배워지지 않습니다. kubectl get pod 에 뜬 글자를 보고 3초 안에 다음에 볼 곳이 떠올라야 하는데, 그건 직접 만들어 봐야 몸에 남습니다.

비슷해 보이는데 원인이 다른 것들

• Pending 과 ContainerCreating — 전자는 스케줄러, 후자는 kubelet 의 문제입니다. kubectl get pod -o wide 의 NODE 열이 채워졌는지로 갈립니다.
• liveness 실패와 readiness 실패 — 전자는 재시작, 후자는 트래픽에서만 제외합니다.
• 없는 ConfigMap 을 env 로 참조하면 CreateContainerConfigError, 같은 것을 볼륨으로 참조하면 Pending 입니다.

세 가지만 기억하면 된다

1. describe 의 Events 를 먼저 본다. 상태 이름은 *어디서* 막혔는지만 알려 줍니다. *무엇이* 없는지는 언제나 이벤트에 있습니다.
2. logs 가 비었으면 --previous. CrashLoopBackOff 인 파드의 지금 컨테이너는 아직 아무것도 안 찍었습니다.
3. NODE 열을 본다. 비어 있으면 스케줄러, 채워져 있으면 kubelet. 이 한 줄로 조사 범위가 절반이 됩니다.

실무에서 진짜 중요한 것

상태 이름이 아니라 Events 를 먼저 읽습니다. 상태는 어디서 막혔는지만 알려 주고, 무엇이 없는지는 언제나 이벤트에 있습니다. 시험에서도 실무에서도 이 순서를 바꾸면 시간을 두 배로 씁니다.

NODE 열 하나로 조사 범위가 절반이 됩니다. 비어 있으면 스케줄러, 채워져 있으면 kubelet 입니다. kubectl get pod -o wide 를 습관으로 두면 이 분기가 공짜로 따라옵니다.

CrashLoopBackOff 에서는 --previous 없이 로그를 보지 않습니다. 지금 컨테이너는 방금 다시 만들어져 아직 아무것도 찍지 않았습니다. 빈 로그를 보고 "로그가 없다" 고 판단하는 것이 가장 흔한 헛걸음입니다.

다음 두 실습에서 이것들을 직접 만들어 봅니다.