On this page

Deploy Gloo-managed service meshes

Use Gloo Mesh Core to install and manage Solo Istio service meshes in your clusters for you.

By using Gloo-managed service meshes, you no longer need to manually install and manage the istiod control plane. Instead, you provide the Istio configuration in a Gloo custom resource (CR), and Gloo translates this configuration into managed istiod control plane and gateways in each workload cluster for you.

Before you begin

Follow the quickstart to install the Gloo Mesh Core components.
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.
  info
  For testing environments only, you can deploy a revisionless installation. Revisionless installations permit in-place upgrades, which are quicker than the canary-based upgrades that revisioned installations require. To omit a revision, do not set a revision environment variable. Then in the following sections, you edit the sample IstioLifecycleManager and GatewayLifecycleManager files that you download to remove the revision and gatewayRevision fields. Note that if you deploy multiple Istio installations in the same cluster, only one installation can be revisionless.
```
  export REPO=<repo-key>
export ISTIO_IMAGE=1.19.3-solo
export REVISION=1-19-3
  
```

Single-cluster setup

Use Gloo Mesh Core to install a managed service mesh that runs a hardened Solo Istio version in your cluster.

Prepare an IstioLifecycleManager CR 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/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
  
```
  check_circle
  For testing environments only, you can deploy a revisionless installation by removing the revision field.
4. Apply the IstioLifecycleManager CR to your cluster.
```
  kubectl apply -f istiod-values.yaml
  
```
5. Verify that the istiod pod has a status of Running.
```
  kubectl get pods -n istio-system
  
```
  Example output:
```
  NAME                            READY   STATUS    RESTARTS   AGE
istiod-1-19-3-b65676555-g2vmr   1/1     Running   0          57s
  
```
Optional: Prepare a GatewayLifecycleManager CR 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
  
```
  - You can add cloud provider-specific load balancer annotations to the istioOperatorSpec.components.ingressGateways.k8s section, such as the following AWS annotations:
```
          ...
          k8s:
            service:
              ...
            serviceAnnotations:
              service.beta.kubernetes.io/aws-load-balancer-backend-protocol: ssl
              service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
              service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
              service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
              service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:<cert>"
              service.beta.kubernetes.io/aws-load-balancer-type: external
  
```
  - For testing environments only, you can deploy a revisionless installation by removing the gatewayRevision field.
4. Apply the GatewayLifecycleManager CR to your cluster.
```
  kubectl apply -f ingress-gateway-values.yaml
  
```
5. Verify that the ingress gateway pod 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.
Optional: Prepare a GatewayLifecycleManager CR 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
  
```
  - You can add cloud provider-specific load balancer annotations to the istioOperatorSpec.components.egressGateways.k8s section, such as the following AWS annotations:
```
          ...
          k8s:
            service:
              ...
            serviceAnnotations:
              service.beta.kubernetes.io/aws-load-balancer-backend-protocol: ssl
              service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
              service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
              service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
              service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:<cert>"
              service.beta.kubernetes.io/aws-load-balancer-type: external
  
```
  - For testing environments only, you can deploy a revisionless installation by removing the gatewayRevision field.
4. Apply the GatewayLifecycleManager CR to your cluster.
```
  kubectl apply -f egress-gateway-values.yaml
  
```
5. Verify that the egress gateway pod 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.
Now that Istio is up and running, you can create service namespaces for your teams to run app workloads in. For any namespaces that you want to deploy apps to, be sure to follow these steps to include your services in the service mesh.
1. Label the namespace with the Istio revision so that Istio sidecars deploy to your app pods.
```
  export REVISION=$(kubectl get pod -L app=istiod -n istio-system -o jsonpath='{.items[0].metadata.labels.istio\.io/rev}')
kubectl label ns <namespace> istio.io/rev=$REVISION --overwrite
  
```
  check_circle
  If you deployed revisionless installations in testing environments, you can instead label your workload namespaces with `kubectl label ns istio-injection=enabled`.
2. If you already deployed app pods to the namespace, restart the workloads so that sidecars are injected into the pods. For example, you might roll out a restart to each deployment by using a command similar to the following.
```
  kubectl rollout restart deployment -n <namespace> <deployment>
  
