LabHub

KCNA — 쿠버네티스·클라우드 네이티브 입문 · 쿠버네티스 아키텍처 · 퀴즈

퀴즈: 쿠버네티스 아키텍처

LabHub 에서 이어서 보기

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

  1. kube-scheduler 가 완전히 멈춘 클러스터에서 새 Deployment 를 만들면 어떻게 되는가?

    1. Deployment 생성 자체가 거부된다
    2. Deployment 와 ReplicaSet 은 만들어지고 파드도 생성되지만 Pending 상태로 남는다
    3. kubelet 이 스케줄러 대신 노드를 골라 파드를 띄운다
    4. apiserver 가 라운드로빈으로 노드를 배정한다
  2. 컨트롤러 매니저나 스케줄러가 etcd 를 직접 읽지 않고 반드시 apiserver 를 거치도록 설계한 가장 큰 이유는?

    1. etcd 의 gRPC 프로토콜이 Go 언어에서만 동작하기 때문
    2. 인증·인가·어드미션·검증·감사를 한 지점에서 강제하고 저장 형식 변경을 컴포넌트로부터 감추기 위해
    3. etcd 는 동시 접속을 두 개까지만 허용하기 때문
    4. etcd 에는 watch 기능이 없어 apiserver 가 폴링으로 대신하기 때문
  3. `kubectl api-resources` 가 문서 사이트보다 정확한 답을 주는 상황은?

    1. 다음 릴리스에서 추가될 리소스를 미리 알고 싶을 때
    2. 각 필드의 상세한 설명과 예시 YAML 이 필요할 때
    3. 특정 리소스의 과거 API 버전 변경 이력을 추적할 때
    4. 이 클러스터에 CRD 로 설치된 커스텀 리소스까지 포함한 실제 목록이 필요할 때
  4. 라벨 셀렉터 기반 연결이 가진 대표적인 함정은?

    1. 셀렉터가 어긋나면 오브젝트 생성 자체가 실패해 배포가 막힌다
    2. 셀렉터가 어긋나도 오브젝트는 정상 생성되고 다만 아무 대상도 잡지 못해 조용히 동작하지 않는다
    3. 라벨은 대소문자를 구분하지 않아 서로 다른 파드가 뒤섞인다
    4. 셀렉터는 한 번에 하나의 라벨 조건만 지정할 수 있다
  5. etcd 멤버 3개로 쿼럼을 갖춘 클러스터에서 첫 번째 컨트롤 플레인 노드가 죽었는데 kubectl 이 전혀 동작하지 않았다. 가장 가능성 높은 원인은?

    1. etcd 쿼럼이 깨져 클러스터가 읽기 전용으로 전환되었다
    2. 모든 클라이언트의 서버 주소가 죽은 노드의 물리 IP 로 박혀 있고, 인증서 SAN 에 다른 노드 IP 가 없어 우회 접속도 TLS 검증에 실패한다
    3. 스케줄러가 죽으면 apiserver 도 함께 종료되도록 설계되어 있다
    4. 컨트롤러 매니저의 리더 선출이 실패하면 apiserver 가 요청을 거부한다
  6. 명령형(`kubectl create`)과 선언형(`kubectl apply`)의 실질적 차이로 가장 정확한 것은?

    1. apply 는 원하는 상태를 파일로 남기고 last-applied-configuration 을 기록해 반복 적용·차이 계산·되돌리기가 가능하다
    2. create 는 파드만 만들 수 있고, apply 는 모든 종류의 리소스를 만들 수 있다
    3. create 는 클러스터를 거치지 않고 로컬에서만 동작한다
    4. apply 는 항상 기존 오브젝트를 삭제한 뒤 새로 만든다