DEV Community

Jose Roman Martin Gil
Jose Roman Martin Gil

Posted on • Originally published at blog.jromanmartin.io on

How to upgrade Strimzi Operator using the CLI

#howto #kubernetes #openshift #operators

Operator Lifecycle Manager (OLM) helps users install, update, and manage the lifecycle of all Operators and their associated services running across their clusters. It is part of the Operator Framework, an open source toolkit designed to manage Kubernetes native applications (Operators) in an effective, automated, and scalable way.

OLM is responsible for managing the custom resources definitions (CRDs) that are the basis for the OLM framework:

  • OperatorGroup (og): OLM used to group multiple namespaces and prepare for use by an operator.
  • Subscription (sub): Catalog used to keep CSVs up to date by tracking a channel in a package.
  • ClusterServiceVersion (csv):OLM application metadata: name, version, icon, required resources, installation, etc…
  • InstallPlan (ip): Catalog calculated list of resources to be created in order to automatically install/upgrade a CSV.

This article describes the upgrade process for the Strimzi Operator (or Red Hat AMQ Streams Operator) in an OpenShift Platform.

Note 1 : Only cluster-admin users could manage the OLM objects.

Note 2 : The article only covers the upgrade process of the Strimzi Operator, does not cover the strategies to upgrade the Apache Kafka cluster version.

Operator Subscription

To deploy the Strimzi Operators only to inspect a namespace (namespaced scope), we need to use an OperatorGroup. An OperatorGroup is an OLM resource that provides multitenant configuration to OLM-installed Operators.

This is a definition for manage operators in myproject namespace:

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: myproject-og
  namespace: myproject
spec:
  targetNamespaces:
    - myproject
Enter fullscreen mode Exit fullscreen mode

To install it:

❯ oc apply -f operatorgroup.yml
Enter fullscreen mode Exit fullscreen mode

A Subscription represents an intention to install an Operator. It is the custom resource that relates an Operator to a CatalogSource. Subscriptions describe which channel of an Operator package to subscribe to, and whether to perform updates automatically or manually. If set to automatic, the Subscription ensures OLM manages and upgrades the Operator to ensure that the latest version is always running in the cluster.

This is a Subscription definition to install Strimzi Operator:

---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: strimzi-kafka-operator
  namespace: myproject
spec:
  channel: stable
  installPlanApproval: Manual
  name: strimzi-kafka-operator
  source: community-operators
  sourceNamespace: openshift-marketplace
  startingCSV: strimzi-cluster-operator.v0.17.0
Enter fullscreen mode Exit fullscreen mode

In the case of Red Hat AMQ Streams the definition is:

---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: amq-streams
  namespace: myproject
spec:
  channel: stable
  installPlanApproval: Manual
  name: amq-streams
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: amqstreams.v1.4.0
Enter fullscreen mode Exit fullscreen mode

In both cases the following attributes are the important:

The channel, such as alpha, beta, or stable, helps determine which Operator stream should be installed from the CatalogSource.

  • channel : Identifies which Operator stream should be installed from the CatalogSourceThe channel. Values: alpha, beta, or stable.
  • installPlanApproval : Identifies the approval mode of the installPlan. If you defined as Automatic then the upgrade of the operator will be done as soon a new version is available.
  • startingCSV : Identifies the initial version to install of the operator.

💡 If you don’t know to values needed for these attributes, the following command will show you that information easily:

❯ oc get packagemanifest strimzi-kafka-operator \
    -o jsonpath='{range .status.channels[*]}{"Chanel: "}{.name}{" -- CSV: "}{.currentCSV}{" -- Version: "}{.currentCSVDesc.version}{" -- skipRange: "}{.currentCSVDesc.annotations.olm\.skipRange}{"\n"}'
Chanel: stable -- CSV: strimzi-cluster-operator.v0.19.0 -- Version: 0.19.0 -- skipRange: 
Chanel: strimzi-0.19.x -- CSV: strimzi-cluster-operator.v0.19.0 -- Version: 0.19.0 -- skipRange:
Enter fullscreen mode Exit fullscreen mode

For Red Hat AMQ Streams should be similar to:

❯ oc get packagemanifest amq-streams \
    -o jsonpath='{range .status.channels[*]}{"Chanel: "}{.name}{" -- CSV: "}{.currentCSV}{" -- Version: "}{.currentCSVDesc.version}{" -- skipRange: "}{.currentCSVDesc.annotations.olm\.skipRange}{"\n"}'
Chanel: amq-streams-1.5.x -- CSV: amqstreams.v1.5.3 -- Version: 1.5.3 -- skipRange: 
Chanel: amq-streams-1.x -- CSV: amqstreams.v1.5.3 -- Version: 1.5.3 -- skipRange: 
Chanel: stable -- CSV: amqstreams.v1.5.3 -- Version: 1.5.3 -- skipRange:
Enter fullscreen mode Exit fullscreen mode

💡 This article is focused to show how to update the Strimzi Operator manually, so this is the reason that we will use Manual installation plan approval mode. It could be a good practice to declare your subscriptions manually to control in which moment update your operators.

