K8s 망가뜨리기 — 범인은 내 YAML · 살아 있음과 받을 준비가 됨 · 퀴즈
퀴즈: 살아 있음과 받을 준비가 됨
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
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으로 바꾸면?
- 검사는 초록색이어도 업무 실패가 남을 수 있다
- 의존 서비스가 자동으로 복구된다
- 이전 컨테이너 로그가 모두 복원된다
- 서비스의 모든 데이터 정합성이 보장된다