Apache Kafka y KRaft: guía rápida sin ZooKeeper

Sobre esta infografía

Qué es KRaft: modo nativo de Apache Kafka (Kafka Raft Metadata mode) que reemplaza a ZooKeeper para gestionar metadatos con un quórum de controladores basado en Raft. Beneficios clave mostrados: sin dependencia externa, metadatos internos, quórum de controladores, menor complejidad operativa. Cambios frente a ZooKeeper: arquitectura pasa de dos sistemas (Kafka + ZooKeeper) a uno solo; componentes de Brokers + ZooKeeper a Brokers + quórum de controladores; gestión de metadatos externa vs interna en Kafka (Raft); menor complejidad operativa; consistencia basada en Raft nativo; se elimina el punto de fallo externo (ZooKeeper). Cómo funciona: productores y consumidores fluyen a través de brokers; particiones con réplicas para tolerancia a fallos; el quórum de controladores mantiene el estado de metadatos; elección de líder por partición; los brokers se registran ante el quórum y reciben asignaciones de particiones. Arquitectura KRaft: quórum de controladores (Raft) C1–C3 para metadatos; clúster de brokers para tráfico de datos; almacenamiento de particiones y réplicas; separación de flujos de datos y de metadatos. Conceptos clave visibles: KRaft, quórum de controladores, broker, tópico, partición, réplica, metadata log, bootstrap (direcciones de arranque para clientes y herramientas). Configuración básica (server.properties mostrado): - process.roles=broker,controller - node.id=1 - controller.quorum.voters=1@node1:9093,2@node2:9093,3@node3:9093 - listeners=PLAINTEXT://:9092,CONTROLLER://:9093 - inter.broker.listener.name=PLAINTEXT - controller.listener.names=CONTROLLER - log.dirs=/var/lib/kafka/data - metadata.log.dir=/var/lib/kafka/meta Comandos principales ilustrados: generar UUID del clúster, formatear almacenamiento, iniciar servidor, crear/describir tópicos, consultar estado del quórum de metadatos. Pasos de configuración: formatear almacenamiento con cluster ID; definir IDs de nodo; configurar el quórum de controladores; definir listeners/puertos y directorios; iniciar brokers/controladores; crear tópicos y verificar metadatos; validar el clúster y salud del quórum. Ventajas: despliegues más simples y ligeros; menos componentes; elimina la dependencia de ZooKeeper; mejor arranque y rendimiento de metadatos; mayor confiabilidad operativa. Cuándo usar KRaft: en nuevos despliegues; en migraciones desde ZooKeeper; con versiones modernas de Kafka 3.3+ (recomendada en la lámina). Consideraciones: revisar compatibilidades; usar número impar de controladores (p. ej., 3 o 5); planificar redundancia/almacenamiento para logs; preparar estrategia de migración desde ZooKeeper; considerar rendimiento de discos. Mensajes finales visibles: sin ZooKeeper; mejor rendimiento; arquitectura escalable; mayor confiabilidad ante fallos.

Ideas clave

• KRaft reemplaza a ZooKeeper gestionando metadatos dentro de Kafka mediante un quórum basado en Raft.
• La arquitectura se simplifica: de dos sistemas a uno solo, reduciendo complejidad y puntos de fallo externos.
• Los metadatos (líderes de partición, registro de brokers, asignaciones) residen en el quórum de controladores.
• Se recomiendan conjuntos impares de controladores (por ejemplo, 3 o 5) para consenso Raft.
• Configuración básica incluye definir roles de proceso, node.id, controller.quorum.voters, listeners y rutas de datos/meta.
• El flujo de datos permanece en brokers; el flujo de metadatos se gestiona por controladores.
• Ventajas destacadas: despliegues más simples, mejor rendimiento de metadatos, escalabilidad y confiabilidad.
• Escenarios de uso: nuevos despliegues y migraciones en Kafka 3.3+ (según la lámina).

Fuentes

• KIP-500 (Replace ZooKeeper with a Self-Managed Metadata Quorum)cwiki.apache.org