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.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

  • 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.

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

Confluent for Kubernetes 2.1.0 Release Notes

Confluent for Kubernetes 2.1.0 allows you to deploy and manage Confluent Platform versions 6.0.x, 6.1.x, and 6.2.x on Kubernetes.

New features

Kubernetes-native interface for Confluent services
  • Declaratively manages Standalone Confluent REST Proxy with the REST Proxy custom resource definition (CRD).
Manage data plane resources
  • Declaratively manages Schemas with the Schema CRD.
  • Declaratively manages Connectors with the Connector CRD.

To use the REST Proxy CRD or Connector CRD, you need to upgrade the CFK init container to the 2.1.0 tag.

Notable enhancements

The enhancements support you to:

  • Configure more than one external listener with OpenShift routes, where each external listener is advertised on different DNS names, on port 443.
  • Create a support bundle with kubectl plugin in a custom directory.
  • Configure HTTP timeouts through annotations.
  • Configure Confluent Platform components to use Kubernetes Horizontal Pod Autoscaler.
  • Deploy CFK and Confluent Platform on Kubernetes 1.21.

Notable fixes

  • During a migration from Confluent Operator to CFK, TLS is correctly configured for the metric reporter with mTLS authentication.
  • Added a correct data type for Prometheus exporter rule fields.
  • Fixed an issue where Confluent Platform components were not accessible through load balancers after migrating from Confluent Operator to CFK.
  • A secret for Confluent Control Center mail authentication is created only if the username exists.
  • Now you can successfully deploy CFK using a custom Service Account as imagePullSecrets is correctly configured on the Service Account.
  • When using Kafka Connect with Schema Registry, Connect worker properties, key.converter and value.converter, are both correctly configured.

Known issues

  • 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.

  • With Confluent Platform 6.1.1 version, you cannot enable basic authentication for the ksqlDB REST interface. There is no workaround for this.

  • If using DirectoryInPathContainer to provide sensitive configurations for ZooKeeper TLS certificates, you cannot specify the JKS truststore and keystore password through this mechanism. You can use secretRef or configOverrides to provide this.

Known gaps from Confluent Platform 6.2

CFK 2.1.0 does not support the following Confluent Platform 6.2 functionality:

  • Kafka authentication mechanisms: Kerberos and SASL/Scram
  • Multi-region cluster deployments

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.

Notable enhancements

  • There are no new enhancements in this release.

Notable fixes

  • 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.

Known issues

  • 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 custom resource (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 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.

  • If using DirectoryInPathContainer to provide sensitive configurations for ZooKeeper TLS certificates, you cannot specify the JKS truststore and keystore password through this mechanism. You can use secretRef or configOverrides to provide this.

Known gaps from Confluent Platform 6.2

CFK 2.0.3 does not support the following Confluent Platform 6.2 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.

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.

Notable enhancements

  • 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 (Always, Never, IfNotPresent) for all Confluent component custom resources.

Notable fixes

  • 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 nodePortOffset configuration input.
  • 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 zookeeper.connect property.
  • 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.

Known issues

  • 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 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.

  • If using DirectoryInPathContainer to provide sensitive configurations for ZooKeeper TLS certificates, you cannot specify the JKS truststore and keystore password through this mechanism. You can use secretRef or configOverrides to provide this.

Known gaps from Confluent Platform 6.2

CFK 2.0.2 does not support the following Confluent Platform 6.2 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.

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.

Notable enhancement

  • Improved Kubernetes RBAC security footprint - Confluent for Kubernetes no longer requires the pod/exec Kubernetes resource privilege.

Notable fixes

  • 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 replicationFactor in Topic custom resources to support confluent.placement.constraints for the Topic.
  • 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.

Known issues

  • 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 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.2

CFK 2.0.1 does not support the following Confluent Platform 6.2 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.

Confluent for Kubernetes 2.0.0 Release Notes

New features

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.

Supported environments

  • 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.

Upgrade paths

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.

Known issues

  • 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 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.