Upgrade Confluent Operator and Confluent Platform¶

Before you start the upgrade process, make sure your Kubernetes cluster is among the Supported Environments for the target version of Confluent Operator.

The examples in this guide use the following assumptions:

$VALUES_FILE refers to the configuration file you set up in Create the global configuration file.
To present simple and clear examples in the Operator documentation, all the configuration parameters are specified in the config file ($VALUES_FILE). However, in your production deployments, use the --set or --set-file option when applying sensitive data with Helm. For example:
```
helm upgrade --install kafka \
 --set kafka.services.mds.ldap.authentication.simple.principal="cn=mds\,dc=test\,dc=com" \
 --set kafka.services.mds.ldap.authentication.simple.credentials=”Developer!” \
 --set kafka.enabled=true
```
operator is the namespace that Confluent Platform is deployed in.
All commands are executed in the helm directory under the directory Confluent Operator was downloaded to.

Currently, Confluent Operator does not support the direct upgrade from Confluent Platform 5.3.x to 6.0.x or from 5.4.x to 6.0.x. If you are upgrading to 6.0.x, perform a rolling upgrade as following:

Upgrade Confluent Platform from 5.3.x to 5.4.x, specifically running the pre_upgrade_cp54_zookeeper.sh script before upgrading.
Upgrade Confluent Platform from 5.4.x to 5.5.x.
Upgrade Confluent Platform from 5.5.x to 6.0.x as described in the following sections.

Upgrade Confluent Platform version 5.5.x to 6.0.x¶

Important

Upgrading Confluent Platform to 6.0.x with Operator 1.6.2 will roll the cluster as resources configuration was introduced in the init container of Operator 1.6.2.

Download Confluent Operator 1.6.2¶

As the first step in the migration and upgrade process, Download and extract the Operator bundle.

Prepare for upgrade¶

In general, it is best to minimize the number of changes occurring at the same time. For the purposes of upgrading from Confluent Platform 5.5.x to 6.0.x, we recommend that you perform this upgrade separate from making other changes to your clusters, such as scaling up, changing configuration, or rotating credentials.

Review the following upgrade considerations carefully as they include required actions you must perform before upgrading to Confluent Platform 6.0.x. When you make the required pre-upgrade changes, those changes are applied when you upgrade with the helm upgrade as described in the following sections.

Prepare for upgrading RBAC-enabled Confluent Platform¶

If you have RBAC enabled in Confluent Platform 5.5, you must:
1. Add a user in your LDAP service for Confluent REST API.
2. Update the kafka.services.restProxy.authentication section in the configuration file ($VALUES_FILE) to use the above credentials as described in Configure Kafka for RBAC.
If you have RBAC enabled and have deployed Schema Registry, you must grant the Schema Registry component principal the ResourceOwner role on the _confluent-license topic as described in Configure Schema Registry for RBAC.

Prepare for upgrading connectors¶

Connectors are no longer packaged with the Connect images in Confluent Platform 1.6.2. You must redeploy those connectors by adding them to the Connect image, cp-server-connect-operator, before completing the upgrade of Connect workers. For more information on extending a Docker image, see Build the Confluent Platform images.

Create a Dockerfile in <dockerfile-dir> to add one or more connectors to the cp-server-connect-operator image.

You can either:

Pull connectors from Confluent Hub.
Use a connector JAR downloaded to the machine you are running the Docker build from.

To pull connectors from Confluent Hub, create a Dockerfile as follows:

FROM confluentinc/cp-server-connect-operator:6.0.0.0
USER root
RUN confluent-hub install --no-prompt <connector1>:<connector1-version> \
  && confluent-hub install --no-prompt <connector2>:<connector2-version> \
  && ...
USER 1001

An example Dockerfile to create a Docker image with the data-gen connector from Confluent Hub:

FROM confluentinc/cp-server-connect-operator:6.0.0.0
USER root
RUN  confluent-hub install --no-prompt confluentinc/kafka-connect-datagen:0.3.3
USER 1001

To use connector JAR files that are on your machine that you are running the Docker build from, create a Dockerfile as follows:

FROM confluentinc/cp-server-connect-operator:6.0.0.0
ADD <local-connector1-path> /usr/share/java/<connector1> \
  && <local-connector2-path> /usr/share/java/<connector2> \
  && ...
USER 1001

An example Dockerfile to use the data-gen connector existing on your local machine in the <connector-dir> directory:

FROM confluentinc/cp-server-connect-operator:6.0.0.0
ADD​ my-connector-dir/confluentinc-kafka-connect-datagen /usr/share/java/confluentinc-kafka-connect-datagen
USER 1001

Build and push the image with the following commands;

docker build <dockerfile-dir> -t <someregistry>/<somerepo>:<sometag>

