Chapter 2. Enhancements

AMQ Streams 2.2 adds a number of enhancements.

2.1. Kafka 3.2.3 enhancements

For an overview of the enhancements introduced with Kafka 3.2.0, 3.2.1, and 3.2.3, refer to the Kafka 3.2.0 Release Notes, Kafka 3.2.1 Release Notes, and Kafka 3.2.3 Release Notes.

2.2. Tracking Cruise Control status on the command line

It is now easier to check the status of optimization proposals. Instead of inspecting the resource configuration YAML, you can check the status on the command line.

When you run a proposal, run the following command and wait for the status of the optimization proposal to change to ProposalReady:

oc get kafkarebalance -o wide -w -n <namespace>
PendingProposal
A PendingProposal status means the rebalance operator is polling the Cruise Control API to check if the optimization proposal is ready.
ProposalReady
A ProposalReady status means the optimization proposal is ready for review and approval.

When the status changes to ProposalReady, the optimization proposal is ready to approve.

See Generating optimization proposals and Approving optimization proposals.

2.3. Renewing user certificates during the maintenance time window

Maintenance time windows allow you to schedule certain rolling updates of your Kafka and ZooKeeper clusters to start at a convenient time. Maintenance windows are now supported in the User Operator. If you have deployed the User Operator using the Cluster Operator, and not as a standalone operator, automatic renewal of user certificates is included in the schedule.

If you are deploying the standalone User Operator, you can configure the maintenance time window during which expiring user certificates are renewed. You specify the time window as a Cron expression for the STRIMZI_MAINTENANCE_TIME_WINDOWS environment variable.

See Deploying the standalone User Operator.

2.4. Renaming Cruise Control topics

It’s now possible to rename the topics related to metrics that are created automatically by Cruise Control. You can use the following Cruise Control configuration properties to make the name change.

Example Cruise Control topic renaming

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
      # ...
    config: 1
      # ...
      metric.reporter.topic: cruise-control-metrics-reporter-topic-name
      partition.metric.sample.store.topic: cruise-control-partitions-metrics-name
      broker.metric.sample.store.topic: cruise-control-broker-metrics
      # ...
# ...

If you change the names of the topics in an existing deployment, you need to remove the topics with the old names manually.

See Configuring and deploying Cruise Control with Kafka.

2.5. Using Cruise Control without ZooKeeper

Cruise Control now runs without ZooKeeper, using Kafka APIs instead. The TLS sidecar that was used for secure communication with ZooKeeper has been removed.

The TLS sidecar configuration for Cruise Control in the Kafka resource is no longer required. For this reason, the .spec.cruiseControl.tlsSidecar and .spec.cruiseControl.template.tlsSidecar properties are now deprecated.

See Configuring and deploying Cruise Control with Kafka.

2.6. Configuring rack awareness for MirrorMaker 2.0

You can now enable rack awareness in your MirrorMaker 2.0 resource configuration. This is a specialized option intended for a deployment within the same location, not across regions. You can use this option if you want connectors to consume from the closest replica rather than the leader replica.

A topologyKey in the rack configuration must match a node label containing the rack ID. In the following example, the standard topology.kubernetes.io/zone label is specified.

Rack configuration for MirrorMaker 2.0

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.2.3
  # ...
  rack:
    topologyKey: topology.kubernetes.io/zone

To consume from the closest replica, you must also enable the RackAwareReplicaSelector in the Kafka broker configuration.

Example rack configuration with enabled replica-aware selector

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: topology.kubernetes.io/zone
    config:
      # ...
      replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector
    # ...

See Configuring Kafka MirrorMaker 2.0 and Rack schema reference.

2.7. Setting heap sizes based on the percentage of available memory

If you don’t specify heap sizes in your configuration, the Cluster Operator imposes default heap sizes automatically. The Cluster Operator sets default maximum and minimum heap values based on a percentage of the memory resource configuration. The available memory allocated by default is now set at the levels shown in the following table.

Table 2.1. Default heap settings for components

ComponentPercent of available memory allocated to the heapMaximum limit

Kafka

50%

5 GB

ZooKeeper

75%

2 GB

Kafka Connect

75%

None

MirrorMaker 2.0

75%

None

MirrorMaker

75%

None

Cruise Control

75%

None

Kafka Bridge

50%

31 Gi

See jvmOptions