LabHub
배우기 러닝패스 코스

K8s 망가뜨리기 — 범인은 내 YAML · 정상인데 왜 배송되지 않을까 · 퀴즈

퀴즈: 정상인데 왜 배송되지 않을까

LabHub 에서 이어서 보기

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

  1. Pod가 Running인데 Service 요청은 실패합니다. 먼저 구분할 사실은?

    1. Pod 직접 요청과 Service 요청의 차이
    2. 클러스터의 모든 노드를 재시작할 순서
    3. 새 이미지를 강제로 다시 받을 주기
    4. 모든 정상 Pod를 삭제할 우선순위
  2. Service selector만 app=missing으로 바꿨습니다. 가장 잘 맞는 관측은?

    1. Pod도 같은 라벨로 자동 변경된다
    2. Pod는 응답하지만 선택된 주소가 없어진다
    3. Deployment 리비전이 반드시 증가한다
    4. 같은 컨테이너의 재시작 횟수가 증가한다
  3. EndpointSlice의 endpoints가 null이면 관측기는 어떻게 해야 하나요?

    1. 컨트롤 플레인이 죽었다고 즉시 확정한다
    2. 직전의 정상 주소를 계속 사용한다
    3. 대상 주소가 없는 상태로 해석한다
    4. 첫 Pod의 주소를 대신 채워 넣는다
  4. kubectl patch가 성공했지만 바로 보낸 요청은 실패했습니다. 적절한 해석은?

    1. API 성공이므로 요청 실패는 무시한다
    2. 다른 네임스페이스까지 함께 수정한다
    3. 모든 컨테이너 이미지를 다시 빌드한다
    4. 반영 지연과 실제 데이터 경로를 확인한다
  5. Pod 직접 요청 성공만으로 주장할 수 있는 것은?

    1. 그 Pod의 해당 HTTP 경로가 응답했다
    2. 외부 DNS와 TLS도 모두 정상이다
    3. Service의 대상 포트가 반드시 맞다
    4. 모든 고객의 업무가 복구됐다
  6. Pod IP의 8080번은 성공하지만 Ready 주소가 있는 Service IP의 8080번은 실패합니다. 다음 비교로 가장 직접적인 것은?

    1. ClusterIP 직접 요청의 외부 DNS 전파 시간
    2. Service targetPort와 실제 수신 포트
    3. Pod 재시작 횟수와 요청 본문의 글자 수
    4. Ingress TLS 인증서와 Pod 이미지 태그