Apache Kafka офіційно позбулася залежності від ZooKeeper. Команда Confluent Developer пояснює, як режим KRaft (Kafka Raft mode) перебудовує керування метаданими, спрощує архітектуру кластера та відкриває шлях до масштабування без старих обмежень.
Від ZooKeeper до KRaft: нова модель керування метаданими
Раніше Kafka покладалася на окремий кластер ZooKeeper для всього, що стосувалося метаданих:
- ідентифікатори брокерів
- конфігурації топіків
- інформація про партиції та їхніх лідерів
- загальний стан кластера
У режимі KRaft ця роль переходить самій Kafka. Ключові зміни:
- Жодного окремого кластера ZooKeeper — більше не потрібно розгортати й підтримувати другу систему.
- Метадані зберігаються в Kafka — у спеціальному внутрішньому топіку, а не в ZooKeeper.
- Вбудований консенсус на базі Raft — Kafka отримує власний шар узгодження стану замість зовнішнього сервісу.
Це означає, що платформа сама «володіє» своїми метаданими, не делегуючи критичну логіку зовнішньому компоненту.
Контролерний кворум і Raft: як тепер працює кластер
Одне з головних архітектурних оновлень — перехід від єдиного контролера до кворуму контролерів, які працюють за алгоритмом Raft.
Було: один контролер
У класичній архітектурі Kafka:
- існував один контролер-брокер, який відповідав за керування метаданими;
- інші брокери стежили за ZooKeeper, щоб отримувати оновлення;
- вибір нового контролера та лідерів партицій залежав від сесій і таймаутів ZooKeeper.
Це створювало додаткову складність і потенційні затримки під час відмов.
Стало: кворум контролерів і єдиний журнал метаданих
У KRaft:
- формується невеликий кворум контролерів всередині самого кластера Kafka;
- усі метадані записуються в metadata log — внутрішній журнал, який реплікується за Raft;
- вибір лідерів партицій і контролерів відбувається через Raft, а не через механізми ZooKeeper.
Ключові наслідки:
- підвищена відмовостійкість — кілька контролерів у кворумі замість одного вузла;
- єдине джерело істини для стану кластера — один Raft-журнал метаданих, з якого брокери реплікують інформацію так само, як звичайні дані Kafka;
- швидші та передбачувані фейловери — вибори лідерів більше не залежать від нестабільних сесій ZooKeeper.
Спрощена архітектура та операційка
Перехід на KRaft змінює не лише внутрішню логіку, а й операційну модель:
- Одна система замість двох — адміністрування зосереджене навколо Kafka, без окремого життєвого циклу ZooKeeper.
- Єдина поверхня безпеки та експлуатації — немає потреби налаштовувати, моніторити й оновлювати ще один критичний компонент.
- Менше точок відмови — окремий кластер ZooKeeper більше не може «покласти» Kafka у разі проблем.
Для команд експлуатації це означає простіше розгортання, менше рухомих частин і більш передбачувану поведінку кластера під навантаженням.
Що залишилося незмінним для розробників
Попри суттєву внутрішню перебудову, модель використання Kafka для клієнтів не змінюється:
- продюсери та конс’юмери працюють як раніше;
- топіки, партиції, патерни споживання — усе зберігає звичну семантику;
- зміни стосуються переважно внутрішньої архітектури, а не API для застосунків.
Тобто перехід до KRaft — це радше еволюція платформи, ніж злам сумісності для користувачів.
Чому це важливо: масштаб, надійність, cloud native
KRaft робить Kafka більш придатною до сучасних сценаріїв використання:
- Cloud native-підхід — вбудований консенсус і відсутність зовнішнього координатора краще вписуються в хмарні середовища.
- Простіше керування та масштабування — менше компонентів, чіткіший шлях масштабування кластера.
- Більше партицій на кластер — ZooKeeper більше не виступає «вузьким місцем» для метаданих, що відкриває шлях до значно більшої кількості партицій.
У підсумку відмова від ZooKeeper — це не просто «прибирання старого коду», а крок до зрілої, самодостатньої платформи, де Kafka повністю контролює власні метадані та краще відповідає вимогам великих розподілених систем.