Multicluster management

   curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/gloo-mesh-mgmt.yaml > mgmt-plane.yaml
   open mgmt-plane.yaml

7. Decide how you want to secure the relay connection between the management server and agents. In test and POC environments, you can use self-signed certificates to secure the connection. If you plan to use Solo Enterprise for Istio in production, bringing your own certificates instead is recommended. 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 Solo Enterprise for Istio’s built-in capability to automatically issue and sign client TLS certificates for 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 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 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 value	Description
      glooMgmtServer.relay.disableCaCertGeneration	Disable the generation of self-signed certificates to secure the relay connection between the management server and agent.
      glooMgmtServer.relay.signingTlsSecret	Add the name and namespace of the Kubernetes secret that holds the intermediate CA credentials that you created earlier.
      glooMgmtServer.relay.tlsSecret	Add the name and namespace of the Kubernetes secret that holds the server TLS certificate for the management server that you created earlier.
      glooMgmtServer.relay.tokenSecret	Add the name, namespace, and key of the Kubernetes secret that holds the relay identity token that you created earlier.
      telemetryGateway.extraVolumes	Add 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.extraVolumes	Add 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 agent uses a client TLS certificate when establishing the first connection with the management server. No relay identity tokens are used. With this approach, you cannot use Solo Enterprise for Istio’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.

   3. 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 management server
      • gloo-telemetry-gateway-tls-secret that holds the key, TLS certificate and certificate chain for the telemetry gateway
      • telemetry-root-secret that holds the root CA certificate for the certificate chain
   4. 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 value	Description
      relay.disableCa	Disable the generation of self-signed root and intermediate CA certificates and the use of identity tokens to establish initial trust between the management server and agent.
      relay.disableCaCertGeneration	Disable the generation of self-signed certificates to secure the relay connection between the management server and agent.
      relay.disableTokenGeneration	Disable the generation of relay identity tokens.
      relay.tlsSecret	Add the name and namespace of the Kubernetes secret that holds the server TLS certificate for the management server that you created earlier.
      relay.tokenSecret	Set all values to null to instruct the management server to not use identity tokens to establish initial trust with agents.
      telemetryGateway.extraVolumes	Add 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.extraVolumes	Add 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.

   report

   Do not use self-signed certs for production. This setup is recommended for testing purposes only.

   You can use Solo Enterprise for Istio 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 management server and client TLS certificate for the 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 Solo Enterprise for Istio 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 management server. For more information, see Bring your own server TLS certificate.

   5. 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 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 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 telemetry gateway, and root CA certificate information for the certificate chain. It is recommended to use the same credentials that you use for the 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 management server when creating self-signed certificates.
      • telemetry-root-secret: The root CA certificate for the certificate chain.

   6. 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 value	Description
      relay.tlsSecret.name	Add the name of the Kubernetes secret with the custom server TLS secret that you created earlier.
      RELAY_TOKEN	Specify the relay token that the management server and agent use to establish initial trust. When you install Solo Enterprise for Istio and set RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION to true, the connection between the 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 agent to allow the agent to connect to the management server.
      RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION	Set this value to true to not require a client TLS certificate from the 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 management server and agent.
      telemetryGateway.extraVolumes	Add 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.extraVolumes	Add 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.

   report

   Do not use self-signed certs for production. This setup is recommended for testing purposes only.

   Use Solo Enterprise for Istio to create a self-signed server TLS certificate that the 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 value	Description
   RELAY_TOKEN	Specify the relay token that the management server and agent use to establish initial trust. When you install Solo Enterprise for Istio and set RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION to true, the connection between the 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 Solo Enterprise for Istio in a workload cluster to allow agents to connect to the management server.
   RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION	Set this value to true to not require a client TLS certificate from the 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 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.

   check_circle

   For more information about the settings you can configure:

   • See Best practices for production.
   • See all possible fields for the Helm chart by running helm show values gloo-platform/gloo-platform --version v2.11.5 > all-values.yaml. You can also see these fields in the Helm values documentation.

   Field	Description
   glooMgmtServer.resources.limits	Add 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.annotations	Add 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.auth	Set up OIDC authorization for the Gloo UI. For more information, see UI authentication.
   prometheus.enabled	Disable 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.
   redis	Disable the default Redis deployment and provide your own backing database as needed. For more information, see Backing databases.
   OpenShift: glooMgmtServer.serviceType and telemetryGateway.service.type	In 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.glooMeshCoreLicenseKey=$SOLO_ISTIO_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.glooMeshCoreLicenseKey=$SOLO_ISTIO_LICENSE_KEY \
         --set glooMgmtServer.floatingUserId=true \
         --set glooMgmtServer.serviceType=LoadBalancer \
         --set glooUi.floatingUserId=true \
         --set redis.deployment.floatingUserId=true \
         --set telemetryGateway.service.type=LoadBalancer

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-collector-agent-mf5rw      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-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
12. 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

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.

helm upgrade -i gloo-platform-crds gloo-platform/gloo-platform-crds \
   --namespace=gloo-mesh \
   --create-namespace \
   --version=$GLOO_VERSION \
   --set installEnterpriseCrds=false \
   --kube-context $REMOTE_CONTEXT