조정된 리더 선출
조정된 리더 선출 (Coordinated Leader Election)
기능 상태: Kubernetes v1.33부터 Beta; 기본적으로 비활성화.
이 기능을 사용하려면 여러분(또는 클러스터 관리자)이 클러스터의 모든 관련 컴포넌트에 대해 CoordinatedLeaderElection 기능 게이트를 활성화해야 해요. 기능 게이트 활성화/비활성화에 대한 자세한 내용은 참고하세요.
Kubernetes 1.37에는 컨트롤 플레인 컴포넌트가 조정된 리더 선출(coordinated leader election)을 통해 결정론적으로 리더를 선택할 수 있게 해 주는 베타 기능이 포함돼 있어요. 이는 클러스터 업그레이드 중 쿠버네티스 버전 편차(version skew) 제약을 충족하는 데 유용해요. 현재 내장된 유일한 선택 전략은 OldestEmulationVersion으로, 가장 낮은 에뮬레이션 버전을 가진 리더를 선호하고, 그 다음 바이너리 버전, 그다음 생성 타임스탬프를 따져요.
출처: 문서
본문
조정된 리더 선출 활성화하기 (Enabling coordinated leader election)
API Server를 시작할 때 CoordinatedLeaderElection 기능 게이트가 활성화되고 coordination.k8s.io/v1beta1 API 그룹이 활성화되었는지 확인하세요. 이는 --feature-gates="CoordinatedLeaderElection=true"와 --runtime-config="coordination.k8s.io/v1beta1=true" 플래그를 설정해 수행할 수 있어요.
컴포넌트 구성 (Component configuration)
CoordinatedLeaderElection 기능 게이트를 활성화하고 coordination.k8s.io/v1beta1 API 그룹을 활성화했다면, 호환되는 컨트롤 플레인 컴포넌트가 필요에 따라 LeaseCandidate와 Lease API를 자동으로 사용해 리더를 선출해요.
Kubernetes 1.37에서 두 컨트롤 플레인 컴포넌트(kube-controller-manager와 kube-scheduler)가 기능 게이트와 API 그룹이 활성화되면 조정된 리더 선출을 자동으로 사용해요.
쿠버네티스 컴포넌트의 리더 선택 (Leader selection for Kubernetes components)
쿠버네티스는 Lease API를 사용해 고가용성 클러스터에서 kube-controller-manager나 kube-scheduler 같은 같은 컨트롤 플레인 컴포넌트의 여러 인스턴스 간에 리더 선출을 수행해요.
Lease는 쿠버네티스 API 서버가 저장하는 경량 분산 잠금 역할을 해요. 컴포넌트의 모든 실행 인스턴스는 관련 Lease 객체를 감시하거나 주기적으로 읽어 현재 어떤 인스턴스가 리더 역할을 하는지 결정해요.
Lease API는 다음과 같은 필드를 정의해요.
| 필드 | 설명 |
|---|---|
holderIdentity |
현재 리더의 정체성 (예: 파드 이름이나 호스트네임 기반 문자열) |
acquireTime |
리더십을 획득한 시점의 타임스탬프 |
renewTime |
리더가 마지막으로 갱신한 시점의 타임스탬프 |
leaseDurationSeconds |
리스의 유효 기간 (후보는 만료된 리스 획득을 시도하기 전에 이 시간에 소량의 유예 기간을 더해 기다려야 함) |
leaseTransitions |
리더십이 몇 번 바뀌었는지의 카운터 |
이 필드들은 어떤 인스턴스가 리더십을 보유하는지와 그 리더십이 얼마나 유효한지 나타내요.
Lease가 존재하지 않거나 만료되면(현재 시간 > renewTime + leaseDurationSeconds), 후보 인스턴스들이 자신의 정체성으로 Lease를 업데이트하려 시도해요. 쿠버네티스는 객체의 resourceVersion을 통한 낙관적 동시성 제어에 의존해요. 동시 시도에서 버전 불일치로 오직 하나의 업데이트만 성공해요. 업데이트가 수락된 인스턴스가 리더가 돼요.
쿠버네티스는 LeaseCandidate API를 사용해 리더 선출을 관리해요. kube-controller-manager와 kube-scheduler 같은 컨트롤 플레인 컴포넌트는 LeaseCandidate 객체를 만들어 후보로 자신의 역할을 등록해요. LeaseCandidate 객체는 리더십을 위해 경쟁하는 모든 인스턴스를 추적하고, 후보의 정체성, 바이너리 버전, 에뮬레이션 버전을 포함한 메타데이터를 담아요.
선거 중 후보들은 공유 Lease를 통해 조정돼요. 쿠버네티스 컨트롤 플레인은 오직 한 후보만 Lease를 성공적으로 획득해 리더 역할을 맡고, 나머지는 모두 팔로워로 남도록 보장해요. 현재 리더가 선택된 타임아웃 기간 내에 Lease를 갱신하지 못하면, 나머지 후보들이 리더십 획득을 위해 경쟁해 새 리더를 선출해요.
일단 선출되면 리더는 renewTime 필드를 업데이트해 주기적으로 Lease를 갱신해요(예: Lease가 곧 만료될 때 충돌을 피하기 위해 leaseDurationSeconds ÷ 2마다 갱신 수행). 갱신이 리스 만료 전에 이루어지기만 하면 현재 리더 인스턴스가 리더십을 유지해요. 리더가 충돌하거나, 접근 불가능해지거나, Lease 갱신을 중단하면 그 Lease는 만료돼요. 다른 건강한 인스턴스들이 만료된 Lease를 감지하고 새 선거를 시도해요.
이 메커니즘은 안정성과 복구를 위해 컴포넌트의 여러 복제본이 실행될 수 있더라도, 한 번에 오직 하나의 인스턴스만 능동적으로 제어 작업을 수행하고 나머지는 대기 상태로 Lease를 감시하며 필요하면 빠르게 인계받을 준비를 하도록 보장해요.