Updating OpenShift Service Mesh | Updating | Red Hat OpenShift Service Mesh 3.0.0tp1

About update strategies
About InPlace strategy
About RevisionBased strategy

The strategy you use to deploy a service mesh affects how you can update the mesh.

About update strategies

The update strategy affects how the update process is performed. For each mesh, you select one of two strategies:

InPlace
RevisionBased

The default strategy is the InPlace strategy. For more information, see the following documentation located in "Updating OpenShift Service Mesh":

"About InPlace strategy"
"About RevisionBased strategy"

About InPlace strategy

The InPlace strategy runs only one revision of the control plane at all times. When you perform an InPlace update, all of the workloads immediately connect to the new version of the control plane. In order to ensure compatibility between the sidecars and the control plane you cannot upgrade by more than one minor version at a time.

Select InPlace strategy

To select the InPlace strategy, set the spec.updateStrategy.type value in the Istio resource to InPlace.

Example specification to select InPlace update strategy

kind: Istio
spec:
  updateStrategy:
    type: InPlace

You can set this value when you first create the resource or you can edit the resource later. If you choose to edit the resource after it is created, make the change prior to updating the Istio control plane.

Attach workloads to the control plane

When Istio is configured to use the InPlace strategy, the IstioRevision resource that the Operator creates always has the same name as the Istio resource. To attach the workloads to a control plane deployed using the InPlace strategy, you can set the istio.io/rev namespace label to the name of the IstioRevision.

Example istio.io namespace label to attach workloads to a mesh

$ oc label namespace <namespace-name> istio.io/rev=<revision-name>

Alternatively, you can apply the label to the workload pods by modifying the pod template in deployment resource.

Example pod template to attach workloads to a mesh

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    metadata:
      labels:
        istio.io/rev: <revision-name>
    spec:

If the revision name is default, then you can attach the workloads to the revision by labeling the namespace or the pods with the label istio-injection: enabled.

Example istio-injection label to attach workloads to a mesh

oc label namespace <namespace-name> istio-injection=enabled

Performing InPlace update

When updating Istio using the InPlace strategy, you can only increment by one minor version at a time. If you want to update by more than one minor version, then you must increment the version and restart the workloads after each update. This ensures that the sidecar version is compatible with the control plane version. After all the workloads are restarted the update process is complete.

Prerequisites

You are logged in to Red Hat OpenShift Service Mesh as cluster-admin.
You have installed the Red Hat OpenShift Service Mesh Operator, and deployed Istio.

Procedure

Change the version in the Istio resource:
```
kind: Istio
spec:
  version: 1.20.2
  updateStrategy:
    type: InPlace
```
The Service Mesh Operator deploys a new version of the control plane that replaces the old version of the control plane. The sidecars automatically reconnect to the new control plane.
Confirm that the new version of the control plane is running and ready by entering the following command:
```
$ oc get istio <control-plane-name>
```
Restart the application workloads so that the new version of the sidecar gets injected by entering the following command:
```
$ oc rollout restart <deployment-name>
```

About RevisionBased strategy

Typically, an update that is performed using the RevisionBased strategy runs two revisions of a control plane. This capability allows you to gradually migrate workloads from the old control plane to the new control plane, making canary upgrades possible. The RevisionBased strategy also allows you to update by more than one minor version.

Select RevisionBased strategy

To deploy Istio with the RevisionBased strategy, create the Istio resource with the following spec.updateStrategy value:

Example specification to select RevisionBased strategy

kind: Istio
spec:
  version: 1.20.0
  updateStrategy: RevisionBased

After you select the strategy for the Istio resource, the Operator creates a new IstioRevision resource with the name <istio resource name>-<version>.

Attach workloads to the control plane by using RevisionBased strategy

To attach the workloads to a control plane deployed by using the RevisionBased strategy, you must set the istio.io/rev namespace label to the name of the IstioRevision. Alternatively, you can apply the label to the workload pods.

Performing RevisionBased update

When updating Istio using the RevisionBased strategy, you may increment by more than one minor version at a time because the existing sidecars do not automatically connect to the new revision of the control plane. Instead, you must manually move the workloads to the new control plane.

Prerequisites

You have installed the Red Hat OpenShift Service Mesh Operator, and deployed Istio.

Procedure

Change the version in the Istio resource:
```
kind: Istio
spec:
  version: 1.20.2
  updateStrategy:
    type: RevisionBased
```
The Service Mesh Operator deploys a new version of the control plane alongside the old version of the control plane. The sidecars remain connected to the old control plane.
Confirm that both revisions of the control plane are running and ready:
```
$ oc get istiorevisions
```
Move the workloads to the new control plane by updating the istio.io/rev label on the application namespace or the pods to the revision name of the new control plane.
Restart the application workloads so that the new version of the sidecar gets injected.
```
$ oc rollout restart <deployment>
```