LabHub
배우기 러닝패스 코스

KCNA — 쿠버네티스·클라우드 네이티브 입문 · 배포·준비 실패·롤백의 증거 읽기 · 퀴즈

퀴즈: 배포 완료와 롤백의 경계

LabHub 에서 이어서 보기

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

  1. 새 템플릿은 v3인데 availableReplicas=2이고 Service 응답은 v2다. 가장 정확한 판단은?

    1. 기존 v2의 가용성이 유지될 수 있으므로 updatedReplicas·조건·응답을 더 확인한다
    2. 가용 복제본이 두 개이므로 v3 배포는 끝났고 응답 버전만 캐시돼 있다고 판단한다
    3. Service가 v2를 전달하므로 Deployment 컨트롤러가 자동 롤백했다고 판단한다
    4. API가 템플릿을 받았으므로 v3를 직접 가리키도록 Service selector를 바꾼다
  2. Deployment 객체의 설명용 annotation만 바꿨고 spec.template은 그대로다. 어떤 비교가 변경의 의미를 가장 잘 보여 주는가?

    1. annotation을 바꾼 시각과 노드 CPU 사용률이 함께 증가했는지 비교한다
    2. 기존 ReplicaSet·Pod UID와 revision이 유지되는지 비교한다
    3. annotation 값이 환경변수로 주입돼 앱 응답이 달라지는지 비교한다
    4. API 응답이 성공했으므로 새 이미지 digest가 내려왔는지 비교한다
  3. 환경변수 COLOR가 ConfigMap에서 blue로 주입된 Pod가 실행 중이다. ConfigMap만 green으로 바꿨을 때 가능한 관측은?

    1. ConfigMap은 blue로 남고 컨트롤러가 Pod의 환경변수만 green으로 바꾼다
    2. Pod가 같은 UID로 자동 재시작해야 ConfigMap 변경 요청이 성공한다
    3. ConfigMap은 green이지만 기존 프로세스의 응답은 blue로 유지된다
    4. 새 ReplicaSet이 반드시 생기고 기존 Pod는 즉시 모두 삭제된다
  4. 복제본 2개, maxSurge=1, maxUnavailable=0이고 새 Pod가 readiness에 실패한다. 이 실험에서 가능한 상태는?

    1. Pod가 총 2개여야 하므로 정상 옛 Pod 하나를 즉시 삭제해 공간을 만든다
    2. 새 Pod가 있으므로 기존 정상 Pod 두 개는 모두 전달 대상에서 빠진다
    3. 새 Pod의 준비 실패를 무시해 세 Pod 모두 가용한 것으로 처리한다
    4. 기존 정상 Pod 두 개와 준비 안 된 새 Pod 하나가 함께 남는다
  5. Progressing=False, reason=ProgressDeadlineExceeded다. 다음 설명 중 맞는 것은?

    1. 진도 실패를 알리는 조건이며 원하는 템플릿과 실제 응답을 보고 복구를 결정한다
    2. 정상 revision으로 자동 롤백됐다는 뜻이므로 이력이나 템플릿 확인은 생략한다
    3. 컨테이너 liveness 실패를 뜻하므로 재시작 횟수가 반드시 증가해야 한다
    4. 전체 클러스터가 종료됐다는 뜻이므로 모든 namespace를 다시 생성한다
  6. ConfigMap은 purple이고 정상 v2 프로세스는 green을 유지한다. 실패한 v3에서 v2로 Deployment 롤백 후 무엇을 더 확인해야 하는가?

    1. 롤백이 모든 외부 상태를 복원하므로 ConfigMap의 이전 resourceVersion만 기록한다
    2. ConfigMap이 purple로 남았는지 조사하고 다음 Pod 생성에 미칠 영향을 확인한다
    3. 현재 응답이 green이면 새로 생기는 Pod도 반드시 green이라고 결론 낸다
    4. v2가 정상이어도 ConfigMap을 삭제해 앱이 기존 값을 계속 쓰게 만든다
  7. 정상 revision 2로 수동 롤백했더니 현재 Deployment revision이 4이고 기존 정상 v2 Pod가 남아 있다. 어떻게 해석해야 하는가?

    1. 현재 번호가 2가 아니므로 롤백 명령이 실행되지 않았다고 단정한다
    2. Pod UID가 유지됐으므로 어떤 선언도 변경되지 않았다고 단정한다
    3. 이전 템플릿으로 돌아가는 새 변경이며 실제 템플릿·복제본·응답을 대조한다
    4. revision 번호가 커졌으므로 앱 코드도 반드시 v4가 됐다고 단정한다
  8. 별도의 운영 GitOps 환경에서 self-heal이 켜져 있다. 수동 롤백 뒤 Git에는 여전히 실패한 선언이 남아 있다면?

    1. 수동 명령이 한 번 성공하면 Git 선언은 자동으로 정상 버전으로 수정된다
    2. 현재 Pod가 정상이면 Git과 클러스터의 차이는 이후 조정에 영향을 주지 않는다
    3. 롤백을 유지하려면 모든 컨트롤러와 준비 검사를 영구적으로 꺼야 한다
    4. 원하는 복구 상태를 Git에도 반영하고 실제 롤아웃·응답을 다시 확인해야 한다