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

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->








  <div class="feature-state-notice feature-beta" title="Функціональна можливість: CoordinatedLeaderElection">
              <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
              <code>Kubernetes v1.33 [beta]</code>(стандартно вимкнено)</div>


Kubernetes 1.36 включає бета-функцію, яка дозволяє компонентам <a class='glossary-tooltip' title='Шар оркестрування контейнерів, який надає API та інтерфейси для виявлення, розгортання та управління життєвим циклом контейнерів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-control-plane' target='_blank' aria-label='панелі управління'>панелі управління</a> детерміновано обирати лідера через _координовані вибори лідера_. Це корисно для задоволення обмежень щодо розбіжності версій Kubernetes під час оновлення кластера. Наразі єдина вбудована стратегія вибору — це `OldestEmulationVersion`, що надає перевагу лідеру з найнижчою версією емуляції, за яким йде бінарна версія, а потім позначка часу створення.

## Увімкнення координованих виборів лідера {#enabling-coordinated-leader-election}

Переконайтеся, що [функціональну можливість](/docs/reference/command-line-tools-reference/feature-gates/) `CoordinatedLeaderElection` увімкнено під час запуску <a class='glossary-tooltip' title='Компонент панелі управління, що обслуговує API Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/#kube-apiserver' target='_blank' aria-label='API Server'>API Server</a> та що група API `coordination.k8s.io/v1beta1` увімкнена також.

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

## Конфігурація компонентів {#component-configuration}

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

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

## Вибір лідера для компонентів Kubernetes {#leader-selection-for-kubernetes-components}

Kubernetes використовує [Lease API](/docs/concepts/architecture/leases/) для проведення виборів лідера серед кількох екземплярів одного й того ж компонента панелі управління в кластері з високою доступністю, таких як `kube-controller-manager` або `kube-scheduler`.

[Lease](/docs/concepts/architecture/leases/) діє як легке розподілене блокування, збережене [API-сервером Kubernetes](/docs/reference/command-line-tools-reference/kube-apiserver/). Всі запущені екземпляри компонента спостерігають або періодично читають відповідний обʼєкт Lease, щоб визначити, який екземпляр наразі виконує роль лідера.

[Lease API](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) визначає такі поля:

`holderIdentity`
: ідентичність (наприклад, імʼя Podʼа або рядок на основі імені хоста) поточного лідера.

`acquireTime`
: час, коли було отримано лідерство.

`renewTime`
: час останнього оновлення лідерства лідером.

`leaseDurationSeconds`
: період дії лізингу (кандидати повинні чекати цей час плюс невеликий додатковий період перед спробою отримати прострочений лізинг).

`leaseTransitions`
: лічильник, скільки разів лідерство змінювалося.

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

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

Kubernetes використовує API [LeaseCandidate](/docs/reference/kubernetes-api/cluster-resources/lease-candidate-v1beta1/) для керування виборами лідера. Компоненти панелі управління, такі як `kube-controller-manager` та `kube-scheduler`, реєструють свою роль як кандидата, створюючи обʼєкти LeaseCandidate, які відстежують усі екземпляри, що змагаються за лідерство, і містять метадані, включаючи ідентичність кандидата, версію бінарного файлу та версію емуляції.

Під час виборів кандидати координують свої дії через спільний [Lease](/docs/concepts/architecture/leases/). Панель управління Kubernetes гарантує, що лише один кандидат успішно отримує [Lease](/docs/concepts/architecture/leases/) і стає _лідером_, тоді як усі інші залишаються підлеглими. Якщо поточний _лідер_ не оновлює [Lease](/docs/concepts/architecture/leases/) протягом обраного періоду тайм-ауту, інші кандидати змагаються за лідерство і обирають нового _лідера_.

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

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