Confluent for Kubernetes 2.0.0 Release Notes¶
Confluent for Kubernetes 2.0.0 provides a declarative API driven control plane to deploy and manage Confluent Platform on Kubernetes.
The following sections summarize the technical details of the release.
- 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.
- 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.
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.
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.pemthat 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.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.