Release notes

Rebase to Strimzi 1.0.1 and Kafka 4.2.0

This release of Cloudera Streams Messaging Operator for Kubernetes is based on Strimzi 1.0.1 (previously 0.49.1) and Kafka 4.2.0 (previously 4.1.1), bringing new features including per-listener Kafka options, advertised port templates, environment variable-based rack awareness, and on-demand KafkaUser certificate renewal.

See the following upstream resources for more information on these versions:

• Strimzi 0.50.0 Release notes
• Strimzi 0.51.0 Release notes
• Strimzi 1.0.0 Release notes
• Strimzi 1.0.1 Release notes
• Kafka 4.2.0 Release notes
• Kafka 4.2.0 Notable changes

Strimzi v1 API is now the only supported API version

The v1alpha1, v1beta1, and v1beta2 API versions for Strimzi Custom Resource Definitions (CRDs) are removed in this release. Only the v1 API (kafka.strimzi.io/v1) is supported.

Custom resources still using old API versions will stop working after upgrading to this release. Before upgrading, convert all Strimzi custom resources to the v1 API using the Strimzi API conversion tool shipped with Cloudera Streams Messaging Operator for Kubernetes. Additionally, run the crd-upgrade command to finalize the API conversion at the CRD level before upgrading Strimzi.

For conversion instructions, see Converting Strimzi custom resource to the v1 API

Strimzi Drain Cleaner

Cloudera Streams Messaging Operator for Kubernetes now ships Strimzi Drain Cleaner as an optional, separately installable component. Strimzi Drain Cleaner helps you safely drain Kubernetes nodes that run Strimzi-managed Kafka Pods during cluster maintenance or upgrades. It uses a validating admission webhook to coordinate rolling Pod restarts through the Strimzi Cluster Operator, helping keep Kafka partitions in sync while nodes are drained.

For more information, see the following resources:

• Deployment architecture
• Installing Strimzi Drain Cleaner with Helm
• Strimzi Drain Cleaner overview
• Strimzi Drain Cleaner Helm chart configuration reference

OperatorHub installation on OpenShift is discontinued

Cloudera Streams Messaging Operator for Kubernetes no longer ships an Operator Lifecycle Manager (OLM) bundle. New releases are not published to OperatorHub in OpenShift. Use Helm for installation instead.

For installation instructions, see Installation overview.

Minimum Kubernetes version is now 1.30

The minimum supported Kubernetes version is raised to 1.30. Kubernetes 1.27, 1.28, and 1.29 are no longer supported. The minimum supported OpenShift version is raised to 4.17.

For the full list of system requirements, see System requirements.

report.sh captures Cloudera Surveyor data

The report.sh diagnostic tool now discovers and includes diagnostic data for Cloudera Surveyor instances by default. The bundle captures the full set of Kubernetes resources associated with each Cloudera Surveyor instance, including Deployments, ConfigMaps, Secrets, Services, ReplicaSets, Pods, and pod logs.

For more information, see Diagnostics.

Kafka options are now configurable per listener

The following Kafka options can now be configured individually for each listener in the Kafka resource, rather than only at the broker level via spec.kafka.config:

• connections.max.reauth.ms
• max.connections
• max.connections.per.ip
• max.connections.per.ip.overrides
• max.connection.creation.rate

Per-listener configuration enables more granular control. For example, session re-authentication can be enforced on a specific external listener without affecting internal listeners. For more information, see Listener configuration options.

Advertised port template for listener configuration

A new advertisedPortTemplate field in the listener configuration controls how Strimzi generates the advertised ports for individual brokers. The field accepts a simple mathematical expression using the {nodeId} placeholder and the +, -, and * operators. This is useful for external listener types such as nodeport and loadbalancer, where clients connect directly to specific brokers and need predictable per-broker port numbers. For more information, see Listener configuration options.

Environment variable-based rack awareness

A new type: environment-variable option is available for rack awareness configuration in the Kafka resource. Instead of reading rack information from Kubernetes node labels, which requires ClusterRoleBindings for the Strimzi Cluster Operator, the rack value is derived from an environment variable present in the broker pod.

This makes rack awareness available in environments where granting ClusterRoleBindings to the Strimzi Cluster Operator is restricted. For more information, see Rack awareness.

Force-renew KafkaUser certificates on demand

A new strimzi.io/force-renew annotation on the user Secret triggers immediate renewal of a KafkaUser certificate. This is useful when a certificate needs to be rotated ahead of its normal renewal schedule, for example after a security incident or when a certificate must be rotated for operational reasons. For more information, see Renewing KafkaUser certificates.

Client Configurations download in Cloudera Surveyor

Cloudera Surveyor adds a Client Configurations tab on the Cluster Details page for each monitored Kafka cluster. From this tab, end users can preview, copy, and download files that you configure for that cluster. The typical use case is exposing connection material for external Kafka clients, such as client configuration properties and CA certificates.

