Kafka sin ZooKeeper: KRaft en producción

Actualizado: 2026-05-03

Kafka 4.0 llegó en marzo de 2025 y con ella desapareció de forma definitiva la dependencia de ZooKeeper. La promesa venía de lejos: KIP-500 se aprobó en 2019, el modo KRaft se marcó estable en Kafka 3.3 a finales de 2022, y 3.5 trajo la vía de migración. Lo que 4.0 hace es cerrar la puerta: ya no se puede arrancar un clúster con ZooKeeper, incluso aunque quieras. Después de meses operando clústeres KRaft y de haber hecho la migración obligada en un par de entornos reales, toca repasar qué cambia de verdad, qué sigue igual y qué hay que saber antes de planificar el salto.

Para el contexto de infraestructura de datos donde Kafka opera, el análisis de Delta Lake e Iceberg comparativa describe la capa de almacenamiento que complementa a Kafka en arquitecturas modernas. El patrón de migración escalonada con dependencias externas también aplica al contexto de Kubernetes 1.33 mejoras, donde la actualización de plataforma sigue una lógica similar.

Puntos clave

• KRaft almacena los metadatos del clúster en un topic interno __cluster_metadata usando Raft como consenso; no hay sistema externo.
• Un clúster KRaft arranca en segundos frente a las decenas de segundos o más de un minuto con ZooKeeper.
• Las métricas de ZooKeeper desaparecen; aparecen métricas nuevas del quórum de controladores que los paneles heredados necesitan actualizar.
• La migración desde Kafka 3.7/3.8 se hace en modo dual sin interrupción de servicio; Kafka 4.0 no admite ya ZooKeeper.
• Si el clúster está en 2.x, lo recomendado es ir primero a 3.5/3.6 con ZooKeeper antes de planificar KRaft.

Por qué ZooKeeper era un problema

Durante más de una década Kafka dependió de ZooKeeper para mantener metadatos del clúster: quién es el controlador, qué brokers están vivos, qué topics existen, qué particiones van a qué réplica. ZooKeeper es sólido pero no estaba diseñado para el volumen de metadatos que un clúster Kafka grande genera. Había un techo práctico: clústeres con cientos de miles de particiones encontraban ZooKeeper como cuello de botella.

El segundo problema era operativo: mantener dos sistemas distribuidos distintos con dos modelos de consenso distintos. Un equipo tenía que saber Kafka y también ZooKeeper, con su configuración, sus comandos, sus modos de fallo. Cada ampliación del clúster implicaba pensar en los dos lados. Cada fallo obligaba a decidir si era un fallo de Kafka o de ZooKeeper.

KRaft es la respuesta: el propio Kafka mantiene sus metadatos usando Raft como algoritmo de consenso, dentro de un quórum de brokers especiales llamados controladores. No hay sistema externo. Los metadatos se almacenan en un topic interno llamado __cluster_metadata y se replican siguiendo las mismas reglas que cualquier otro topic.

Qué mejora claramente

Lo primero que se nota es el arranque. Un clúster KRaft arranca en segundos. El mismo clúster con ZooKeeper tardaba varias decenas de segundos, a veces más de un minuto si había que sincronizar metadatos. Para despliegues frecuentes esto cambia el ritmo; para recuperaciones después de un fallo cambia todavía más.

La segunda mejora es el techo de particiones. El equipo de Apache Kafka ha publicado pruebas con clústeres KRaft que soportan millones de particiones por clúster, frente a los varios cientos de miles donde ZooKeeper empezaba a sufrir. Saber que el techo es alto cambia cómo diseñas tus topics: puedes ser más generoso con las particiones sin miedo a que el metadato sea el cuello de botella.

La tercera mejora es operativa. Una sola tecnología, una sola configuración, un solo conjunto de comandos. Los comandos de administración como kafka-topics y kafka-configs siguen funcionando igual, pero detrás ya no hay un sistema adicional que puede fallar por su cuenta.

Lo que cambia en la operativa

El modelo de despliegue cambia en dos puntos. Primero, los brokers pueden asumir el rol de controlador además del rol de broker. En un clúster pequeño es habitual tener tres nodos que hacen ambas cosas. En un clúster grande se separan: tres o cinco nodos dedicados como controladores, y el resto como brokers puros.

Segundo, el concepto de cluster ID aparece desde el principio. En KRaft hay que generar este identificador con la herramienta kafka-storage durante la inicialización. No es complicado pero es un paso nuevo que conviene automatizar en los guiones de despliegue.

