// This assembly is included in the following assemblies:
//
// assembly-upgrade.adoc

[id='assembly-upgrade-cluster-operator-{context}']
= Upgrading the Cluster Operator

[role="_abstract"]
Use the same method to upgrade the Cluster Operator as the initial method of deployment.

include::../../modules/upgrading/proc-upgrade-cluster-operator.adoc[leveloffset=+1]

== Upgrading the Cluster Operator using the OperatorHub

If you deployed Strimzi from {OperatorHub}, use the Operator Lifecycle Manager (OLM) to change the update channel for the Strimzi operators to a new Strimzi version.

Updating the channel starts one of the following types of upgrade, depending on your chosen upgrade strategy:

* An automatic upgrade is initiated
* A manual upgrade that requires approval before installation begins

NOTE: If you subscribe to the _stable_ channel, you can get automatic updates without changing channels.
However, enabling automatic updates is not recommended because of the potential for missing any pre-installation upgrade steps.
Use automatic upgrades only on version-specific channels.

For more information on using OperatorHub to upgrade Operators, see the {OLMOperatorDocs}.

== Upgrading the Cluster Operator using a Helm chart

If you deployed the Cluster Operator using a Helm chart, use `helm upgrade`.

The `helm upgrade` command does not upgrade the {HelmCustomResourceDefinitions}.
Install the new CRDs manually after upgrading the Cluster Operator.
You can access the CRDs from the {ReleaseDownload} or find them in the `crd` subdirectory inside the Helm Chart.

[id='con-upgrade-cluster-operator-unsupported-kafka-{context}']
== Upgrading the Cluster Operator returns Kafka version error

If you upgrade the Cluster Operator to a version that does not support the current version of Kafka you are using, you get an _unsupported Kafka version_ error.
This error applies to all installation methods and means that you must upgrade Kafka to a supported Kafka version.
Change the `spec.kafka.version` in the `Kafka` resource to the supported version.

You can use `kubectl` to check for error messages like this in the `status` of the `Kafka` resource.

.Checking the Kafka status for errors
[source,shell, subs=+quotes]
----
kubectl get kafka <kafka_cluster_name> -n <namespace> -o jsonpath='{.status.conditions}'
----

Replace <kafka_cluster_name> with the name of your Kafka cluster and <namespace> with the Kubernetes namespace where the pod is running.

== Upgrading from a Strimzi version using the Bidirectional Topic Operator
When deploying the Topic Operator to manage topics, the Cluster Operator enables unidirectional topic management.
This means that the Topic Operator only manages Kafka topics associated with `KafkaTopic` resources and does not interfere with topics managed independently within the Kafka cluster.

Previously, the Topic Operator worked in bidirectional mode, which meant it could also perform operations on topics within the Kafka cluster.
If you are switching from a version of Strimzi that uses the Bidirectional Topic Operator, after upgrading the Cluster Operator, perform some cleanup tasks on the following internal topics that were used by the operator: 

* `strimzi-store-topic`
* `strimzi-topic-operator`
* `consumer-offsets`
* `transaction-state`

For the `strimzi-store-topic` and `strimzi-topic-operator` topics, delete the resources that were used to manage them:

.Deleting internal topics used by the operator
[source,shell,subs=+quotes]
----
kubectl delete $(kubectl get kt -n <namespace> -o name | grep strimzi-store-topic) -n <namespace> \
  && kubectl delete $(kubectl get kt -n <namespace> -o name | grep strimzi-topic-operator) -n <namespace>
----

For the internal topics for storing consumer offsets and transaction states, `consumer-offsets` and `transaction-state`, you want to retain them in Kafka, but you don't want them to be managed by the Topic Operator.

Discontinue their management before deleting their resources.
Annotating the `KafkaTopic` resources with `strimzi.io/managed="false"` indicates that the Topic Operator should no longer manage those topics: 

.Discontinuing management of internal topics
[source,shell,subs=+quotes]
----
kubectl annotate $(kubectl get kt -n <namespace> -o name | grep consumer-offsets) strimzi.io/managed="false" -n <namespace> \
  && kubectl annotate $(kubectl get kt -n <namespace> -o name | grep transaction-state) strimzi.io/managed="false" -n <namespace>
----

Check the statuses of the `KafkaTopic` resources to make sure the reconciliation was successful and the topics are no longer managed, as shown in the   xref:proc-converting-managed-topics-str[procedure to stop managing topics]. 

Having discontinued their management, delete the `KafkaTopic` resources:

.Deleting the resources for managing internal topics
[source,shell,subs=+quotes]
----
kubectl delete $(kubectl get kt -n <namespace> -o name | grep consumer-offsets) -n <namespace> \
  && kubectl delete $(kubectl get kt -n <namespace> -o name | grep transaction-state) -n <namespace>
----

By discontinuing their management, they won't also be deleted in Kafka.
