퀴즈: 건강 신호와 자동 복구

문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. Pod A는 Running이고 컨테이너 ID와 재시작 횟수가 그대로입니다. Ready=false이며 Service의 EndpointSlice에서도 A의 ready=false가 관측됩니다. 가장 알맞은 해석은?

   1. 실행 중이지만 새 요청을 맡길 준비는 안 됐으며 readiness 실패만으로 재시작되지는 않았다
   2. 프로세스가 종료된 상태이며 Running은 종료 처리가 완료되기 전까지 남은 표시에 불과하다
   3. 업무 처리는 정상이지만 EndpointSlice 전파만 늦어져 readiness 검사가 실패한 상태다
   4. liveness 실패로 재시작을 기다리는 상태이므로 readiness의 트래픽 제외와 같은 사건이다

2. 한 Pod에서 liveness 실패 뒤 정상 응답이 돌아왔습니다. 컨테이너 재시작과 Pod 교체를 구분하기에 가장 직접적인 증거는?

   1. Pod 이름과 Service 이름이 모두 같다는 사실만 비교한다
   2. Pod UID는 같고 containerID가 바뀌었으며 restartCount가 증가했는지 비교한다
   3. 현재 Ready=true이므로 어떤 형태의 재시작도 없었다고 판단한다
   4. Service의 ClusterIP가 바뀌었는지만 비교해 프로세스의 수명을 판단한다

3. TCP readiness가 성공한 Pod로 Service가 요청을 보냅니다. 해당 앱은 모든 업무 요청에 HTTP 503을 반환합니다. 우선 검토할 것은?

   1. TCP 연결 성공이 모든 HTTP 경로의 정상 처리를 보장하므로 클라이언트만 교체한다
   2. 업무 응답보다 연결이 안정적인지 확인하도록 TCP readiness의 성공 횟수만 늘린다
   3. 연결 수락과 업무 준비의 의미를 구분하고 실제 준비 상태를 표현하는 검사를 설계한다
   4. 요청이 도착하므로 준비 상태는 유지하고 readiness의 주기만 짧게 바꿔 해결한다

4. 초기화에 약 20초가 필요한 앱이 시작 도중 /livez에서 503을 반환합니다. 짧은 liveness만 적용하면 시작 전에 반복 종료됩니다. 어떤 접근이 적절한가요?

   1. liveness 실패 한도를 늘려 초기화를 보호하고 실행 중 장애 감지도 같은 긴 예산으로 처리한다
   2. readiness에만 초기 지연을 넣으면 liveness도 함께 기다린다고 보고 나머지 설정은 유지한다
   3. readiness 성공 횟수만 늘려 초기화를 보호하고 liveness의 짧은 종료 기준은 그대로 둔다
   4. 최악의 초기화 시간에 여유를 둔 startup probe로 시작과 실행 중 검사 예산을 분리한다

5. readiness 실패 후 EndpointSlice JSON에 해당 Pod 주소가 아직 보입니다. 이 사실만으로 Service가 계속 새 요청을 보낸다고 결론 내려도 될까요?

   1. 아니다. 대상 Pod UID와 ready 조건, Service 설정, 실제 요청을 함께 확인해야 한다
   2. 그렇다. 주소가 한 줄이라도 존재하면 모든 Service가 반드시 그 Pod에 전달한다
   3. 그렇다. EndpointSlice에는 준비되지 않은 Pod에 관한 어떤 정보도 남을 수 없다
   4. 아니다. EndpointSlice는 HTTP 응답 코드만 저장하므로 주소는 아무 의미가 없다

6. 공유 데이터베이스가 잠시 느려졌습니다. 각 앱의 liveness가 매번 무거운 DB 쿼리를 수행하고 실패 시 앱을 종료합니다. 가장 우려되는 위험은?

   1. liveness가 실패하면 Kubernetes가 자동으로 데이터베이스를 정상 백업으로 복원한다
   2. 외부 의존 장애가 앱 재시작 폭주와 남은 인스턴스의 부하 증가로 번질 수 있다
   3. liveness가 성공한 순간 이후에는 모든 데이터베이스 요청의 성공이 보장된다
   4. 같은 Pod에서 두 종류의 프로브를 설정하면 모든 검사 결과가 항상 무시된다

7. startup probe가 한 번 성공했고 같은 컨테이너가 계속 실행 중입니다. 이후 readiness가 일시적으로 실패했습니다. 일반적인 동작으로 맞는 것은?

   1. readiness 실패 때마다 startup과 초기화 작업이 반드시 처음부터 다시 실행된다
   2. startup이 한 번 성공했으므로 이후 readiness의 실패는 언제나 무시된다
   3. readiness는 계속 동작하며, 그 실패만으로 완료된 startup 검사가 다시 시작되지는 않는다
   4. startup이 완료됐으므로 이후 liveness는 어떤 설정이어도 다시 실행되지 않는다

8. 한 번의 HTTP 200과 짧은 정상 로그를 얻었습니다. 이번 실험 결과를 보고서에 적는 가장 타당한 방식은?

   1. 이 관측만으로 모든 사용자 경로의 장기 가용성과 보안이 검증됐다고 적는다
   2. 앱이 200을 반환했으므로 EndpointSlice와 Pod 신원은 확인할 필요가 없다고 적는다
   3. 같은 이름의 Pod라면 교체 전 관측을 새 Pod의 검증 결과로 그대로 사용한다
   4. 관측한 경로·시점·객체 신원과 제한을 적고 다른 경로나 기간의 보장으로 확대하지 않는다