```

Multicluster setup

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

Prepare an IstioLifecycleManager CR 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/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 provide your own details. For more information, see the API reference.
```
  open istiod-values.yaml
  
```
check_circle
For testing environments only, you can deploy a revisionless installation by removing the revision fields.
1. Apply the IstioLifecycleManager CR to your management cluster.
```
  kubectl apply -f istiod-values.yaml --context $MGMT_CONTEXT
  
```
2. In each workload cluster, verify that the Istio pods have a status of Running.
```
  kubectl get pods -n istio-system --context $REMOTE_CONTEXT1
kubectl get pods -n istio-system --context $REMOTE_CONTEXT2
  
```
  Example output:
```
  NAME                            READY   STATUS    RESTARTS   AGE
istiod-1-19-3-b65676555-g2vmr   1/1     Running   0          47s
NAME                            READY   STATUS    RESTARTS   AGE
istiod-1-19-3-7b96cb895-4nzv9   1/1     Running   0          43s
  
```
Optional: Prepare a GatewayLifecycleManager CR 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 provide your own settings. For more information, see the API reference.
```
  open ingress-gateway-values.yaml
  
```
  - You can add cloud provider-specific load balancer annotations to the istioOperatorSpec.components.ingressGateways.k8s section, such as the following AWS annotations:
```
          ...
          k8s:
            service:
              ...
            serviceAnnotations:
              service.beta.kubernetes.io/aws-load-balancer-backend-protocol: ssl
              service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
              service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
              service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
              service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:<cert>"
              service.beta.kubernetes.io/aws-load-balancer-type: external
  
```
  - For testing environments only, you can deploy a revisionless installation by removing the gatewayRevision fields.
4. Apply the GatewayLifecycleManager CR 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 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 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.
Optional: Prepare a GatewayLifecycleManager CR 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 provide your own settings. For more information, see the API reference.
```
  open egress-gateway-values.yaml
  
```
  - You can add cloud provider-specific load balancer annotations to the istioOperatorSpec.components.egressGateways.k8s section, such as the following AWS annotations:
```
          ...
          k8s:
            service:
              ...
            serviceAnnotations:
              service.beta.kubernetes.io/aws-load-balancer-backend-protocol: ssl
              service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
              service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
              service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
              service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:<cert>"
              service.beta.kubernetes.io/aws-load-balancer-type: external
  
```
  - For testing environments only, you can deploy a revisionless installation by removing the gatewayRevision fields.
4. Apply the GatewayLifecycleManager CR 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 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 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.
Now that Istio is up and running, you can create service namespaces for your teams to run app workloads in. For any namespaces that you want to deploy apps to, be sure to follow these steps to include your services in the service mesh.
1. Label the namespace with the Istio revision so that Istio sidecars deploy to your app pods.
```
  export REVISION=$(kubectl get pod -L app=istiod -n istio-system --context $REMOTE_CONTEXT -o jsonpath='{.items[0].metadata.labels.istio\.io/rev}')
kubectl label ns <namespace> istio.io/rev=$REVISION --overwrite --context $REMOTE_CONTEXT
  
```
  check_circle
  If you deployed revisionless installations in testing environments, you can instead label your workload namespaces with `kubectl label ns istio-injection=enabled --context $REMOTE_CONTEXT`.
2. If you already deployed app pods to the namespace, restart the workloads so that sidecars are injected into the pods. For example, you might roll out a restart to each deployment by using a command similar to the following.
```
  kubectl rollout restart deployment -n <namespace> <deployment> --context $REMOTE_CONTEXT
  
```

Next steps

TODO Istio docs for:

deploying gateways
deploying sample apps & basic routing

When it’s time to upgrade Istio, you can use Gloo Mesh Core to upgrade managed Istio installations.

Supported Solo Istio versions

View supported Solo Istio versions and …

Upgrade Gloo-managed service meshes

Use Gloo Mesh Core to upgrade your …

Deploy Gloo-managed service meshes

Before you begin link

Single-cluster setup link

Multicluster setup link

Next steps link

Before you begin

Single-cluster setup

Multicluster setup

Next steps