Confluent for Kubernetes Release Notes

Confluent for Kubernetes 2.0.1 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.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

  • Fixed issue in 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.
  • Fixed issue in Topic creation - A Topic custom resource can contain multiple configurations for the Topic.
  • Fixed issue in Topic creation - You can specify the optional replicationFactor in Topic custom resources to support confluent.placement.constraints for the Topic.
  • Fixed issue in 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.

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 supports deploying Confluent Platform 6.0 and 6.1.
  • CFK 2.0 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.

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