Upgrade Confluent Platform Using Confluent for Kubernetes

A Confluent for Kubernetes deployment includes:

  • Confluent for Kubernetes (CFK) Operator

  • Confluent Platform component clusters

You can upgrade either CFK or Confluent Platform independently from each other.

When you are planning for an upgrade, review the following so that you can chart the appropriate upgrade path:

The following upgrade paths are supported:

To upgrade from Confluent Operator 1.x to Confluent for Kubernetes, see Migrate to Confluent for Kubernetes.

Upgrade considerations and troubleshooting

CFK and Confluent Platform compatibility support

Starting in CFK 2.9, your upgrades get simplified from the CFK-Confluent Platform compatibility standpoint as CFK supports all supported Confluent Platform versions.

For the CFK versions that are older than 2.9, when you upgrade both CFK and Confluent Platform, a CFK and Confluent Platform combination that is not listed in the support matrix will be still supported until you reach the final state where CFK and Confluent Platform are both upgraded to a supported combination.

For example, suppose you are upgrading CFK from 2.6.1 to 3.0.0 along with Confluent Platform from 7.3.1 to 8.0.0. In that case, the combination of CFK 3.0.0 and Confluent Platform 7.3.1 will be temporarily supported during the upgrade even though it is not a supported combination in the support matrix table.

Disable resource reconciliation

There are configuration changes in CFK 3.0.0, and the changes will cause the existing Confluent Platform clusters to roll during the CFK upgrade process.

Before upgrading CFK, you must disable resource reconciliation as described in Upgrade CFK.

ZooKeeper removal in Confluent Platform 8.0

ZooKeeper was removed in Confluent Platform 8.0 and is no longer supported with the 8.0 and later versions. Follow the steps in Migrate Confluent Platform from ZooKeeper to KRaft using Confluent for Kubernetes to migrate your ZooKeeper-based deployment to KRaft before you upgrade to Confluent Platform 8.0.

To upgrade a Zookeeper-based Confluent Platform deployment 7.6.x and earlier to the 8.0 release:

  1. Upgrade your Confluent Platform to 7.9.

    If you are on Confluent Platform 7.6.x or earlier, first, you need to upgrade your Confluent Platform to a version where production-level KRaft migration is supported, such as 7.9.

  2. Migrate the Zookeeper-based Confluent Platform to KRaft in 7.9.

  3. Upgrade the KRaft-based Confluent Platform to 8.0.

To upgrade a Zookeeper-based Confluent Platform deployment 7.7.x and later to the 8.0 release:

According to the Confluent Platform KRaft migration guide, it is recommended that you use Confluent Platform 7.7.0 or laster version for production migration. If you are using Confluent Platform 7.7.x or later, you can migrate the current version of Confluent Platform to KRaft, and then upgrade that KRaft-based Confluent Platform to 8.0.

  1. Migrate the Zookeeper-based Confluent Platform to KRaft in the current version.

  2. Upgrade the KRaft-based Confluent Platform to 8.0.

Upgrade Control Center

Migrate Confluent Control Center (Legacy) alerts to Control Center

Starting in the 8.0 release, Confluent Platform no longer supports Confluent Control Center (Legacy).

To use Control Center with Confluent Platform 8.0, you can migrate supported alerts from Confluent Control Center (Legacy) to Control Center as below:

  1. Upgrade the Confluent Platform to 7.9.1.

  2. Configure your Confluent Control Center (Legacy) and Control Center with the same Kafka bootstrap endpoint to point to the same Kafka cluster.

  3. Migrate the alerts to Control Center using the REST API as described in Control Center Alert Migration.

  4. Migrate your Confluent Platform deployment to 8.0 and Control Center to 2.2 as described in Upgrade KRaft-based Confluent Platform 8.0.0.

Upgrading Confluent Control Center (Legacy) to Control Center or upgrading Confluent Control Center (Legacy) metrics to Control Center are not supported.

