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

Confluent for Kubernetes 2.2.4 Release Notes

Confluent for Kubernetes 2.2.4 allows you to deploy and manage Confluent Platform versions 6.2.x and 7.0.x on Kubernetes.

Notable fixes

  • Fixed where ClusterLink mirror topics were prematurely reported as being stuck in the PENDING_STOPPED state. Now those topics can transition into a terminal state.
  • Fixed security and vulnerability issues.

Confluent for Kubernetes 2.2.3 Release Notes

Confluent for Kubernetes 2.2.3 allows you to deploy and manage Confluent Platform versions 6.2.x and 7.0.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.2.2 Release Notes

Confluent for Kubernetes 2.2.2 allows you to deploy and manage Confluent Platform versions 6.2.x and 7.0.x on Kubernetes.

Notable enhancements

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

Notable fixes

  • Connector plugin installation correctly fails if the archive path has the wrong suffix.
  • Fixed CFK migration to not set global Telemetry if it was not set before migration.
  • Fixed a redundant space in spec.mirrorTopics.configs in the ClusterLink CRD that caused a validation error when creating a ClusterLink CR.
  • Fixed security and vulnerability issues.

Confluent for Kubernetes 2.2.1 Release Notes

Confluent for Kubernetes 2.2.1 allows you to deploy and manage Confluent Platform versions 6.2.x and 7.0.x on Kubernetes.

Notable fixes

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

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