Gloo Mesh Enterprise is a multicluster and multimesh management plane that is based on hardened, open-source projects like Envoy and Istio. With Gloo Mesh, you can unify the configuration, operation, and visibility of service-to-service connectivity across your distributed applications. These apps can run in different virtual machines (VMs) or Kubernetes clusters on premises or in various cloud providers, and even in different service meshes.

You can follow this guide to customize settings for an advanced Gloo Mesh Enterprise installation. To learn more about the benefits and architecture, see About.

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.4.16 sh -
export PATH=$HOME/.gloo-mesh/bin:$PATH
    • helm, the Kubernetes package manager.

  2. Set your Gloo Mesh Enterprise 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_LICENSE_KEY} | base64 -w0).

      export GLOO_MESH_LICENSE_KEY=<license_key>

  3. Set the Gloo Mesh Enterprise 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.4.16-fips. Do not include v before the version number.

      export GLOO_VERSION=2.4.16

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

Install Gloo Mesh Enterprise

In a multicluster setup, you deploy the Gloo management plane into a dedicated management cluster, and the Gloo data plane into one or more workload clusters that run Istio service meshes.

Management plane

Deploy the Gloo management plane into a dedicated management cluster.

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

  2. Add and update the Helm repository for Gloo.

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

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

  5. 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 Enterprise 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 Enterprise’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 Enterprise’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 Enterprise and does not require any additional configuration on the management server.

      
glooMgmtServer:
  enabled: true

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

  7. 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.glooMeshLicenseKey=$GLOO_MESH_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.glooMeshLicenseKey=$GLOO_MESH_LICENSE_KEY

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

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

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

  11. 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. 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 deploy and manage your Istio installation in workload clusters rather than using Solo’s Istio 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.
      curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/agent.yaml > data-plane.yaml
open data-plane.yaml
  
      curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/agent-openshift.yaml > data-plane.yaml
open data-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.

  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

  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 Enterprise 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-mesh 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

Istio

Deploy Istio on each workload cluster.

Optional: Configure the locality labels for the nodes

Gloo Mesh Enterprise 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 Enterprise up and running, check out some of the following resources to learn more about Gloo Mesh and expand your service mesh capabilities.

Gloo Mesh Enterprise:

Istio:

Help and support: