Chapter 3. Features AMQ Streams 2.5 introduces the features described in this section. AMQ Streams 2.5 on OpenShift is based on Apache Kafka 3.5.0 and Strimzi 0.36.x. Note To view all the enhancements and bugs that are resolved in this release, see the AMQ Streams Jira project . 3.1. AMQ Streams 2.5.x (Long Term Support) AMQ Streams 2.5.x is the Long Term Support (LTS) offering for AMQ Streams. The latest patch release is AMQ Streams 2.5.2. The AMQ Streams product images have changed to version 2.5.2. Although the supported Kafka version is listed as 3.5.0, it incorporates updates and improvements from Kafka 3.5.2. For information on the LTS terms and dates, see the AMQ Streams LTS Support Policy . 3.2. OpenShift Container Platform support AMQ Streams 2.5 is supported on OpenShift Container Platform 4.12 and later. For more information, see Chapter 11, Supported Configurations . 3.3. Kafka 3.5.x support AMQ Streams supports and uses Apache Kafka version 3.5.0. Updates for Kafka 3.5.2 are incorporated with the 2.5.2 patch release. Only Kafka distributions built by Red Hat are supported. You must upgrade the Cluster Operator to AMQ Streams version 2.5 before you can upgrade brokers and client applications to Kafka 3.5.0. For upgrade instructions, see Upgrading AMQ Streams . Refer to the Kafka 3.5.0 , Kafka 3.5.1 , and Kafka 3.5.2 Release Notes for additional information. Kafka 3.4.x is supported only for the purpose of upgrading to AMQ Streams 2.5. Note Kafka 3.5.x provides access to KRaft mode, where Kafka runs without ZooKeeper by utilizing the Raft protocol. KRaft mode is available as a Developer Preview . 3.4. Supporting the v1beta2 API version The v1beta2 API version for all custom resources was introduced with AMQ Streams 1.7. For AMQ Streams 1.8, v1alpha1 and v1beta1 API versions were removed from all AMQ Streams custom resources apart from KafkaTopic and KafkaUser . Upgrade of the custom resources to v1beta2 prepares AMQ Streams for a move to Kubernetes CRD v1 , which is required for Kubernetes 1.22. If you are upgrading from an AMQ Streams version prior to version 1.7: Upgrade to AMQ Streams 1.7 Convert the custom resources to v1beta2 Upgrade to AMQ Streams 1.8 Important You must upgrade your custom resources to use API version v1beta2 before upgrading to AMQ Streams version 2.5. 3.4.1. Upgrading custom resources to v1beta2 To support the upgrade of custom resources to v1beta2 , AMQ Streams provides an API conversion tool , which you can download from the AMQ Streams 1.8 software downloads page . You perform the custom resources upgrades in two steps. Step one: Convert the format of custom resources Using the API conversion tool, you can convert the format of your custom resources into a format applicable to v1beta2 in one of two ways: Converting the YAML files that describe the configuration for AMQ Streams custom resources Converting AMQ Streams custom resources directly in the cluster Alternatively, you can manually convert each custom resource into a format applicable to v1beta2 . Instructions for manually converting custom resources are included in the documentation. Step two: Upgrade CRDs to v1beta2 , using the API conversion tool with the crd-upgrade command, you must set v1beta2 as the storage API version in your CRDs. You cannot perform this step manually. For more information, see Upgrading from an AMQ Streams version earlier than 1.7 . 3.5. (Preview) Node pools for managing nodes in a Kafka cluster This release introduces the KafkaNodePools feature gate and a new KafkaNodePool custom resource that enables the configuration of different pools of Apache Kafka nodes. This feature gate is at an alpha level of maturity, which means that it is disabled by default, and should be treated as a developer preview . A node pool refers to a distinct group of Kafka nodes within a Kafka cluster. The KafkaNodePool custom resource represents the configuration for nodes only in the node pool. Each pool has its own unique configuration, which includes mandatory settings such as the number of replicas, storage configuration, and a list of assigned roles. As you can assign roles to the nodes in a node pool, you can try the feature with a Kafka cluster that uses ZooKeeper for cluster management or KRaft mode. To enable the KafkaNodePools feature gate, specify +KafkaNodePools in the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration. Enabling the KafkaNodePools feature gate env: - name: STRIMZI_FEATURE_GATES value: +KafkaNodePools Note Drain Cleaner is not supported for the node pools preview. See Configuring node pools . 3.6. (Preview) Unidirectional topic management using the Topic Operator This release also incorporates the UnidirectionalTopicOperator feature gate, introducing a unidirectional topic management mode. With unidirectional mode, you create Kafka topics using the KafkaTopic resource, which are then managed by the Topic Operator. This feature gate is at an alpha level of maturity, and should be treated as a developer preview . To enable the UnidirectionalTopicOperator feature gate, specify +UnidirectionalTopicOperator in the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration. Enabling the UnidirectionalTopicOperator feature gate env: - name: STRIMZI_FEATURE_GATES value: +UnidirectionalTopicOperator Up to this release, the only way to use the Topic Operator to manage topics was in bidirectional mode, which is compatible with using ZooKeeper for cluster management. Unidirectional mode does not require ZooKeeper for cluster management, which is an important development as Kafka moves to using KRaft mode for managing clusters. See Using the Topic Operator . 3.7. Reporting tool for retrieving diagnostic and troubleshooting data The report.sh diagnostics tool is a script provided by Red Hat to gather essential data for troubleshooting AMQ Streams deployments on OpenShift. It collects relevant logs, configuration files, and other diagnostic data to assist in identifying and resolving issues. When you run the script, you can use additional parameters to retrieve specific data. The tool requires the OpenShift oc command-line tool to establish a connection to the running cluster. After which you can open a terminal and run the tool to retrieve data on components. From the following request, data is collected on a Kafka cluster, a Kafka Bridge cluster, and on secret keys and data values: Example request with data collection options ./report.sh --namespace=my-amq-streams-namespace --cluster=my-kafka-cluster --bridge=my-bridge-component --secrets=all --out-dir=~/reports The data is output to a specified directory. See Retrieving diagnostic and troubleshooting data . 3.8. OpenTelemetry for distributed tracing OpenTelemetry for distributed tracing has moved to GA. You can use OpenTelemetry with a specified tracing system. OpenTelemetry has replaced OpenTracing for distributed tracing. Support for OpenTracing is deprecated . By Default, OpenTelemetry uses the OTLP (OpenTelemetry Protocol) exporter for tracing. AMQ Streams with OpenTelemetry is distributed for use with the Jaeger exporter, but you can specify other tracing systems supported by OpenTelemetry. AMQ Streams plans to migrate to using OpenTelemetry with the OTLP exporter by default, and is phasing out support for the Jaeger exporter. See Introducing distributed tracing .

Commands:
env: - name: STRIMZI_FEATURE_GATES value: +KafkaNodePools
env: - name: STRIMZI_FEATURE_GATES value: +UnidirectionalTopicOperator
./report.sh --namespace=my-amq-streams-namespace --cluster=my-kafka-cluster --bridge=my-bridge-component --secrets=all --out-dir=~/reports