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 and local.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 the kubectl 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 and controlcenter-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