The tab is empty by default and no files are available for download. You configure what is available by storing file content in Kubernetes Secrets and referencing them using clusterConfigs.clusters[*].clientConfigs properties in your values file.

Controller column visibility and metadata store display in Cloudera Surveyor

The Controller column on the Brokers page and in theCluster Details > Brokers tab is not displayed for KRaft-based clusters. A new Metadata Store property is now visible in the cluster details drawer, explicitly indicating whether the cluster uses KRaft or ZooKeeper.

Configurable instance name in Cloudera Surveyor

You can now configure an instance name for Cloudera Surveyor using the new instanceName property. When set, the name is displayed on the UI. This is useful when running multiple Cloudera Surveyor instances, as the name allows for quick differentiation between instances.

Read-only broker configuration in Cloudera Surveyor

A new clusterConfigs.clusters[*].readOnlyBrokerConfigs property allows you to disable broker configuration editing for individual registered Kafka clusters. When set to true, the Edit Properties button on Broker Details pages is disabled and broker configuration properties cannot be modified through the Cloudera Surveyor UI or API.

This is particularly useful for Kafka clusters managed by the Strimzi Cluster Operator, where any configuration changes applied through Cloudera Surveyor would be overwritten during the next Strimzi reconciliation cycle. Setting this property to true for Strimzi-managed clusters is highly recommended. For more information, see Disabling broker configuration editing.

Redesigned Cloudera Surveyor user interface

The Cloudera Surveyor user interface has been redesigned. All pages, tables, navigation elements, filters, controls, and icons have a new look and feel. All existing functionality, navigation structure, and workflows remain unchanged.

Updated Entity Details drawer in Cloudera Surveyor

The Entity Details drawer has been updated with the following improvements:

• Attributes are now organized into named sections that vary by entity type, replacing the previous flat attribute list.
• After the drawer is opened, a collapsible strip persists on the right edge of the page until you navigate away, so you can reopen the drawer without reselecting an entity.

For more information, see Entity Details drawer.

Strimzi

None.

Kafka

None.

Cloudera Surveyor

CSMDS-1697: Snapshot errors when Connect or MirrorMaker 2 groups are present on a Kafka cluster

Fixed a bug where Cloudera Surveyor incorrectly attempted to describe consumer groups that use the connect protocol on Kafka clusters running Kafka Connect or MirrorMaker 2, causing snapshot failures.

CSMDS-1825: Topic name field not reset or focused after topic creation

Fixed a bug where the Topic Name field was not cleared or focused after creating a topic. The field is now reset and automatically focused after each successful topic creation.

CSMDS-1821: Browser back navigation looping on detail pages

Fixed a bug where the browser Back button would loop instead of navigating back on Topic, Broker, Cluster, Consumer Group, and Producer Details pages.

CSMDS-1820: Missing placeholder for unset broker rack

Fixed a bug where the Rack field on the Broker Details page showed nothing when a broker had no rack configured. The field now displays a placeholder value.

CSMDS-1780: Stuck time counter and incorrect tooltips on Configuration tabs

Fixed a bug where the time-since-last-update counter on Configuration tabs was frozen when auto-update was disabled. Additionally corrected the tooltip texts on Configuration tabs to reflect that configuration data is fetched live and is not based on a Kafka snapshot.

Schema Registry

None.

Strimzi

None.

Kafka

None.

Cloudera Surveyor

None.

Schema Registry

None.

Strimzi

Kafka

None.

Cloudera Surveyor

None.

Schema Registry

None.

Strimzi

Strimzi API versions v1alpha1, v1beta1, and v1beta2

The v1alpha1, v1beta1, and v1beta2 API versions for Strimzi Custom Resources are removed. Only the v1 API (kafka.strimzi.io/v1) is supported. Custom resources still using old API versions will stop working after upgrading. Before upgrading, convert all custom resources to the v1 API using the Strimzi API conversion tool shipped with Cloudera Streams Messaging Operator for Kubernetes.

The type: oauth authentication in Kafka

The type: oauth authentication type for Kafka listeners and Kafka Connect is removed. It was only available in the v1beta2 API and is not present in the v1 API. Use type: custom instead to configure OAuth authentication.

Mounting additional Secrets in the custom authentication type

Support for the spec.kafka.listeners[*].authentication.secrets property in the custom authentication type is removed. Use the additional volumes and volume mounts instead to mount additional Secrets. For more information, see Configuring additional volumes and volume.

Storage overrides

Support for storage overrides for persistent volumes is removed. The spec.storage.overrides property in the KafkaNodePool resource is no longer supported. If you want to configure storage classes on a per-broker basis, deploy multiple KafkaNodePool resources with a different storage class each.

CPU and memory configuration in the Kafka resource

The spec.kafka.resources property is removed from the v1 API. Define CPU and memory requests and limits in KafkaNodePool resources instead.

spec.externalConfiguration in KafkaConnect resources

