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 releases.
Confluent for Kubernetes 2.0.3 Release Notes¶
Confluent for Kubernetes 2.0.3 allows you to deploy and manage Confluent Platform versions 6.0.x, 6.1.x, and 6.2.x on Kubernetes.
- There are no new enhancements in this release.
- Confluent Control Center configuration - Fixed the configuration setting to add the right prefix for Schema Registry REST TLS.
- Kafka rolling restart - Fixed rolling restart to gracefully shutdown each Kafka broker.
- Red Hat Universal Base Images (UBI) - Incorporated the latest version of UBI.
Confluent for Kubernetes 2.0.2 Release Notes¶
Confluent for Kubernetes 2.0.2 allows you to deploy and manage Confluent Platform versions 6.0.x, 6.1.x, and 6.2.x on Kubernetes.
- Improved troubleshooting during deployments - CFK logs a message when a missing secret prevents a Confluent custom resource from being deployed.
- Multiple Kafka listeners, for example, internal and external listeners, can share the same secret reference for a TLS certificate in the Kafka custom resource.
- You can specify an image pull policy (
IfNotPresent) for all Confluent component custom resources.
- ZooKeeper TLS - ZooKeeper no longer logs an unnecessary “Unsuccessful handshake” message.
- Configurations - CFK supports specifying username and password without quotes in configuration secret text files.
- Configurations - Usernames and passwords can contain the “=” character.
- Node ports creation - The NodePort services are created with the appropriate
ports taking into account the
- CFK Helm configuration - Helm commands with a list of namespaces can now handle a space character between namespace names.
- License configuration - The license secrets can contain whitespaces and newline characters.
- Dangling secrets - CFK deletes the secrets it created when the secret is no longer needed.
- Telemetry configuration - Now allows empty proxy configurations so that you can configure that a proxy is not required.
- Connect mTLS configuration is supported.
- Kubectl Confluent plugin - Now works with CFK cluster deployed to Microsoft Azure.
- ZooKeeper config overrides - Now you can override the
- Automatic rolling updates - For Kafka config overrides, CFK automatically rolls the Kafka deployment.
- CFK supports changing the password for the default inter-broker user and ZooKeeper quorum user.
- If using
DirectoryInPathContainerto provide sensitive configurations for ZooKeeper TLS certificates, you cannot specify the JKS truststore and keystore password through this mechanism. You can use
configOverridesto provide this.
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/execKubernetes resource privilege.
- 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.
- Topic creation - A Topic custom resource can contain multiple configurations for the Topic.
- Topic creation - You can specify the optional
replicationFactorin Topic custom resources to support
confluent.placement.constraintsfor the Topic.
- Inter-broker communication with SASL/Plain with Kafka ACLs - The
operatoruser 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.x supports deploying Confluent Platform 6.0 and 6.1.
- CFK 2.0.x 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.x.
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.pemthat contains the both (1) the Confluent Cloud CA and (2) the self-signed CA to the ksqlDB CR.
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 fully up.
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.0 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.