[CKA] Kubernetes 컨트롤 플레인 고가용성
여러 컨트롤 플레인에서 API 서버와 리더 선출 컴포넌트가 동작하는 방식을 정리합니다.
단일 컨트롤 플레인이 멈춰도 이미 실행 중인 Pod는 워커 노드에서 당분간 계속 동작할 수 있습니다. 그러나 API 요청 처리, 새 워크로드 스케줄링, 장애 난 Pod를 대체하는 제어 루프는 정상적으로 수행되지 못합니다.
고가용성 구성은 여러 컨트롤 플레인 인스턴스를 두고 API 서버 앞에 로드 밸런서를 배치합니다. API 서버는 각 노드에서 요청을 처리할 수 있습니다. kubectl과 다른 클라이언트는 개별 노드 대신 로드 밸런서의 안정적인 주소로 접속합니다.
kube-controller-manager와 kube-scheduler는 여러 인스턴스가 실행되더라도 리더 선출을 통해 한 인스턴스가 주도적으로 작업합니다. 리더가 lease를 갱신하지 못하면 대기하던 인스턴스가 새 리더가 될 수 있습니다. 정확한 lease와 재시도 시간은 버전과 실행 인자에서 확인해야 합니다.
etcd 토폴로지
- Stacked etcd: 각 컨트롤 플레인 노드에 etcd 멤버도 함께 둠. 필요한 서버 수와 관리 복잡도가 적지만 한 노드 장애가 컨트롤 플레인과 etcd 멤버를 동시에 줄입니다.
- External etcd: etcd를 별도 노드에 둠. 장애 도메인을 분리하지만 더 많은 인프라와 복잡한 운영이 필요합니다.
kubeadm의 HA 구성은 일반적으로 3개 이상의 컨트롤 플레인 노드와 API 서버 로드 밸런서를 전제로 합니다. External etcd를 선택하면 etcd 엔드포인트와 인증서를 kubeadm 설정에 명시합니다.