Overview

In a multicluster setup, you install the Gloo management plane and gateway proxy in separate clusters.

  • Gloo management plane: When you install the Gloo management plane in a dedicated management cluster, a deployment named gloo-mesh-mgmt-server is created to translate and implement your Gloo configurations.
  • Data plane: Set up one or more workload clusters that are registered with and managed by the Gloo management plane in the management cluster. A deployment named gloo-mesh-agent is created to run the Gloo agent in each workload cluster. Additionally, you use the Gloo management plane to install an ingress gateway proxy in each workload cluster, as part of the Istio lifecycle management. By using Gloo-managed installations, you no longer need to manually install and manage the istiod control plane and gateway proxy in each workload cluster. Instead, you provide the Istio configuration in your gloo-platform Helm chart, and Gloo translates this configuration into managed istiod control plane and gateway proxies in the clusters.

Before you begin

  1. Install the following command-line (CLI) tools.

    • kubectl, the Kubernetes command line tool. Download the kubectl version that is within one minor version of the Kubernetes clusters you plan to use.
    • meshctl, the Solo command line tool.
        curl -sL https://run.solo.io/meshctl/install | GLOO_MESH_VERSION=v2.5.12 sh -
export PATH=$HOME/.gloo-mesh/bin:$PATH

  2. Set your Gloo Mesh Gateway license key as an environment variable. If you do not have one, contact an account representative. If you prefer to specify license keys in a secret instead, see Licensing. To check your license’s validity, you can run meshctl license check --key $(echo ${GLOO_MESH_GATEWAY_LICENSE_KEY} | base64 -w0).

      export GLOO_MESH_GATEWAY_LICENSE_KEY=<license_key>

  3. Set the Gloo Mesh Gateway version. This example uses the latest version. You can find other versions in the Changelog documentation. Append -fips for a FIPS-compliant image, such as 2.5.12-fips. Do not include v before the version number.

      export GLOO_VERSION=2.5.12

  4. Create or use at least two existing Kubernetes clusters. The instructions in this guide assume one management cluster and two workload clusters. The cluster name must be alphanumeric with no special characters except a hyphen (-), lowercase, and begin with a letter (not a number).

  5. For quick installations, such as for testing environments, you can install with meshctl. To customize your installation in detail, such as for production environments, install with Helm.

  6. Running your own Prometheus server: In Gloo version 2.5.0, the prometheus.io/port: "<port_number>" annotation was removed from the Gloo management server and agent. However, the prometheus.io/scrape: true annotation is still present. If you have another Prometheus instance that runs in your cluster, and it is not set up with custom scraping jobs for the Gloo management server and agent, the instance automatically scrapes all ports on the management server and agent pods. This can lead to error messages in the management server and agent logs. Note that this issue is resolved in version 2.5.2. To view your options to resolve this issue, see Run another Prometheus instance alongside the built-in one. Note that this issue is resolved in version 2.5.2.

Install with meshctl

Quickly install Gloo Mesh Gateway by using meshctl, such as for testing purposes.

Management plane

Deploy the Gloo management plane into a dedicated management cluster.

  1. Install the Gloo management plane in your management cluster. This command uses a basic profile to create a gloo-mesh namespace and install the management plane components, such as the management server and Prometheus server, in your management cluster.

      meshctl install --profiles mgmt-server \
  --kubecontext $MGMT_CONTEXT \
  --set common.cluster=$MGMT_CLUSTER \
  --set licensing.glooGatewayLicenseKey=$GLOO_MESH_GATEWAY_LICENSE_KEY

    Note:

    • Need to use OpenShift routes instead of load balancer service types? Follow the OpenShift steps in the Helm section instead.
    • In OpenShift 4.11 and later, you might see warnings for the pods and containers which violate the OpenShift PodSecurity "restricted:v1.24" profile, due to the elevated permissions required by Istio. You can ignore these warnings. For more info, see this article.
    1. Elevate the permission for the gloo-mesh service account. The telemetry collector agent requires the hostmount-anyuid permission to read the varlogpods, varlibdockercontainers, and cilium-run volumes.
        oc adm policy add-scc-to-group hostmount-anyuid system:serviceaccounts:gloo-mesh --context $MGMT_CONTEXT
    2. Install the Gloo management plane in the management cluster.
        meshctl install --profiles mgmt-server-openshift \
  --kubecontext $MGMT_CONTEXT \
  --set common.cluster=$MGMT_CLUSTER \
  --set licensing.glooGatewayLicenseKey=$GLOO_MESH_GATEWAY_LICENSE_KEY

  2. Verify that the management plane pods have a status of Running.

      kubectl get pods -n gloo-mesh --context $MGMT_CONTEXT

    Example output:

      NAME                                      READY   STATUS    RESTARTS   AGE
