测验：健康信号与自动恢复

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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