Критические сбои в Kafka 4.x: когда метаданные теряют кворум
В экосистеме Apache Kafka версии 4.x произошли значительные изменения, касающиеся управления метаданными. Отказ от ZooKeeper в пользу встроенного механизма KRaft означает, что восстановление работоспособности кластера после потери большинства контроллеров теперь требует иных подходов. Отсутствие внешнего сервиса для метаданных переносит всю ответственность за их целостность и доступность на сам кластер Kafka.
Симптомы потери KRaft-кворума и их последствия
Типичный сценарий критического сбоя, описанный в баг-репорте Strimzi от 25 мая 2026 года, демонстрирует сложность диагностики и восстановления. Несмотря на внешне рабочее состояние подов (все 1/1 Running, Readiness зелёный) и успешные ответы kafka-agent (204), кластер фактически не функционирует. Оператор Strimzi постоянно пытается выполнить реконсайл и завершается с ошибкой TimeoutException: Timed out waiting for a node assignment при вызове describeMetadataQuorum. Анализ состояния контроллера показывает, что leaderId для __cluster_metadata-0/quorum-state установлен, но appliedOffset равен нулю, что указывает на отсутствие применения записей метаданных. При этом JVM активны, а raft-лог на диске продолжает расти, но в stdout не фиксируется никаких событий в течение многих часов. Эта ситуация подчеркивает важность понимания внутренних механизмов KRaft для эффективного устранения неисправностей.
Новые вызовы восстановления кворума в Kafka без ZooKeeper
До версии 4.x ZooKeeper выступал в качестве надежного «запасного выхода» для управления конфигурацией и метаданными, предлагая собственный набор инструментов и методики восстановления. Теперь, когда метаданные интегрированы непосредственно в Kafka через KRaft, потеря большинства контроллеров означает, что необходимо восстанавливать сам кластер Kafka. Документация по процедурам восстановления в старых версиях (например, ссылка на 3.9) становится неактуальной для Kafka 4.x. В данной статье мы рассмотрим конкретные шаги и методы для восстановления KRaft-кворума, чтобы предотвратить или эффективно решить подобные критические ситуации.
С KRaft у меня было несколько неприятных моментов, особенно при работе с небольшими тестовыми кластерами, где потеря одного контроллера сразу выбивает кворум. В продакшене с тремя контроллерами все намного стабильнее, но все равно приходится быть начеку. Главная проблема – это когда Kafka внешне выглядит живой, но по факту не принимает запросы. Мой совет: всегда мониторьте appliedOffset, это первый признак беды. И бэкап метаданных – наше все!