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.1 releases.
Confluent for Kubernetes 3.1.0 Release Notes
CFK 3.1.0 allows you to deploy and manage Confluent Platform versions from 7.3.x to 8.0.x on Kubernetes versions 1.26 - 1.34 (OpenShift 4.13 -4.19).
The images released in CFK 3.1.0 are:
confluentinc/confluent-operator:0.1351.24
confluentinc/confluent-init-container:3.1.0
confluentinc/<CP component images>:8.1.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.1.0 is a minor release with the following noteworthy new features and updates.
- Confluent Unified Stream Manager Agent Support
You can use CFK to deploy Unified Stream Manager.
See Configure, Deploy, and Manage Unified Stream Manager Using Confluent for Kubernetes.
- Unified Stream Manager Schema Registry Support
You can use CFK to deploy Unified Stream Manager Schema Registry.
See Set up Schema Registry Switchover with Unified Stream Manager.
- Confluent Private Cloud Gateway Support
You can use CFK to deploy Confluent Gateway.
See Deploy and Manage Confluent Private Cloud Gateway with Confluent for Kubernetes.
- Removal of Confluent for Kubernetes (CFK) Blueprints
Confluent for Kubernetes (CFK) Blueprints is deprecated and removed in this release.
Notable update
A new Confluent Enterprise license is available for the customer-managed Confluent Platform for Confluent Cloud subscription. This license allows you to use self-managed Confluent Platform components exclusively with Confluent Cloud services.
If you encounter the following error when provisioning a new license, you should upgrade to a CFK version, 2.9.7, 2.10.3, 2.11.3, 3.0.1, 3.1.0, or later.
secretRef confluent-license: missing subject or contains invalid subject
Known issues
When deploying CFK to Red Hat OpenShift with Red Hat’s Operator Lifecycle Manager using the OperatorHub, you must use OpenShift version 4.9 or higher.
This OpenShift version restriction does not apply when deploying CFK to Red Hat OpenShift in the standard way without using the Red Hat Operator Lifecycle Manager.
When CFK is deployed on an OpenShift cluster with Red Hat’s Operator LIfecycle Manager/OperatorHub, capturing the support bundle for CFK using the command,
kubectl confluent support-bundle --namespace <namespace>
, can fail with the following error message:panic: runtime error: index out of range [0] with length 0
If the ksqlDB REST endpoint is using the auto-generated certificates, the ksqlDB deployment that points to Confluent Cloud requires trusting the Let’s Encrypt CA.
For this to work, you must provide a CA bundle through
cacerts.pem
that contains both (1) the Confluent Cloud CA and (2) the self-signed CA to the ksqlDB CR.When TLS is enabled, and when Confluent Control Center (Legacy) uses a different TLS certificate to communicate with MDS or Confluent Cloud Schema Registry, Control Center (Legacy) (used with Confluent Platform 7.x) cannot use an auto-generated TLS certificate to connect to MDS or Confluent Cloud Schema Registry. See Troubleshooting Guide for a workaround.
When deploying the Schema Registry and Kafka CRs simultaneously, Schema Registry could fail because it cannot create topics with a replication factor of 3. It is because the Kafka brokers have not fully started.
The workaround is to delete the Schema Registry deployment and re-deploy once Kafka is fully up.
When deploying an RBAC-enabled Kafka cluster in centralized mode, where another “secondary” Kafka is being used to store RBAC metadata, an error, “License Topic could not be created”, may return on the secondary Kafka cluster.
A periodic Kubernetes TCP probe on ZooKeeper (in Confluent Platform 7.x) causes frequent warning messages “client has closed socket” when warning logs are enabled.
REST Proxy configured with monitoring interceptors is missing the callback handler properties when RBAC is enabled. Interceptor would not work, and you would see an error message in the KafkaRestProxy log.
As a workaround, manually add configuration overrides as shown in the following KafkaRestProxy CR:
configOverrides: server: - confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler - consumer.confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler - producer.confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
When configuring source-initiated cluster links with CFK where the source cluster has TLS enabled, set the following in the Source mode ClusterLink CR, under the
spec.configs
section:local.security.protocol: SSL
andlocal.listener.name: <SSL listener name>
for mTLS.local.security.protocol: SASL_SSL
for SASL authentication with TLS.
For details about configuring source-initiated Cluster Linking, see Configure the source-initiated cluster link on the source cluster.
The CFK support bundle plugin on Windows systems does not capture all the logs.
As a workaround, specify the
--out-dir
flag in thekubectl confluent support-bundle
command to provide the output location for the support bundle.When you have external access enabled with load balancer type for both Control Center and Prometheus, only
controlcenter-next-gen-prometheus-bootstrap-lb
gets created.The workaround is to enable Control Center external access first, and then add Prometheus external access. This will show both Control Center and Prometheus external
controlcenter-next-gen-bootstrap-lb
andcontrolcenter-next-gen-prometheus-bootstrap-lb
get created.
Known gaps from Confluent Platform 8.1
CFK 3.1 does not support the following Confluent Platform 8.1 functionality:
Kafka authentication mechanisms: Kerberos and SASL/Scram