Take over existing Istio installations

If you already maintain existing Istio installations, you can migrate those installations to the Gloo Mesh Core service mesh lifecycle management system. Then, you can use Gloo to manage the configuration and maintenance of the Istio installations. By using Gloo-managed installations, you no longer need to manually install and manage the istiod control plane in each workload cluster. Instead, you provide the Istio configuration to Gloo, and Gloo translates this configuration into managed istiod control plane for you in the workload clusters.

This process involves creating an IstioLifecycleManager resource that makes use of a different revision than your existing Istio installations. If you do not use revisions, no conflict will exist between the new installations and existing installations. If you do use revisions, be sure to choose a different revision for the new installations than your existing installations. Always test this process in a representative test environment before attempting this process in a production setup.

Before you begin link

1. Follow the quickstart to install the Gloo Mesh Core components.

2. Review Supported versions to choose the Solo Istio version that you want to use, and save the version information in the following environment variables.

   • For REPO, use the Solo Istio repo key that you can get by logging in to the Support Center and reviewing the Istio images built by Solo.io support article.
   • For ISTIO_IMAGE, save the version that you want to use with the solo tag, such as 1.19.3-solo. You can optionally append other Solo Istio tags as needed.
   • For REVISION, take the Istio major and minor version numbers and replace the period with a hyphen, such as 1-19-3. If you use a revision for your existing Istio installations, be sure to use a different revision than the existing one.

     export REPO=<repo-key>
   export ISTIO_IMAGE=1.19.3-solo
   export REVISION=1-19-3
     

3. Install istioctl, the Istio CLI tool.

     curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} sh -
   cd istio-$ISTIO_VERSION
   export PATH=$PWD/bin:$PATH
     

Single-cluster service mesh link

Use Gloo Mesh Core to take over the Istio service mesh in one cluster.

The takeover process follows these general steps:

1. Install a managed service mesh with the same settings as your unmanaged Istio installation. The Gloo control plane installs an Istio service mesh for you in the cluster, which runs a hardened Solo Istio version and a different revision than your existing Istio installation. The managed istiod control plane for the new installation is not active at deployment time.
2. Test the new control plane by deploying workloads with a label for the new revision and generating traffic to those workloads.
3. Change the new control plane to be active, and rollout a restart to data plane workloads so that the new control plane manages them.
4. Update service selectors or update internal/external DNS entries for your Istio gateways.
5. Uninstall the old Istio installation.

Deploy link

Use Gloo Mesh Core to deploy a managed service mesh that replicates the settings from your unmanaged Istio installation.

1. Prepare an IstioLifecycleManager resource to manage the istiod control plane.

   1. Download the example file, istiod.yaml, which contains a basic IstioLifecycleManager configuration for the control plane.

        curl -0L https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-mesh-core/istio-install/managed/single/takeover-istiod.yaml > istiod.yaml
        

   2. Update the example file with the environment variables that you previously set. Save the updated file as istiod-values.yaml.

      • For example, you can run a terminal command to substitute values:

          envsubst < istiod.yaml > istiod-values.yaml
          

   3. Verify that the configuration is correct. You can also further edit the file to provide your own details. For more information, see the API reference.

        open istiod-values.yaml
        

   4. Apply the IstioLifecycleManager resource to your cluster.

        kubectl apply -f istiod-values.yaml
        

   5. Verify that the istiod pod for the new revision has a status of Running. Note that this new, managed control plane is not currently the active Istio installation.

        kubectl get pods -n istio-system
        

      Example output:

        NAME                            READY   STATUS    RESTARTS   AGE
      istiod-1-19-3-b65676555-g2vmr   1/1     Running   0          1m57s
      istiod-1-18-3-yt72566r9-8j5tr   1/1     Running   0          23d
        

