Navigation :

Upgrade Gloo Mesh

Upgrade minor and patch versions for the Gloo Mesh management server and agent.

During the upgrade, the data plane continues to run, but you might not be able to modify the configurations through the management plane. Because zero downtime is not guaranteed, try testing the upgrade in a staging environment before upgrading your production environment.

Upgrade to version 2.3

Upgrade Gloo Mesh to version 2.3 for the first time by migrating your Helm charts to the improved gloo-platform Helm chart.

In Gloo Mesh 2.3 and later, the gloo-mesh-enterpise, gloo-mesh-agent, and other included Helm charts are considered legacy. If you installed Gloo Mesh by using these legacy Helm charts, or if you used meshctl version 2.2 or earlier to install Gloo Mesh, you can migrate your existing installation to the new gloo-platform Helm chart by using the meshctl migrate helm command. During the migration, your installation version is also upgraded to 2.3.

To migrate you Helm charts and upgrade to 2.3, see Migrate to the gloo-platform Helm chart.

Although it is possible to upgrade your Gloo Mesh version to 2.3 without migrating your legacy Helm charts to the new chart, it is not recommended. All guides in the 2.3 documentation use Helm values from the gloo-platform chart. If you must upgrade your legacy Helm charts to 2.3 without migrating, see the legacy upgrade guide.

Upgrade Helm values or the 2.3 patch version

After you upgrade your Gloo Mesh installation to version 2.3, follow these steps to modify Helm values or upgrade your 2.3 patch version.

The upgrade steps in this section are intended for installations that use the gloo-platform Helm chart, which is available in Gloo Platform 2.3 and later. If you installed Gloo Mesh by using the legacy gloo-mesh-enterpise, gloo-mesh-agent, and other included Helm charts, or if you used meshctl version 2.2 or earlier to install Gloo Mesh, migrate your legacy installation to the new gloo-platform Helm chart first. Then, you can upgrade your gloo-platform Helm chart installation by using this section.

Before you begin

Review the changelog. Focus especially on any Breaking Changes that might require a different upgrade procedure.
Check that your underlying Kubernetes platform and Istio service mesh run supported versions for the Gloo Mesh Enterprise version that you want to upgrade to.
1. Review the supported versions.
2. Compare the supported version against the versions of Kubernetes and Istio that you run in your clusters.
3. If necessary, upgrade Istio or Kubernetes. For example, if you want to upgrade from Gloo Mesh Enterprise 2.2 to 2.3 but you currently run Istio 1.12, you must upgrade to Istio 1.13 first.
  - For Istio steps, see Upgrade Gloo Mesh-managed Istio or Upgrade manually deployed Istio.
  - For Kubernetes steps, consult your cluster infrastructure provider.
Set the Gloo Mesh version that you want to upgrade to as an environment variable. The latest version is used as an example. You can find other versions in the Changelog documentation. Append ‘-fips’ for a FIPS-compliant image, such as ‘2.4.0-beta1-fips’. Do not include v before the version number.
```
export UPGRADE_VERSION=2.4.0-beta1
```

Step 1: Upgrade Gloo CRDs

Looking to update certain Helm chart values but not the version? Skip to step 2.

Update the Helm repository for Gloo Platform.

helm repo add gloo-platform https://storage.googleapis.com/gloo-platform/helm-charts
helm repo update

Apply the Gloo custom resource definitions (CRDs) for the target version by upgrading your gloo-platform-crds Helm release in the management cluster.

helm upgrade gloo-platform-crds gloo-platform/gloo-platform-crds \
   --kube-context $MGMT_CONTEXT \
   --namespace=gloo-mesh \
   --version=$UPGRADE_VERSION

Upgrade your gloo-platform-crds Helm release in each workload cluster. Remember to change the context for each workload cluster that you upgrade.

helm upgrade gloo-platform-crds gloo-platform/gloo-platform-crds \
   --kube-context $REMOTE_CONTEXT \
   --namespace=gloo-mesh \
   --version=$UPGRADE_VERSION

Step 2: Get your Helm chart values

As part of the upgrade, you can update or reuse the Helm chart values for your Gloo management server, agent, and any add-ons that you might have such as rate limiting and external authentication services.

Get the Helm values files for your current version.
1. Get your current values for the management cluster. Note that if you migrated from the legacy Helm charts, your Helm release might be named gloo-mgmt or gloo-mesh-enterprise instead.
```
helm get values gloo-platform -n gloo-mesh --kube-context $MGMT_CONTEXT > mgmt-server.yaml
open mgmt-server.yaml
```
2. Delete the first line that contains USER-SUPPLIED VALUES:, and save the file.
3. Get your current values for the workload clusters. Note that if you migrated from the legacy Helm charts, your Helm release might be named gloo-agent or gloo-mesh-agent instead.
```
helm get values gloo-platform -n gloo-mesh --kube-context $REMOTE_CONTEXT > agent.yaml
open agent.yaml
```
4. Delete the first line that contains USER-SUPPLIED VALUES:, and save the file.
5. Optional: If you maintain a separate gloo-agent-addons Helm release, get the values for that Helm release too, and delete the first line that contains USER-SUPPLIED VALUES:.
```
helm get values gloo-agent-addons -n gloo-mesh-addons --kube-context $REMOTE_CONTEXT > gloo-agent-addons.yaml
open gloo-agent-addons.yaml
```
Compare your current Helm chart values with the version that you want to upgrade to. You can get a values file for the upgrade version with the helm show values command.
```
helm show values gloo-platform/gloo-platform --version $UPGRADE_VERSION > all-values.yaml
```
Review the changelog for any Helm Changes that might require modifications to your Helm chart.
Edit the Helm values files or prepare the --set flags to make any changes that you want. If you do not want to use certain settings, comment them out.

Updating values in the istioInstallations section? See Upgrade managed Istio for special instructions.

Step 3: Upgrade and verify the Helm installation

You must always upgrade the Gloo management server before upgrading the Gloo agent to avoid unexpected behavior. Note that only n-1 minor version skew is supported between the management server and the agent. For more information, see the Skew policy.

Upgrade the Gloo Mesh Helm installation. Make sure to include your Helm values when you upgrade either as a configuration file in the --values flag or with --set flags. Otherwise, any previous custom values that you set might be overwritten. In single cluster setups, this might mean that your Gloo agent and ingress gateways are removed.
1. Upgrade your Helm release in the management cluster. Change the release name as needed.
```
helm upgrade gloo-platform gloo-platform/gloo-platform \
   --kube-context $MGMT_CONTEXT \
   --namespace gloo-mesh \
   -f mgmt-server.yaml \
   --version $UPGRADE_VERSION
```
2. Upgrade your Helm release in each workload cluster. Change the release name as needed. Be sure to update the cluster context for each workload cluster that you repeat this command for.
```
helm upgrade gloo-platform gloo-platform/gloo-platform \
   --kube-context $REMOTE_CONTEXT \
   --namespace gloo-mesh \
   -f agent.yaml \
   --version $UPGRADE_VERSION
```
3. Optional: If you migrated from the legacy Helm charts and maintained a separate gloo-agent-addons Helm release during the migration, upgrade that Helm release in each workload cluster too. Be sure to update the cluster context for each workload cluster that you repeat this command for.
```
helm upgrade gloo-agent-addons gloo-platform/gloo-platform \
   --kube-context $REMOTE_CONTEXT \
   --namespace gloo-mesh-addons \
   -f gloo-agent-addons.yaml \
   --version $UPGRADE_VERSION
```
Optional: Check that the Gloo management and agent resources are connected.
```
meshctl check --kubecontext $MGMT_CONTEXT
```

Confirm that the server components such as gloo-mesh-mgmt-server run the version that you upgraded to.

meshctl version --kubecontext $MGMT_CONTEXT

Example output:

   "server": [
   {
     "Namespace": "gloo-mesh",
     "components": [
       {
         "componentName": "gloo-mesh-mgmt-server",
         "images": [
            {
             "name": "gloo-mesh-mgmt-server",
             "domain": "gcr.io",
             "path": "gloo-mesh-mgmt-server",
             "version": "2.4.0-beta1"
           }
         ]
       },

Confirm that the agent components such as gloo-mesh-agent run the version that you upgraded to.

meshctl version --kubecontext $REMOTE_CONTEXT

Example output:

   {
         "componentName": "gloo-mesh-agent",
         "images": [
           {
             "name": "gloo-mesh-agent",
             "domain": "gcr.io",
             "path": "gloo-mesh/gloo-mesh-agent",
             "version": "2.4.0-beta1"
           }
         ]
       },

Next steps

Now that you upgraded Gloo Mesh Enterprise, you must upgrade your meshctl CLI to the matching version. Depending on the Gloo Mesh Enterprise version support, you might also want to upgrade Istio or Kubernetes in your clusters.

Upgrade the meshctl CLI to the same version of Gloo Mesh.
Optional: If the new version of Gloo Mesh supports a more recent version of Istio, you can upgrade Istio.
Optional: If the new version of Gloo Mesh supports a more recent version of Kubernetes, you can upgrade Kubernetes on your cluster. For more information, consult your cluster infrastructure provider.

Upgrade managed Istio

The steps in this section upgrade Istio installations that are managed by the istioInstallations section of your Gloo Mesh Helm chart. If you directly created IstioLifecycleManager and GatewayLifecycleManager CRDs to manage the Istio control planes and gateways instead of using the Helm chart option, follow the Upgrade Gloo Mesh-managed Istio guide instead.

During step 2 of the Helm upgrade process, you might make changes to the istioInstallations section of your Helm values file to update your Istio control plane and gateways. Depending on the type of change, you apply updates to the installations in one of the following ways:

Canary upgrade (recommended)
In-place upgrade
Testing only: Manually replacing the IstioLifecycleManager CR

Istio version 1.17 does not support the Gloo legacy metrics pipeline. If you run the legacy metrics pipeline, before you upgrade or install Istio with version 1.17, be sure that you set up the Gloo OpenTelemetry (OTel) pipeline instead in your new or existing Gloo Mesh installation.

Canary upgrades (recommended)

In a canary upgrade, you install another Istio installation (canary) alongside your active installation. Note that 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.

Perform a canary upgrade when you change one of the following fields:

istioOperatorSpec.tag minor version
istioOperatorSpec.hub repository, such as switching to the Gloo Istio repository for the minor version you want to upgrade to
components, profile, values, or namespace in the istioOperatorSpec

To perform a canary upgrade:

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-17-2 --context $REMOTE_CONTEXT1
oc adm policy add-scc-to-group anyuid system:serviceaccounts:gm-iop-1-17-2 --context $REMOTE_CONTEXT2
```

Follow the steps in this guide to perform a regular upgrade of your Gloo Mesh installation. When you edit the istioInstallations.controlPlane and istioInstallations.eastWestGateways sections of your Helm values file, add another installation entry for the canary revision, and leave the entry your your current installation as-is. For the canary revision, be sure to set defaultRevision and activeGateway to false so that only the existing revisions continue to run.

For example, you might add the following installation entries for the Istio control plane and east-west gateway alongside your existing entries. If you have a Gloo Gateway license, you might also have entries for the ingress gateway proxy in the nothSouthGateways section too.

istioInstallations:
    controlPlane:
        enabled: true
        installations:
            # EXISTING revision
            - clusters:
                  # Keep this field set to TRUE
                - defaultRevision: true
                  name: cluster1
                  trustDomain: ""
              istioOperatorSpec:
                hub: $REPO
                tag: 1.16.4-solo
                profile: minimal
                namespace: istio-system
                ...
              revision: 1-16-4
            # NEW revision
            - clusters:
                  # Set this field to FALSE
                - defaultRevision: false
                  name: cluster1
                  trustDomain: ""
              istioOperatorSpec:
                hub: $REPO
                tag: 1.17.2-solo
                profile: minimal
                namespace: istio-system
                ...
              revision: 1-17-2
    eastWestGateways:
        - enabled: true
          installations:
            # EXISTING revision
            - clusters:
                  # Keep this field set to TRUE
                - activeGateway: true
                  name: cluster1
                  name: 
                  trustDomain: ""
              gatewayRevision: 1-16-4
              istioOperatorSpec:
                hub: $REPO
                tag: 1.16.4-solo
                profile: empty
                namespace: gloo-mesh-gateways
                ...
            # NEW revision
            - clusters:
                  # Set this field to FALSE
                - activeGateway: false
                  name: cluster1
                  name: 
                  trustDomain: ""
              gatewayRevision: 1-17-2
              istioOperatorSpec:
                hub: $REPO
                tag: 1.17.2-solo
                profile: empty
                namespace: gloo-mesh-gateways
                ...
          name: istio-eastwestgateway
    enabled: true

Updating the minor version of Istio? In your canary revision section, be sure to update both the repo key in the hub field, and the Istio version in the tag 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.

For most use cases, you can set the revision and the gatewayRevision to the same version. However, gateway installations can point to any istiod control plane revision by using the controlPlaneRevision field. For simplicity, if you do not specify controlPlaneRevision, the gateway installation uses a control plane with the same revision as itself.

After you apply the Helm upgrade with your updated values file, verify that Istio resources for the canary installation are created. For example, if you updated the Istio minor version to 1-17-2, verify that resources are created in the gm-iop-1-17-2 namespace, and that resources for 1-17-2 are created alongside the existing resources for the previous version in the istio-system and gloo-mesh-gateways namespaces. Note that the gateway load balancers for the canary revision contain the revision in the name, such as istio-eastwestgateway-1-17-2.
```
kubectl get all -n gm-iop-1-17-2
kubectl get all -n istio-system
kubectl get all -n gloo-mesh-gateways
```

After performing any necessary testing, switch to the new Istio control plane and gateway revisions.

Get your Helm values file. Change the release name as needed.

helm get values gloo-platform -n gloo-mesh > mgmt-server.yaml
open mgmt-server.yaml

Change defaultRevision and activeGateway to false for the old revision and to true for the new revision.

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 the istio.io/rev label on the gateway deployment, which triggers a rolling restart.

istioInstallations:
    controlPlane:
        enabled: true
        installations:
            # OLD revision
            - clusters:
                  # Set this field to FALSE
                - defaultRevision: false
                  name: cluster1
                  trustDomain: ""
              istioOperatorSpec:
                hub: $REPO
                tag: 1.16.4-solo
                profile: minimal
                namespace: istio-system
                ...
              revision: 1-16-4
            # NEW revision
            - clusters:
                  # Set this field to TRUE
                - defaultRevision: true
                  name: cluster1
                  trustDomain: ""
              istioOperatorSpec:
                hub: $REPO
                tag: 1.17.2-solo
                profile: minimal
                namespace: istio-system
                ...
              revision: 1-17-2
    eastWestGateways:
        - enabled: true
          installations:
            # OLD revision
            - clusters:
                  # Set this field to FALSE
                - activeGateway: false
                  name: cluster1
                  name: 
                  trustDomain: ""
              gatewayRevision: 1-16-4
              istioOperatorSpec:
                hub: $REPO
                tag: 1.16.4-solo
                profile: empty
                namespace: gloo-mesh-gateways
                ...
            # NEW revision
            - clusters:
                  # Set this field to TRUE
                - activeGateway: true
                  name: cluster1
                  name: 
                  trustDomain: ""
              gatewayRevision: 1-17-2
              istioOperatorSpec:
                hub: $REPO
                tag: 1.17.2-solo
                profile: empty
                namespace: gloo-mesh-gateways
                ...
          name: istio-eastwestgateway
    enabled: true

Upgrade your Helm release. Change the release name as needed.

helm upgrade gloo-platform gloo-platform/gloo-platform \
   --namespace gloo-mesh \
   -f mgmt-server.yaml \
   --version $UPGRADE_VERSION

After your Helm upgrade completes, 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-eastwestgateway) for the new revision and inactive gateway (such as istio-eastwestgateway-1-16-4) for the old revision are created:
```
NAME                            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)     
istio-eastwestgateway            LoadBalancer   10.44.4.140   34.150.235.221   15021:31321/TCP,80:32525/TCP,443:31826/TCP   48s                                                 AGE
istio-eastwestgateway-1-16-4       LoadBalancer   10.56.15.36    34.145.163.61   15021:31936/TCP,80:30196/TCP,443:32286/TCP,15443:31851/TCP   45s
```

Upgrade your apps’ Istio sidecars.

For any namespace where you run Istio-managed apps, change the label to use the new revision. For example, you might update the bookinfo namespace.
If you did not previously use revision labels for your apps, you can upgrade your application's sidecars by running ‘kubectl label ns bookinfo istio-injection-’ and ‘kubectl label ns bookinfo istio.io/rev=$REVISION’.
- Single cluster setup
- Multicluster setup
```
kubectl label ns bookinfo istio.io/rev=$REVISION --overwrite
```
```
kubectl label ns bookinfo istio.io/rev=$REVISION --overwrite --context $REMOTE_CONTEXT1
kubectl label ns bookinfo istio.io/rev=$REVISION --overwrite --context $REMOTE_CONTEXT2
```

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.

Single cluster setup
Multicluster setup

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

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.

Single cluster setup
Multicluster setup

istioctl proxy-status

istioctl proxy-status --context $REMOTE_CONTEXT1

Example output:

NAME                                                              CLUSTER     ...     ISTIOD                           VERSION
details-v1-7b6df9d8c8-s6kg5.bookinfo                              cluster1    ...     istiod-1-17-2-7c8f6fd4c4-m9k9t     1.17.2-solo
istio-eastwestgateway-1-17-2-bdc4fd65f-ftmz9.gloo-mesh-gateways     cluster1    ...     istiod-1-17-2-6495985689-rkwwd     1.17.2-solo
productpage-v1-bb494b7d7-xbtxr.bookinfo                           cluster1    ...     istiod-1-17-2-7c8f6fd4c4-m9k9t     1.17.2-solo
ratings-v1-55b478cfb6-wv2m5.bookinfo                              cluster1    ...     istiod-1-17-2-7c8f6fd4c4-m9k9t     1.17.2-solo
reviews-v1-6dfcc9fc7d-7k6qh.bookinfo                              cluster1    ...     istiod-1-17-2-7c8f6fd4c4-m9k9t     1.17.2-solo
reviews-v2-7dddd799b5-m5n2z.bookinfo                              cluster1    ...     istiod-1-17-2-7c8f6fd4c4-m9k9t     1.17.2-solo

To uninstall the previous installations, or if you need to uninstall the canary installations, you can edit your Helm values file to remove the revision entries from the istioInstallations.controlPlane.installations and istioInstallations.northSouthGateways.installations lists. Then, upgrade your Gloo Mesh Helm release with your updated values file.

In-place upgrades

In an in-place upgrade, Gloo Mesh upgrades your existing control plane or gateway installations. In-place upgrades are triggered when you apply changes to one of the following fields in the istioInstallations section:

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 the auto setting to a specific version. This is because you must also specify hub and revision values, which require a canary upgrade.
istioOperatorSpec.meshConfig values

To update the patch version of Istio or update meshConfig values of the Istio installations:

Follow the steps in this guide to perform a regular upgrade of your Gloo Mesh installation and include your Istio changes in your Helm values file. For example, in a single-cluster setup, you might edit your Helm values file to update the patch version of Istio in the istioInstallations.controlPlane.installations.istioOperatorSpec.tag and istioInstallations.northSouthGateways.installations.istioOperatorSpec.tag fields. After you apply the updates in your Helm upgrade of the gloo-platform chart, Gloo starts an in-place upgrade of the Istio control plane and gateways.

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-eatwestgateway-1-17-2 and istio-ingressgateway-1-17-2 deployments.

kubectl rollout restart -n gloo-mesh-gateways deployment/istio-eastwestgateway-1-17-2 --context $REMOTE_CONTEXT1
kubectl rollout restart -n gloo-mesh-gateways deployment/istio-ingressgateway-1-17-2 --context $REMOTE_CONTEXT1

kubectl rollout restart -n gloo-mesh-gateways deployment/istio-eastwestgateway-1-17-2 --context $REMOTE_CONTEXT2
kubectl rollout restart -n gloo-mesh-gateways deployment/istio-ingressgateway-1-17-2 --context $REMOTE_CONTEXT2

Verify that your Istio resources are updated.

kubectl get all -n gm-iop-1-17-2 --context $REMOTE_CONTEXT1
kubectl get all -n istio-system --context $REMOTE_CONTEXT1
kubectl get all -n gloo-mesh-gateways --context $REMOTE_CONTEXT1

Testing only: Manually replacing the GatewayLifecycleManager CR

If you manage Istio through your main Gloo Mesh Helm chart in testing or demo setups, you can quickly upgrade your Istio service mesh and gateway configurations by manually deleting the IstioLifecycleManager and GatewayLifecycleManager CRs, and upgrading your Gloo Mesh installation with your updated gateway values in your Helm values file. Note that you can also use this method to clear your managed Istio configurations if a canary upgrade becomes stuck.

This method is supported only for testing scenarios, because your istiod control plane and gateways are temporarily removed in this process.

Get the name of your IstioLifecycleManager resource. Typically, this resource is named gloo-platform.
```
kubectl get IstioLifecycleManager -A
```

Delete the resource.

kubectl delete IstioLifecycleManager gloo-platform -n gloo-mesh

Verify that your istiod control plane is removed.
```
kubectl get all -n istio-system
```
Optional: If you also need to make changes to your gateways, clear those configurations.
1. Get the name of your GatewayLifecycleManager resource. Typically, this resource is named istio-eastwestgateway. You might also have an istio-ingressgateway resource, such as if you use Gloo Gateway.
```
kubectl get GatewayLifecycleManager -A
```
2. Delete the resource.
```
kubectl delete GatewayLifecycleManager istio-eastwestgateway -n gloo-mesh
```
```
kubectl delete GatewayLifecycleManager istio-ingressgateway -n gloo-mesh
```
3. Verify that your gateway proxy is removed.
```
kubectl get svc -n gloo-mesh-gateways
```
Follow the steps in this guide to perform a regular upgrade of your Gloo Mesh installation and include your Istio changes in your Helm values file. After you apply the updates in your Helm upgrade of the gloo-platform chart, Gloo re-creates the istiod control plane, and if applicable, the Istio gateways.

After your Helm upgrade completes, verify that your Istio resources are re-created.

# Change the revision as needed
kubectl get all -n gm-iop-1-17-2
kubectl get all -n istio-system
kubectl get all -n gloo-mesh-gateways

Update your Gloo license

Before your Gloo license expires, you can update the license by performing a Helm upgrade. If you use Gloo Mesh along with other Gloo products such as Gloo Gateway and Gloo Network, you can also update those licenses.

For example, if you notice that your Gloo control plane deployments are in a crash loop, your Gloo license might be expired. You can check the logs for one of the deployments, such as the management server, to look for an error message similar to the following:

meshctl logs mgmt --kubecontext ${MGMT_CONTEXT}

{"level":"fatal","ts":1628879186.1552186,"logger":"gloo-mesh-mgmt-server","caller":"cmd/main.go:24","msg":"License is invalid or expired, crashing - license expired", ...

To update your license key in your Gloo installation:

Get a new Gloo license key by contacting your account representative. If you use Gloo Mesh along with other Gloo products such as Gloo Gateway and Gloo Network, make sure to ask for up-to-date license keys for all your products.

Save the new license key as an environment variable.

Gateway
Mesh
Network

export GLOO_GATEWAY_LICENSE_KEY=<new-key-string>

export GLOO_MESH_LICENSE_KEY=<new-key-string>

export GLOO_NETWORK_LICENSE_KEY=<new-key-string>

Perform a regular upgrade of your Gloo installation. During the upgrade, either update the license value in your Helm values file, or provide your new license key in a --set flag in the helm upgrade command. For example, to update your Gloo Mesh license key, either change the value of the licensing.glooMeshLicenseKey setting in your Helm values file, or supply the --set licensing.glooMeshLicenseKey=$GLOO_MESH_LICENSE_KEY flag when you upgrade.
Optional: If your license expired and the management server pods are in a crash loop, restart the management server pods. If you updated the license before expiration, skip this step.
```
kubectl rollout restart -n gloo-mesh deployment/gloo-mesh-mgmt-server --context ${MGMT_CONTEXT}
```

Verify that your license check is now valid, and no errors are reported.

meshctl check --kubecontext ${MGMT_CONTEXT}

Example output:

🟢 License status

INFO  gloo-gateway enterprise license expiration is 25 Aug 24 10:38 CDT
INFO  Valid GraphQL license module found