...

However, there is currently no way to unregister a controller, like there is for brokers via UnregisterBrokerRequest and UnregisterBrokerRecord. This means stale controller registrations can block feature upgrades. This KIP proposes adding support for operators to manually unregister controllers like they can with brokers.

The main One important use cases for unregistering a controller are for dynamic quorum clusters (i.e. clusters with KIP-853 enabled), since controller processes can now become observers of the KRaft log case for this KIP is to remove controller registrations from KRaft observers (i.e. they nodes that replicate the log but do not participate in leader election or committing data) and persist a controller registration to from the metadata log. However, there is a static quorum edge case where modifications to controller.quorum.voters can allow for a stale ControllerRegistrationRecord  to end up in the log. In either quorum mode, this KIP allows for operators to remove those controller registrations from the metadata logThis means operators can remove these stale registrations to unblock feature upgrades on their cluster.

Public Interfaces

New RPC 

...

The main use case for this command is to remove a node from the voter set in a dynamic KRaft quorum, AND unregister it from the cluster all within the same CLI command. Since this is a common usage pattern, running this command with --unregister can be thought of as a "built-in" script that provides a smooth UX for decommissioning voters in a dynamic quorum. Running the command with --unregister will still fail when the cluster does not support dynamic quorum to be consistent with the behavior of the command when --unregister is not set.

...