gloo-mesh-mgmt-server-56c495796b-cx687    1/1     Running   0          30s
gloo-mesh-redis-8455d49c86-f8qhw          1/1     Running   0          30s
gloo-mesh-ui-65b6b6df5f-bf4vp             3/3     Running   0          30s
gloo-telemetry-collector-agent-7rzfb      1/1     Running   0          30s
gloo-telemetry-gateway-6547f479d5-r4zm6   1/1     Running   0          30s
prometheus-server-57cd8c74d4-2bc7f        2/2     Running   0          30s

  3. Save the external address and port that your cloud provider assigned to the Gloo OpenTelemetry (OTel) gateway service. The OTel collector agents in each workload cluster send metrics to this address.

      export TELEMETRY_GATEWAY_IP=$(kubectl get svc -n gloo-mesh gloo-telemetry-gateway --context $MGMT_CONTEXT -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
export TELEMETRY_GATEWAY_PORT=$(kubectl get svc -n gloo-mesh gloo-telemetry-gateway --context $MGMT_CONTEXT -o jsonpath='{.spec.ports[?(@.name=="otlp")].port}')
export TELEMETRY_GATEWAY_ADDRESS=${TELEMETRY_GATEWAY_IP}:${TELEMETRY_GATEWAY_PORT}
echo $TELEMETRY_GATEWAY_ADDRESS
    1. Expose the telemetry gateway by using an OpenShift route. Your route might look like the following.
        oc apply --context $MGMT_CONTEXT -n gloo-mesh -f- <<EOF
kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: gloo-telemetry-gateway
  namespace: gloo-mesh
spec:
  host: gloo-telemetry-gateway.<your_domain>.com
  to:
    kind: Service
    name: gloo-telemetry-gateway
    weight: 100
  port:
    targetPort: otlp
  tls:
    termination: passthrough
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None
EOF
    2. Save the telemetry gateway’s address, which consists of the route host and the route port. Note that the port is the route’s own port, such as 443, and not the otlp port of the telemetry gateway that the route points to.
        export TELEMETRY_GATEWAY_HOST=$(oc get route -n gloo-mesh gloo-telemetry-gateway --context $MGMT_CONTEXT -o jsonpath='{.status.ingress[0].host}')
export TELEMETRY_GATEWAY_ADDRESS=${TELEMETRY_GATEWAY_HOST}:443
echo $TELEMETRY_GATEWAY_ADDRESS

  4. Create a workspace that selects all clusters and namespaces by default, and workspace settings that enable communication across clusters. Gloo workspaces let you organize team resources across Kubernetes namespaces and clusters. In this example, you create a global workspace that imports and exports all resources and namespaces, and a workspace settings resource in the gloo-mesh-config namespace. Later, as your teams grow, you can create a workspace for each team, to enforce service isolation, set up federation, and even share resources by importing and exporting.

      kubectl apply --context $MGMT_CONTEXT -f- <<EOF
apiVersion: admin.gloo.solo.io/v2
kind: Workspace
metadata:
  name: $MGMT_CLUSTER
  namespace: gloo-mesh
spec:
  workloadClusters:
    - name: '*'
      namespaces:
        - name: '*'
---
apiVersion: v1
kind: Namespace
metadata:
  name: gloo-mesh-config
---
apiVersion: admin.gloo.solo.io/v2
kind: WorkspaceSettings
metadata:
  name: $MGMT_CLUSTER
  namespace: gloo-mesh-config
spec:
  options:
    serviceIsolation:
      enabled: false
    federation:
      enabled: false
      serviceSelector:
      - {}
    eastWestGateways:
    - selector:
        labels:
          istio: eastwestgateway
EOF

Data plane

Register each workload cluster with the Gloo management plane by deploying Gloo data plane components. A deployment named gloo-mesh-agent runs the Gloo agent in each workload cluster.

  1. Register both workload clusters with the management server. These commands use basic profiles to install the Gloo agent, rate limit server, and external auth server in each workload cluster.
      meshctl cluster register $REMOTE_CLUSTER1 \
--kubecontext $MGMT_CONTEXT \
--remote-context $REMOTE_CONTEXT1 \
--profiles agent,ratelimit,extauth \
--telemetry-server-address $TELEMETRY_GATEWAY_ADDRESS

meshctl cluster register $REMOTE_CLUSTER2 \
--kubecontext $MGMT_CONTEXT \
--remote-context $REMOTE_CONTEXT2 \
--profiles agent,ratelimit,extauth \
--telemetry-server-address $TELEMETRY_GATEWAY_ADDRESS
    1. Elevate the permissions for the gloo-mesh service account. The telemetry collector agent requires the hostmount-anyuid permission to read the varlogpods, varlibdockercontainers, and cilium-run volumes.
        oc adm policy add-scc-to-group hostmount-anyuid system:serviceaccounts:gloo-mesh --context $REMOTE_CONTEXT1
oc adm policy add-scc-to-group hostmount-anyuid system:serviceaccounts:gloo-mesh --context $REMOTE_CONTEXT2
    2. Register the workload clusters.
        meshctl cluster register $REMOTE_CLUSTER1 \
 --kubecontext $MGMT_CONTEXT \
 --remote-context $REMOTE_CONTEXT1 \
 --profiles agent-openshift,ratelimit,extauth \
 --version $GLOO_VERSION \
 --telemetry-server-address $TELEMETRY_GATEWAY_ADDRESS

meshctl cluster register $REMOTE_CLUSTER2 \
 --kubecontext $MGMT_CONTEXT \
 --remote-context $REMOTE_CONTEXT2 \
 --profiles agent-openshift,ratelimit,extauth \
 --version $GLOO_VERSION \
 --telemetry-server-address $TELEMETRY_GATEWAY_ADDRESS

    Note: In OpenShift 4.11 and later, you might see warnings for the pods and containers which violate the OpenShift PodSecurity "restricted:v1.24" profile, due to the elevated permissions required by Istio. You can ignore these warnings. For more info, see this article.

  2. Verify that the Gloo data plane components in each workload cluster are healthy. If not, try debugging the agent.

      meshctl check --kubecontext $REMOTE_CONTEXT1
meshctl check --kubecontext $REMOTE_CONTEXT2

    Example output:

      🟢 Gloo deployment status

Namespace | Name                           | Ready | Status
gloo-mesh | ext-auth-service               | 1/1   | Healthy
gloo-mesh | gloo-mesh-agent                | 1/1   | Healthy
gloo-mesh | gloo-telemetry-collector-agent | 3/3   | Healthy
gloo-mesh | rate-limiter                   | 1/1   | Healthy

  3. Verify that your Gloo Mesh Gateway setup is correctly installed. If not, try debugging the relay connection. Note that this check might take a few seconds to verify that:

    • Your Gloo product licenses are valid and current.
    • The Gloo CRDs are installed at the correct version.
    • The management plane pods in the management cluster are running and healthy.
    • The agents in the workload clusters are successfully identified by the management server.
      meshctl check --kubecontext $MGMT_CONTEXT

    Example output:

      🟢 License status

INFO  gloo-gateway enterprise license expiration is 25 Aug 24 10:38 CDT

🟢 CRD version check

🟢 Gloo deployment status

Namespace | Name                           | Ready | Status
gloo-mesh | gloo-mesh-mgmt-server          | 1/1   | Healthy
gloo-mesh | gloo-mesh-redis                | 1/1   | Healthy
gloo-mesh | gloo-mesh-ui                   | 1/1   | Healthy
gloo-mesh | gloo-telemetry-collector-agent | 3/3   | Healthy
gloo-mesh | gloo-telemetry-gateway         | 1/1   | Healthy
gloo-mesh | prometheus-server              | 1/1   | Healthy

🟢 Mgmt server connectivity to workload agents

Cluster  | Registered | Connected Pod                                   
cluster1 | true       | gloo-mesh/gloo-mesh-mgmt-server-65bd557b95-v8qq6
cluster2 | true       | gloo-mesh/gloo-mesh-mgmt-server-65bd557b95-v8qq6

Connected Pod                                    | Clusters
gloo-mesh/gloo-mesh-mgmt-server-65bd557b95-v8qq6 | 2

Gateway proxies

Deploy gateway proxies in each workload cluster.

Install with Helm

Customize your Gloo Mesh Gateway setup by installing with the Gloo Platform Helm chart. For more information, see the Gloo Helm chart overview.

Management plane

Deploy the Gloo management plane into a dedicated management cluster.

  1. Production installations: Review Best practices for production to prepare your optional security measures. For example, before you begin your Gloo installation, you can provide your own certificates to secure the management server and agent connection, and set up secure access to the Gloo UI.

  2. Install helm, the Kubernetes package manager.

  3. Save the name and kubeconfig context for your management cluster in environment variables.

      export MGMT_CLUSTER=<management-cluster-name>
export MGMT_CONTEXT=<management-cluster-context>

  4. Add and update the Helm repository for Gloo.

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

  5. Install the Gloo CRDs.

      helm upgrade -i gloo-platform-crds gloo-platform/gloo-platform-crds \
   --namespace=gloo-mesh \
   --create-namespace \
   --version=$GLOO_VERSION \
   --kube-context $MGMT_CONTEXT
  6. Prepare a Helm values file to provide your customizations. To get started, you can use the minimum settings in the following profile as a basis. These settings enable all components that are required for a Gloo management plane installation.
      curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/mgmt-server.yaml > mgmt-plane.yaml
open mgmt-plane.yaml
  
      curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/mgmt-server-openshift.yaml > mgmt-plane.yaml
open mgmt-plane.yaml

    Note: In OpenShift 4.11 and later, you might see warnings for the pods and containers which violate the OpenShift PodSecurity "restricted:v1.24" profile, due to the elevated permissions required by Istio. You can ignore these warnings. For more info, see this article.

  7. Decide how you want to secure the relay connection between the Gloo management server and agents. In test and POC environments, you can use self-signed certificates to secure the connection. If you plan to use Gloo Mesh Gateway in production, it is recommended to bring your own certificates instead. For more information, see Setup options.

    Use your preferred PKI provider to generate your root CA and intermediate CA credentials. You then store the intermediate CA credentials in your cluster so that you can leverage Gloo Mesh Gateway’s built-in capability to automatically issue and sign client TLS certificates for Gloo agents. For more information, see the Bring your own CAs with automatic client TLS certificate rotation.

    1. Create your root CA, intermediate CA, server, and telemetry gateway credentials, as well as relay identity token, and store them as the following Kubernetes secrets in the gloo-mesh namespace on the management cluster:

      • relay-root-tls-secret that holds the root CA certificate
      • relay-tls-signing-secret that holds the intermediate CA credentials
      • relay-server-tls-secret that holds the server key, TLS certificate and certificate chain information for the Gloo management server
      • relay-identity-token-secret that holds the relay identity token value
      • telemetry-root-secret that holds the root CA certificate for the certificate chain
      • gloo-telemetry-gateway-tls-secret that holds the key, TLS certificate and certificate chain for the Gloo telemetry gateway

      You can use your preferred PKI provider to create the TLS certificates or follow the steps in BYO server certificate with managed client certificate to create these TLS credentials with OpenSSl.

    2. In your Helm values file for the management server, add the following values.

        
glooMgmtServer:
  enabled: true
  relay:
    disableCaCertGeneration: true
    signingTlsSecret:
      name: relay-tls-signing-secret
      namespace: gloo-mesh
    tlsSecret:
      name: relay-server-tls-secret
      namespace: gloo-mesh
    tokenSecret:
      key: token
      name: relay-identity-token-secret
      namespace: gloo-mesh
telemetryCollector: 
  enabled: true
  extraVolumes: 
    - name: root-ca
      secret:
        defaultMode: 420
        optional: true
        secretName: telemetry-root-secret
    - configMap:
        items:
          - key: relay
            path: relay.yaml
        name: gloo-telemetry-collector-config
      name: telemetry-configmap
    - hostPath:
        path: /var/run/cilium
        type: DirectoryOrCreate
      name: cilium-run
telemetryGateway:
  enabled: true
  extraVolumes:
  - name: tls-keys
    secret:
      secretName:  gloo-telemetry-gateway-tls-secret
      defaultMode: 420
  - name: telemetry-configmap
    configMap:
      name: gloo-telemetry-gateway-config
      items:
        - key: relay
          path: relay.yaml
telemetryGatewayCustomization:
  disableCertGeneration: true
      Helm valueDescription
      glooMgmtServer.relay.disableCaCertGenerationDisable the generation of self-signed certificates to secure the relay connection between the Gloo management server and agent.
      glooMgmtServer.relay.signingTlsSecretAdd the name and namespace of the Kubernetes secret that holds the intermediate CA credentials that you created earlier.
      glooMgmtServer.relay.tlsSecretAdd the name and namespace of the Kubernetes secret that holds the server TLS certificate for the Gloo management server that you created earlier.
      glooMgmtServer.relay.tokenSecretAdd the name, namespace, and key of the Kubernetes secret that holds the relay identity token that you created earlier.
      telemetryGateway.extraVolumesAdd the gloo-telemetry-gateway-tls-secret-custom Kubernetes secret that you created earlier to the tls-keys volume. Make sure that you also add the other volumes to your telemetry gateway configuration.
      telemetryCollector.extraVolumesAdd the telemetry-root-secret Kubernetes secret that you created earlier to the root-ca volume. Make sure that you also add the other volumes to your telemetry collector configuration.

    Use your preferred PKI provider to create the root CA, server TLS, client TLS, and telemetry gateway certificates. Then, store these certificates in the cluster so that the Gloo agent uses a client TLS certificate when establishing the first connection with the Gloo management server. No relay identity tokens are used. With this approach, you cannot use Gloo Mesh Gateway’s built-in client TLS certificate rotation capabilities. Instead, you must set up your own processes to monitor the expiration of your certificates and to rotate them before they expire. For more information, see Bring your own CAs and client TLS certificates.

    1. Create your root CA, server, client, and telemetry gateway TLS certificates. You can use your preferred PKI provider to do that or follow the steps in Create certificates with OpenSSL to create custom TLS certificates by using OpenSSL. Then, you store the following information in a Kubernetes secret in the gloo-mesh namespace on the management cluster.
      • relay-server-tls-secret that holds the server key, TLS certificate and certificate chain information for the Gloo management server
      • gloo-telemetry-gateway-tls-secret that holds the key, TLS certificate and certificate chain for the Gloo telemetry gateway
      • telemetry-root-secret that holds the root CA certificate for the certificate chain
    2. In your Helm values file for the management server, add the following values.
        
glooMgmtServer:
  enabled: true
  relay:
    disableCa: true
    disableCaCertGeneration: true
    disableTokenGeneration: true
    tlsSecret:
      name: relay-server-tls-secret
      namespace: gloo-mesh
    tokenSecret:
      key: null
      name: null
      namespace: null
telemetryCollector: 
  enabled: true
  extraVolumes: 
    - name: root-ca
      secret:
        defaultMode: 420
        optional: true
        secretName: telemetry-root-secret
    - configMap:
        items:
          - key: relay
            path: relay.yaml
        name: gloo-telemetry-collector-config
      name: telemetry-configmap
    - hostPath:
        path: /var/run/cilium
        type: DirectoryOrCreate
      name: cilium-run
telemetryGateway:
  enabled: true
  extraVolumes:
  - name: tls-keys
    secret:
      secretName:  gloo-telemetry-gateway-tls-secret
      defaultMode: 420
  - name: telemetry-configmap
    configMap:
      name: gloo-telemetry-gateway-config
      items:
        - key: relay
          path: relay.yaml
telemetryGatewayCustomization:
  disableCertGeneration: true
      Helm valueDescription
      relay.disableCaDisable the generation of self-signed root and intermediate CA certificates and the use of identity tokens to establish initial trust between the Gloo management server and agent.
      relay.disableCaCertGenerationDisable the generation of self-signed certificates to secure the relay connection between the Gloo management server and agent.
      relay.disableTokenGenerationDisable the generation of relay identity tokens.
      relay.tlsSecretAdd the name and namespace of the Kubernetes secret that holds the server TLS certificate for the Gloo management server that you created earlier.
      relay.tokenSecretSet all values to null to instruct the Gloo management server to not use identity tokens to establish initial trust with Gloo agents.
      telemetryGateway.extraVolumesAdd the gloo-telemetry-gateway-tls-secret Kubernetes secret that you created earlier to the tls-keys volume. Make sure that you also add the other volumes to your telemetry gateway configuration.
      telemetryCollector.extraVolumesAdd the telemetry-root-secret Kubernetes secret that you created earlier to the root-ca volume. Make sure that you also add the other volumes to your telemetry collector configuration.

    You can use Gloo to generate self-signed certificates and keys for the root and intermediate CA. These credentials are used to derive the server TLS certificate for the Gloo management server and client TLS certificate for the Gloo agent. Note that this setup is not recommended for production, but can be used for testing purposes. For more information, see Self-signed CAs with automatic client certificate rotation.

    In your Helm values file for the management server, add the following values. Note that mTLS is the default mode in Gloo Mesh Gateway and does not require any additional configuration on the management server.

      
glooMgmtServer:
  enabled: true

    Use your preferred PKI provider to create the server TLS certificate for the Gloo management server. For more information, see Bring your own server TLS certificate.

    1. Create your root CA credentials and derive a server TLS certificate. To create the TLS certificate, you can use your preferred PKI provider or follow the steps in BYO server certificate to create a custom server TLS certificate by using OpenSSL. Make sure that you have the following Kubernetes secrets in the management cluster:

      • relay-server-tls-secret-custom: The key and TLS certificate for the Gloo management server, and root CA certificate information for the certificate chain. Note that you can use a different name, but you cannot use relay-server-tls-secret as this name is reserved by the Gloo management server when creating self-signed root CAs and server TLS certificates.
      • gloo-telemetry-gateway-tls-secret-custom: The key and TLS certificate for the Gloo telemetry gateway, and root CA certificate information for the certificate chain. It is recommended to use the same credentials that you use for the Gloo management server. Note that you can use a different name, but you cannot use gloo-telemetry-gateway-tls-secret as this name is reserved by the Gloo management server when creating self-signed certificates.
      • telemetry-root-secret: The root CA certificate for the certificate chain.

    2. In your Helm values file for the management server, add the following values.

        
glooMgmtServer:
  enabled: true
  relay:
    tlsSecret:
      name: relay-server-tls-secret-custom
  extraEnvs:
    RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION:
      value: "true"  
    RELAY_TOKEN: 
      value: "My token"
telemetryCollector: 
  enabled: true
  extraVolumes: 
    - name: root-ca
      secret:
        defaultMode: 420
        optional: true
        secretName: telemetry-root-secret
    - configMap:
        items:
          - key: relay
            path: relay.yaml
        name: gloo-telemetry-collector-config
      name: telemetry-configmap
    - hostPath:
        path: /var/run/cilium
        type: DirectoryOrCreate
      name: cilium-run
telemetryGateway:
  enabled: true
  extraVolumes:
  - name: tls-keys
    secret:
      secretName:  gloo-telemetry-gateway-tls-secret-custom
      defaultMode: 420
  - name: telemetry-configmap
    configMap:
      name: gloo-telemetry-gateway-config
      items:
        - key: relay
          path: relay.yaml
telemetryGatewayCustomization:
  disableCertGeneration: true
      Helm valueDescription
      relay.tlsSecret.nameAdd the name of the Kubernetes secret with the custom server TLS secret that you created earlier.
      RELAY_TOKENSpecify the relay token that the Gloo management server and agent use to establish initial trust. When you install Gloo Mesh Gateway and set RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION to true, the connection between the Gloo management server and agent is automatically secured by using simple, server-side TLS. In a simple TLS setup, only the management server presents a certificate to authenticate its identity. The identity of the agent is not verified. To ensure that only trusted agents connect to the management server, the relay identity token is used. The relay identity token can be any string value and is stored in the relay-identity-token-secret Kubernetes secret on the management cluster. You must set the same value in glooAgent.extraEnvs.RELAY_TOKEN.value when you install the Gloo agent to allow the Gloo agent to connect to the Gloo management server.
      RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATIONSet this value to true to not require a client TLS certificate from the Gloo agent to prove the agent’s identity and establish the connection with the management server. This setting is required when you want to use simple TLS to secure the connection between the Gloo management server and agent.
      telemetryGateway.extraVolumesAdd the gloo-telemetry-gateway-tls-secret-custom Kubernetes secret that you created earlier to the tls-keys volume. Make sure that you also add the other volumes to your telemetry gateway configuration.
      telemetryCollector.extraVolumesAdd the telemetry-root-secret Kubernetes secret that you created earlier to the root-ca volume. Make sure that you also add the other volumes to your telemetry collector configuration.

    Use Gloo Mesh Gateway to create a self-signed server TLS certificate that the Gloo management server presents when workload cluster agents connect. This setup is not recommended for production, but can be used for testing purposes. For more information, see Self-signed server TLS certificate.

    In your Helm values file for the management server, add the following values.

      
glooMgmtServer:
  enabled: true
  extraEnvs:
    RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION:
      value: "true"  
    RELAY_TOKEN: 
      value: "My token"
    Helm valueDescription
    RELAY_TOKENSpecify the relay token that the Gloo management server and agent use to establish initial trust. When you install Gloo Mesh Gateway and set RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION to true, the connection between the Gloo management server and agent is automatically secured by using simple, server-side TLS. In a simple TLS setup, only the management server presents a certificate to authenticate its identity. The identity of the agent is not verified. To ensure that only trusted agents connect to the management server, the relay identity token is used. The relay identity token can be any string value and is stored in the relay-identity-token-secret Kubernetes secret on the management cluster. You must set the same value in glooAgent.extraEnvs.RELAY_TOKEN.value when installing Gloo Mesh Gateway in a workload cluster to allow Gloo agents to connect to the Gloo management server.
    RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATIONSet this value to true to not require a client TLS certificate from the Gloo agent to prove the agent’s identity and establish the connection with the management server. This setting is required when you want to use simple TLS to secure the connection between the Gloo management server and agent.

  8. Edit the file to provide your own details for settings that are recommended for production deployments, such as the following settings.

    FieldDecription
    glooMgmtServer.resources.limitsAdd resource limits for the gloo-mesh-mgmt-server pod, such as cpu: 1000m and memory: 1Gi.
    glooMgmtServer.safeMode
    glooMgmtServer.safeStartWindow    		Configure how you want the Gloo management server to handle translation after a Redis restart. For available options, see Redis safe mode options.
    glooMgmtServer.serviceOverrides.metadata.annotationsAdd annotations for the management server load balancer as needed, such as AWS-specific load balancer annotations. For more information, see Deployment and service overrides.
    glooUi.authSet up OIDC authorization for the Gloo UI. For more information, see UI authentication.
    prometheus.enabledDisable the default Prometheus instance as needed to provide your own. Otherwise, you can keep the default Prometheus server enabled, and deploy a production-level server to scrape metrics from the server. For more information on each option, see Best practices for collecting metrics in production.
    redisDisable the default Redis deployment and provide your own backing database as needed. For more information, see Backing databases.
    OpenShift: glooMgmtServer.serviceType and telemetryGateway.service.typeIn some OpenShift setups, you might not use load balancer service types. You can set these two deployment service types to ClusterIP, and expose them by using OpenShift routes after installation.

  9. Use the customizations in your Helm values file to install the Gloo management plane components in your management cluster.

      helm upgrade -i gloo-platform gloo-platform/gloo-platform \
   --kube-context $MGMT_CONTEXT \
   -n gloo-mesh \
   --version $GLOO_VERSION \
   --values mgmt-plane.yaml \
   --set common.cluster=$MGMT_CLUSTER \
   --set licensing.glooGatewayLicenseKey=$GLOO_MESH_GATEWAY_LICENSE_KEY

    1. Elevate the permissions of the gloo-mesh service account that will be created.

        oc adm policy add-scc-to-group anyuid system:serviceaccounts:gloo-mesh --context $MGMT_CONTEXT

    2. Install the Gloo management plane.

        helm upgrade -i gloo-platform gloo-platform/gloo-platform \
   --kube-context $MGMT_CONTEXT \
   -n gloo-mesh \
   --version $GLOO_VERSION \
   --values mgmt-plane.yaml \
   --set common.cluster=$MGMT_CLUSTER \
   --set licensing.glooGatewayLicenseKey=$GLOO_MESH_GATEWAY_LICENSE_KEY

  10. Verify that the management plane pods have a status of Running.

      kubectl get pods -n gloo-mesh --context $MGMT_CONTEXT

    Example output:

      NAME                                      READY   STATUS    RESTARTS   AGE
gloo-mesh-mgmt-server-56c495796b-cx687    1/1     Running   0          30s
gloo-mesh-redis-8455d49c86-f8qhw          1/1     Running   0          30s
gloo-mesh-ui-65b6b6df5f-bf4vp             3/3     Running   0          30s
gloo-telemetry-collector-agent-7rzfb      1/1     Running   0          30s
gloo-telemetry-gateway-6547f479d5-r4zm6   1/1     Running   0          30s
prometheus-server-57cd8c74d4-2bc7f        2/2     Running   0          30s

  11. Save the external address and port that your cloud provider assigned to the Gloo OpenTelemetry (OTel) gateway service. The OTel collector agents in each workload cluster send metrics to this address.

      export TELEMETRY_GATEWAY_IP=$(kubectl get svc -n gloo-mesh gloo-telemetry-gateway --context $MGMT_CONTEXT -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
export TELEMETRY_GATEWAY_PORT=$(kubectl get svc -n gloo-mesh gloo-telemetry-gateway --context $MGMT_CONTEXT -o jsonpath='{.spec.ports[?(@.name=="otlp")].port}')
export TELEMETRY_GATEWAY_ADDRESS=${TELEMETRY_GATEWAY_IP}:${TELEMETRY_GATEWAY_PORT}
echo $TELEMETRY_GATEWAY_ADDRESS
    1. Expose the telemetry gateway by using an OpenShift route. Your route might look like the following.
        oc apply --context $MGMT_CONTEXT -n gloo-mesh -f- <<EOF
kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: gloo-telemetry-gateway
  namespace: gloo-mesh
spec:
  host: gloo-telemetry-gateway.<your_domain>.com
  to:
    kind: Service
    name: gloo-telemetry-gateway
    weight: 100
  port:
    targetPort: otlp
  tls:
    termination: passthrough
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None
EOF
    2. Save the telemetry gateway’s address, which consists of the route host and the route port. Note that the port is the route’s own port, such as 443, and not the otlp port of the telemetry gateway that the route points to.
        export TELEMETRY_GATEWAY_HOST=$(oc get route -n gloo-mesh gloo-telemetry-gateway --context $MGMT_CONTEXT -o jsonpath='{.status.ingress[0].host}')
export TELEMETRY_GATEWAY_ADDRESS=${TELEMETRY_GATEWAY_HOST}:443
echo $TELEMETRY_GATEWAY_ADDRESS

  12. Save the external address and port that your cloud provider assigned to the gloo-mesh-mgmt-server service. The gloo-mesh-agent agent in each workload cluster accesses this address via a secure connection.

      export MGMT_SERVER_NETWORKING_DOMAIN=$(kubectl get svc -n gloo-mesh gloo-mesh-mgmt-server --context $MGMT_CONTEXT -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
export MGMT_SERVER_NETWORKING_PORT=$(kubectl get svc -n gloo-mesh gloo-mesh-mgmt-server --context $MGMT_CONTEXT -o jsonpath='{.spec.ports[?(@.name=="grpc")].port}')
export MGMT_SERVER_NETWORKING_ADDRESS=${MGMT_SERVER_NETWORKING_DOMAIN}:${MGMT_SERVER_NETWORKING_PORT}
echo $MGMT_SERVER_NETWORKING_ADDRESS
    1. Expose the management server by using an OpenShift route. Your route might look like the following.
        oc apply --context $MGMT_CONTEXT -n gloo-mesh -f- <<EOF
kind: Route
apiVersion: route.openshift.io/v1
metadata:
   name: gloo-mesh-mgmt-server
   namespace: gloo-mesh
   annotations:
      # Needed for the different agents to connect to different replica instances of the management server deployment
      haproxy.router.openshift.io/balance: roundrobin
spec:
   host: gloo-mesh-mgmt-server.<your_domain>.com
   to:
      kind: Service
      name: gloo-mesh-mgmt-server
      weight: 100
   port:
      targetPort: grpc
   tls:
      termination: passthrough
      insecureEdgeTerminationPolicy: Redirect
   wildcardPolicy: None
EOF
    2. Save the management server’s address, which consists of the route host and the route port. Note that the port is the route’s own port, such as 443, and not the grpc port of the management server that the route points to.
        export MGMT_SERVER_NETWORKING_DOMAIN=$(oc get route -n gloo-mesh gloo-mesh-mgmt-server --context $MGMT_CONTEXT -o jsonpath='{.status.ingress[0].host}')
export MGMT_SERVER_NETWORKING_ADDRESS=${MGMT_SERVER_NETWORKING_DOMAIN}:443
echo $MGMT_SERVER_NETWORKING_ADDRESS

Data plane

Register each workload cluster with the Gloo management plane by deploying Gloo data plane components. A deployment named gloo-mesh-agent runs the Gloo agent in each workload cluster.

  1. For the workload cluster that you want to register with Gloo, set the following environment variables. You update these variables each time you follow these steps to register another workload cluster.

      export REMOTE_CLUSTER=<workload_cluster_name>
export REMOTE_CONTEXT=<workload_cluster_context>

  2. In the management cluster, create a KubernetesCluster resource to represent the workload cluster and store relevant data, such as the workload cluster’s local domain.

      kubectl apply --context $MGMT_CONTEXT -f- <<EOF
apiVersion: admin.gloo.solo.io/v2
kind: KubernetesCluster
metadata:
   name: ${REMOTE_CLUSTER}
   namespace: gloo-mesh
spec:
   clusterDomain: cluster.local
EOF

  3. In your workload cluster, apply the Gloo CRDs. Note: If you plan to manually install gateway proxies rather than using Solo’s gateway lifecycle manager, include the --set installIstioOperator=false flag to ensure that the Istio operator CRD is not managed by this Gloo CRD Helm release.

      helm upgrade -i gloo-platform-crds gloo-platform/gloo-platform-crds \
   --namespace=gloo-mesh \
   --create-namespace \
   --version=$GLOO_VERSION \
   --kube-context $REMOTE_CONTEXT
  4. Prepare a Helm values file to provide your customizations. To get started, you can use the minimum settings in the following profile as a basis. These settings enable all components that are required for a Gloo data plane installation.

  5. Depending on the method you chose to secure the relay connection, prepare the Helm values for the data plane installation. For more information, see the Setup options.

    1. Make sure that the following Kubernetes secrets exist in the gloo-mesh namespace on each workload cluster.

      • relay-root-tls-secret that holds the root CA certificate
      • relay-identity-token-secret that holds the relay identity token value
      • telemetry-root-secret that holds the root CA certificate for the certificate chain

      You can use the steps in BYO server certificate with managed client certificate as a guidance for how to create these secrets in the workload cluster.

    2. In your Helm values file for the agent, add the following values.

        
glooAgent:
  enabled: true
  relay:
    authority: gloo-mesh-mgmt-server.gloo-mesh
    clientTlsSecretRotationGracePeriodRatio: ""
    rootTlsSecret:
      name: relay-root-tls-secret
      namespace: gloo-mesh
    tokenSecret:
      key: token
      name: relay-identity-token-secret
      namespace: gloo-mesh
telemetryCollector: 
  enabled: true
  extraVolumes: 
    - name: root-ca
      secret:
        defaultMode: 420
        optional: true
        secretName: telemetry-root-secret
    - configMap:
        items:
          - key: relay
            path: relay.yaml
        name: gloo-telemetry-collector-config
      name: telemetry-configmap
    - hostPath:
        path: /var/run/cilium
        type: DirectoryOrCreate
      name: cilium-run
      Helm valueDescription
      glooAgent.relay.rootTlsSecretAdd the name and namespace of the Kubernetes secret that holds the root CA credentials that you copied from the management cluster to the workload cluster.
      glooAgent.relay.tokenSecretAdd the name, namespace, and key of the Kubernetes secret that holds the relay identity token that you copied from the management cluster to the workload cluster.
      telemetryCollector.extraVolumesAdd the telemetry-root-secret Kubernetes secret that you created earlier to the root-ca volume. Make sure that you also add the other volumes to your telemetry collector configuration.

    1. Make sure that the following Kubernetes secrets exist in the gloo-mesh namespace on each workload cluster.

      • $REMOTE_CLUSTER1-tls-cert that holds the key, TLS certificate, and certificate chain information for the Gloo agent
      • telemetry-root-secret that holds the root CA certificate for the certificate chain

      You can use the steps in Create certificates with OpenSSL as a guidance for how to create these secrets in the workload cluster.

    2. In your Helm values file for the agent, add the following values. Replace <client-tls-secret-name> with the name of the Kubernetes secret that holds the client TLS certificate, and add the name of the Kubernetes secret that holds the telemetry gateway certificate to the root-ca telemetry collector volume.

        
glooAgent:
  enabled: true
  relay:
    authority: gloo-mesh-mgmt-server.gloo-mesh
    clientTlsSecretRotationGracePeriodRatio: ""
    clientTlsSecret: 
      name: <client-tls-secret-name>
      namespace: gloo-mesh
    tokenSecret:
      key: null
      name: null
      namespace: null
telemetryCollector:
  enabled: true
  extraVolumes: 
    - name: root-ca
      secret:
        defaultMode: 420
        optional: true
        secretName: telemetry-root-secret
    - configMap:
        items:
          - key: relay
            path: relay.yaml
        name: gloo-telemetry-collector-config
      name: telemetry-configmap
    - hostPath:
        path: /var/run/cilium
        type: DirectoryOrCreate
      name: cilium-run
      Helm valueDescription
      glooAgent.relay.clientTlsSecretAdd the name and namespace of the Kubernetes secret that holds the client TLS certificate for the Gloo agent that you created earlier.
      glooAgent.relay.tokenSecretSet all values to null to instruct the Gloo agent to not use identity tokens to establish initial trust with Gloo agents.
      telemetryCollector.extraVolumesAdd the name of the Kubernetes secret that holds the Gloo telemetry gateway certificate that you created earlier to the root-ca volume. Make sure that you also add the configMap and hostPath volumes to your configuration.

    1. Get the value of the root CA certificate from the management cluster and create a secret in the workload cluster.

        kubectl get secret relay-root-tls-secret -n gloo-mesh --context $MGMT_CONTEXT -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
kubectl create secret generic relay-root-tls-secret -n gloo-mesh --context $REMOTE_CONTEXT1 --from-file ca.crt=ca.crt
rm ca.crt
  
        kubectl get secret relay-root-tls-secret -n gloo-mesh --context $MGMT_CONTEXT -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
kubectl create secret generic relay-root-tls-secret -n gloo-mesh --context $REMOTE_CONTEXT2 --from-file ca.crt=ca.crt
rm ca.crt

    2. Get the identity token from the management cluster and create a secret in the workload cluster.

        kubectl get secret relay-identity-token-secret -n gloo-mesh --context $MGMT_CONTEXT -o jsonpath='{.data.token}' | base64 -d > token
kubectl create secret generic relay-identity-token-secret -n gloo-mesh --context $REMOTE_CONTEXT1 --from-file token=token
rm token
  
        kubectl get secret relay-identity-token-secret -n gloo-mesh --context $MGMT_CONTEXT -o jsonpath='{.data.token}' | base64 -d > token
kubectl create secret generic relay-identity-token-secret -n gloo-mesh --context $REMOTE_CONTEXT2 --from-file token=token
rm token

    3. Make sure that the following Helm values are added to your values file.

        
glooAgent:
  enabled: true

    1. Make sure that the following Kubernetes secret exists in the gloo-mesh namespace on each workload cluster.

      • telemetry-root-secret that holds the root CA certificate for the certificate chain

      You can use the steps in BYO server certificate as a guidance for how to create this secret in the workload cluster.

    2. In your Helm values file for the workload cluster, add the following values.

        
glooAgent:
  enabled: true
  extraEnvs:
    RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION:
      value: "true"  
    RELAY_TOKEN: 
      value: "My token"
telemetryCollector: 
  enabled: true
  extraVolumes: 
    - name: root-ca
      secret:
        defaultMode: 420
        optional: true
        secretName: telemetry-root-secret
    - configMap:
        items:
          - key: relay
            path: relay.yaml
        name: gloo-telemetry-collector-config
      name: telemetry-configmap
    - hostPath:
        path: /var/run/cilium
        type: DirectoryOrCreate
      name: cilium-run
telemetryCollectorCustomization:
  skipVerify: true
      Helm valueDescription
      RELAY_TOKENThe relay token to establish initial trust between the Gloo management server and the agent. The relay token is saved in memory on the Gloo agent. You must set the same value that you set in glooMgmtServer.extraEnvs.RELAY_TOKEN.value when you installed the Gloo Mesh Gateway management plane to allow Gloo agents to connect to the Gloo management server.
      RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATIONSet to true to skip validating the server TLS certificate that the Gloo management server presents. This setting is required to configure the relay connection for TLS.
      telemetryCollector.extraVolumesAdd the telemetry-root-secret Kubernetes secret that you created earlier to the root-ca volume. Make sure that you also add the other volumes to your telemetry collector configuration.
      telemetryCollectorCustomization.skipVerifySet to true to skip validation of the server certificate that the Gloo telemetry gateway presents. By default, the Gloo telemetry gateway uses the same TLS certificates that the Gloo management server uses for the relay connection. If you configure the relay connection for TLS, you must set skipVerify to true on the telemetry collector agent.

    In your Helm values file for the workload cluster, add the following values.

      
glooAgent:
  enabled: true
  extraEnvs:
    RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION:
      value: "true"  
    RELAY_TOKEN: 
      value: "My token"
telemetryCollector:
  enabled: true
telemetryCollectorCustomization:
  skipVerify: true
    Helm valueDescription
    RELAY_TOKENThe relay token to establish initial trust between the Gloo management server and the agent. The relay token is saved in memory on the Gloo agent. You must set the same value that you set in glooMgmtServer.extraEnvs.RELAY_TOKEN.value when you installed the Gloo Mesh Gateway management plane to allow Gloo agents to connect to the Gloo management server.
    RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATIONSet to true to skip validating the server TLS certificate that the Gloo management server presents. This setting is required to configure the relay connection for TLS.
    telemetryCollectorCustomization.skipVerifySet to true to skip validation of the server certificate that the Gloo telemetry gateway presents. By default, the Gloo telemetry gateway uses the same TLS certificates that the Gloo management server uses for the relay connection. If you configure the relay connection for TLS, you must set skipVerify to true on the telemetry collector agent.

  6. Edit the file to provide your own details for settings that are recommended for production deployments, such as the following settings.

    FieldDecription
    glooAgent.resources.limitsAdd resource limits for the gloo-mesh-mgmt-server pod, such as cpu: 500m and memory: 512Mi.
    extAuthService.enabledSet to true to install the external auth server add-on.
    rateLimiter.enabledSet to true to install the rate limit server add-on.

  7. Use the customizations in your Helm values file to install the Gloo data plane components in your workload cluster.

      helm upgrade -i gloo-platform gloo-platform/gloo-platform \
   --namespace gloo-mesh \
   --kube-context $REMOTE_CONTEXT \
   --version $GLOO_VERSION \
   --values data-plane.yaml \
   --set common.cluster=$REMOTE_CLUSTER \
   --set glooAgent.relay.serverAddress=$MGMT_SERVER_NETWORKING_ADDRESS \
   --set telemetryCollector.config.exporters.otlp.endpoint=$TELEMETRY_GATEWAY_ADDRESS

    1. Elevate the permissions of the gloo-mesh service account that will be created.

        oc adm policy add-scc-to-group anyuid system:serviceaccounts:gloo-mesh --context $REMOTE_CONTEXT

    2. Install the Gloo agent in your workload cluster.

        helm upgrade -i gloo-platform gloo-platform/gloo-platform \
   --namespace gloo-mesh \
   --kube-context $REMOTE_CONTEXT \
   --version $GLOO_VERSION \
   --values data-plane.yaml \
   --set common.cluster=$REMOTE_CLUSTER \
   --set glooAgent.relay.serverAddress=$MGMT_SERVER_NETWORKING_ADDRESS \
   --set telemetryCollector.config.exporters.otlp.endpoint=$TELEMETRY_GATEWAY_ADDRESS

  8. Verify that the Gloo data plane component pods are running. If not, try debugging the agent.

      meshctl check --kubecontext $REMOTE_CONTEXT

    Example output:

      🟢 Gloo deployment status

Namespace | Name                           | Ready | Status
gloo-mesh | ext-auth-service               | 1/1   | Healthy
gloo-mesh | gloo-mesh-agent                | 1/1   | Healthy
gloo-mesh | gloo-telemetry-collector-agent | 3/3   | Healthy
gloo-mesh | rate-limiter                   | 1/1   | Healthy

  9. Repeat steps 1 - 8 to register each workload cluster with Gloo.

  10. Verify that your Gloo Mesh Gateway setup is correctly installed. If not, try debugging the relay connection. Note that this check might take a few seconds to verify that:

    • Your Gloo product licenses are valid and current.
    • The Gloo CRDs are installed at the correct version.
    • The management plane pods in the management cluster are running and healthy.
    • The agents in the workload clusters are successfully identified by the management server.
      meshctl check --kubecontext $MGMT_CONTEXT

    Example output:

      🟢 License status

INFO  gloo-gateway enterprise license expiration is 25 Aug 24 10:38 CDT

🟢 CRD version check

🟢 Gloo deployment status

Namespace | Name                           | Ready | Status
gloo-mesh | gloo-mesh-mgmt-server          | 1/1   | Healthy
gloo-mesh | gloo-mesh-redis                | 1/1   | Healthy
gloo-mesh | gloo-mesh-ui                   | 1/1   | Healthy
gloo-mesh | gloo-telemetry-collector-agent | 3/3   | Healthy
gloo-mesh | gloo-telemetry-gateway         | 1/1   | Healthy
gloo-mesh | prometheus-server              | 1/1   | Healthy

🟢 Mgmt server connectivity to workload agents

Cluster  | Registered | Connected Pod                                   
cluster1 | true       | gloo-mesh/gloo-mesh-mgmt-server-65bd557b95-v8qq6
cluster2 | true       | gloo-mesh/gloo-mesh-mgmt-server-65bd557b95-v8qq6

Connected Pod                                    | Clusters
gloo-mesh/gloo-mesh-mgmt-server-65bd557b95-v8qq6 | 2

Gateway proxies

Deploy gateway proxies in each workload cluster.

Install gateway proxies by using the Istio and Gateway Lifecycle Manager

Streamline the gateway installation process by using the Gloo management plane to install Istio gateways in your clusters, as part of the Istio lifecycle management. By using a Gloo-managed installation, you no longer need to use istioctl to individually install the Istio control plane and gateways. Instead, you can supply IstioOperator configurations in Gloo resources. Gloo translates this configuration into an Istio control plane and gateway proxy in the cluster.

Before you begin, review the following considerations for using the Istio lifecycle manager.

  • Throughout this guide, you use example configuration files that have pre-filled values. You can update some of the values, but unexpected behaviors might occur. For example, if you change the default istio-ingressgateway name, you cannot also use Kubernetes horizontal pod autoscaling. For more information, see the Troubleshooting docs.
  • If you plan to run multiple revisions of Istio in your cluster and use discoverySelectors in each revision to discover the resources in specific namespaces, enable the glooMgmtServer.extraEnvs.IGNORE_REVISIONS_FOR_VIRTUAL_DESTINATION_TRANSLATION environment variable on the Gloo management server. For more information, see Multiple Istio revisions in the same cluster.
  • If your organization restricts elevated Kubernetes RBAC permissions for security reasons, you might need to install the Istio CNI plug-in. The OpenShift steps provide an example. For more information, see the Istio docs.
  • In multicluster setups, one gateway proxy for north-south traffic is deployed to each workload cluster. To learn about your gateway options, such as creating a global load balancer to route to each gateway IP address or registering each gateway IP address in one DNS entry, see the gateway deployment patterns page.

istiod control planes

Prepare an IstioLifecycleManager CR to manage istiod control planes.

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

    • REPO: The repo key for the Solo distribution of Istio that you can get by logging in to the Support Center and reviewing the Istio images built by Solo.io support article.
    • ISTIO_IMAGE: The version that you want to use with the solo tag, such as 1.20.8-patch1-solo. You can optionally append other tags of Solo distributions of Istio as needed.
    • REVISION: Take the Istio major and minor versions and replace the periods with hyphens, such as 1-20.

      export REPO=<repo-key>
export ISTIO_IMAGE=1.20.8-patch1-solo
export REVISION=1-20

  2. 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/istio-install/gm-managed/gm-istiod.yaml > gm-istiod.yaml
    1. Elevate the permissions of the following service accounts that will be created. These permissions allow the to make use of a user ID that is normally restricted by OpenShift. For more information, see the Istio on OpenShift documentation.
        oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system --context $REMOTE_CONTEXT1
oc adm policy add-scc-to-group anyuid system:serviceaccounts:gloo-mesh-gateways --context $REMOTE_CONTEXT1
# Update revision as needed
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:istio-system --context $REMOTE_CONTEXT2
oc adm policy add-scc-to-group anyuid system:serviceaccounts:gloo-mesh-gateways --context $REMOTE_CONTEXT2
# Update revision as needed
oc adm policy add-scc-to-group anyuid system:serviceaccounts:gm-iop-1-20 --context $REMOTE_CONTEXT2
    2. Create the gloo-mesh-gateways project, and create a NetworkAttachmentDefinition custom resource for the project.
        kubectl create ns gloo-mesh-gateways --context $REMOTE_CONTEXT1
cat <<EOF | oc --context $REMOTE_CONTEXT1 -n gloo-mesh-gateways create -f -
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: istio-cni
EOF
  
        kubectl create ns gloo-mesh-gateways --context $REMOTE_CONTEXT2
cat <<EOF | oc --context $REMOTE_CONTEXT2 -n gloo-mesh-gateways create -f -
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: istio-cni
EOF
    3. Download the example file.
        curl -0L https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-mesh/istio-install/gm-managed/gm-istiod-openshift.yaml > istiod.yaml

  3. 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

  4. 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

  5. Apply the IstioLifecycleManager CR to your management cluster.

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

  6. 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-20-b65676555-g2vmr     1/1     Running   0          47s
   NAME                            READY   STATUS    RESTARTS   AGE
   istiod-1-20-7b96cb895-4nzv9     1/1     Running   0          43s

Ingress gateways

Prepare a GatewayLifecycleManager custom resource to manage the ingress gateways.

  1. Download the gm-ingress-gateway.yaml example file.

      curl -0L https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-mesh/istio-install/gm-managed/gm-ingress-gateway.yaml > gm-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 management cluster.

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

  5. In each workload cluster, verify that the ingress gateway pod is 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

  7. Optional for OpenShift: Expose the gateways by using OpenShift routes.

      oc -n gloo-mesh-gateways expose svc istio-ingressgateway --port=http2 --context $REMOTE_CONTEXT1
oc -n gloo-mesh-gateways expose svc istio-ingressgateway --port=http2 --context $REMOTE_CONTEXT2

East-west gateways

Deploy an Istio east-west gateway into each cluster in addition to the ingress gateway. In Gloo Mesh Gateway, the east-west gateways allow the ingress gateway in one cluster to route incoming traffic requests to services in another cluster.

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

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

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

    • For example, you can run a terminal command to substitute values:
        envsubst < ew-gateway.yaml > ew-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 ew-gateway-values.yaml
    * For testing environments only, you can deploy a revisionless installation by removing the revision field.

  4. Apply the GatewayLifecycleManager CR to your management cluster.

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

  5. In each workload cluster, verify that the east-west gateway pod is 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-eastwestgateway-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-eastwestgateway      LoadBalancer   10.96.252.49    <externalip>  15021:32378/TCP,80:30315/TCP,443:32186/TCP,31400:30313/TCP,15443:31632/TCP      2m2s

Optional: Configure the locality labels for the nodes

Gloo Mesh Gateway uses Kubernetes labels on the nodes in your clusters to indicate locality for the services that run on the nodes. For more information, see the Kubernetes topology and Istio locality documentation.

  • Cloud: Typically, your cloud provider sets the Kubernetes region and zone labels for each node automatically. Depending on the level of availability that you want, you might have clusters in the same region, but different zones. Or, each cluster might be in a different region, with nodes spread across zones.
  • On-premises: Depending on how you set up your cluster, you likely must set the region and zone labels for each node yourself. Additionally, consider setting a subzone label to specify nodes on the same rack or other more granular setups.

  1. Verify that your nodes have at least region and zone labels.

      kubectl get nodes --context $REMOTE_CONTEXT1 -o jsonpath='{.items[*].metadata.labels}'
kubectl get nodes --context $REMOTE_CONTEXT2 -o jsonpath='{.items[*].metadata.labels}'

    Example output with region and zone labels:

      ..."topology.kubernetes.io/region":"us-east","topology.kubernetes.io/zone":"us-east-2"
    • If your nodes have at least region and zone labels, and you do not want to update the labels, you can skip the remaining steps.
    • If your nodes do not already have region and zone labels, you must add the labels. Depending on your cluster setup, you might add the same region label to each node, but a separate zone label per node. The values are not validated against your underlying infrastructure provider. The following steps show how you might label multizone clusters in two different regions, but you can adapt the steps for your actual setup.

  2. Label all the nodes in each cluster for the region. If your nodes have incorrect region labels, include the --overwrite flag in the command.

      kubectl label nodes --all --context $REMOTE_CONTEXT1 topology.kubernetes.io/region=us-east
kubectl label nodes --all --context $REMOTE_CONTEXT2 topology.kubernetes.io/region=us-west

  3. List the nodes in each cluster. Note the name for each node.

      kubectl get nodes --context $REMOTE_CONTEXT1
kubectl get nodes --context $REMOTE_CONTEXT2

  4. Label each node in each cluster for the zone. If your nodes have incorrect zone labels, include the --overwrite flag in the command.

      kubectl label node <cluster1_node-1> --context $REMOTE_CONTEXT1 topology.kubernetes.io/zone=us-east-1
kubectl label node <cluster1_node-2> --context $REMOTE_CONTEXT1 topology.kubernetes.io/zone=us-east-2
kubectl label node <cluster1_node-3> --context $REMOTE_CONTEXT1 topology.kubernetes.io/zone=us-east-3

kubectl label node <cluster2_node-1> --context $REMOTE_CONTEXT2 topology.kubernetes.io/zone=us-west-1
kubectl label node <cluster2_node-2> --context $REMOTE_CONTEXT2 topology.kubernetes.io/zone=us-west-2
kubectl label node <cluster2_node-3> --context $REMOTE_CONTEXT2 topology.kubernetes.io/zone=us-west-3

Next steps

Now that you have Gloo Mesh Gateway up and running, check out some of the following resources to learn more about your API Gateway and expand your routing and network capabilities.

Traffic management:

Gloo Mesh Gateway:

Help and support: