How to manage units

For general Juju unit management process, see the Juju documentation.

Scale the cluster

Scaling the cluster does not automatically rebalance existing topics and partitions. Rebalancing must be performed manually—before scaling in or after scaling out.

To scale Charmed Apache Kafka application, use juju scale-application command with the name of the app and the required number of units:

juju scale-application kafka-k8s <units>

See the scale-application command reference.

Make sure to reassign partitions and topics to use newly added units for existing topics and partitions. See below for guidance.

Partition reassignment

When brokers are added or removed, Apache Kafka cluster does not automatically rebalance existing topics and partitions.

Without reassignment or rebalancing:

• New storages and new brokers will be used only when new topics and new partitions are created.
• Removing a broker can result in permanent data loss if the partitions are not replicated on another broker.

Partition reassignment can be done manually by the admin user with the /opt/kafka/bin/kafka-reassign-partitions.sh Apache Kafka bin utility script. For more information on the script usage, refer to Apache Kafka documentation.

LinkedIn’s Cruise Control can be used for semi-automatic rebalancing. For guidance on how to use it with Charmed Apache Kafka K8s, see our Tutorial.

Admin utility scripts

Apache Kafka ships with bin/*.sh commands to do various administrative tasks such as:

• bin/kafka-config.sh to update cluster configuration
• bin/kafka-topics.sh for topic management
• bin/kafka-acls.sh for management of ACLs of Apache Kafka users

Please refer to the upstream Apache Kafka project and its documentation, for a full list of the bash commands available in Apache Kafka distributions. Additionally, you can use --help argument to print a short summary for a given bash command.

These scripts can be found in the /opt/kafka/bin folder of the workload container.

For more information about listeners opened based on integrations, see the Listeners reference page. For example, to open a SASL/SCRAM listener, integrate a client application using the data integrator, as described in the How to manage app guide.

To run most of the scripts, you need to provide:

1. the Apache Kafka service endpoints, generally referred to as bootstrap servers
2. authentication information

Endpoints and credentials

For Juju admins of the Apache Kafka deployment, the bootstrap servers information can be obtained using the get-admin-credentials action output:

BOOTSTRAP_SERVERS=$(juju run kafka-k8s/leader get-admin-credentials | grep "bootstrap.servers" | cut -d "=" -f 2)

Admin client authentication information is stored in the /etc/kafka/client.properties file that is present on every Apache Kafka container. The content of the file can be accessed using juju ssh command:

juju ssh --container kafka kafka-k8s/leader 'cat /etc/kafka/client.properties'

where the --container kafka is to select the Apache Kafka workload container of the unit. By default, the charm operator container is opened.

This file can be provided to the Apache Kafka bin commands via the --command-config argument. Note that client.properties may also refer to other files (e.g. truststore and keystore for TLS-enabled connections). Those files also need to be accessible and correctly specified.

Commands can be run within an Apache Kafka broker, since both the authentication file (along with the truststore if needed) and the Charmed Apache Kafka binaries are already present.

Listing topics example

For instance, to list the current topics on the Apache Kafka cluster, run:

juju ssh --container kafka kafka-k8s/leader '/opt/kafka/bin/kafka-topics.sh --bootstrap-server $BOOTSTRAP_SERVERS --list --command-config /etc/kafka/client.properties'

The BOOTSTRAP_SERVERS variable contains the information we retrieved earlier in the previous section.

For example, a full command without the usage of the variable might look like the following:

juju ssh --container kafka kafka-k8s/leader '/opt/kafka/bin/kafka-topics.sh --bootstrap-server kafka-k8s-0.kafka-k8s-endpoints:9092,kafka-k8s-1.kafka-k8s-endpoints:9092,kafka-k8s-2.kafka-k8s-endpoints:9092,kafka-k8s-3.kafka-k8s-endpoints:9092 --list --command-config /etc/kafka/client.properties'

where kafka-k8s-0.kafka-k8s-endpoints:9092,kafka-k8s-1.kafka-k8s-endpoints:9092,kafka-k8s-2.kafka-k8s-endpoints:9092,kafka-k8s-3.kafka-k8s-endpoints:9092 - is the contents of the $BOOTSTRAP_SERVERS variable.

Juju external users

For external users managed by the Data Integrator Charm, the endpoints and credentials can be fetched using the dedicated action:

juju run data-integrator/leader get-credentials --format yaml

The client.properties file can be generated by substituting the relevant information in the file available on the brokers at /etc/kafka/client.properties.

To do so, fetch the information using juju commands:

BOOTSTRAP_SERVERS=$(juju run data-integrator/leader get-credentials --format yaml | yq .kafka.endpoints )
USERNAME=$(juju run data-integrator/leader get-credentials --format yaml | yq .kafka.username )
PASSWORD=$(juju run data-integrator/leader get-credentials --format yaml | yq .kafka.password )

Then copy the /etc/kafka/client.properties and substitute the following lines:

...
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="<USERNAME>" password="<PASSWORD>";
...
bootstrap.servers=<BOOTSTRAP_SERVERS>