Page History

...

The migration from ZK to KRaft will be triggered by the cluster's state. To start a migration, the cluster must meet two some requirements:

1. The metadata.version is set to the version added by this KIP. This indicates the software is at a minimum version which includes the necessary logic to perform the migration.
2. All ZK brokers have kafka.metadata.migration.enable set to “true”. This indicates an operator has declared some intention to start the migration.
3. No brokers are offline (we will use offline replicas as a proxy for this).

Once these conditions are satisfied, an operator can start a KRaft quorum with kafka.metadata.migration.enable set to “true” to begin the migration.

...

The first step of the migration is to upgrade the cluster to at least the bridge release version. Upgrading the cluster to a well known starting point will reduce our compatibility matrix and ensure that the necessary logic is in place prior to the migration. As mentioned in the "Migration Trigger" section, we must also upgrade the cluster to the metadata.version introduced by this KIP. 

All brokers must be online before the migration can begin. This is necessary to ensure that all brokers satisfy the criteria for the migration. 

Controller Migration

A new set of nodes will be provisioned to host the controller quorum. These controllers will be started with kafka.metadata.migration.enable set to “true”. Once the quorum is established and a leader is elected, the controller will check the state of the cluster using the MigrationCheck RPC. If all brokers are properly configured, the migration process will begin. The ZK data migration will copy the existing ZK data into the KRaft metadata log and establish the new KRaft active controller as the active controller from a ZK perspective.

...