Координовані вибори лідера

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.33 [beta](стандартно вимкнено)

Kubernetes 1.35 включає бета-функцію, яка дозволяє компонентам панелі управління детерміновано обирати лідера через координовані вибори лідера. Це корисно для задоволення обмежень щодо несумісності версій Kubernetes під час оновлення кластера. Наразі єдина вбудована стратегія вибору — це OldestEmulationVersion, що надає перевагу лідеру з найнижчою версією емуляції, за яким йде бінарна версія, а потім позначка часу створення.

Увімкнення координованих виборів лідера

Переконайтеся, що функціональну можливість CoordinatedLeaderElection увімкнено під час запуску API Server та що група API coordination.k8s.io/v1beta1 увімкнена також.

Це можна зробити, встановивши прапорці --feature-gates="CoordinatedLeaderElection=true" та --runtime-config="coordination.k8s.io/v1beta1=true".

Конфігурація компонентів

За умови, що ви увімкнули функціональну можливість CoordinatedLeaderElection та увімкнули групу API coordination.k8s.io/v1beta1, сумісні компоненти панелі управління автоматично використовують LeaseCandidate та Lease API для вибору лідера за потреби.

Для Kubernetes 1.35 два компоненти панелі управління (kube-controller-manager і kube-scheduler) автоматично використовують координовані вибори лідера, коли функціональну можливість та група API увімкнені.

Вибір лідера для компонентів Kubernetes

Kubernetes використовує Lease API для проведення виборів лідера серед кількох екземплярів одного й того ж компонента панелі управління в кластері з високою доступністю, таких як kube-controller-manager або kube-scheduler.

Lease діє як легке розподілене блокування, збережене API-сервером Kubernetes. Всі запущені екземпляри компонента спостерігають або періодично читають відповідний обʼєкт Lease, щоб визначити, який екземпляр наразі виконує роль лідера.

Lease API визначає такі поля:

holderIdentity
ідентичність (наприклад, імʼя Podʼа або рядок на основі імені хоста) поточного лідера.
acquireTime
час, коли було отримано лідерство.
renewTime
час останнього оновлення лідерства лідером.
leaseDurationSeconds
період дії лізингу (кандидати повинні чекати цей час плюс невеликий додатковий період перед спробою отримати прострочений лізинг).
leaseTransitions
лічильник, скільки разів лідерство змінювалося.

Ці поля показують, який екземпляр утримує лідерство та як довго це лідерство залишається дійсним.

Коли Lease не існує або його термін дії минув (поточний час > renewTime + leaseDurationSeconds), кандидатські екземпляри намагаються оновити Lease зі своєю ідентичністю. Kubernetes покладається на оптимістичний контроль консенсусу через resourceVersion обʼєкта: лише одне оновлення успішне через невідповідність версій при одночасних спробах. Екземпляр, чиє оновлення прийнято, стає лідером.

Kubernetes використовує API LeaseCandidate для керування виборами лідера. Компоненти панелі управління, такі як kube-controller-manager та kube-scheduler, реєструють свою роль як кандидата, створюючи обʼєкти LeaseCandidate, які відстежують усі екземпляри, що змагаються за лідерство, і містять метадані, включаючи ідентичність кандидата, версію бінарного файлу та версію емуляції.

Під час виборів кандидати координують свої дії через спільний Lease. Панель управління Kubernetes гарантує, що лише один кандидат успішно отримує Lease і приймає роль лідера, тоді як усі інші залишаються підлеглими. Якщо поточний лідер не оновлює Lease протягом обраного періоду тайм-ауту, інші кандидати змагаються за лідерство і обирають нового лідера.

Після обрання лідер періодично оновлює свій Lease, оновлюючи поле renewTime (наприклад, виконуючи оновлення кожні leaseDurationSeconds ÷ 2, щоб уникнути конфліктів, коли Lease ось-ось закінчиться). Поки оновлення відбуваються до закінчення терміну дії лізингу, поточний екземпляр лідера зберігає лідерство. Якщо лідер аварійно завершує роботу, стає недоступним або припиняє оновлювати Lease, цей Lease закінчується. Інші справні екземпляри виявляють прострочений Lease і намагаються провести нові вибори.

Цей механізм забезпечує, що навіть якщо кілька реплік компонента працюють для стабільності та відновлення, лише один екземпляр активно виконує завдання керування одночасно, тоді як інші залишаються в режимі очікування, спостерігаючи за Lease і готові швидко взяти на себе керівництво у разі потреби.

Востаннє змінено April 10, 2026 at 5:15 PM PST: [uk] Ukrainian translation (all-in-one) (3973e2ac64)