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.4 Release Notes

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

Notable fixes

  • CFK now correctly sets the external traffic policy to cluster on the bootstrap load balancer and to local on the broker load balancers.
  • CFK does not auto delete KafkaTopics custom resources created in a different namespace from where the referenced KafkaClusterRef is.
  • Fixed the issue where Confluent Control Center migration fails with a nil pointer reference when Schema Registry dependency is not enabled.
  • Removed the redundant configuration in Confluent Control Center server properties when any Connect, ksqlDB, or Schema Registry dependency is configured with mTLS authentication.
  • Security and vulnerability fixes.

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

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