LabHub
배우기 러닝패스 코스

K8s 망가뜨리기 — 범인은 내 YAML · 살아 있음과 받을 준비가 됨 · 퀴즈

퀴즈: 살아 있음과 받을 준비가 됨

LabHub 에서 이어서 보기

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

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

    1. 실패한 모든 프로세스를 즉시 재시작한다
    2. Pod 템플릿을 직전 리비전으로 되돌린다
    3. Service 트래픽의 준비된 대상에서 제외한다
    4. 컨테이너 이미지를 다른 버전으로 교체한다
  2. 프로브는 /missing에서 404인데 / 직접 요청은 성공합니다. 가장 타당한 가설은?

    1. 앱과 readiness 경로의 계약이 다르다
    2. 컨테이너가 CPU 부족으로 종료됐다
    3. Service selector가 자동으로 바뀌었다
    4. 클러스터의 모든 DNS가 멈췄다
  3. 프로브 설정 변경 뒤 새 Pod UID와 restartCount 0을 보았습니다. 올바른 구분은?

    1. 프로브 실패가 컨테이너를 한 번 재시작했다
    2. 같은 Pod가 이름만 바꿔 계속 실행된다
    3. restartCount 0이면 템플릿 변경은 없었다
    4. Pod 교체와 컨테이너 재시작은 다른 기록이다
  4. 이전 Pod의 Unhealthy 이벤트로 현재 장애를 설명하기 전에 필요한 것은?

    1. 이벤트 reason이 같으면 현재 장애로 간주
    2. 이벤트 대상 UID와 현재 Pod UID 비교
    3. 같은 Deployment의 이벤트면 현재 것으로 간주
    4. 가장 최근 시각의 이벤트 하나만 원인으로 확정
  5. 이 실습이 단일 replica와 Recreate를 사용하는 이유는?

    1. 무중단 운영의 유일한 권장 설정이라서
    2. readiness 프로브를 쓰지 않기 위해서
    3. 이전 정상 Pod가 실험 장애를 가리지 않게
    4. Kubernetes가 RollingUpdate를 지원하지 않아서
  6. 실제 의존성 장애인데 readiness를 무조건 200으로 바꾸면?

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