Upgrade Control Center from 2.0 or 2.1 to 2.2 in Confluent Platform 8.0

Confluent Platform 8.0 does not work with Control Center 2.0 or 2.1. Only specific to when upgrading Confluent Platform to 8.0 and Control Center to 2.2, you must upgrade Control Center before upgrading Kafka.

Upgrade Log4j to Log4j 2

Upgrade Log4j to Log4j 2 in Confluent Platform 8.0

Starting in the 8.0 release, Confluent Platform only supports Log4j 2.

When upgrading from Confluent Platform 7.x to 8.x, your custom Log4j configurations are not automatically converted to Log4j 2 configurations. You need to explicitly define the properties for Log4j 2 as described in Configure Log4j 2.

In 3.x, by default, CFK sets up Log4j 2 with the default properties.

Enable Log4j if using CFK 3.0 to manage Confluent Platform 7.x

In 3.x, by default, CFK supports Log4j 2. When you upgrade your CFK 2.x to 3.x to deploy and manage Confluent Platform 7.x, set the annotation platform.confluent.io/use-log4j1=true as described in Upgrade CFK.

To upgrade from Confluent Platform 7.x to 8.x, remove the annotation or set it to false during Confluent Platform version upgrade.

Upgrade default auto-generated certificates to configurable auto-generated certificates

By default, Confluent for Kubernetes (CFK) uses auto-generated certificates without configuration options.

Starting in CFK 2.4.0, you can use configurable certificates that CFK generates with the options you specify.

To upgrade the certificates that were auto-generated in CFK 2.3.x or earlier to configurable auto-managed certificates in 2.4.x or later, follow the below steps. For details, see Use auto-generated TLS certificates.

  1. Set managedCerts.enabled: true and managedCerts.caCertificate.secretRef=<secretName> in the CFK Helm values file.

  2. Set the other configuration settings under managedCerts as described in Use auto-generated TLS certificates.

CFK will renew the certificates based on the CA certificates and the key present in managedCerts.caCertificate.secretRefs, and will roll the corresponding Confluent clusters.

Change of CA is not supported while moving from the legacy to the configurable certificates mode.

Upgrade Kafka clusters involved in Cluster Linking

When you upgrade the KRaft-based Kafka clusters you use in Cluster Linking, upgrade the brokers on the destination cluster first, and then upgrade the metadata version on the source cluster.

Connect pods restart when upgrading to CFK 2.9 and later

In CFK 2.9, a configuration property in the Connect stateful set template was updated, and the change causes the Connect cluster to roll when you upgrade CFK to 2.9 and later.

Under replicated partitions

Check for under-replicated partitions (URPs) on the existing cluster before upgrading the Confluent Platform cluster. If there is any URP on any broker, you need to fix the issue first before starting the Confluent Platform upgrade process.

To check for URPs, in Control Center (Legacy), navigate to Overview of the cluster, and observe the Under replicated partitions value.

Issue: Disabled JMX reporter when using telemetry reporter in Confluent Platform 8.0.0

In Confluent Platform 8.0.0, when using Control Center or other telemetry reporters, the JMX reporter is disabled. When upgrading to Confluent Platform 8.0.0 with the JMX reporter disabled, CFK cannot use the JMX reporter metric to validate the health of the Kafka and KRaft clusters and causes the upgrade to halt.

Workaround: Add org.apache.kafka.common.metrics.JmxReporter to the metric.reporters configuration. For example, if you previously set metric.reporters=io.confluent.telemetry.reporter.TelemetryReporter to use Control Center, you should now set:

kind: Kafka
spec:
  configOverrides:
    server:
      - metric.reporters=io.confluent.telemetry.reporter.TelemetryReporter, org.apache.kafka.common.metrics.JmxReporter

kind: KRaftController
spec:
  configOverrides:
    server:
      - metric.reporters=io.confluent.telemetry.reporter.TelemetryReporter, org.apache.kafka.common.metrics.JmxReporter