Confluent Platform Upgrade Checklist

Upgrading to Confluent Platform 7.0+ enables you to leverage the latest innovative features that bring a powerful cloud-native experience to your event streaming platform. Here are some of the exciting new features that enhance your event streaming use cases with greater elasticity, improved cost-effectiveness, increased reliability, and global availability:

  • KRaft preview: Kafka 3.0 with a preview of KRaft
  • Cluster Linking: Now generally available. Deploy hybrid cloud and multi-cloud architectures with applications that span multiple environments by bridging independent clusters to one another with fully offset-preserving replication.
  • Support for Ansible collections and Ansible Galaxy
  • Support for Debian 10 and Ubuntu 20 installations
  • Schema Registry: Schemas linking (preview)
  • ksqlDB: foreign-key table-table joins and pull queries over streams

The following checklist provides a quick guide for how to upgrade to the latest version. For detailed guidance, see Upgrade Confluent Platform.

Step 0: Prepare for the upgrade

Here’s what you need to get started:

  • An existing Confluent Platform deployment. If you’re starting with a new deployment, follow the steps in On-Premises Deployments.
  • An upgrade plan that matches your specific requirements and environment. You should not start working through this checklist on a live cluster. Review the Upgrade Guide fully and draft an upgrade plan.

Important

If you’re running a Confluent Platform version that’s lower than 5.3.1, upgrade to 5.3.1 before upgrading to 6.1.x and higher.

Step 1: Upgrade ZooKeeper

  • Back up all configuration files before upgrading.
  • Back up ZooKeeper data from the leader. In case of an upgrade failure, this backup gets you back to the latest committed state.

For more information, see Upgrade ZooKeeper.

Note

KIP-500: Kafka Raft (KRaft) replaces ZooKeeper, but KRaft is in early access and should be used in development only. It is not suitable for production. For more information, see Kafka Raft (KRaft) in Confluent Platform Preview.

Step 2: Upgrade Kafka brokers

You have these options for upgrading your Kafka brokers:

  • Downtime upgrade: If downtime is acceptable for your business case, you can take down the entire cluster, upgrade each Kafka broker individually, and restart the cluster.
  • Rolling upgrade: In a rolling upgrade scenario, you upgrade one Kafka broker at a time while the cluster continues to run. To avoid downtime for end users, follow the recommendations in rolling restarts.

For more information, see Upgrade Kafka brokers.

Step 3: Upgrade Confluent Platform components

In this step, you will upgrade the Confluent Platform components. For a rolling upgrade, you can do this on one server at a time while the cluster continues to run. The details depend on your environment, but the steps are the same.

  1. Stop the Confluent Platform components.
  2. Back up configuration files, for example in ./etc/kafka.
  3. Remove existing packages and their dependencies.
  4. Install new packages.
  5. Restart the Confluent Platform components.

You should upgrade Confluent Control Center as the final Confluent Platform component.

For more information, see:

Upgrade steps for individual Confluent Platform components:

Step 4: Update configuration files

Some configuration settings change from one version to the next. The following sections describe changes that are required for specific versions.

Confluent license

When you upgrade to Confluent Platform 5.4.x and later, add the confluent.license configuration parameter to the server.properties file. Confluent Platform 5.4.x and later requires the confluent.license setting to start. For more information, see Confluent Platform Licenses.

Security

When you upgrade to Confluent Platform 5.4.x and later, update the authorizer class in the server.properties file.

Starting with Confluent Platform 5.4.x, the new authorizer class, kafka.security.authorizer.AclAuthorizer, replaces kafka.security.auth.SimpleAclAuthorizer. In the server.properties file, change existing instances of kafka.security.auth.SimpleAclAuthorizer to kafka.security.authorizer.AclAuthorizer. For more information, see ACL concepts.

Replication factor for Self-Balancing Clusters

In Confluent Platform 6.0.0, the confluent.balancer.topic.replication.factor setting was added for Self-Balancing configuration. Ensure that its value is less than or equal to the total number of brokers.

For more information, see confluent.balancer.topic.replication.factor.

Step 5: Enable Health+

Health+ enables you to identify issues before downtime occurs, ensuring high availability for your event streaming applications.

  • Enable Telemetry – The Confluent Telemetry Reporter is a plugin that runs inside each Confluent Platform service to push metadata about the service to Confluent. Telemetry Reporter enables product features based on the metadata, like Health+. Telemetry is limited to metadata required to provide Health+ (for example, no topic data) and is used solely to assist Confluent in the provisioning of support services.
  • Enable Health+ – After you enable Telemetry Reporter, you can activate Health+, which provides ongoing, real-time analysis of performance and configuration data for your Confluent Platform deployment.

Note

While enabling Telemetry and Health+ is highly encouraged and beneficial to minimize downtime, it is not mandatory in order to upgrade to Confluent Platform 6.0+. Speak with your Confluent account team if you have any questions about the features.

Step 6: Rebuild applications

If you have applications that use Kafka producers and consumers against the new 7.0.x libraries, rebuild and redeploy them. For more information, see Application Development.

You can upgrade Kafka Streams applications independently, without requiring Kafka brokers to be upgraded first. Follow the instructions in the Kafka Streams Upgrade Guide to upgrade your applications to use the latest version of Kafka Streams.

For more information, see Upgrade other client applications.