Leader Election의 필요 여부는?
컨트롤러의 leader Election을 더 파악해본다.
- https://itnext.io/leader-election-in-kubernetes-using-client-go-a19cbe7a9a85
- https://ssup2.github.io/programming/Kubernetes_Kubebuilder/
즉 리더는 lease 유무에 따라 정해지는데
특정 변수 자체가 있으면 리더 선정이 되는 듯 하다.
리더가 없으면 파드 여러개가 다같이 reconcile 한다.
다만 이걸로 CR 상태가 이상해지진 않았다.
(다른 한쪽에선 컨트롤러에선 계속 error가 나오는 상황이 됐다.)
오히려 리더가 있으면 리더 재선정까지 다시 reconcile하기까지 시간이 걸리는데
리더 없이 여러개 돌리면, CR 상태 반영에 시간 지연이 없음.
lease의 용도
기본적으로 kube-node-lease 라는 네임스페이스가 있음.
여기에 있는 lease 리소스는 노드의 상태 체크를 해주는 역할이라고 한다.
controller-runtime 패키지를 알아야 할 듯 함.
Operator의 라이프사이클 동안, 예를 들어 Operator에 대한 업그레이드를 롤아웃할 때 언제든지 여러 개의 인스턴스를 실행할 수 있습니다. 이러한 시나리오에서는 리더를 선택하여 여러 Operator
인스턴스 간 경합을 방지해야 합니다. 그러면 하나의 리더 인스턴스에서만 조정을 처리하고 다른 인스턴스는 비활성화되지만 리더가 아래로 내려가면 이어서 작업을 수행할 수 있습니다.
즉 리더 선택 자체는 컨트롤러 업그레이드에 필요한 것 같다.
Leader Election 총정리
(영상도 찍었는데 올라가지 않아서 생략)
지금까지 개발한 custom controller의 리더 설정은 기본으로 적용되어 있다.
사용하지 않을 경우, main.go 에서 이부분을 주석처리 한다.
- leader 사용 여부는 manifest로 반영되는게 아닌, 코드상으로 작성되어 있다.
이와 관련하여 kubebuilder는 내부적으로 두 패키지를 사용한다.
- client-go
- controller-runtime
lease
- kube-node-lease 네임스페이스에서 각 노드에 대한 lease가 있음
Leader Election이 없는 경우 테스트
- n개의 controller 파드가 실행될 때, n개 모두 reconcile 수행.
- 1개의 controller 파드 제외하고는 error 로그를 표시 (단, CR 상태 반영은 문제 없음)
Leader Election이 필요한 이유
오퍼레이터에 대한 업데이트/롤아웃을 고려해야 함.
Operator의 라이프사이클 동안, 예를 들어 Operator에 대한 업그레이드를 롤아웃할 때 언제든지 여러 개의 인스턴스를 실행할 수 있습니다. 이러한 시나리오에서는 리더를 선택하여 여러 Operator
인스턴스 간 경합을 방지해야 합니다. 그러면 하나의 리더 인스턴스에서만 조정을 처리하고 다른 인스턴스는 비활성화되지만 리더가 아래로 내려가면 이어서 작업을 수행할 수 있습니다.
Leader 구현 방식
- Leader-for-life (split brain은 발생하지 않으나 리더 선택이 지연될 수 있음)
- Leader-with-lease (리더 선택이 빠르나 특정 상황에서 split brain 발생 가능성 있음)
kubebuilder에서는 후자(lease)를 쓰고 있다.
