Quiz: The Kubernetes Architecture

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

• Deployment 생성 자체가 거부된다
• Deployment 와 ReplicaSet 은 만들어지고 파드도 생성되지만 Pending 상태로 남는다
• kubelet 이 스케줄러 대신 노드를 골라 파드를 띄운다
• apiserver 가 라운드로빈으로 노드를 배정한다

컨트롤러 매니저나 스케줄러가 etcd 를 직접 읽지 않고 반드시 apiserver 를 거치도록 설계한 가장 큰 이유는?

• etcd 의 gRPC 프로토콜이 Go 언어에서만 동작하기 때문
• 인증·인가·어드미션·검증·감사를 한 지점에서 강제하고 저장 형식 변경을 컴포넌트로부터 감추기 위해
• etcd 는 동시 접속을 두 개까지만 허용하기 때문
• etcd 에는 watch 기능이 없어 apiserver 가 폴링으로 대신하기 때문

kubectl api-resources 가 문서 사이트보다 정확한 답을 주는 상황은?

• 다음 릴리스에서 추가될 리소스를 미리 알고 싶을 때
• 각 필드의 상세한 설명과 예시 YAML 이 필요할 때
• 특정 리소스의 과거 API 버전 변경 이력을 추적할 때
• 이 클러스터에 CRD 로 설치된 커스텀 리소스까지 포함한 실제 목록이 필요할 때

라벨 셀렉터 기반 연결이 가진 대표적인 함정은?

• 셀렉터가 어긋나면 오브젝트 생성 자체가 실패해 배포가 막힌다
• 셀렉터가 어긋나도 오브젝트는 정상 생성되고 다만 아무 대상도 잡지 못해 조용히 동작하지 않는다
• 라벨은 대소문자를 구분하지 않아 서로 다른 파드가 뒤섞인다
• 셀렉터는 한 번에 하나의 라벨 조건만 지정할 수 있다

etcd 멤버 3개로 쿼럼을 갖춘 클러스터에서 첫 번째 컨트롤 플레인 노드가 죽었는데 kubectl 이 전혀 동작하지 않았다. 가장 가능성 높은 원인은?

• etcd 쿼럼이 깨져 클러스터가 읽기 전용으로 전환되었다
• 모든 클라이언트의 서버 주소가 죽은 노드의 물리 IP 로 박혀 있고, 인증서 SAN 에 다른 노드 IP 가 없어 우회 접속도 TLS 검증에 실패한다
• 스케줄러가 죽으면 apiserver 도 함께 종료되도록 설계되어 있다
• 컨트롤러 매니저의 리더 선출이 실패하면 apiserver 가 요청을 거부한다

명령형(kubectl create)과 선언형(kubectl apply)의 실질적 차이로 가장 정확한 것은?

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