Entrevista de Ingeniería de Datos: Puertas de actualización para la migración de ZooKeeper a KRaft en Kafka 4.2

Consigna y contexto

Un clúster multiinquilino de Kafka todavía ejecuta ZooKeeper. El equipo desea migrar a KRaft y actualizar a Kafka 4.2. El clúster utiliza productores transaccionales, Kafka Streams y Connect, y no puede tolerar pérdida de mensajes, confirmaciones (commits) duplicadas ni una interrupción prolongada del servicio. Diseñe verificaciones previas (preflight checks), actualizaciones continuas, puertas de metadata-version, compatibilidad de clientes, recuperación ante fallos y rollback.

Qué evalúa el entrevistador

• Reconocer que Kafka 4.2 es exclusivo para KRaft (KRaft-only) en lugar de tratarlo como un reemplazo normal de brokers.
• Separar la versión del software, metadata.version y el estado de migración.
• Elegir 4.2.1 tras considerar las correcciones de 4.2.0 para la migración offline de Streams y la actualización de productores transaccionales.
• Cubrir controladores, brokers, clientes, Connect y Streams en la verificación.
• Saber cuándo se admite el rollback y cuándo los cambios de metadatos requieren una recuperación hacia adelante (forward recovery).

Preguntas para clarificar

1. ¿Cuáles son las versiones de Kafka, ZooKeeper, clientes y Streams, y cumplen con los requisitos previos para la migración a KRaft?
2. ¿Cómo se observan la idempotencia transaccional, los tiempos de espera de las transacciones (timeouts) y las transacciones abiertas?
3. ¿Existe replicación entre regiones (cross-region), MirrorMaker o un clúster de recuperación verificado?
4. ¿Las cargas de trabajo utilizan Streams Rebalance Protocol, Share Groups u otras funciones de 4.2?
5. ¿Qué ventana de actualización continua, rebalanceo de consumidores y tiempo de rollback puede aceptar el negocio?

Respuesta en 30 segundos

Trataría 4.2 como una migración de arquitectura: un clúster de ZooKeeper debe migrar a KRaft antes de poder actualizarse. Apuntaría a 4.2.1 para evitar el defecto de migración offline de Streams en 4.2.0 y el problema de actualización continua de los productores transaccionales. Antes de la migración, congele los cambios de alto riesgo e inventaríe clientes, transacciones, estado de Streams y réplicas de recuperación. Actualice el software primero de forma continua, observe el comportamiento y el rendimiento, y eleve metadata.version por separado. Cada paso verifica mensajes de extremo a extremo, confirmaciones de transacciones, retraso de consumidores (consumer lag), cuórum de controladores y estado de Streams. Si un paso falla, deténgase antes de la activación de metadatos o recupérese a través de una ruta compatible admitida en lugar de tratar los cambios de metadatos como un interruptor reversible.

Análisis detallado paso a paso

1. Elaborar la matriz de versiones y estados

Kafka 4.2 solo admite KRaft, por lo que el modo ZooKeeper debe migrarse primero. La versión del software, la versión de metadatos y el estado del cuórum de controladores son dimensiones independientes. Confirme los requisitos previos y registre las versiones de brokers, controladores, clientes, Connect, Streams y protocolos en una lista de verificación auditable.

ZooKeeper -> KRaft migration -> rolling broker/controller upgrade -> verify -> raise metadata.version
    |             |                      |                         |
    +-- blocked --+----------------------+----------> stop and recover

2. Elegir la versión corregida y el orden

Utilice 4.2.1 como objetivo. La guía oficial de actualización enumera una corrección para las actualizaciones continuas de productores transaccionales que podían generar UnsupportedVersionException y una corrección para el defecto de migración offline de Streams Rebalance Protocol; 4.2.0 no debería ejecutar la migración afectada de classic a streams group. Actualice primero las herramientas y las matrices de clientes, luego actualice un broker a la vez para evitar alterar varios dominios de falla juntos.

3. Establecer puertas para metadatos y cambios de controladores

Después de la actualización continua de software, observe el comportamiento y el rendimiento del clúster antes de elevar metadata.version con kafka-features.sh. Las puertas incluyen estabilidad del cuórum de controladores, elecciones de líder, latencia de propagación de metadatos, ISR y salud del disco. Kafka 4.2 documenta compatibilidad con degradación (downgrade) cuando no hay cambios de metadatos, pero cada versión de destino necesita su propia verificación de compatibilidad de metadatos.

