K8s 망가뜨리기 — 범인은 내 YAML · 세 사건을 복구하고 보고하기 · 퀴즈
퀴즈: 세 사건을 복구하고 보고하기
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
CrashLoopBackOff만 보고 바로 알 수 없는 것은?
- 재시작 대기 상태라는 단서
- 애플리케이션이 종료된 구체적인 원인
- 컨테이너 상태를 더 조사할 필요성
- 로그와 종료 코드를 확인할 필요성
정상으로 확인한 리비전이 있다면 롤백 목표를 어떻게 정하나요?
- 항상 가장 작은 번호만 고른다
- Service 생성 순서로 번호를 계산한다
- kubectl 호출 횟수를 리비전으로 쓴다
- 이력과 내용을 확인하고 정상 리비전을 지정한다
롤백 뒤 Pod는 Ready인데 Service의 targetPort가 틀렸다면?
- Pod 복구와 별개로 Service 요청은 실패할 수 있다
- Deployment 롤백이 Service도 자동으로 복구한다
- 이전 EndpointSlice가 포트 숫자를 덮어쓴다
- Service가 실패하면 리비전 이력은 삭제된다
복구 전에 관측 JSON을 저장하는 주된 이유는?
- 파일만 있으면 실제 복구가 필요 없어서
- 학습자가 절대 편집할 수 없게 하기 위해서
- 복구 후 사라질 당시 상태를 비교하기 위해서
- 모든 로그를 영구 보존한다고 보장하기 위해서
선택자 불일치 사건에 직접 대응하는 예방 검사는?
- 프로브를 무조건 성공으로 변경
- Service 선택자와 Pod 라벨을 사전 비교
- 정상 Pod의 재시작 주기를 단축
- 이전 컨테이너 로그를 주기적으로 삭제
채점기를 검증할 때 정상 정답만 실행하면 무엇을 놓치나요?
- 성공 응답이 있다는 사실 자체를 확인할 수 없다
- 정상 환경에서 검사 시간 상한을 측정할 수 없다
- 정상 파일의 JSON 문법이 맞는지 확인할 수 없다
- 잘못된 복구도 통과시키는 검사를 놓친다