Why am I seeing the active controller change for my Confluent Cloud cluster via 3rd party CLI tools – Confluent Support Portal

Description

When using certain 3rd party CLI tools to query Confluent Cloud clusters you may notice that the listed metadata for which broker is the active controller is inconsistent between queries.

As an example, here is a response using the 3rd party tool kcat(previously known as kafkacat), listing brokers in a Confluent Cloud cluster where the controller is specifically identified:

Metadata for all topics (from broker 0: sasl_ssl://b0-[REDACTED].europe-west2.gcp.confluent.cloud:9092/0):
 3 brokers: 
  broker 0 at b0-[REDACTED].europe-west2.gcp.confluent.cloud:9092 
  (controller)
  broker 1 at b1-[REDACTED].europe-west2.gcp.confluent.cloud:9092 
  broker 2 at b2-[REDACTED].europe-west2.gcp.confluent.cloud:9092

For further details on querying the brokers in your Confluent Cloud cluster please refer to the following Confluent documentation: How to list all the available brokers for your Confluent Cloud cluster

Applies To

Confluent Cloud

Confluent CLI

Cause

Confluent Cloud clusters have migrated from Zookeeper to kRaft clusters. Due to this change the active controller ID is no longer relevant and effectively deprecated. Fixed controller ID's are only returned in the metadata response for kafka controllers in Zookeeper clusters.

For kRaft clusters, random brokers are advertised as the controller, and requests that need to reach the controller are routed to the appropriate destination. Observing the active controller change VIA the CLI isn’t reflective of controller elections.

Resolution

Confluent is actively working to update the listed controller response from 3rd party CLI tools to clear up any confusion, and will update this article accordingly to reflect the change.

When utilizing 3rd party CLI tools such as kcat to query Confluent Cloud cluster metadata, the returned controller ID metadata is deprecated and should be safely ignored.