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.1.x releases.

Confluent for Kubernetes 2.1.3 Release Notes

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

Notable fixes

  • Removed expiring license check when the license is within 7 days of expiring.

  • Corrected Java heap min and max size to use pod template memory request and instead of the limit.

  • Allow passwords containing equal signs.

  • Fixed security and vulnerability issues.

Confluent for Kubernetes 2.1.2 Release Notes

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

Notable enhancements

  • Capability to add labels to the LoadBalancer, Nodeport, and Route services.

Notable fixes

  • Fixed CFK migration to not set global Telemetry if it was not set before migration.

  • Fixed security and vulnerability issues.

Known issues

  • When deploying Confluent for Kubernetes to Red Hat OpenShift with Red Hat’s Operator Lifecycle Manager (that is, 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 that does not use the Red Hat Operator Lifecycle Manager.

  • 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 (Legacy) uses a different TLS certificate to communicate with MDS or Confluent Cloud Schema Registry, Control Center (Legacy) 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.1 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.1.1 Release Notes

Confluent for Kubernetes 2.1.1 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 (Legacy) migration fails with a nil pointer reference when Schema Registry dependency is not enabled.

  • Removed the redundant configuration in Confluent Control Center (Legacy) server properties when any Connect, ksqlDB, or Schema Registry dependency is configured with mTLS authentication.

  • The issue with KafkaTopic custom resources was fixed where the CFK failed to create topics when Kafka ACL was enabled.

  • Fixed security and vulnerability issues.

Known issues

  • When deploying Confluent for Kubernetes to Red Hat OpenShift with Red Hat’s Operator Lifecycle Manager (that is, 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 that does not use the Red Hat Operator Lifecycle Manager.

  • 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 (Legacy) uses a different TLS certificate to communicate with MDS or Confluent Cloud Schema Registry, Control Center (Legacy) 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.1 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.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 manage Standalone Confluent REST Proxy with the REST Proxy custom resource definition (CRD).

Manage data plane resources

  • Declaratively manage Schemas with the Schema CRD.

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

  • Kubernetes API version was upgraded from apiextensions.k8s.io/v1beta1 to apiextensions.k8s.io/v1 for the CFK CRDs.

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 (Legacy) 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

  • When deploying Confluent for Kubernetes to Red Hat OpenShift with Red Hat’s Operator Lifecycle Manager (that is, 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 that does not use the Red Hat Operator Lifecycle Manager.

  • 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 (Legacy) uses a different TLS certificate to communicate with MDS or Confluent Cloud Schema Registry, Control Center (Legacy) 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