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

Confluent for Kubernetes 2.4.4 Release Notes

Confluent for Kubernetes (CFK) 2.4.4 allows you to deploy and manage Confluent Platform versions 6.2.x, 7.1.x, and 7.2.x on Kubernetes.

Notable fixes

  • Fixed security and vulnerability issues.

Confluent for Kubernetes 2.4.3 Release Notes

Confluent for Kubernetes (CFK) 2.4.3 allows you to deploy and manage Confluent Platform versions 6.2.x, 7.1.x, and 7.2.x on Kubernetes.

Notable fixes

  • Fixed the issue with the Kafka CR where the status.phase is sometimes stuck in PROVISIONING even after all replicas have successfully rolled and have come up cleanly.
  • Fixed security and vulnerability issues.

Confluent for Kubernetes 2.4.2 Release Notes

Confluent for Kubernetes (CFK) 2.4.2 allows you to deploy and manage Confluent Platform versions 6.2.x, 7.1.x, and 7.2.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.
  • Kafka Pod Delete Webhook now also works with the Node Eviction actions on top of Pod Delete actions.
  • Fixed security and vulnerability issues.

Notable enhancements and updates

  • CFK provides Linux ARM64 architecture Docker images for use in non-production environments. ARM64 is for preview-support only.

Confluent for Kubernetes 2.4.1 Release Notes

Confluent for Kubernetes (CFK) 2.4.1 allows you to deploy and manage Confluent Platform versions 7.1.x and 7.2.x on Kubernetes.

Notable fixes

  • Removed expiring license check when the license is within 7 days of expiring.
  • Allow passwords containing equal signs.
  • Support Connect and ksqlDB to authentication Control Center using basic authentication.
  • Fixed security and vulnerability issues.

Confluent for Kubernetes 2.4.0 Release Notes

Confluent for Kubernetes (CFK) 2.4.0 allows you to deploy and manage Confluent Platform versions 7.1.x and 7.2.x on Kubernetes.

New features

Auto-rotation of auto-generated certificates at a configurable period of days

To provide a fully encrypted streaming platform, CFK automates provisioning, securing, and operating certificates for internal networking communications.

Now CFK automates the rotation of auto-generated certificates at a period that you specify at the Helm level.

See Auto-generated TLS certificates.

Protection against unintended Kafka pod deletion through admission controller

Support for Kubernetes Admission Controller is now in GA.

You can configure CFK to reject object deletion requests, specifically for clusters and Kafka pods.

See Deploy CFK with cluster object deletion protection.

Source-initiated cluster links

To bolster Confluent cluster linking that CFK declaratively supports, now you can create and use source-initiated cluster links. It enables Confluent Platform deployed on private infrastructure to create a link and initiate a connection to Confluent Cloud to replicate topic data.

You use this type of cluster links when it is not possible to open up your private infra firewall to let Confluent Cloud connect directly to your Confluent Platform brokers to use the default type of cluster linking.

See Cluster Linking using Confluent for Kubernetes.

Notable enhancements and updates

Notable fixes

  • Fixed an edge case where deletion of application custom resources failed with the namespace list and watch error.
  • Fixed an issue where incomplete scaling down of all clusters deployed on non-OpenShift environments was incomplete.
  • Fixed an issue where provision workflow of Schema Registry and Confluent Control Center cluster were incomplete because certain reconcile errors were not retried.
  • Fixed Kafka custom resource to reflect the correct status after a force reconciliation.
  • Fixed an issue where non-namespaced CFK deployment missed the watch permission on namespaces.

Known issues in CFK 2.4

  • 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 or 4.10. You cannot use OpenShift 4.6 - 4.8.

    This OpenShift version restriction does not apply when deploying CFK to Red Hat OpenShift in the standard way without using the Red Hat Operator Lifecycle Manager.

  • If the 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 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. It 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.

  • When you deploy Confluent Platform 7.1.0 with centralized RBAC, you might see an “Invalid License” issue when connecting to the secondary Kafka cluster.

    The workaround is to restart the secondary Kafka cluster.

  • REST Proxy configured with monitoring interceptors is missing the callback handler properties when RBAC is enabled. Interceptor would not work, and you would see an error message in the KafkaRestProxy log.

    As a workaround, manually add configuration overrides as shown in the following KafkaRestProxy CR:

    configOverrides:
  server:
    - confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
    - consumer.confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
    - producer.confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler

  • When configuring source initiated cluster links with CFK where the source cluster has TLS enabled, do not set spec.tls, and do not set spec.authentication if the source cluster has mTLS authentication.

    Instead, in the ClusterLink CR, under the spec.configs section, set local.security.protocol: SSL for mTLS.

    Set local.security.protocol: SASL_SSL for SASL authentication with TLS.

Known gaps from Confluent Platform 7.2

CFK 2.4 does not support the following Confluent Platform 7.2 functionality:

  • Kafka authentication mechanisms: Kerberos and SASL/Scram