Quiz: Cluster Architecture

스케줄러나 컨트롤러가 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 를 만들 때 컨트롤러 파드가 자동으로 생성된다