This command will install the subscription to deploy the operator:

❯ oc apply -f subscription.yml
Enter fullscreen mode Exit fullscreen mode

After you create the subscription we could check it:

❯ oc get sub
NAME PACKAGE SOURCE CHANNEL
strimzi-kafka-operator strimzi-kafka-operator community-operators stable
Enter fullscreen mode Exit fullscreen mode

The install plan is created, but it is not approved, so the operator is not installed jet:

❯ oc get ip
NAME CSV APPROVAL APPROVED
install-kt477 strimzi-cluster-operator.v0.17.0 Manual false
Enter fullscreen mode Exit fullscreen mode

This command will approve it to start the deployment of the operator:

❯ oc patch installplan install-kt477 --type merge --patch '{"spec":{"approved":true}}'
Enter fullscreen mode Exit fullscreen mode

The install plan will be updated as:

❯ oc get ip
NAME CSV APPROVAL APPROVED
install-kt477 strimzi-cluster-operator.v0.17.0 Manual true
Enter fullscreen mode Exit fullscreen mode

After some minutes we could check the status of the CSV:

❯ oc get csv
NAME DISPLAY VERSION REPLACES PHASE
strimzi-cluster-operator.v0.17.0 Strimzi 0.17.0 Succeeded
Enter fullscreen mode Exit fullscreen mode

Now you are ready to deploy an Apache Kafka cluster using the Kafka CRD provided by this operator:

❯ oc apply -f kafka.yml
Enter fullscreen mode Exit fullscreen mode

Upgrading the Operator

When a new version of your operator is released, OLM will check it and then a new install plan will be created for the new version.

If there is a new version available, the install plan should be similar to:

❯ oc get ip
NAME CSV APPROVAL APPROVED
install-2lxhr strimzi-cluster-operator.v0.18.0 Manual false
install-kt477 strimzi-cluster-operator.v0.17.0 Manual true
Enter fullscreen mode Exit fullscreen mode

Here you can see that there is a new strimzi-cluster-operator.v0.18.0 version available, so we could approved in the same way as the first installation:

❯ oc patch installplan install-2lxhr --type merge --patch '{"spec":{"approved":true}}'
Enter fullscreen mode Exit fullscreen mode

When the new version is active the CSV will be updated and then you could check the upgrading history:

❯ oc get csv
NAME DISPLAY VERSION REPLACES PHASE
strimzi-cluster-operator.v0.17.0 Strimzi 0.17.0 Replacing
strimzi-cluster-operator.v0.18.0 Strimzi 0.18.0 strimzi-cluster-operator.v0.17.0 Installing
Enter fullscreen mode Exit fullscreen mode

When the upgrade concluded the final status of the CSV will be:

❯ oc get csv
NAME DISPLAY VERSION REPLACES PHASE
strimzi-cluster-operator.v0.18.0 Strimzi 0.18.0 strimzi-cluster-operator.v0.17.0 Succeeded
Enter fullscreen mode Exit fullscreen mode

The operator pod it will be recreated with the new version as you can see in the following watcher command:

❯ oc get pod -w
NAME READY STATUS RESTARTS AGE
strimzi-cluster-operator-v0.17.0-5d9c7757c9-2blvf 1/1 Running 0 2m40s
strimzi-cluster-operator-v0.18.0-647d7bccc-bh66x 0/1 Pending 0 0s
strimzi-cluster-operator-v0.18.0-647d7bccc-bh66x 0/1 ContainerCreating 0 0s
strimzi-cluster-operator-v0.18.0-647d7bccc-bh66x 1/1 Running 0 2m36s
strimzi-cluster-operator-v0.17.0-5d9c7757c9-2blvf 1/1 Terminating 0 6m22s
Enter fullscreen mode Exit fullscreen mode

This process will be repeated every time a new version of the operator is available. You only need to approve each version.

Versions Upgrading Workflow

Strimzi Operator is a very matured operator and includes a large list of versions. Each version includes a set of new features. If you start from an older version, OLM will prompt you to upgrade to the next version.

The upgrade pathway for Strimzi Operator versions starting from v0.17.0:

v0.17.0 -> v0.18.0 -> v0.19.0

In the case of Red Hat AMQ Streams starting from v1.4.0 version is:

v1.4.0 -> v1.4.1 -> v1.5.0 -> v1.5.1 -> v1.5.2 -> v1.5.3

References

Top comments (0)

Read next

pipscript profile image

From Localhost to Production: Problem-First SRE Journey with One2N Bootcamp

Barigbue Nbira -

pareekplatform profile image

How a Pod is Deleted - Behind the Scenes Breakdown

Shubham -

sarvar_04 profile image

🚀 Spin Up an Amazon EKS Cluster in Minutes! ⏱️

Sarvar Nadaf -

alialp profile image

Why Running Databases on Kubernetes is a Recipe for Disaster: The Case for a New Platform Designed for Stateful Workloads

Ali Alp -