Chapter 1. Updating OpenShift Service Mesh
The strategy you use to deploy a service mesh affects how you can update the mesh.
1.1. 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"
1.2. 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.
1.2.1. 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.
1.2.2. 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
1.2.3. 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: InPlaceThe 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>
1.3. 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.
1.3.1. 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>.
1.3.2. 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.
1.3.3. 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: RevisionBasedThe 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/revlabel 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>
