CKA — 쿠버네티스 관리자 · 클러스터 아키텍처·설치·설정 · 퀴즈
퀴즈: 클러스터 아키텍처
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
스케줄러나 컨트롤러가 etcd 에 직접 붙지 않고 반드시 kube-apiserver 를 거치도록 설계한 가장 핵심적인 이유는?
- etcd 클라이언트 라이브러리가 Go 에서만 동작하기 때문
- etcd 가 동시에 세 개 이상의 클라이언트 연결을 받지 못하기 때문
- kubelet 이 etcd 인증서를 갖고 있지 않기 때문
- 인가·검증·어드미션·감사가 우회되고 각 컴포넌트가 etcd 저장 형식에 결합되기 때문
컨트롤 플레인 3대에 etcd 멤버 3개가 정상인데, 첫 번째 노드가 죽자 kubectl 과 모든 노드의 kubelet 이 접속 불가가 됐다. 가장 그럴듯한 원인은?
- etcd 쿼럼을 잃어 쓰기가 막혔다
- controlPlaneEndpoint 와 모든 kubeconfig/kubelet 설정이 죽은 노드의 물리 IP 를 가리키고, apiserver 인증서 SAN 에 다른 노드 IP 가 없다
- kube-controller-manager 의 리더 선출이 실패해 모든 컨트롤 루프가 멈췄다
- CNI 가 죽어 파드 네트워크가 끊겼다
컨트롤 플레인을 1대에서 2대로만 늘리는 것이 오히려 위험한 이유는?
- 멤버가 2개면 리더 선출 자체가 불가능하다
- 멤버 2의 과반은 2라서, 둘 중 아무 한 대만 죽어도 쿼럼을 잃고 쓰기가 막힌다
- 멤버가 짝수면 Raft 가 기동을 거부한다
- 두 멤버가 WAL 파일을 공유해야 해서 디스크 경합이 생긴다
kube-scheduler 의 filter 단계와 score 단계를 바르게 설명한 것은?
- score 로 후보를 추린 뒤 filter 로 최종 노드 하나를 고른다
- filter 는 대기 중인 파드를 정렬하고, score 는 노드를 정렬한다
- filter 는 제약을 위반하는 노드를 후보에서 제거하고, score 는 남은 노드에 점수를 매겨 최고점을 고른다
- filter 는 kubelet 이 수행하고 score 는 스케줄러가 수행한다
컨트롤러의 reconcile 루프에 대한 설명으로 옳은 것은?
- watch 이벤트를 하나라도 놓치면 그 리소스의 상태는 영구히 어긋난다
- apiserver 가 각 컨트롤러에게 무엇을 할지 명령을 내려 준다
- 선언된 상태와 관측된 상태의 차이를 반복해 줄이므로, 이벤트를 놓쳐도 주기적 리싱크로 수렴한다
- 성능을 위해 컨트롤러는 etcd 에 직접 write 한다
CRD 만 적용하고 해당 커스텀 컨트롤러는 설치하지 않은 상태에서 그 CR 을 만들면 어떻게 되나?
- apiserver 가 컨트롤러 부재를 감지해 요청을 거부한다
- kube-controller-manager 가 기본 컨트롤러로 대신 처리한다
- 오브젝트는 스키마 검증을 거쳐 저장되지만 아무도 reconcile 하지 않아 실제 변화는 일어나지 않는다
- CRD 를 만들 때 컨트롤러 파드가 자동으로 생성된다