2. Optional: Prepare a GatewayLifecycleManager resource to deploy and manage an ingress gateway.

   1. Download the example file, ingress-gateway.yaml, which contains a basic GatewayLifecycleManager configuration for an ingress gateway.

        curl -0L https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-mesh-core/istio-install/managed/single/ingress-gateway.yaml > ingress-gateway.yaml
        

   2. Update the example file with the environment variables that you previously set. Save the updated file as ingress-gateway-values.yaml.

      • For example, you can run a terminal command to substitute values:

          envsubst < ingress-gateway.yaml > ingress-gateway-values.yaml
          

   3. Verify that the configuration is correct. You can also further edit the file to provide your own settings. For more information, see the API reference.

        open ingress-gateway-values.yaml
        

   4. Apply the GatewayLifecycleManager resource to your cluster.

        kubectl apply -f ingress-gateway-values.yaml
        

   5. Verify that the ingress gateway pod for the new revision is running and that the load balancer service has an external address.

        kubectl get pods -n gloo-mesh-gateways
      kubectl get svc -n gloo-mesh-gateways
        

      Example output:

        NAME                                    READY   STATUS    RESTARTS   AGE
      istio-ingressgateway-665d46686f-nhh52   1/1     Running   0          106s
      
      NAME                        TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                         AGE
      istio-ingressgateway        LoadBalancer   10.96.252.49    <externalip>  15021:32378/TCP,80:30315/TCP,443:32186/TCP,31400:30313/TCP,15443:31632/TCP      2m2s
        

      info

      AWS clusters only: For the Elastic Load Balancer (ELB) instance that is automatically created for you to back the ingress gateway service, verify that the health check shows a healthy state. Gloo Mesh Core configures the ingress gateway to listen on HTTPS port 15443. However, when the ELB is created, the first port that is defined in the Kubernetes service manifest is used to perform the health check. This port might be different from the port that Gloo configures. For your ELB health check to pass, you might need to configure the load balancer to run the health check on port 15443.

3. Optional: Prepare a GatewayLifecycleManager resource to deploy and manage an egress gateway.

   1. Download the example file, egress-gateway.yaml, which contains a basic GatewayLifecycleManager configuration for an egress gateway.

        curl -0L https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-mesh-core/istio-install/managed/single/egress-gateway.yaml > egress-gateway.yaml
        

   2. Update the example file with the environment variables that you previously set. Save the updated file as egress-gateway-values.yaml.

      • For example, you can run a terminal command to substitute values:

          envsubst < egress-gateway.yaml > egress-gateway-values.yaml
          

   3. Verify that the configuration is correct. You can also further edit the file to provide your own settings. For more information, see the API reference.

        open egress-gateway-values.yaml
        

   4. Apply the GatewayLifecycleManager resource to your cluster.

        kubectl apply -f egress-gateway-values.yaml
        

   5. Verify that the egress gateway pod for the new revision is running and that the load balancer service has an external address.

        kubectl get pods -n gloo-mesh-gateways
      kubectl get svc -n gloo-mesh-gateways
        

      Example output for one cluster:

        NAME                                    READY   STATUS    RESTARTS   AGE
      istio-egressgateway-665d46686f-nhh52    1/1     Running   0          106s
      
      NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                         AGE
      istio-egressgateway        LoadBalancer   10.96.252.49    <externalip>  15021:32378/TCP,80:30315/TCP,443:32186/TCP,31400:30313/TCP,15443:31632/TCP      2m2s
        

      info

      AWS clusters only: For the Elastic Load Balancer (ELB) instance that is automatically created for you to back the ingress gateway service, verify that the health check shows a healthy state. Gloo Mesh Core configures the ingress gateway to listen on HTTPS port 15443. However, when the ELB is created, the first port that is defined in the Kubernetes service manifest is used to perform the health check. This port might be different from the port that Gloo configures. For your ELB health check to pass, you might need to configure the load balancer to run the health check on port 15443.

Test link

Test the new managed service mesh by deploying the Istio sample app, Bookinfo, and updating its sidecars from the old revision to the new.

1. Create the bookinfo namespace.

     kubectl create ns bookinfo
     

2. Label the namespace for Istio injection with the old revision so that the old revision’s control plane manages the services.

     kubectl label ns bookinfo istio.io/rev=<old_revision>
     

   check_circle

   If you did not previously use revision labels for your apps, you can instead run kubectl label ns bookinfo istio-injection.

3. Deploy the Bookinfo app.

     # deploy bookinfo app components for all versions less than v3
   kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/1.19.3/samples/bookinfo/platform/kube/bookinfo.yaml -l 'app,version notin (v3)'
   # deploy an updated product page with extra container utilities such as 'curl' and 'netcat'
   kubectl -n bookinfo apply -f https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/policy-demo/productpage-with-curl.yaml
   # deploy all bookinfo service accounts
   kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/1.19.3/samples/bookinfo/platform/kube/bookinfo.yaml -l 'account'
     

4. Verify that the Bookinfo app deployed successfully.

     kubectl get pods -n bookinfo
   kubectl get svc -n bookinfo
     

