Quiz: Alive is not the same as ready

readiness 실패의 직접적인 역할은?

• 실패한 모든 프로세스를 즉시 재시작한다
• Pod 템플릿을 직전 리비전으로 되돌린다
• Service 트래픽의 준비된 대상에서 제외한다
• 컨테이너 이미지를 다른 버전으로 교체한다

프로브는 /missing에서 404인데 / 직접 요청은 성공합니다. 가장 타당한 가설은?

• 앱과 readiness 경로의 계약이 다르다
• 컨테이너가 CPU 부족으로 종료됐다
• Service selector가 자동으로 바뀌었다
• 클러스터의 모든 DNS가 멈췄다

프로브 설정 변경 뒤 새 Pod UID와 restartCount 0을 보았습니다. 올바른 구분은?

• 프로브 실패가 컨테이너를 한 번 재시작했다
• 같은 Pod가 이름만 바꿔 계속 실행된다
• restartCount 0이면 템플릿 변경은 없었다
• Pod 교체와 컨테이너 재시작은 다른 기록이다

이전 Pod의 Unhealthy 이벤트로 현재 장애를 설명하기 전에 필요한 것은?

• 이벤트 reason이 같으면 현재 장애로 간주
• 이벤트 대상 UID와 현재 Pod UID 비교
• 같은 Deployment의 이벤트면 현재 것으로 간주
• 가장 최근 시각의 이벤트 하나만 원인으로 확정

이 실습이 단일 replica와 Recreate를 사용하는 이유는?

• 무중단 운영의 유일한 권장 설정이라서
• readiness 프로브를 쓰지 않기 위해서
• 이전 정상 Pod가 실험 장애를 가리지 않게
• Kubernetes가 RollingUpdate를 지원하지 않아서

실제 의존성 장애인데 readiness를 무조건 200으로 바꾸면?

• 검사는 초록색이어도 업무 실패가 남을 수 있다
• 의존 서비스가 자동으로 복구된다
• 이전 컨테이너 로그가 모두 복원된다
• 서비스의 모든 데이터 정합성이 보장된다