Upgrade Gloo-managed service meshes
Use Gloo Mesh Core to upgrade your managed Solo distributions of Istio service meshes.
Istio 1.20 is supported only as patch version 1.20.1-patch1
and later. Do not use patch versions 1.20.0 and 1.20.1, which contain bugs that impact several Gloo Mesh Core features that rely on Istio ServiceEntries.
Introduction
After you deploy Gloo-managed service meshes, changes that you make to the IstioLifecycleManager
and GatewayLifecycleManager
resources are automatically propagated to your Istio installations. In some cases, these changes might require updates to your control plane or gateway deployments. Depending on the type of change, you apply updates to the installations by using an in-place upgrade or a revisioned canary upgrade.
In-place upgrade
In an in-place upgrade, Gloo upgrades your existing control plane or gateway installations. In-place upgrades behave differently based on whether your installation is revisionless or revisioned.
Revisionless (testing only): If your testing-only installation is revisionless (your settings omit the revision
and gatewayRevision
fields), in-place upgrades are triggered when you apply changes to any field in the istioInstallations
section.
Revisioned: If your installation is revisioned, in-place upgrades are triggered only when you apply changes to one of the following fields in the istioInstallations
section. Otherwise, a canary upgrade is required. You can change this behavior by setting the spec.installations.skipUpgradeValidation
boolean value to true
in the IstioLifecycleManager
and GatewayLifecycleManager
resources.
istioOperatorSpec.tag
patch version- In-place upgrades are not supported for downgrading the patch version.
- In-place upgrades are not supported if you do not already specify a
tag
value, such as if you want to switch from theauto
setting to a specific version. This is because you must also specifyhub
andrevision
values, which require a canary upgrade.
istioOperatorSpec.meshConfig
values
Multicluster
Get the names of your managed Istio installation resources.
kubectl get IstioLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT kubectl get GatewayLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT
Upgrade your istiod control plane by editing the
IstioLifecycleManager
resource. For example, you might update the patch version of Istio by changing the value ofistioOperatorSpec.tag
. After you save and close the editor, Gloo starts an in-place upgrade of theistiod
control planes.kubectl edit IstioLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT <istiod-installation-name>
If you created
GatewayLifecycleManager
resources for ingress or egress gateways, you can upgrade your gateways by editing each resource. For example, if you updated the patch version of the control plane, you can also update your gateway patch versions by changing the value ofistioOperatorSpec.tag
. After you save and close the editor, Gloo starts an in-place upgrade of the gateways.If you are updating the Istio image, be sure to update theistiod
control plane via the IstioLifecycleManager first, before you update your gateways. If you update the gateways before the control plane, the gateways might have an outdated image.kubectl edit GatewayLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT <ingress-gateway-installation-name>
kubectl edit GatewayLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT <egress-gateway-installation-name>
Required for versions earlier than 2.5.9, 2.4.16, and 2.3.24: After your Helm upgrade completes, restart your gateway pods in each workload cluster. For example, you might use the following command to rollout a restart of the
istio-ingressgateway-1-20
andistio-egressgateway-1-20
deployments.kubectl rollout restart -n gloo-mesh-gateways deployment/istio-ingressgateway-1-20 --context $REMOTE_CONTEXT1 kubectl rollout restart -n gloo-mesh-gateways deployment/istio-egressgateway-1-20 --context $REMOTE_CONTEXT1
kubectl rollout restart -n gloo-mesh-gateways deployment/istio-ingressgateway-1-20 --context $REMOTE_CONTEXT2 kubectl rollout restart -n gloo-mesh-gateways deployment/istio-egressgateway-1-20 --context $REMOTE_CONTEXT2
Verify that your Istio resources are updated.
kubectl get all -n gm-iop-1-20 --context $REMOTE_CONTEXT1 kubectl get all -n istio-system --context $REMOTE_CONTEXT1 kubectl get all -n gloo-mesh-gateways --context $REMOTE_CONTEXT1
Single cluster
Get the names of your managed Istio installation resources.
kubectl get IstioLifecycleManager -n gloo-mesh kubectl get GatewayLifecycleManager -n gloo-mesh
Upgrade your istiod control plane by editing the
IstioLifecycleManager
resource. For example, you might update the patch version of Istio by changing the value ofistioOperatorSpec.tag
. After you save and close the editor, Gloo starts an in-place upgrade of theistiod
control planes.kubectl edit IstioLifecycleManager -n gloo-mesh <istiod-installation-name>
If you created
GatewayLifecycleManager
resources for ingress or egress gateways, you can upgrade your gateways by editing each resource. For example, if you updated the patch version of the control plane, you can also update your gateway patch versions by changing the value ofistioOperatorSpec.tag
. After you save and close the editor, Gloo starts an in-place upgrade of the gateways.If you are updating the Istio image, be sure to update theistiod
control plane via the IstioLifecycleManager first, before you update your gateways. If you update the gateways before the control plane, the gateways might have an outdated image.kubectl edit GatewayLifecycleManager -n gloo-mesh <ingress-gateway-installation-name>
kubectl edit GatewayLifecycleManager -n gloo-mesh <egress-gateway-installation-name>
Required for versions earlier than 2.5.9, 2.4.16, and 2.3.24: After your Helm upgrade completes, restart your gateway pods in each workload cluster. For example, you might use the following command to rollout a restart of the
istio-ingressgateway-1-20
andistio-egressgateway-1-20
deployments.kubectl rollout restart -n gloo-mesh-gateways deployment/istio-ingressgateway-1-20 kubectl rollout restart -n gloo-mesh-gateways deployment/istio-egressgateway-1-20
Verify that your Istio resources are updated.
kubectl get all -n gm-iop-1-20 kubectl get all -n istio-system kubectl get all -n gloo-mesh-gateways
Revisioned canary upgrade
In a canary upgrade, you install another Istio installation (canary) alongside your active installation. Each installation is revisioned so that you can easily identify and verify the separate settings and resources for each installation.
Perform a canary upgrade when you change one of the following fields:
istioOperatorSpec.tag
minor versionistioOperatorSpec.hub
repository, such as switching to the repository for the minor version of the Solo distribution of Istio that you want to upgrade tocomponents
,profile
,values
, ornamespace
in theistioOperatorSpec
Keep in mind the following considerations:
- During a canary upgrade, the validating admissions webhook is enabled only for the canary installation to prevent issues that occur when multiple webhooks are enabled.
Multicluster
OpenShift only: Elevate the permissions of the service account that will be created for the new revision’s operator project. This permission allows the Istio sidecar to make use of a user ID that is normally restricted by OpenShift. Replace the revision with the revision you plan to use.
oc adm policy add-scc-to-group anyuid system:serviceaccounts:gm-iop-1-20 --context $REMOTE_CONTEXT1 oc adm policy add-scc-to-group anyuid system:serviceaccounts:gm-iop-1-20 --context $REMOTE_CONTEXT2
Get the names of your managed Istio installation resources.
kubectl get IstioLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT kubectl get GatewayLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT
Edit the
IstioLifecycleManager
resource for theistiod
control plane to add another installation entry for the canary revision. For the canary revision, be sure to setdefaultRevision
tofalse
so that only the existing revision continues to run.kubectl edit IstioLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT <installation-name>
For example, if you upgrade to Istio 1.20.8-patch1, add the following
1-20
canary revision as a new entry in theinstallations
section:apiVersion: admin.gloo.solo.io/v2 kind: IstioLifecycleManager metadata: name: istiod-control-plane namespace: gloo-mesh spec: installations: # Existing revision - revision: 1-19 clusters: - name: cluster1 # Keep this field set to TRUE so that only the existing revision continues to run defaultRevision: true - name: cluster2 defaultRevision: true istioOperatorSpec: ... # Canary revision - revision: 1-20 clusters: - name: cluster1 # Set this field to FALSE so that only the existing revision continues to run defaultRevision: false - name: cluster2 defaultRevision: false istioOperatorSpec: ...
Updating the minor version of Istio? In your canary revision section, be sure to update both the repo key in thehub
field, and the Istio version in thetag
field. You can get the repo key for the Istio version that you want to install from the Istio images built by Solo.io support article.If you created
GatewayLifecycleManager
resources for ingress or egress gateways, edit those resources to add another installation entry for the canary revision. Be sure to setactiveGateway
tofalse
so that only the existing revision continues to run.If you are updating the Istio image, be sure to update theistiod
control plane via the IstioLifecycleManager first, before you update your gateways. If you update the gateways before the control plane, the gateways might have an outdated image.
If you disable the load balancer services that are defined by default in the GatewayLifecycleManager, and instead maintain your own services to expose the gateways, you can later switch from the old to the new gateways by updating the services to point to the new gateways. However, note that due to an upstream Istio bug, it can takeistiod
up to 10 minutes to reconfigure the gateway listener for the updated ports on the service. To avoid this delay, you can expose the canary gateway with at least a ClusterIP service so that the control plane detects the service's ports immediately at deployment time.kubectl edit GatewayLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT <installation-name>
For example, if you upgrade to Istio 1.20.8-patch1, add the following
1-20
canary revision as a new entry in theinstallations
section:apiVersion: admin.gloo.solo.io/v2 kind: GatewayLifecycleManager metadata: name: istio-ingressgateway namespace: gloo-mesh spec: installations: # Existing revision - gatewayRevision: 1-19 clusters: - name: cluster1 # Keep this field set to TRUE so that only the existing revision continues to run activeGateway: true - name: cluster2 activeGateway: true istioOperatorSpec: profile: empty ... # Canary revision - gatewayRevision: 1-20 clusters: - name: cluster1 # Set this field to FALSE so that only the existing revision continues to run activeGateway: false - name: cluster2 activeGateway: false istioOperatorSpec: profile: empty ...
For most use cases, you can set therevision
for the IstioLifecycleManager and thegatewayRevision
for the GatewayLifecycleManager to the same version. However, gateway installations can point to any istiod control plane revision by using thecontrolPlaneRevision
field. For simplicity, if you do not specifycontrolPlaneRevision
, the gateway installation uses a control plane with the same revision as itself.Verify that Istio resources for the canary installation are created. For example, if you updated the Istio minor version to
1.20.8-patch1
, verify that resources are created in thegm-iop-1-20
namespace, and that resources for1-20
are created alongside the existing resources for the previous version in theistio-system
andgloo-mesh-gateways
namespaces. Note that the gateway load balancers for the canary revision contain the revision in the name, such asistio-ingressgateway-1-20
.kubectl get all -n gm-iop-1-20 --context $REMOTE_CONTEXT1 kubectl get all -n istio-system --context $REMOTE_CONTEXT1 kubectl get all -n gloo-mesh-gateways --context $REMOTE_CONTEXT1
kubectl get all -n gm-iop-1-20 --context $REMOTE_CONTEXT2 kubectl get all -n istio-system --context $REMOTE_CONTEXT2 kubectl get all -n gloo-mesh-gateways --context $REMOTE_CONTEXT2
After performing any necessary testing, switch to the new
istiod
control plane revision by changingdefaultRevision
tofalse
for the old revision and totrue
for the new revision.kubectl edit IstioLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT istiod-control-plane
Example:
apiVersion: admin.gloo.solo.io/v2 kind: IstioLifecycleManager metadata: name: istiod-control-plane namespace: gloo-mesh spec: installations: # Old revision - revision: 1-19 clusters: - name: cluster1 # Set this field to FALSE defaultRevision: false - name: cluster2 defaultRevision: false istioOperatorSpec: ... # New revision - revision: 1-20 clusters: - name: cluster1 # Set this field to TRUE defaultRevision: true - name: cluster2 defaultRevision: true istioOperatorSpec: ...
In your workload clusters, update the labels on your service namespaces to use the new revision.
For any namespace where you run Istio-managed apps, change the label to use the new revision, such as in these example commands.
kubectl label ns <namespace> --overwrite istio.io/rev=1-20 --context $REMOTE_CONTEXT1 kubectl label ns <namespace> --overwrite istio.io/rev=1-20 --context $REMOTE_CONTEXT2
For example, if you installed the Bookinfo sample app:
kubectl label ns bookinfo --overwrite istio.io/rev=1-20 --context $REMOTE_CONTEXT1 kubectl label ns bookinfo --overwrite istio.io/rev=1-20 --context $REMOTE_CONTEXT2
If you did not previously use revision labels for your apps, you can upgrade your application's sidecars by runningkubectl label ns <namespace> istio-injection-
andkubectl label ns <namespace> istio.io/rev=<revision>
.Update any Istio-managed apps by rolling out restarts. The Istio sidecars for each microservice are updated to use the new Istio version. Make sure that you only restart one microservice at a time. For example, in the following commands to update the Bookinfo microservices, 20 seconds elapse between each restart to ensure that the pods have time to start running.
kubectl rollout restart deployment -n bookinfo details-v1 --context $REMOTE_CONTEXT1 sleep 20s kubectl rollout restart deployment -n bookinfo ratings-v1 --context $REMOTE_CONTEXT1 sleep 20s kubectl rollout restart deployment -n bookinfo productpage-v1 --context $REMOTE_CONTEXT1 sleep 20s kubectl rollout restart deployment -n bookinfo reviews-v1 --context $REMOTE_CONTEXT1 sleep 20s kubectl rollout restart deployment -n bookinfo reviews-v2 --context $REMOTE_CONTEXT1 sleep 20s kubectl rollout restart deployment -n bookinfo reviews-v3 --context $REMOTE_CONTEXT2 sleep 20s kubectl rollout restart deployment -n bookinfo ratings-v1 --context $REMOTE_CONTEXT2 sleep 20s
Verify that your workloads and new gateways point to the new revision.
istioctl proxy-status --context $REMOTE_CONTEXT1
Example output:
NAME CLUSTER ... ISTIOD VERSION details-v1-7b6df9d8c8-s6kg5.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo istio-ingressgateway-1-20-bdc4fd65f-ftmz9.gloo-mesh-gateways cluster1 ... istiod-1-20-6495985689-rkwwd 1.20.8-patch1-solo productpage-v1-bb494b7d7-xbtxr.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo ratings-v1-55b478cfb6-wv2m5.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo reviews-v1-6dfcc9fc7d-7k6qh.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo reviews-v2-7dddd799b5-m5n2z.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo
Switch to any new gateways by changing
activeGateway
tofalse
for the old revision and totrue
for the new revision.kubectl edit GatewayLifecycleManager -n gloo-mesh --context $MGMT_CONTEXT <installation-name>
Example:
apiVersion: admin.gloo.solo.io/v2 kind: GatewayLifecycleManager metadata: name: istio-ingressgateway namespace: gloo-mesh spec: installations: # Old revision - gatewayRevision: 1-19 clusters: - name: cluster1 # Set this field set to FALSE activeGateway: false - name: cluster2 activeGateway: false istioOperatorSpec: profile: empty ... # New revision - gatewayRevision: 1-20 clusters: - name: cluster1 # Set this field to TRUE activeGateway: true - name: cluster2 activeGateway: true istioOperatorSpec: profile: empty ...
New load balancers are created for the canary gateways. To instead change the control plane revision in use by the existing gateway load balancers, you can set theistio.io/rev
label on the gateway deployment, which triggers a rolling restart.Verify that the active gateways for the new revision are created, which do not have the revision appended to the name. Note that gateways for the inactive revision that you previously ran also exist in the namespace, in the case that a rollback is required.
kubectl get all -n gloo-mesh-gateways --context $REMOTE_CONTEXT1 kubectl get all -n gloo-mesh-gateways --context $REMOTE_CONTEXT2
Example output, in which the active gateway (
istio-ingressgateway
) for the new revision and inactive gateway (such asistio-ingressgateway-1-19
) for the old revision are created:NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.44.4.140 34.150.235.221 15021:31321/TCP,80:32525/TCP,443:31826/TCP 48s istio-ingressgateway-1-19 LoadBalancer 10.56.15.36 34.145.163.61 15021:31936/TCP,80:30196/TCP,443:32286/TCP,15443:31851/TCP 45s
To uninstall the previous installation, or if you need to uninstall the canary installation, you can edit the
IstioLifecycleManager
andGatewayLifecycleManager
resources to remove the revision’s entry from theinstallations
list.
Single cluster
OpenShift only: Elevate the permissions of the service account that will be created for the new revision’s operator project. This permission allows the Istio sidecar to make use of a user ID that is normally restricted by OpenShift. Replace the revision with the revision you plan to use.
oc adm policy add-scc-to-group anyuid system:serviceaccounts:gm-iop-1-20 --context $REMOTE_CONTEXT1 oc adm policy add-scc-to-group anyuid system:serviceaccounts:gm-iop-1-20 --context $REMOTE_CONTEXT2
Get the names of your managed Istio installation resources.
kubectl get IstioLifecycleManager -n gloo-mesh kubectl get GatewayLifecycleManager -n gloo-mesh
Edit the
IstioLifecycleManager
resource for theistiod
control plane to add another installation entry for the canary revision. For the canary revision, be sure to setdefaultRevision
tofalse
so that only the existing revision continues to run.kubectl edit IstioLifecycleManager -n gloo-mesh <installation-name>
For example, if you upgrade to Istio 1.20.8-patch1, add the following
1-20
canary revision as a new entry in theinstallations
section:apiVersion: admin.gloo.solo.io/v2 kind: IstioLifecycleManager metadata: name: istiod-control-plane namespace: gloo-mesh spec: installations: # Existing revision - revision: 1-19 clusters: - name: cluster1 # Keep this field set to TRUE so that only the existing revision continues to run defaultRevision: true istioOperatorSpec: ... # Canary revision - revision: 1-20 clusters: - name: cluster1 # Set this field to FALSE so that only the existing revision continues to run defaultRevision: false istioOperatorSpec: ...
Updating the minor version of Istio? In your canary revision section, be sure to update both the repo key in thehub
field, and the Istio version in thetag
field. You can get the repo key for the Istio version that you want to install from the Istio images built by Solo.io support article.If you created
GatewayLifecycleManager
resources for ingress or egress gateways, edit those resources to add another installation entry for the canary revision. Be sure to setactiveGateway
tofalse
so that only the existing revision continues to run.If you are updating the Istio image, be sure to update theistiod
control plane via the IstioLifecycleManager first, before you update your gateways. If you update the gateways before the control plane, the gateways might have an outdated image.
If you disable the load balancer services that are defined by default in the GatewayLifecycleManager, and instead maintain your own services to expose the gateways, you can later switch from the old to the new gateways by updating the services to point to the new gateways. However, note that due to an upstream Istio bug, it can takeistiod
up to 10 minutes to reconfigure the gateway listener for the updated ports on the service. To avoid this delay, you can expose the canary gateway with at least a ClusterIP service so that the control plane detects the service's ports immediately at deployment time.kubectl edit GatewayLifecycleManager -n gloo-mesh <installation-name>
For example, if you upgrade to Istio 1.20.8-patch1, add the following
1-20
canary revision as a new entry in theinstallations
section:apiVersion: admin.gloo.solo.io/v2 kind: GatewayLifecycleManager metadata: name: istio-ingressgateway namespace: gloo-mesh spec: installations: # Existing revision - gatewayRevision: 1-19 clusters: - name: cluster1 # Keep this field set to TRUE so that only the existing revision continues to run activeGateway: true istioOperatorSpec: profile: empty ... # Canary revision - gatewayRevision: 1-20 clusters: - name: cluster1 # Set this field to FALSE so that only the existing revision continues to run activeGateway: false istioOperatorSpec: profile: empty ...
For most use cases, you can set therevision
for the IstioLifecycleManager and thegatewayRevision
for the GatewayLifecycleManager to the same version. However, gateway installations can point to any istiod control plane revision by using thecontrolPlaneRevision
field. For simplicity, if you do not specifycontrolPlaneRevision
, the gateway installation uses a control plane with the same revision as itself.Verify that Istio resources for the canary installation are created. For example, if you updated the Istio minor version to
1.20.8-patch1
, verify that resources are created in thegm-iop-1-20
namespace, and that resources for1-20
are created alongside the existing resources for the previous version in theistio-system
andgloo-mesh-gateways
namespaces. Note that the gateway load balancers for the canary revision contain the revision in the name, such asistio-ingressgateway-1-20
.kubectl get all -n gm-iop-1-20 kubectl get all -n istio-system kubectl get all -n gloo-mesh-gateways
After performing any necessary testing, switch to the new
istiod
control plane revision by changingdefaultRevision
tofalse
for the old revision and totrue
for the new revision.kubectl edit IstioLifecycleManager -n gloo-mesh istiod-control-plane
Example:
apiVersion: admin.gloo.solo.io/v2 kind: IstioLifecycleManager metadata: name: istiod-control-plane namespace: gloo-mesh spec: installations: # Old revision - revision: 1-19 clusters: - name: cluster1 # Set this field to FALSE defaultRevision: false istioOperatorSpec: ... # New revision - revision: 1-20 clusters: - name: cluster1 # Set this field to TRUE defaultRevision: true istioOperatorSpec: ...
Update the labels on your service namespaces to use the new revision.
For any namespace where you run Istio-managed apps, change the label to use the new revision, such as in these example commands.
kubectl label ns <namespace> --overwrite istio.io/rev=1-20
For example, if you installed the Bookinfo sample app:
kubectl label ns bookinfo --overwrite istio.io/rev=1-20
If you did not previously use revision labels for your apps, you can upgrade your application's sidecars by runningkubectl label ns <namespace> istio-injection-
andkubectl label ns <namespace> istio.io/rev=<revision>
.Update any Istio-managed apps by rolling out restarts. The Istio sidecars for each microservice are updated to use the new Istio version. Make sure that you only restart one microservice at a time. For example, in the following commands to update the Bookinfo microservices, 20 seconds elapse between each restart to ensure that the pods have time to start running.
kubectl rollout restart deployment -n bookinfo details-v1 sleep 20s kubectl rollout restart deployment -n bookinfo productpage-v1 sleep 20s kubectl rollout restart deployment -n bookinfo reviews-v1 sleep 20s kubectl rollout restart deployment -n bookinfo reviews-v2 sleep 20s kubectl rollout restart deployment -n bookinfo reviews-v3 sleep 20s kubectl rollout restart deployment -n bookinfo ratings-v1 sleep 20s
Verify that your workloads and new gateways point to the new revision.
istioctl proxy-status
Example output:
NAME CLUSTER ... ISTIOD VERSION details-v1-7b6df9d8c8-s6kg5.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo istio-ingressgateway-1-20-bdc4fd65f-ftmz9.gloo-mesh-gateways cluster1 ... istiod-1-20-6495985689-rkwwd 1.20.8-patch1-solo productpage-v1-bb494b7d7-xbtxr.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo ratings-v1-55b478cfb6-wv2m5.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo reviews-v1-6dfcc9fc7d-7k6qh.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo reviews-v2-7dddd799b5-m5n2z.bookinfo cluster1 ... istiod-1-20-7c8f6fd4c4-m9k9t 1.20.8-patch1-solo
Switch to any new gateways by changing
activeGateway
tofalse
for the old revision and totrue
for the new revision.kubectl edit GatewayLifecycleManager -n gloo-mesh <installation-name>
Example:
apiVersion: admin.gloo.solo.io/v2 kind: GatewayLifecycleManager metadata: name: istio-ingressgateway namespace: gloo-mesh spec: installations: # Old revision - gatewayRevision: 1-19 clusters: - name: cluster1 # Keep this field set to FALSE activeGateway: false istioOperatorSpec: profile: empty ... # New revision - gatewayRevision: 1-20 clusters: - name: cluster1 # Set this field to TRUE activeGateway: true istioOperatorSpec: profile: empty ...
New load balancers are created for the canary gateways. To instead change the control plane revision in use by the existing gateway load balancers, you can set theistio.io/rev
label on the gateway deployment, which triggers a rolling restart.Verify that the active gateways for the new revision are created, which do not have the revision appended to the name. Note that gateways for the inactive revision that you previously ran also exist in the namespace, in the case that a rollback is required.
kubectl get all -n gloo-mesh-gateways
Example output, in which the active gateway (
istio-ingressgateway
) for the new revision and inactive gateway (such asistio-ingressgateway-1-19
) for the old revision are created:NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.44.4.140 34.150.235.221 15021:31321/TCP,80:32525/TCP,443:31826/TCP 48s istio-ingressgateway-1-19 LoadBalancer 10.56.15.36 34.145.163.61 15021:31936/TCP,80:30196/TCP,443:32286/TCP,15443:31851/TCP 45s
To uninstall the previous installation, or if you need to uninstall the canary installation, you can edit the
IstioLifecycleManager
andGatewayLifecycleManager
resources to remove the revision’s entry from theinstallations
list.