Confluent for Kubernetes Release Notes

Confluent for Kubernetes (CFK) provides a declarative API driven control plane to deploy and manage Confluent Platform on Kubernetes.

The following sections summarize the technical details of the CFK 2.2.x releases.

Confluent for Kubernetes 2.2.0 Release Notes

Confluent for Kubernetes 2.2.0 allows you to deploy and manage Confluent Platform versions 6.2.x and 7.0.x on Kubernetes.

New features

The following new features are supported in Confluent for Kubernetes 2.2.0:

Notable enhancements

  • You can deploy CFK and Confluent Platform on Kubernetes 1.22.

Notable fixes

  • Applying a KafkaTopic custom resource failed to create a Kafka topic when Kafka ACLs were enabled.
  • An incorrect Confluent Admin Rest API configuration was generated when Kafka ACLs were enabled.
  • Now the external traffic policy is correctly set to Local instead of Cluster for external broker load balancers.

Known issues

  • When deploying Confluent for Kubernetes to Red Hat OpenShift with Red Hat’s Operator Lifecycle Manager (i.e. using the Operator Hub), you must use OpenShift version 4.9.

    This OpenShift version restriction does not apply when deploying CFK to Red Hat OpenShift in the standard way described in this documentation which does not use the Red Hat Operator Lifecycle Manager, and which applies generically across any supported Kubernetes distribution.

  • If ksqlDB REST endpoint is using the auto-generated certificates, the ksqlDB deployment that points to Confluent Cloud requires to trust the Let’s Encrypt CA.

    For this to work, you must provide a CA bundle through cacerts.pem that contains the 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 uses a different TLS certificate to communicate with MDS or Confluent Cloud Schema Registry, Control Center 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. This 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 causes frequent warning messages “client has closed socket” when warning logs are enabled.

  • If you are deploying Confluent Platform 6.2.3 or 7.0.2 with centralized RBAC, you might see an “Invalid License” issue when connecting to the secondary Kafka cluster.

    The workaround is to restart the secondary Kafka cluster.

Known gaps from Confluent Platform 7.0

CFK 2.2.0 does not support the following Confluent Platform 7.0 functionality:

  • Kafka authentication mechanisms: Kerberos and SASL/Scram
  • Multi-region cluster deployments: Only supported in the Early Access program