La arquitectura de Apache Kafka dio un giro radical con la llegada de la versión 4.0.0: Zookeeper dejó de ser obligatorio. Para quienes hemos trabajado con Kafka durante años, este cambio no solo representa una mejora tecnológica, sino una liberación operativa.
Ahora, Kafka puede funcionar de forma independiente gracias a KRaft, su nuevo sistema interno de consenso distribuido. Y sí, lo he implementado en entornos reales, donde desde el primer momento los brokers arrancan sin siquiera mirar a Zookeeper. En este artículo te explico en detalle cómo funciona este nuevo paradigma, cómo configurarlo y qué beneficios (y retos) trae consigo.
Contenidos
¿Por qué Kafka eliminó Zookeeper?
Durante años, Zookeeper ha sido una pieza crítica en la arquitectura de Kafka. Coordinaba el estado del clúster, gestionaba la metadata de los topics, controladores, particiones y más. Pero también era un cuello de botella.
Con el tiempo, mantener un clúster Kafka + Zookeeper implicaba una complejidad innecesaria. Dos sistemas distintos, cada uno con sus propios mecanismos de replicación, seguridad y tolerancia a fallos. Para una herramienta que pretendía ser sencilla de operar, Zookeeper era una herencia complicada.
KRaft (Kafka Raft Metadata mode) surge como una solución a ese problema: reemplazar a Zookeeper con un protocolo de consenso propio, basado en Raft, que gestiona todo el control del clúster dentro del propio Apache Kafka.
¿Qué es KRaft y cómo reemplaza a Zookeeper?
El modo KRaft es mucho más que una mejora estética: es una re-arquitectura completa del núcleo de Kafka.
En vez de depender de Zookeeper para gestionar quién es el líder, cuántos brokers hay o qué particiones existen, el propio Kafka ahora almacena su metadata internamente y utiliza Raft para lograr consenso entre los nodos controladores.
¿Quieres Convertirte en experto en Streaming de Datos?
De esta forma, los brokers se autogestionan y coordinan entre ellos de forma nativa.
Diferencias clave entre Zookeeper y KRaft
| Característica | Zookeeper | KRaft (nuevo modo) |
|---|---|---|
| Sistema externo | Sí | No |
| Protocolo | Zab (Zookeeper Atomic Broadcast) | Raft |
| Gestión de metadata | Externa (en ZK) | Interna (en Kafka) |
| Arranque de brokers | Requiere conexión previa | Brokers se conectan entre sí |
| Complejidad operativa | Alta | Menor |
Configurar un clúster de Kafka sin Zookeeper (modo KRaft)
El proceso de configuración es uno de los puntos donde más cambios verás si vienes del mundo Zookeeper.
Los cambios empiezan desde el archivo server.properties. Aquí, en vez de configurar la conexión a Zookeeper, necesitas indicar roles y parámetros propios del consenso Raft:
process.roles=broker,controller
controller.quorum.voters=1@localhost:9093
node.id=1process.roles: Define si el nodo es broker, controller o ambos.controller.quorum.voters: Define qué nodos forman el quórum de controladores.node.id: Identificador único del nodo dentro del clúster.
Además, deberás usar el nuevo comando de inicialización de metadata, que reemplaza el tradicional registro en Zookeeper:
kafka-storage.sh format -t <UUID> -c config/kraft/server.propertiesPasos para levantar un clúster desde cero
- Define los roles y puertos de cada broker.
- Ejecuta
kafka-storage.shen cada uno para formatear el disco con el UUID del clúster. - Arranca cada broker con su configuración individual.
- Kafka ahora asignará el controlador automáticamente y replicará el metadata internamente.
Ventajas de Kafka sin Zookeeper
Los beneficios de esta nueva arquitectura se hacen evidentes en cuanto trabajas un par de días con ella.
- Simplificación del despliegue: desaparece una dependencia crítica. Ya no necesitas monitorizar ni asegurar la alta disponibilidad de Zookeeper. Puedes centrarte únicamente en Kafka y sus brokers.
- Resiliencia y escalabilidad: Al eliminar la duplicación de responsabilidades (ZK por un lado, Kafka por otro), el clúster se vuelve más compacto. Todo el consenso ocurre en el corazón del propio Kafka.
- Mejores tiempos de recuperación: Los controladores se eligen entre los propios brokers, lo que permite que el clúster recupere liderazgo más rápido en caso de fallos. En las pruebas que he podido hacer, la conmutación por error ha sido casi instantánea comparada con el enfoque tradicional.
¿Puedo migrar de un clúster Zookeeper a KRaft?
No todo es color de rosa. También hay retos que debes tener en cuenta, sobre todo si vienes de versiones anteriores.
Algunas herramientas del ecosistema Kafka aún dependen (o dependían hasta hace poco) de Zookeeper. Aunque la mayoría están adaptándose rápidamente, siempre conviene verificar la compatibilidad antes de migrar.
Lo ideal en los casos de migración es crear un clúster nuevo en modo KRaft y hacer una migración de datos (por ejemplo, con replicación cruzada).
Aunque KRaft está considerado production-ready a partir de Kafka 4.0, es clave seguir las guías oficiales al pie de la letra. La configuración de los controladores y el quorum es delicada, y hay que diseñar bien el clúster desde el principio.
Mi consejo: si estás comenzando con Kafka o vas a montar un clúster nuevo, no mires atrás. Configura directamente en modo KRaft, olvídate de Zookeeper y prepárate para una experiencia más simple y potente.
Siguientes Pasos y Formación
Arquitecto de Datos con más de 10 años de experiencia en el sector del Big Data. Autor de cursos de formación en tecnologías Big Data, Cloud y Streaming completados por más de 7000 alumnos en Udemy y otras plataformas. Miembro de la Apache Software Foundation desde 2019.