4. Verificar transacciones, Streams y Connect

Las pruebas de transacciones cubren épocas (epochs) de productores, confirmaciones, cancelaciones (aborts), reinicios, duplicados y tiempos de espera. Las pruebas de Streams cubren restauración de almacenes de estado (state stores), rebalanceos, changelogs, semántica de procesamiento y la ruta de migración offline. Las pruebas de Connect cubren offsets, reinicios de tareas e idempotencia de sistemas externos. Ejecute verificaciones de producción/consumo de extremo a extremo para cada clase de cliente; la salud del broker por sí sola no es suficiente.

5. Observar y ensayar fallos

Registre elecciones de controladores, versión de metadatos, errores de brokers, fallos de solicitudes, estado de transacciones, retraso de consumidores, restauración de Streams, tareas de Connect y crecimiento de disco. Ensaye el reinicio de brokers, pérdida de controladores, transacciones interrumpidas, migración fallida de Streams y clientes incompatibles; cada escenario necesita una condición de detención de actualización y de recuperación.

6. Definir límites de rollback y recuperación

Antes de elevar metadata.version, conserve binarios antiguos, configuraciones, instantáneas (snapshots) y un clúster de recuperación, y defina una ventana de verificación de solo lectura. Un fallo en la actualización continua puede detenerse en una versión compatible y restaurar los brokers. Una vez que ocurre un cambio de metadatos no compatible, el rollback se convierte en una restauración de instantánea compatible o en la reconstrucción de un nuevo clúster; no fuerce una degradación de binarios. Preserve la consistencia de transacciones y offsets antes de restaurar el rendimiento (throughput).

Respuesta modelo

Primero demostraría que no se trata de una actualización de versión de rutina: Kafka 4.2 elimina la compatibilidad con ZooKeeper, por lo que el clúster existente debe migrar a KRaft. Elegiría 4.2.1 porque la guía oficial indica correcciones para actualizaciones continuas de productores transaccionales y migración offline de Streams. Previamente, inventariaría brokers, controladores, clientes, Connect, Streams, transacciones y réplicas de recuperación en una matriz de versión/estado.

Actualice un broker a la vez, verifique el cuórum de controladores, ISR, latencia y comportamiento, luego eleve metadata.version. Las pruebas de transacciones cubren épocas, confirmaciones, cancelaciones, reinicios y duplicados; las pruebas de Streams cubren almacenes de estado, changelogs, rebalanceos y migración; las pruebas de Connect cubren offsets y recuperación de tareas. Registre versión de metadatos, elecciones, retraso y errores. Un fallo previo a los metadatos puede detenerse en una etapa compatible; tras un cambio de metadatos no compatible, reconstruya a partir de una instantánea o clúster de recuperación en lugar de forzar una degradación de binarios.

Errores comunes

• Reemplazar los brokers de ZooKeeper directamente con Kafka 4.2 sin una migración a KRaft.
• Comprobar solo la disponibilidad de los brokers en lugar de transacciones, estado de Streams, offsets de Connect y mensajes de extremo a extremo.
• Elevar metadata.version inmediatamente después de la actualización continua de software.
• Ejecutar la migración offline de Streams con riesgo conocido en 4.2.0.
• Tratar metadata.version como una configuración ordinaria a la que siempre se le puede aplicar un downgrade.
• No contar con clúster de recuperación, instantáneas ni puertas explícitas de detención de actualización.

Preguntas de seguimiento y respuestas

¿Por qué un clúster de ZooKeeper no puede actualizarse directamente a Kafka 4.2?

Kafka 4.2 funciona exclusivamente con KRaft y eliminó el modo ZooKeeper. El clúster debe migrar y verificar el cuórum de controladores antes de ingresar a la ruta de actualización continua de 4.2.

¿Cuándo debería elevarse metadata.version?

Después de que todo el software de brokers/controladores esté actualizado y estable, y el cuórum, ISR, errores de clientes y rendimiento sean satisfactorios. Elevarlo por separado permite distinguir problemas de código de la activación del protocolo.

¿Qué ocurre si falla la restauración del estado de Streams tras la activación de metadatos?

Detenga la activación de funciones adicionales, conserve las evidencias y registros, y recupere a partir de una instantánea admitida o ruta de reconstrucción. No oculte inconsistencias eliminando changelogs ni forzando una degradación de binarios.