クイズ：三つの事件を復旧し、報告する

CrashLoopBackOff만 보고 바로 알 수 없는 것은?

• 재시작 대기 상태라는 단서
• 애플리케이션이 종료된 구체적인 원인
• 컨테이너 상태를 더 조사할 필요성
• 로그와 종료 코드를 확인할 필요성

정상으로 확인한 리비전이 있다면 롤백 목표를 어떻게 정하나요?

• 항상 가장 작은 번호만 고른다
• Service 생성 순서로 번호를 계산한다
• kubectl 호출 횟수를 리비전으로 쓴다
• 이력과 내용을 확인하고 정상 리비전을 지정한다

롤백 뒤 Pod는 Ready인데 Service의 targetPort가 틀렸다면?

• Pod 복구와 별개로 Service 요청은 실패할 수 있다
• Deployment 롤백이 Service도 자동으로 복구한다
• 이전 EndpointSlice가 포트 숫자를 덮어쓴다
• Service가 실패하면 리비전 이력은 삭제된다

복구 전에 관측 JSON을 저장하는 주된 이유는?

• 파일만 있으면 실제 복구가 필요 없어서
• 학습자가 절대 편집할 수 없게 하기 위해서
• 복구 후 사라질 당시 상태를 비교하기 위해서
• 모든 로그를 영구 보존한다고 보장하기 위해서

선택자 불일치 사건에 직접 대응하는 예방 검사는?

• 프로브를 무조건 성공으로 변경
• Service 선택자와 Pod 라벨을 사전 비교
• 정상 Pod의 재시작 주기를 단축
• 이전 컨테이너 로그를 주기적으로 삭제

채점기를 검증할 때 정상 정답만 실행하면 무엇을 놓치나요?

• 성공 응답이 있다는 사실 자체를 확인할 수 없다
• 정상 환경에서 검사 시간 상한을 측정할 수 없다
• 정상 파일의 JSON 문법이 맞는지 확인할 수 없다
• 잘못된 복구도 통과시키는 검사를 놓친다