29.5. Upgrading the Cluster Operator


Use the same method to upgrade the Cluster Operator as the initial method of deployment.

This procedure describes how to upgrade a Cluster Operator deployment to use Streams for Apache Kafka 2.8.

Follow this procedure if you deployed the Cluster Operator using the installation YAML files in the install/cluster-operator/ directory. The steps include the necessary configuration changes when the Cluster Operator watches multiple or all namespaces.

The availability of Kafka clusters managed by the Cluster Operator is not affected by the upgrade operation.

注意

Refer to the documentation supporting a specific version of Streams for Apache Kafka for information on how to upgrade to that version.

Prerequisites

Procedure

  1. Take note of any configuration changes made during the previous Cluster Operator installation.

    Any changes will be overwritten by the new version of the Cluster Operator.

  2. Update your custom resources to reflect the supported configuration options available for Streams for Apache Kafka version 2.8.
  3. Modify the installation files for the new Cluster Operator version to reflect the namespace in which the Cluster Operator is running.

    On Linux, use:

    sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

    On MacOS, use:

    sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml
  4. If you modified environment variables in the Deployment configuration, edit the 060-Deployment-strimzi-cluster-operator.yaml file to use those environment variables.

    • If the Cluster Operator is watching multiple namespaces, add the list of namespaces to the STRIMZI_NAMESPACE environment variable.
    • If the Cluster Operator is watching all namespaces, specify value: "*" for the STRIMZI_NAMESPACE environment variable.
  5. If the Cluster Operator is watching more than one namespace, update the role bindings.

    • If watching multiple namespaces, replace the namespace in the RoleBinding installation files with the actual namespace name and create the role bindings for each namespace:

      Creating role bindings for a namespace

      oc create -f install/cluster-operator/020-RoleBinding-strimzi-cluster-operator.yaml -n <watched_namespace>
      oc create -f install/cluster-operator/023-RoleBinding-strimzi-cluster-operator.yaml -n <watched_namespace>
      oc create -f install/cluster-operator/031-RoleBinding-strimzi-cluster-operator-entity-operator-delegation.yaml -n <watched_namespace>

      For example, if the Cluster Operator is watching three namespaces, create three sets of role bindings by substituting <watched_namespace> with the name of each namespace.

    • If watching all namespaces, recreate the cluster role bindings that grant cluster-wide access (if needed):

      Granting cluster-wide access using role bindings

      oc create clusterrolebinding strimzi-cluster-operator-namespaced --clusterrole=strimzi-cluster-operator-namespaced --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator
      oc create clusterrolebinding strimzi-cluster-operator-watched --clusterrole=strimzi-cluster-operator-watched --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator
      oc create clusterrolebinding strimzi-cluster-operator-entity-operator-delegation --clusterrole=strimzi-entity-operator --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator

  6. When you have an updated configuration, deploy it along with the rest of the installation resources:

    oc replace -f install/cluster-operator

    Wait for the rolling updates to complete.

  7. If the new operator version no longer supports the Kafka version you are upgrading from, an error message is returned.

    To resolve this, upgrade to a supported Kafka version:

    1. Edit the Kafka custom resource.
    2. Change the spec.kafka.version property to a supported Kafka version.

    If no error message is returned, you can proceed to the next step and upgrade the Kafka version later.

  8. Get the image for the Kafka pod to ensure the upgrade was successful:

    oc get pods my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'

    The image tag shows the new Streams for Apache Kafka version followed by the Kafka version:

    registry.redhat.io/amq-streams/strimzi-kafka-38-rhel9:2.8.0

    You can also check the upgrade has completed successfully from the status of the Kafka resource.

The Cluster Operator is upgraded to version 2.8, but the version of Kafka running in the cluster it manages is unchanged.

If you deployed Streams for Apache Kafka from OperatorHub, use the Operator Lifecycle Manager (OLM) to change the update channel for the Streams for Apache Kafka operators to a new Streams for Apache Kafka 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
注意

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 Upgrading installed Operators (OpenShift documentation).

Action required if upgrading from Streams for Apache Kafka 1.7 or earlier using the OperatorHub

Before you upgrade the Streams for Apache Kafka Operator to version 2.8, you need to make the following changes:

  • Convert custom resources and CRDs to v1beta2
  • Upgrade to a version of Streams for Apache Kafka where the ControlPlaneListener feature gate is disabled

These requirements are described in 第 29.2.2 节 “Upgrading from a Streams for Apache Kafka version earlier than 1.7”.

If you are upgrading from Streams for Apache Kafka 1.7 or earlier, do the following:

  1. Upgrade to Streams for Apache Kafka 1.7.
  2. Download the Red Hat Streams for Apache Kafka API Conversion Tool provided with Streams for Apache Kafka 1.8 from the Streams for Apache Kafka software downloads page.
  3. Convert custom resources and CRDs to v1beta2.

    For more information, see the Streams for Apache Kafka 1.7 upgrade documentation.

  4. In the OperatorHub, delete version 1.7 of the Streams for Apache Kafka Operator.
  5. If it also exists, delete version 2.8 of the Streams for Apache Kafka Operator.

    If it does not exist, go to the next step.

    If the Approval Strategy for the Streams for Apache Kafka Operator was set to Automatic, version 2.8 of the operator might already exist in your cluster. If you did not convert custom resources and CRDs to the v1beta2 API version before release, the operator-managed custom resources and CRDs will be using the old API version. As a result, the 2.8 Operator is stuck in Pending status. In this situation, you need to delete version 2.8 of the Streams for Apache Kafka Operator as well as version 1.7.

    If you delete both operators, reconciliations are paused until the new operator version is installed. Follow the next steps immediately so that any changes to custom resources are not delayed.

  6. In the OperatorHub, do one of the following:

    • Upgrade to version 1.8 of the Streams for Apache Kafka Operator (where the ControlPlaneListener feature gate is disabled by default).
    • Upgrade to version 2.0 or 2.2 of the Streams for Apache Kafka Operator (where the ControlPlaneListener feature gate is enabled by default) with the ControlPlaneListener feature gate disabled.
  7. Upgrade to version 2.8 of the Streams for Apache Kafka Operator immediately.

    The installed 2.8 operator begins to watch the cluster and performs rolling updates. You might notice a temporary decrease in cluster performance during this process.

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 Streams for Apache Kafka 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

oc delete $(oc get kt -n <namespace> -o name | grep strimzi-store-topic) \
  && oc delete $(oc get kt -n <namespace> -o name | grep strimzi-topic-operator)

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

oc annotate $(oc get kt -n <namespace> -o name | grep consumer-offsets) strimzi.io/managed="false" \
  && oc annotate $(oc get kt -n <namespace> -o name | grep transaction-state) strimzi.io/managed="false"

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 procedure to stop managing topics.

Having discontinued their management, delete the KafkaTopic resources:

Deleting the resources for managing internal topics

oc delete $(oc get kt -n <namespace> -o name | grep consumer-offsets) \
  && oc delete $(oc get kt -n <namespace> -o name | grep transaction-state)

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

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 oc to check for error messages like this in the status of the Kafka resource.

Checking the Kafka status for errors

oc 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 OpenShift namespace where the pod is running.

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部