docker push <someregistry>/<somerepo>:<sometag>

Get the Docker image details from the output of the above process and specify the repository and tag in the Connect section of the configuration file ($VALUES_FILE):
```
connect:
  image:
    repository: <someregistry>/<somerepository>
    tag: <image-tag>
```

Upgrade Confluent Operator¶

Change the working directory to the Confluent Operator 1.6.2 root directory.
Update the Confluent Platform CustomResourceDefinitions (CRDs).

Confluent Operator can manage the installation and update of the Confluent Platform CRDs on your behalf. You can opt out of this with either of the below options:
- Directly by specifying operator.installClusterResources: false in the configuration file ($VALUES_FILE)
- Indirectly by deploying Operator in the namespaced mode with operator.namespaced: true in the configuration file ($VALUES_FILE)
If you have opted out of Operator-managed CRDs and instead manage the Confluent Platform CRDs separately, you must update the CRDs by running the following command from the root of the Operator directory:
```
kubectl apply -f ./resources/crds/
```

Run the disable_reconcile.sh script for each namespace where you have deployed Confluent Platform components.

If you do not disable the reconcile operations before you run the upgrade, components will begin rolling restarts and some pods may go into CrashLoopBackOff status.

The script disables reconcile operations so that Confluent Platform components do not restart. Only Operator restarts during this upgrade.

./scripts/upgrade/disable_reconcile.sh <namespace>

Your output should resemble the following:

./scripts/upgrade/disable_reconcile.sh <namespace>

physicalstatefulcluster.operator.confluent.cloud/connectors annotated
physicalstatefulcluster.operator.confluent.cloud/controlcenter annotated
physicalstatefulcluster.operator.confluent.cloud/kafka annotated
physicalstatefulcluster.operator.confluent.cloud/ksql annotated
physicalstatefulcluster.operator.confluent.cloud/replicator annotated
physicalstatefulcluster.operator.confluent.cloud/schemaregistry annotated
physicalstatefulcluster.operator.confluent.cloud/zookeeper annotated

Retrieve the Operator Helm release name, <operator-helm-release-name>, by running the following command:

helm ls

<operator-helm-release-name> is the NAME displayed in the output.

NAME        REVISION    UPDATED              STATUS   CHART                APP VERSION    NAMESPACE
operator    2           Mon Jan 6            DEPLOYED confluent-operator   1.0            operator

Upgrade Operator by running the following command from the helm directory under the Confluent Operator 1.6.2 directory:

helm upgrade --install <operator-helm-release-name> \
  ./confluent-operator \
  --values $VALUES_FILE \
  --set operator.enabled=true \
  --namespace <namespace> \
  --wait

Upgrade ZooKeeper, Kafka, and other Confluent Platform components¶

Complete the following steps for ZooKeeper, Kafka, and other components, specifically Schema Registry, Connect, Replicator, and Confluent Control Center.

Run the helm upgrade commands from the helm directory under the Confluent Operator 1.6.2 directory.

Note

Each cluster will roll during this procedure.

For each Confluent Platform component cluster, update the desired configuration and version of the cluster:

helm upgrade --install <component-helm-release-name> \
   ./confluent-operator \
   --values $VALUES_FILE \
   --set <component>.enabled=true \
   --namespace <namespace> \
   --wait

Get <component-name> from the configuration file ($VALUES_FILE):
```
<component>:
  name: # This value
```
For each Confluent Platform component cluster, enable reconciliation, using <component-name> from the previous step, so that Operator applies the desired configuration and updates the cluster:
```
./scripts/upgrade/enable_reconcile.sh <namespace> <component-name>
```
For example:
```
./scripts/upgrade/enable_reconcile.sh operator kafka
```

Update a single component image¶

You can update a single Confluent Platform component image version without affecting cluster performance.

Special care is taken when upgrading Kafka brokers. The upgrade process verifies topic leader re-election and zero under-replicated partitions before beginning the upgrade process for the next Kafka broker. This ensures that the Kafka cluster continues to perform well while being upgraded.

In the IMAGES file that comes with the Operator bundle, locate the Confluent Platform component that you want to update, and take the image tag, <new-tag>.
In your config file ($VALUES_FILE), add or update the following section:
```
<component>:
  image:
    tag: <new-tag>
```
Run the following command, replacing <component-helm-release-name> with the Helm release name of the component:
```
helm upgrade --install <component-helm-release-name> \
 --values $VALUES_FILE \
 --set <component>.enabled=true \
 --set <component>.image.tag=<new-tag> \
 ./confluent-operator \
 --namespace <namespace>
```
A component rolling upgrade begins after you run the above helm upgrade command unless you have disabled reconciliation. (See the workflow above on upgrading to 1.6.2 for an example where you might disable reconciliation).