The spec.externalConfiguration property is removed from the v1 API. Use spec.template to configure additional environment variables or volumes in Connect worker pods instead. The Strimzi API conversion tool does not migrate this property automatically. For more information, see Adding external configuration to Kafka Connect worker pods.

Kafka

None.

Cloudera Surveyor

None.

Schema Registry

None.

Strimzi

Buildah is now the default builder for Kafka Connect custom images

Previous Behavior: Kaniko was used to build custom Kafka Connect images when spec.build was configured in a KafkaConnect resource.

New Behavior: Buildah is now the default builder. The spec.build configuration syntax in KafkaConnect resources does not change. Air-gapped users who use the Kafka Connect image build who use spec.build in KafkaConnect resources to automatically build new Kafka images must mirror the Buildah image before upgrading. If the Buildah image is not available in the self-hosted registry after upgrading, the image build will fail. The Buildah image is available at container.repository.cloudera.com/cloudera/buildah:1.0.1-csmop-1.7.0-b248.

Server-side apply is now enabled by default

Previous Behavior: Strimzi used client-side apply when managing Kubernetes resources.

New Behavior: The ServerSideApplyPhase1 feature gate is now enabled by default. Strimzi uses server-side apply when managing Kubernetes resources. For standard deployments this change is transparent. Users who manually modify Strimzi-managed resources or use GitOps tools that also apply these resources may encounter field manager conflicts.

Entity Operator cross-namespace watching is disabled by default

Previous Behavior: In previous versions, when you configured watchedNamespace in your Entity Operator (Topic Operator or User Operator) to watch a different namespace than the Kafka cluster namespace, cross-namespace watching was enabled automatically.

New Behavior: Cross-namespace watching is now disabled by default. To watch a namespace different from the Kafka cluster namespace, you must explicitly enable it by setting the STRIMZI_ENTITY_OPERATOR_WATCHED_NAMESPACE_ENABLED=true environment variable in your Cluster Operator Deployment.

Enabling cross-namespace watching extends the Entity Operator's access beyond the Kafka cluster namespace, including full create, read, update, and delete access to Secret resources in the watched namespace. Enable it only when you need this configuration and accept that cross-namespace trust boundary.

If you are upgrading from a previous version and have watchedNamespace configured to a different namespace than your Kafka cluster, you must set STRIMZI_ENTITY_OPERATOR_WATCHED_NAMESPACE_ENABLED=true during the upgrade. If you upgrade without enabling this environment variable, the Entity Operator Deployment and all related resources will be deleted during reconciliation, and your topics and users will no longer be managed until you enable cross-namespace watching. For upgrade instructions, see Upgrading and rolling back Cloudera Streams Messaging Operator for Kubernetes. For configuration instructions, see Deploying and configuring the Strimzi Entity Operator.

Kafka

None.

Cloudera Surveyor

HTTP listener is disabled and default service port changes when TLS is enabled

Previous Behavior: When tlsConfigs.enabled was set to true, the HTTP listener on port 8080 remained active alongside the HTTPS listener. The default value of service.port was 8080.

New Behavior: The HTTP listener is disabled when TLS is enabled. Cloudera Surveyor accepts only HTTPS traffic on the configured TLS port. The default value of service.port is now 8443 to match the default TLS configuration. The liveness and readiness probes in the Helm-managed Deployment are updated automatically to use HTTPS. The HTTP listener was only reachable from within the Kubernetes cluster, so external traffic was not affected by its presence. If you have TLS enabled and have not explicitly set service.port in your values file, verify that any in-cluster tooling such as custom health checks or monitoring agents targeting port 8080 over HTTP are updated to use port 8443 over HTTPS.

Default service type is now ClusterIP

Previous Behavior: The Helm chart created a NodePort type Service by default, making the Cloudera Surveyor UI reachable from outside the Kubernetes cluster without additional configuration.

New Behavior: The Helm chart now creates a ClusterIP type Service by default. The UI is not reachable externally without configuring an Ingress or a LoadBalancer type Service. If you are upgrading and relied on the NodePort default, configure external access using Ingress or LoadBalancer, or explicitly set service.type: NodePort in your values file.

service.tlsPort and ingress.rules.port properties removed

Previous Behavior: Two separate port properties existed: service.tlsPort configured a dedicated TLS port on the Service, and ingress.rules.port configured which Service port the Ingress forwarded traffic to.

New Behavior: Both properties are removed. Only service.port configures the Service port, and the Ingress forwards to service.port automatically. Remove service.tlsPort and ingress.rules.port from any custom values files.

LDAP authentication properties are now nested under the ldap key

Previous Behavior: LDAP authentication properties were configured directly under surveyorConfig.surveyor.authentication, for example surveyorConfig.surveyor.authentication.enabled.

New Behavior: All LDAP authentication properties are now nested one level deeper under a ldap key, for example surveyorConfig.surveyor.authentication.ldap.enabled. Update any custom values files or automation scripts that reference the old property paths.

Schema Registry

None.