5. Verify that Bookinfo still points to the old revision.

     istioctl proxy-status | grep "\.bookinfo "
     

   In this example output, the Bookinfo apps still point to the existing Istio installation that uses version 1.18.3.

     NAME                                                              CLUSTER   ...  ISTIOD                           VERSION
   details-v1-6758dd9d8d-rh4db.bookinfo                              cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
   productpage-v1-b4cf67f67-s5lsh.bookinfo                           cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
   ratings-v1-f849dc6d-wqdc8.bookinfo                                cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
   reviews-v1-74fb8fdbd8-z8bzc.bookinfo                              cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
   reviews-v2-58d564d4db-g8jzr.bookinfo                              cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
     

6. Prepare any testing to confirm that the Bookinfo apps are still available when you update the apps’ sidecars to use the new revision. For example, if you have an ingress gateway load balancer in your environment, you might follow these steps to ensure you can access Bookinfo:

   1. Apply Istio gateway and virtual service resources to expose the Bookinfo app.

        kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/1.19.3/samples/bookinfo/networking/bookinfo-gateway.yaml
        

   2. Get the address for your existing ingress gateway, and send a request to the productpage service.

        curl http://<gateway_address>:80/productpage
        

7. Test the transition to the new installation on Bookinfo by changing the label on the bookinfo namespace to use the new revision.

     kubectl label ns bookinfo istio.io/rev=$REVISION --overwrite
     

   check_circle

   If you did not previously use revision labels for your apps, you can instead run kubectl label ns bookinfo istio-injection- and kubectl label ns bookinfo istio.io/rev=$REVISION.

8. Update Bookinfo by rolling out restarts to each of the microservices. The Istio sidecars for each microservice update to use the new Istio version. Make sure that you only restart one microservice at a time. For example, in the following commands, 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 ratings-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
     

9. Verify that the Bookinfo pods now use the new revision.

     istioctl proxy-status | grep "\.bookinfo "
     

