Confluent for Kubernetes Release Notes
Confluent for Kubernetes 2.0.1 provides a declarative API driven control plane to deploy
and manage Confluent Platform on Kubernetes.
The following sections summarize the technical details of the releases.
Confluent for Kubernetes 2.0.1 Release Notes
Confluent for Kubernetes 2.0.1 allows you to deploy and manage Confluent Platform versions 6.0.x, 6.1.x,
and 6.2.x on Kubernetes.
- Improved Kubernetes RBAC security footprint - Confluent for Kubernetes no longer requires the
pod/exec Kubernetes resource privilege.
- Fixed issue in Topic clean up - When a Kafka cluster custom resource is
deleted, any Topic custom resources that were associated with that Kafka
cluster are also deleted.
- Fixed issue in Topic creation - A Topic custom resource can contain multiple
configurations for the Topic.
- Fixed issue in Topic creation - You can specify the optional
replicationFactor in Topic custom resources to support
confluent.placement.constraints for the Topic.
- Fixed issue in inter-broker communication with SASL/Plain with Kafka ACLs - The
operator user is configured as the Kafka super-user and as the user to
authenticate inter-broker communication.
Confluent for Kubernetes 2.0.0 Release Notes
- Kubernetes native interface for Confluent services
- Declaratively manages Confluent services with a CustomResourceDefinition
(CRD) for each component.
- Extends configurations with overrides for server, log4j and JVM properties
for all Confluent services.
- Manages sensitive credentials lifecycle separately and securely through
Kubernetes Secrets or Hashicorp Vault.
- Manage data plane resources
- Declaratively manages RoleBindings with the ConfluentRolebinding CRD.
- Declaratively manages Kafka Topics with the KafkaTopic CRD.
- Automate secure deployments
- Automates production ready secure deployment with authentication, RBAC
authorization, and TLS encryption. CFK automatically creates the required
Confluent component role bindings.
- Uses automatically generated TLS certificates for network encryption for
Confluent components. Just provide a certificate authority for those
certificates to be signed.
- Configures ZooKeeper digest authentication and inter-server TLS encryption.
- Configures Basic authentication for Confluent services REST endpoints.
- CFK 2.0 supports deploying Confluent Platform 6.0 and 6.1.
- CFK 2.0 supports deploying on Kubernetes 1.15 through 1.20.
If you are using Confluent Operator 1.6 or 1.7, and running Confluent Platform 6.0 or 6.1, you
can use the migration automation scripts to migrate to CFK 2.0.
If ksqlDB REST endpoint is using the auto-generated certificates, the
ksqlDB deployment that points to Confluent Cloud requires to trust the Let’s
For this to work, you must provide a CA bundle through
that contains the both (1) the Confluent Cloud CA and (2) the self-signed CA to the
When deploying 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
When deploying a RBAC-enabled Kafka cluster in the 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.
With Confluent Platform 6.1.1 version, you cannot enable basic authentication for ksqlDB
REST interface. There is no workaround for this.
Known gaps from Confluent Platform 6.1
CFK 2.0.1 does not support the following Confluent Platform 6.1 functionality:
Kafka authentication mechanisms: Kerberos and SASL/Scram
Multi-region cluster deployments
Confluent REST Proxy
The workaround is to deploy and manage the standalone REST Proxy outside of
CFK and point it to the Kafka cluster managed by CFK.