Kafka 4.0 llego en marzo de 2025 y con ella desaparecio de forma definitiva la dependencia de ZooKeeper. La promesa venia de lejos: KIP-500 se aprobo en 2019, el modo KRaft se marco estable en Kafka 3.3 a finales de 2022, y 3.5 trajo la via de migracion. Lo que 4.0 hace es cerrar la puerta: ya no se puede arrancar un cluster con ZooKeeper, incluso aunque quieras. Despues de meses operando clusters KRaft y de haber hecho la migracion obligada en un par de entornos reales, toca repasar que cambia de verdad, que sigue igual y que hay que saber antes de planificar el salto.
Por que ZooKeeper era un problema
Durante mas de una decada Kafka dependio de ZooKeeper para mantener metadatos del cluster: quien es el controlador, que brokers estan vivos, que topics existen, que particiones van a que replica. ZooKeeper es solido pero no estaba disenado para el volumen de metadatos que un cluster Kafka grande genera. Habia un techo practico: clusters con cientos de miles de particiones encontraban el ZooKeeper como cuello de botella, y las operaciones de mantenimiento eran lentas.
El segundo problema era operativo: mantener dos sistemas distribuidos distintos con dos modelos de consenso distintos. Un equipo tenia que saber Kafka y tambien ZooKeeper, con su configuracion, sus comandos, sus modos de fallo. Cada ampliacion del cluster 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 quorum 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.
Que mejora claramente
Lo primero que se nota es el arranque. Un cluster KRaft arranca en segundos. El mismo cluster con ZooKeeper tardaba varias decenas de segundos, a veces mas de un minuto si habia que sincronizar metadatos. Para despliegues frecuentes esto cambia el ritmo; para recuperaciones despues de un fallo cambia todavia mas.
La segunda mejora es el techo de particiones. El equipo de Apache Kafka ha publicado pruebas con clusters KRaft que soportan millones de particiones por cluster, frente a los varios cientos de miles donde ZooKeeper empezaba a sufrir. Pocos clusters llegan a esas cifras, pero saber que el techo es alto cambia como disenas tus topics: puedes ser mas generoso con las particiones sin miedo a que el metadato sea el cuello de botella.
La tercera mejora es operativa. Una sola tecnologia, una sola configuracion, un solo conjunto de comandos. El numero de cosas que un equipo debe entender se reduce. Los comandos de administracion como kafka-topics y kafka-configs siguen funcionando igual, pero detras 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 ademas del rol de broker. En un cluster pequenio es habitual tener tres nodos que hacen ambas cosas. En un cluster grande se separan: tres o cinco nodos dedicados como controladores, y el resto como brokers puros. Esta separacion es una decision de diseno que conviene hacer de forma consciente.
Segundo, el concepto de cluster ID aparece desde el principio. Antes, ZooKeeper almacenaba un identificador que Kafka usaba para validar que los brokers pertenecian al mismo cluster. En KRaft hay que generar este identificador con la herramienta kafka-storage durante la inicializacion. No es complicado pero es un paso nuevo que conviene automatizar en los guiones de despliegue.
El monitoreo tambien cambia. Las metricas de ZooKeeper desaparecen. Aparecen metricas nuevas sobre el quorum de controladores: cuantas lagging hay, cuanto tardan las actualizaciones de metadatos, cuantos eventos por segundo procesa el controlador activo. Los paneles de Grafana heredados necesitan ajuste. No es dramatico, pero la primera semana en produccion merece tener a alguien vigilando que las alertas nuevas estan bien calibradas.
La migracion sin dolor
La migracion desde un cluster con ZooKeeper a KRaft se hace en modo dual. El cluster corre con ZooKeeper y con un quorum KRaft en paralelo, los metadatos se sincronizan, y cuando todo esta 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 migracion.
En los dos entornos donde he hecho la migracion el patron fue similar. Primero actualizar a 3.7 o 3.8 en modo ZooKeeper, como de costumbre. Despues anadir los nodos controladores KRaft y activar el modo dual; el cluster sigue funcionando, no hay interrupcion de servicio. Esperar a que los metadatos se sincronicen, verificar con los comandos de admin que ambos lados concuerdan. Cambiar el rol de los brokers de ZooKeeper a KRaft uno por uno, siempre uno por uno. Cuando todos los brokers estan ya en KRaft, retirar los nodos ZooKeeper.
El tiempo real depende del tamanio del cluster. En un cluster pequenio con tres brokers y cincuenta topics, la migracion completa se hizo en una tarde sin interrupcion de servicio. En un cluster mediano con quince brokers y varios miles de topics, llevo dos dias de preparacion y una ventana de cambio de cuatro horas para la conmutacion final. En ninguno hubo perdida de mensajes ni caidas.
Donde puede doler
Hay puntos donde la migracion duele. El primero son las herramientas externas que hablan directamente con ZooKeeper: herramientas antiguas de gestion, 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.
El segundo es si usas versiones muy viejas de clientes o bibliotecas que dependen de semanticas expuestas por ZooKeeper; clientes Java 2.x o superiores y librdkafka funcionan sin cambios, pero clientes propios antiguos pueden tropezar. El tercero es la configuracion: con ZooKeeper muchos equipos ponian ACL y cuotas directamente en los nodos, con KRaft eso se traslada a kafka-configs. La migracion es automatica pero cualquier automatizacion de despliegue que toque nodos ZooKeeper habra que reescribirla.
Un ejemplo del tipo de configuracion que aparece en server.properties de un controlador KRaft es process.roles=controller, controller.quorum.voters=1@controller1:9093,2@controller2:9093,3@controller3:9093, listeners=CONTROLLER://0.0.0.0:9093.
Cuando esperar antes de migrar
Hay equipos que deberian esperar. Si el cluster esta en Kafka 2.x, migrar a KRaft implica saltar varias versiones mayores y es arriesgado hacerlo de golpe. El camino recomendado es ir primero a 3.5 o 3.6 con ZooKeeper, estabilizar, y despues planificar el paso a KRaft. Saltar directamente de 2.x a 4.0 no esta soportado y no compensa intentarlo.
Si el cluster tiene integraciones con software propietario que habla ZooKeeper, la decision es sobre cuando ese software se actualice. Algunos proveedores de conectores y herramientas de observabilidad tardaron en soportar KRaft; en 2025 la mayoria ya lo tienen, pero hay excepciones. Antes de migrar conviene verificar explicitamente con cada proveedor critico.
Si el equipo esta en medio de una migracion grande de otro sistema (por ejemplo a Kubernetes), anadir el cambio de KRaft al mismo proyecto multiplica el riesgo. Es mejor secuenciar: primero una cosa, estabilizar, despues la otra. La tentacion de hacer ambas cosas a la vez para ahorrar trabajo casi siempre sale cara en produccion.
Mi lectura
KRaft es una mejora clara y el salto a Kafka 4.0 es, para la mayoria de clusters, una migracion 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 migracion para hacer en viernes por la tarde: requiere planificacion, inventario de dependencias externas y una ventana de cambio pensada.
Mi recomendacion practica es encarar 4.0 con tiempo. Empezar leyendo la documentacion de migracion de 3.7 o 3.8, probar el modo dual en un entorno de prueba, catalogar cada integracion externa que toque ZooKeeper, y preparar los guiones de despliegue con antelacion. Cuando se haya migrado un entorno de prueba con exito, replicar en produccion. 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 tecnologia, un solo modelo de consenso, una sola cosa que aprender. Para quien opera Kafka a diario este es el cambio mas significativo en anios. Para quien solo publica y consume mensajes, es invisible. Ambas cosas son buenas senales.