El monitoreo también cambia. Las métricas de ZooKeeper desaparecen. Aparecen métricas nuevas sobre el quórum de controladores: cuántas hay en lag, cuánto tardan las actualizaciones de metadatos, cuántos eventos por segundo procesa el controlador activo. Los paneles de Grafana heredados necesitan ajuste.

La migración sin dolor

La migración desde un clúster con ZooKeeper a KRaft se hace en modo dual. El clúster corre con ZooKeeper y con un quórum KRaft en paralelo, los metadatos se sincronizan, y cuando todo está verificado se corta la dependencia de ZooKeeper. Kafka 3.7 y 3.8 soportan este modo. Kafka 4.0 ya no: si llegas a 4.0 tienes que haber terminado la migración.

El patrón en los entornos donde se ha hecho la migración fue similar:

1. Actualizar a 3.7 o 3.8 en modo ZooKeeper, como de costumbre.
2. Añadir los nodos controladores KRaft y activar el modo dual; el clúster sigue funcionando sin interrupción de servicio.
3. Esperar a que los metadatos se sincronicen y verificar con los comandos de admin que ambos lados concuerdan.
4. Cambiar el rol de los brokers de ZooKeeper a KRaft uno por uno.
5. Cuando todos los brokers están en KRaft, retirar los nodos ZooKeeper.

El tiempo real depende del tamaño del clúster. En un clúster pequeño con tres brokers y cincuenta topics, la migración completa se hizo en una tarde sin interrupción de servicio. En un clúster mediano con quince brokers y varios miles de topics, llevó dos días de preparación y una ventana de cambio de cuatro horas. En ninguno hubo pérdida de mensajes ni caídas.

Dónde puede doler

Hay puntos donde la migración duele:

• Herramientas externas que hablan directamente con ZooKeeper: herramientas antiguas de gestión, scripts internos que leen nodos de ZooKeeper para inventario, integraciones de terceros que asumen el modelo anterior. Todo eso deja de funcionar y hay que catalogarlo antes de migrar para reescribirlo contra el AdminClient.
• Versiones muy viejas de clientes: clientes Java 2.x+ y librdkafka funcionan sin cambios, pero clientes propios antiguos pueden tropezar.
• Configuración de ACL y cuotas: con ZooKeeper muchos equipos las ponían directamente en los nodos; con KRaft eso se traslada a kafka-configs. La migración es automática pero cualquier automatización de despliegue que toque nodos ZooKeeper habrá que reescribirla.

Un ejemplo del tipo de configuración que aparece en server.properties de un controlador KRaft:

process.roles=controller
controller.quorum.voters=1@controller1:9093,2@controller2:9093,3@controller3:9093
listeners=CONTROLLER://0.0.0.0:9093

Cuándo esperar antes de migrar

Hay equipos que deberían esperar:

• Clúster en Kafka 2.x: migrar a KRaft implica saltar varias versiones mayores. El camino recomendado es ir primero a 3.5 o 3.6 con ZooKeeper, estabilizar, y después planificar el paso a KRaft.
• Integraciones con software propietario que habla ZooKeeper: antes de migrar conviene verificar explícitamente con cada proveedor crítico. En 2025 la mayoría ya soportan KRaft, pero hay excepciones.
• En medio de otra migración grande: si el equipo está migrando a Kubernetes o cambiando de proveedor de nube al mismo tiempo, añadir KRaft al mismo proyecto multiplica el riesgo. Mejor secuenciar.

Mi lectura

KRaft es una mejora clara y el salto a Kafka 4.0 es, para la mayoría de clústeres, una migración sensata hecha con tiempo. El ahorro operativo de eliminar ZooKeeper es real, las mejoras de rendimiento son medibles, y el tiempo de arranque mejora la experiencia de despliegue. Pero no es una migración para hacer en viernes por la tarde: requiere planificación, inventario de dependencias externas y una ventana de cambio pensada.

La recomendación práctica es encarar 4.0 con tiempo: empezar leyendo la documentación de migración de 3.7 o 3.8, probar el modo dual en un entorno de prueba, catalogar cada integración externa que toque ZooKeeper, y preparar los guiones de despliegue con antelación. Este proceso, hecho con cuidado, tarda unas semanas de trabajo distribuido y se salda sin incidencias.

Lo que Kafka 4.0 consolida es una idea simple: una sola tecnología, un solo modelo de consenso, una sola cosa que aprender. Para quien opera Kafka a diario este es el cambio más significativo en años. Para quien solo publica y consume mensajes, es invisible. Ambas cosas son buenas señales.