LabHub
배우기 러닝패스 코스

K8s 망가뜨리기 — 범인은 내 YAML · 세 사건을 복구하고 보고하기 · 퀴즈

퀴즈: 세 사건을 복구하고 보고하기

LabHub 에서 이어서 보기

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

  1. CrashLoopBackOff만 보고 바로 알 수 없는 것은?

    1. 재시작 대기 상태라는 단서
    2. 애플리케이션이 종료된 구체적인 원인
    3. 컨테이너 상태를 더 조사할 필요성
    4. 로그와 종료 코드를 확인할 필요성
  2. 정상으로 확인한 리비전이 있다면 롤백 목표를 어떻게 정하나요?

    1. 항상 가장 작은 번호만 고른다
    2. Service 생성 순서로 번호를 계산한다
    3. kubectl 호출 횟수를 리비전으로 쓴다
    4. 이력과 내용을 확인하고 정상 리비전을 지정한다
  3. 롤백 뒤 Pod는 Ready인데 Service의 targetPort가 틀렸다면?

    1. Pod 복구와 별개로 Service 요청은 실패할 수 있다
    2. Deployment 롤백이 Service도 자동으로 복구한다
    3. 이전 EndpointSlice가 포트 숫자를 덮어쓴다
    4. Service가 실패하면 리비전 이력은 삭제된다
  4. 복구 전에 관측 JSON을 저장하는 주된 이유는?

    1. 파일만 있으면 실제 복구가 필요 없어서
    2. 학습자가 절대 편집할 수 없게 하기 위해서
    3. 복구 후 사라질 당시 상태를 비교하기 위해서
    4. 모든 로그를 영구 보존한다고 보장하기 위해서
  5. 선택자 불일치 사건에 직접 대응하는 예방 검사는?

    1. 프로브를 무조건 성공으로 변경
    2. Service 선택자와 Pod 라벨을 사전 비교
    3. 정상 Pod의 재시작 주기를 단축
    4. 이전 컨테이너 로그를 주기적으로 삭제
  6. 채점기를 검증할 때 정상 정답만 실행하면 무엇을 놓치나요?

    1. 성공 응답이 있다는 사실 자체를 확인할 수 없다
    2. 정상 환경에서 검사 시간 상한을 측정할 수 없다
    3. 정상 파일의 JSON 문법이 맞는지 확인할 수 없다
    4. 잘못된 복구도 통과시키는 검사를 놓친다