Confluent for Kubernetes Release Notes
Confluent for Kubernetes (CFK) provides a declarative API-driven control plane for deploying and managing Confluent Platform on Kubernetes.
The following sections summarize the technical details of the CFK 3.2 releases.
Confluent for Kubernetes 3.2.0 Release Notes
CFK 3.2.0 allows you to deploy and manage Confluent Platform versions from 7.4.x to 8.2.x on Kubernetes versions 1.27 - 1.35 (OpenShift 4.14 - 4.21).
The images released in CFK 3.2.0 are:
confluentinc/confluent-operator:0.1514.1confluentinc/confluent-init-container:3.2.0confluentinc/<CP component images>:8.2.0
For details on installing CFK and Confluent Platform using the above images, see Deploy Confluent for Kubernetes and Deploy Confluent Platform using Confluent for Kubernetes.
New features and enhancements
CFK 3.2.0 is a minor release with the following noteworthy new features and updates.
- Observer container support
Observer container provides self-contained readiness monitoring for Kafka and KRaft controller pods.
- Dynamic quorum support
CFK supports dynamic quorum configuration for KRaft deployments. It supports only single cluster deployments, and not multi-region cluster deployments.
See Configure Dynamic KRaft Quorum for Confluent Platform Using Confluent for Kubernetes.
- Bidirectional cluster linking support
CFK supports bidirectional cluster linking, allowing data replication in both directions between two Kafka clusters.
- FIPS 140-3 compliance support
CFK supports deploying FIPS 140-3 compliant Confluent Platform components.
Notable updates
Automatic inter-broker protocol (IBP) version derivation
Enhanced IBP version handling during ZooKeeper to KRaft migration:
Improved validation for IBP version and added automatic derivation of IBP for standard Confluent Platform images.
Added new subphase
SubPhaseSetupDeriveIBPVersioninSETUPphase of KRaft migration job to automatically derive IBP value for standard Confluent Platform images and enforce annotation requirement for custom Confluent Platform images.
See Migrate Confluent Platform from ZooKeeper to KRaft using CFK.
Kafka topic partition count updates
You can increase the partition count for existing Kafka topics through the
KafkaTopiccustom resource.Important
For brownfield deployments, verify partition counts across all topics before upgrading to CFK 3.2.0. If a drift exists between the partition count specified in the
KafkaTopiccustom resource and the actual partition count in the cluster, CFK will automatically reconcile the partition count on the first operator run after upgrade, which may result in unintended partition increase.See Update Kafka topic.
Safe rolling restarts for secret updates
Secret updates now trigger operator-controlled rolling restarts with under-replicated partition (URP) safety checks for Kafka and KRaft components, preventing cluster instability during certificate rotation.
SASL PLAIN user management without broker restarts
SASL/PLAIN credentials for external clients, such as producers or consumers, can now be added or rotated without triggering broker restarts. The CFK operator automatically hot-reloads credential changes when you use the default
FileBasedLoginModuleforjaasConfig, eliminating the operational overhead of rolling restarts for user management. This capability is enabled by default for all customers and supports zero-downtime onboarding for application-level users. The following are the scope and limitations:Hot-reload applies only to external SASL/PLAIN credentials on server side. Do not use this feature to upgrade inter-broker SASL/PLAIN credentials or Confluent component authentication.
Not supported for SASL/PLAIN with LDAP or when using
configOverrides.This feature requires
FileBasedLoginModule. While this module is automatic withjaasConfig, you must explicitly configure it when you usejaasConfigPassthrough.
Init container environment variable validation
CFK validates required init-container environment variables and allows appending custom environment variables to init containers using the common
podTemplatespec.Unified Stream Manager Schema Registry automation workflow optimization
The Unified Stream Manager Schema Registry automation workflow has been optimized for improved performance.
Notable fixes
Fixed an issue where the CFK operator ignored the
platform.confluent.io/roll-delay-interval-secondsannotation during upgrades. This issue caused the pods to roll immediately instead of waiting for the configured delay.Fixed connector reconciliation for masked sensitive fields in Connect. Updated CFK’s connector reconciliation logic to properly handle Connect’s credential masking in the REST API, preventing unnecessary connector updates or restarts when sensitive configuration fields are masked.
Fixed a issue where the CFK operator did not add the Unified Stream Manager (USM) extension class when RBAC authorization was enabled.