Upgrading CSM Operator

Complete these steps to upgrade CSM Operator. Upgrading CSM Operator involves upgrading both Strimzi and Kafka in your cluster.

Upgrading Strimzi consists of upgrading the Strimzi CRDs to the new version and upgrading the cluster operator using Helm commands. If you are upgrading from a maintenance version, you also need to temporarily set the image of the Kafka cluster to the maintenance version in your Kafka resources. This is necessary because without the explicit image, the Strimzi upgrade will automatically update the image used by the Kafka cluster, which might not contain all bug fixes provided in the maintenance version.

Upgrading the cluster operator may affect the Kafka resources in the cluster. All Kafka clusters that specify the version of the cluster but not the image will be restarted during the cluster operator upgrade. This is due to the fact that the default image of all versions changes with the Strimzi upgrade, triggering a restart. This restart is safe, that is, all healthy topics with a proper replication factor and minimum ISR are kept online during the restart.

Upgrading Kafka involves updating your Kafka resources for each cluster to the latest supported version after a Strimzi upgrade. Upgrading Kafka is:

Strongly recommended by Cloudera after every Strimzi upgrade.
Mandatory if you are upgrading from a maintenance version.

This procedure upgrades your Kafka cluster in a rolling upgrade. The upgrade is safe, all healthy topics with a proper replication factor and minimum ISR are kept online during the upgrade.

Ensure that your Kubernetes environment meets requirements listed in System requirements.
Ensure that you have access to your Cloudera credentials (username and password). Credentials are required to access the Cloudera Archive and Cloudera Docker registry where upgrade artifacts are hosted.
If you are upgrading from a maintenance version, check that the bug fixes provided in the maintenance version are available in the newer Kafka supported by CSM Operator. If certain fixes are not available, be aware that upgrading will result in regressed functionality.
The following steps instruct you to set inter.broker.protocol.version during the upgrade to keep Kafka in backward compatible state during the upgrade. This is only necessary if the protocol version differs between your current and new versions.
If there is no change in the protocol version, you also do not finalize the upgrade. This means that for these types of upgrades, a rollback is possible even after you completed the upgrade.
You can find the Kafka protocol version in Component versions.

Update the Strimzi CRDs.
You do this by replacing the currently installed CRDs with the new version. The CRDs are published as a single YAML on the Cloudera Archive in /p/csm-operator/1.1/install.
```
curl -s --user [***USERNAME***] \
  https://archive.cloudera.com/p/csm-operator/1.1.0/install/strimzi-crds-0.41.0.1.1.0-b79.yaml \
| kubectl replace --filename -
```
Enter your Cloudera password when prompted.
If you are upgrading from a maintenance version, explicitly set the image of the Kafka cluster to the maintenance version in your Kafka resources.
These steps ensure that the Kafka clusters keep the exact maintenance image during the Strimzi upgrade. This is a temporary setup, and you need to change it after the Strimzi upgrade. Repeat these steps for each Kafka cluster.
1. Extract the currently used Zookeeper image.
```
kubectl get pod --namespace [***KAFKA CLUSTER NAMESPACE***] \
  --selector strimzi.io/component-type=zookeeper,strimzi.io/cluster=[***KAFKA CLUSTER NAME***] \
  --output=jsonpath="{@['items'][0].spec.containers[0].image}{'\n'}"
```
2. Extract the currently used Kafka image.
```
kubectl get pod --namespace [***KAFKA CLUSTER NAMESPACE***] \
  --selector strimzi.io/component-type=kafka,strimzi.io/cluster=[***KAFKA CLUSTER NAME***] \
  --output=jsonpath="{@['items'][0].spec.containers[0].image}{'\n'}"
```
3. Update the spec.zookeeper.image and the spec.kafka.image properties in the Kafka resource.
```
kubectl edit kafka [***KAFKA CLUSTER NAME***] \
  --namespace [***KAFKA CLUSTER NAMESPACE***]
```
Log in to the Cloudera Docker registry with helm.
```
helm registry login container.repository.cloudera.com
```
Enter your Cloudera credentials when prompted.
Upgrade Strimzi using Helm.
This step upgrades the Strimzi Cluster Operator. Under the hood, the Strimzi Cluster Operator deployment is updated by changing the image used by the Strimzi Cluster Operator.
```
helm upgrade strimzi-cluster-operator \
  --namespace [***STRIMZI CLUSTER OPERATOR NAMESPACE***] \
  --atomic \
  oci://container.repository.cloudera.com/cloudera-helm/csm-operator/strimzi-kafka-operator \
--version 1.1.0-b79
```
- The string strimzi-cluster-operator is the Helm release name of the chart installation. This is an arbitrary, user-defined name. Replace this string if you used a different name when you installed Strimzi.
- The --atomic option makes the command wait for the upgrade to complete or roll back if the upgrade fails.
note
Usually, you do not need to set new Helm chart properties during upgrade, the properties that you configured during installation are preserved. However, If you set even a single property using the --set options in your helm upgrade command, properties set previously might be ignored. If you decide to set properties during the upgrade, ensure that you do one of the following.
- Set all your properties (including the ones that were set during installation) during upgrade. This ensures that all required properties are set explicitly.
- Set the properties you want to update and use the --reset-then-reuse-values option. Using this option preservers previously set properties. This option is only available in the more recent versions of Helm.

Double check that the Strimzi Cluster operator is in a healthy state.

kubectl get deployments strimzi-cluster-operator \
  --namespace [***STRIMZI CLUSTER OPERATOR NAMESPACE***]

If the upgraded pods crash, check their logs.

If needed, roll back this procedure with helm rollback.

helm rollback strimzi-cluster-operator \
  --namespace [***STRIMZI CLUSTER OPERATOR NAMESPACE***]

Upgrade Kafka.
This is done by updating your Kafka resources for each cluster.
```
kubectl edit kafka [***KAFKA CLUSTER NAME***] \
  --namespace [***KAFKA NAMESPACE***]
```
1. Set the .spec.kafka.version to the latest version.
2. For maintenance versions: Remove the spec.zookeeper.image and spec.kafka.image properties.
3. Add the old inter.broker.protocol.version in spec.kafka.config, for example:
```
#...
kind: Kafka
spec:
  kafka:
    version: 3.7.0.1.1
    config:
      inter.broker.protocol.version: “3.7”
```
  Specifying inter.broker.protocol.version keeps Kafka in a backward-compatible state following the upgrade.
4. Save the changes made to the Kafka resource.

Wait for the cluster pods to become ready.

kubectl get pod --namespace [***KAFKA NAMESPACE***] \
  --selector strimzi.io/cluster=[***KAFKA CLUSTER NAME***] \
  --watch

If the upgraded pods crash, check their logs.
If needed, roll back this procedure by editing the Kafka resource.
1. Set the spec.kafka.version to the previous version.
2. If you are upgrading from a maintenance version, set the spec.kafka.image property to the previous image.
3. Remove the inter.broker.protocol.version property from spec.kafka.config.
4. Save the changes made to the Kafka resource.
Verify that the Kafka upgrade is successful and everything is working fine.
Finalize the Kafka upgrade by removing the old inter.broker.protocol.version.
After this step, rollback is no longer possible.