퀴즈: 리더 선출
임차가 만료됐는지는 무엇으로 정해지나?
- Lease 오브젝트의 만료 표시 필드를 읽어서 정해진다
- API 서버가 만료된 임차를 주기적으로 지워 주기 때문에 존재 여부로 정해진다
- renewTime 에 leaseDurationSeconds 를 더한 값을 지금과 견줘 정해진다
- holderIdentity 가 비어 있는지 여부로 정해진다
리더가 renewTime 만 갱신할 때 leaseTransitions 는?
- 그대로 둔다 — 홀더가 바뀌지 않았기 때문이다
- 갱신할 때마다 하나씩 올린다 — 갱신 횟수를 세는 값이다
- 임차 길이를 넘길 때마다 올린다 — 지연을 세는 값이다
- 리더가 스스로 0 으로 되돌린다 — 건강하다는 표시다
--leader-elect-renew-deadline 이 --leader-elect-lease-duration 보다 길면?
- 리더가 갱신을 포기하지 않아 임차가 영구적으로 고정된다
- 후보들이 임차를 아예 인수하지 못해 리더가 없는 상태가 된다
- API 서버가 두 값의 관계를 검사해 컨트롤러 기동을 거부한다
- 리더가 아직 자기를 리더로 믿는 사이 다른 후보가 인수해 둘이 된다
리더 선출에 필요한 RBAC 동사의 최소 집합은?
- get, create, update
- get, list, watch, update
- create, update, patch, delete
- list, watch, update, delete
리더 선출을 켰는데도 조정 루프를 멱등하게 짜야 하는 이유는?
- 멱등해야 리더 선출이 임차를 더 빨리 인수할 수 있기 때문
- 임차가 만료되면 API 서버가 조정 요청을 다시 보내기 때문
- 리더가 둘인 구간이 원리적으로 존재해 같은 조정이 겹칠 수 있기 때문
- 멱등하지 않으면 RBAC 이 update 요청을 거부하기 때문
두 인스턴스가 같은 오브젝트의 같은 필드를 서버사이드 적용으로 쓰려 하면?
- 나중 요청이 조용히 앞의 값을 덮어쓰고 기록만 남는다
- API 서버가 충돌을 알리며 어느 관리자의 필드인지 이름을 알려 준다
- 두 값이 모두 저장되고 컨트롤러가 나중에 하나를 고른다
- 요청이 큐에 쌓였다가 순서대로 반영되어 마지막 값이 남는다