10. If you exposed Bookinfo, verify that the productpage for Bookinfo is now reachable after the upgrade through the new ingress gateway.

    1. Save the external address of the ingress gateway that runs the new revision.

         export INGRESS_GW_IP=$(kubectl get svc -n gloo-mesh-gateways istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
       echo $INGRESS_GW_IP
         

         export INGRESS_GW_IP=$(kubectl get svc -n gloo-mesh-gateways istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
       echo $INGRESS_GW_IP
         

    2. Send a request to the productpage service.

         open http://$INGRESS_GW_IP/productpage
         

Activate link

After you finish testing, change the new control plane to be active, and rollout a restart to data plane workloads so that the new control plane manages them. You can also optionally uninstall the old Istio installation.

1. In your IstioLifecycleManager resource, switch to the new istiod control plane revision by changing defaultRevision to true.

     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:
          - revision: 1-19-3
            clusters:
            - name: cluster1
              # Set this field to TRUE
              defaultRevision: true
            istioOperatorSpec:
              profile: minimal
              ...
      

2. Roll out a restart to your workload apps so that the new control plane manages them.

   1. Change the label on any Istio-managed namespaces to use the new revision.

        kubectl label ns <namespace> istio.io/rev=$REVISION --overwrite
        

      check_circle

      If you did not previously use revision labels for your apps, you can instead run kubectl label ns [namespace] istio-injection- and kubectl label ns [namespace] istio.io/rev=$REVISION.
   2. Update any Istio-managed apps by rolling out restarts. The Istio sidecars for each microservice update to use the new Istio version. Make sure that you only restart one microservice at a time.
   3. Verify that your workloads point to the new revision.

        istioctl proxy-status
        

3. If you use any gateways, you can either update the service selectors for your load balancers to point to the new revision, or update your DNS entries to point to the addresses of the new gateways.

4. Uninstall the old Istio installation. The uninstallation process varies depending on your original installation method. For more information, see the Istio documentation.

Multicluster service mesh link

Install the Gloo Mesh Core components and take over the Istio service mesh across multiple clusters.

The takeover process follows these general steps:

1. Install managed service meshes with the same settings as your unmanaged Istio installations. You create an IstioLifecycleManager resource in the management cluster that uses a different revision than the existing Istio installations in your workload clusters. Gloo then deploys istiod control planes for the new revision to each workload cluster, but the new, managed control planes are not active at deployment time.
2. Test the new control plane and gateways by deploying workloads with a label for the new revision and generating traffic to those workloads.
3. Change the new control planes to be active, and rollout a restart to data plane workloads so that the new control planes manage them.
4. Update service selectors or update internal/external DNS entries to point to the new gateways.
5. Uninstall the old Istio installations.

Deploy link

Use Gloo Mesh Core to deploy and manage Istio service meshes in each workload cluster.

1. Prepare an IstioLifecycleManager resource to manage istiod control planes.

   1. Download the example file, istiod.yaml, which contains a basic IstioLifecycleManager configuration for the control plane.

        curl -0L https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-mesh-core/istio-install/managed/multi/takeover-istiod.yaml > istiod.yaml
        

   2. Update the example file with the environment variables that you previously set. Save the updated file as istiod-values.yaml.

      • For example, you can run a terminal command to substitute values:

          envsubst < istiod.yaml > istiod-values.yaml
          

   3. Verify that the configuration is correct. For example, in spec.installations.clusters, verify that entries exist for each workload cluster name. You can also further edit the file to replicate the settings in your existing Istio installation. For more information, see the API reference.

        open istiod-values.yaml
        

   4. Apply the IstioLifecycleManager resource to your management cluster.

        kubectl apply -f istiod-values.yaml --context $MGMT_CONTEXT
        

   5. In each workload cluster, verify that the istiod pod for the new revision has a status of Running. Note that these new, managed control planes are not currently the active Istio installations.

        kubectl get pods -n istio-system --context $REMOTE_CONTEXT1
      kubectl get pods -n istio-system --context $REMOTE_CONTEXT2
        

      Example output for one cluster:

        NAME                            READY   STATUS    RESTARTS   AGE
      istiod-1-19-3-b65676555-g2vmr   1/1     Running   0          1m57s
      istiod-1-18-3-yt72566r9-8j5tr   1/1     Running   0          23d
        

2. Optional: Prepare a GatewayLifecycleManager resource to deploy and manage ingress gateways.

   1. Download the example file, ingress-gateway.yaml, which contains a basic GatewayLifecycleManager configuration for an ingress gateway.

        curl -0L https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-mesh-core/istio-install/managed/multi/ingress-gateway.yaml > ingress-gateway.yaml
        

   2. Update the example file with the environment variables that you previously set. Save the updated file as ingress-gateway-values.yaml.

      • For example, you can run a terminal command to substitute values:

          envsubst < ingress-gateway.yaml > ingress-gateway-values.yaml
          

   3. Verify that the configuration is correct. For example, in spec.installations.clusters, verify that entries exist for each workload cluster name. You can also further edit the file to replicate the settings in your existing Istio installation. For more information, see the API reference.

        open ingress-gateway-values.yaml
        

   4. Apply the GatewayLifecycleManager resource to your management cluster.

        kubectl apply -f ingress-gateway-values.yaml --context $MGMT_CONTEXT
        

   5. In each workload cluster, verify that the ingress gateway pods for the new revision in the gloo-mesh-gateways namespace are running.

        kubectl get pods -n gloo-mesh-gateways --context $REMOTE_CONTEXT1
      kubectl get pods -n gloo-mesh-gateways --context $REMOTE_CONTEXT2
        

      Example output for one cluster:

        NAME                                    READY   STATUS    RESTARTS   AGE
      istio-ingressgateway-665d46686f-nhh52   1/1     Running   0          106s
        

   6. In each workload cluster, verify that the load balancer service for the new revision has an external address.

        kubectl get svc -n gloo-mesh-gateways --context $REMOTE_CONTEXT1
      kubectl get svc -n gloo-mesh-gateways --context $REMOTE_CONTEXT2
        

      Example output for one cluster:

        NAME                        TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                                                      AGE
      istio-ingressgateway        LoadBalancer   10.96.252.49    <externalip>  15021:32378/TCP,80:30315/TCP,443:32186/TCP,31400:30313/TCP,15443:31632/TCP                                   2m2s
        

      info

      AWS clusters only: For the Elastic Load Balancer (ELB) instance that is automatically created for you to back the ingress gateway service, verify that the health check shows a healthy state. Gloo Mesh Core configures the ingress gateway to listen on HTTPS port 15443. However, when the ELB is created, the first port that is defined in the Kubernetes service manifest is used to perform the health check. This port might be different from the port that Gloo configures. For your ELB health check to pass, you might need to configure the load balancer to run the health check on port 15443.

3. Optional: Prepare a GatewayLifecycleManager resource to deploy and manage egress gateways.

   1. Download the example file, egress-gateway.yaml, which contains a basic GatewayLifecycleManager configuration for an egress gateway.

        curl -0L https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-mesh-core/istio-install/managed/multi/egress-gateway.yaml > egress-gateway.yaml
        

   2. Update the example file with the environment variables that you previously set. Save the updated file as egress-gateway-values.yaml.

      • For example, you can run a terminal command to substitute values:

          envsubst < egress-gateway.yaml > egress-gateway-values.yaml
          

   3. Verify that the configuration is correct. For example, in spec.installations.clusters, verify that entries exist for each workload cluster name. You can also further edit the file to replicate the settings in your existing Istio installation. For more information, see the API reference.

        open egress-gateway-values.yaml
        

   4. Apply the GatewayLifecycleManager resource to your management cluster.

        kubectl apply -f egress-gateway-values.yaml --context $MGMT_CONTEXT
        

   5. In each workload cluster, verify that the egress gateway pods for the new revision in the gloo-mesh-gateways namespace are running.

        kubectl get pods -n gloo-mesh-gateways --context $REMOTE_CONTEXT1
      kubectl get pods -n gloo-mesh-gateways --context $REMOTE_CONTEXT2
        

      Example output for one cluster:

        NAME                                   READY   STATUS    RESTARTS   AGE
      istio-egressgateway-665d46686f-nhh52   1/1     Running   0          106s
        

   6. In each workload cluster, verify that the load balancer service for the new revision has an external address.

        kubectl get svc -n gloo-mesh-gateways --context $REMOTE_CONTEXT1
      kubectl get svc -n gloo-mesh-gateways --context $REMOTE_CONTEXT2
        

      Example output for one cluster:

        NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                                                      AGE
      istio-egressgateway        LoadBalancer   10.96.252.49    <externalip>  15021:32378/TCP,80:30315/TCP,443:32186/TCP,31400:30313/TCP,15443:31632/TCP                                   2m2s
        

      info

      AWS clusters only: For the Elastic Load Balancer (ELB) instance that is automatically created for you to back the ingress gateway service, verify that the health check shows a healthy state. Gloo Mesh Core configures the ingress gateway to listen on HTTPS port 15443. However, when the ELB is created, the first port that is defined in the Kubernetes service manifest is used to perform the health check. This port might be different from the port that Gloo configures. For your ELB health check to pass, you might need to configure the load balancer to run the health check on port 15443.

Test link

Test the new Istio installation by deploying the Istio sample app, Bookinfo, and updating its sidecars from the old revision to the new.

1. Create the bookinfo namespace in one workload cluster.

     kubectl create ns bookinfo --context $REMOTE_CONTEXT1
     

2. Label the namespaces for Istio injection with the old revision so that the old revision’s control plane manages the services.

     kubectl label ns bookinfo istio.io/rev=<old_revision> --context $REMOTE_CONTEXT1
     

   check_circle

   If you did not previously use revision labels for your apps, you can instead run kubectl label ns bookinfo istio-injection --context $REMOTE_CONTEXT1.

3. Deploy the Bookinfo app to your workload cluster.

     # deploy bookinfo app components for all versions less than v3
   kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/1.19.3/samples/bookinfo/platform/kube/bookinfo.yaml -l 'app,version notin (v3)' --context $REMOTE_CONTEXT1
   # deploy an updated product page with extra container utilities such as 'curl' and 'netcat'
   kubectl -n bookinfo apply -f https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/policy-demo/productpage-with-curl.yaml --context $REMOTE_CONTEXT1
   # deploy all bookinfo service accounts
   kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/1.19.3/samples/bookinfo/platform/kube/bookinfo.yaml -l 'account' --context $REMOTE_CONTEXT1
     

4. Verify that the Bookinfo app deployed successfully.

     kubectl get pods -n bookinfo --context $REMOTE_CONTEXT1
     

5. Verify that Bookinfo still points to the old revision.

     istioctl proxy-status --context $REMOTE_CONTEXT1 | grep "\.bookinfo "
     

   In this example output, the Bookinfo apps in cluster1 still point to the existing Istio installation that uses version 1.18.3.

     NAME                                                              CLUSTER   ...  ISTIOD                           VERSION
   details-v1-6758dd9d8d-rh4db.bookinfo                              cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
   productpage-v1-b4cf67f67-s5lsh.bookinfo                           cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
   ratings-v1-f849dc6d-wqdc8.bookinfo                                cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
   reviews-v1-74fb8fdbd8-z8bzc.bookinfo                              cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
   reviews-v2-58d564d4db-g8jzr.bookinfo                              cluster1  ...  istiod-66d54b865-6b6zt           1.18.3
     

6. Prepare any testing to confirm that the Bookinfo apps are still available when you update the apps’ sidecars to use the new revision. For example, if you have an ingress gateway load balancer in your environment, you might follow these steps to ensure you can access Bookinfo:

   1. Apply Istio gateway and virtual service resources to expose the Bookinfo app.

        kubectl --context $REMOTE_CONTEXT1 -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/1.19.3/samples/bookinfo/networking/bookinfo-gateway.yaml
        

   2. Get the address for your existing ingress gateway, and send a request to the productpage service.

        curl http://<gateway_address>:80/productpage
        

7. Test the transition to the new installation on Bookinfo by changing the label on the bookinfo namespace to use the new revision.

     kubectl label ns bookinfo istio.io/rev=$REVISION --overwrite --context $REMOTE_CONTEXT1
     

   check_circle

   If you did not previously use revision labels for your apps, you can instead run kubectl label ns bookinfo istio-injection- --context $REMOTE_CONTEXT1 and kubectl label ns bookinfo istio.io/rev=$REVISION --context $REMOTE_CONTEXT1.

8. Update Bookinfo by rolling out restarts to each of the microservices. The Istio sidecars for each microservice update to use the new Istio version. Make sure that you only restart one microservice at a time. For example, in the following commands, 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
     

9. Verify that the Bookinfo pods now use the new revision.

     istioctl proxy-status --context $REMOTE_CONTEXT1 | grep "\.bookinfo "
     

10. If you exposed Bookinfo, verify that the productpage for Bookinfo is now reachable after the upgrade through the new ingress gateway.

    1. Save the external address of the ingress gateway that runs the new revision.

         export INGRESS_GW_IP=$(kubectl get svc -n gloo-mesh-gateways istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') --context $REMOTE_CONTEXT1
       echo $INGRESS_GW_IP
         

         export INGRESS_GW_IP=$(kubectl get svc -n gloo-mesh-gateways istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}') --context $REMOTE_CONTEXT1
       echo $INGRESS_GW_IP
         

    2. Send a request to the productpage service.

         open http://$INGRESS_GW_IP/productpage
         

Activate link

After you finish testing, change the new control plane to be active, and rollout a restart to data plane workloads so that the new control plane manages them. You can also optionally uninstall the old Istio installation.

1. In your IstioLifecycleManager resource, switch to the new istiod control plane revision by changing defaultRevision to true.

     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:
          - revision: 1-19-3
            clusters:
            - name: cluster1
              # Set this field to TRUE
              defaultRevision: true
            - name: cluster2
              # Set this field to TRUE
              defaultRevision: true
            istioOperatorSpec:
              profile: minimal
              ...
      

2. In each workload cluster, roll out a restart to your workload apps so that the new control planes manage them.

   1. Change the label on any Istio-managed namespaces to use the new revision.

        kubectl label ns <namespace> istio.io/rev=$REVISION --overwrite --context $REMOTE_CONTEXT1
      kubectl label ns <namespace> istio.io/rev=$REVISION --overwrite --context $REMOTE_CONTEXT2
        

      check_circle

      If you did not previously use revision labels for your apps, you can instead run kubectl label ns [namespace] istio-injection- --context $REMOTE_CONTEXT1 and kubectl label ns [namespace] istio.io/rev=$REVISION --context $REMOTE_CONTEXT1.
   2. Update any Istio-managed apps by rolling out restarts. The Istio sidecars for each microservice update to use the new Istio version. Make sure that you only restart one microservice at a time.
   3. Verify that your workloads and new gateways point to the new revision.

        istioctl proxy-status --context $REMOTE_CONTEXT1
      istioctl proxy-status --context $REMOTE_CONTEXT2
        

3. If you use any gateways, you can either update the service selectors for your load balancers to point to the new revision, or update your DNS entries to point to the addresses of the new gateways.

4. Uninstall the old Istio installations. The uninstallation process varies depending on your original installation method. For more information, see the Istio documentation.

Next steps link

When it’s time to upgrade to a new version or change Istio settings, you can use Gloo Mesh Core to upgrade your managed service meshes.