Gloo Mesh Gateway is a feature-rich, Kubernetes-native ingress controller and next-generation API gateway. With Gloo Mesh Gateway, you have access to its exceptional function-level routing, discovery capabilities, numerous features, tight integration with leading open-source projects, and support for legacy apps, microservices, and serverless. Gloo Mesh Gateway is uniquely designed to support hybrid applications in which multiple technologies, architectures, protocols, and clouds can coexist. To learn more about the benefits and architecture, see About.

Overview

In this guide, you customize Helm settings for an advanced Gloo Mesh Gateway installation in a single-cluster environment. To use a dedicated cluster for your Gloo management plane, and install gateway proxies in one or more workload clusters instead, see the multicluster setup guide.

These settings install the Gloo management plane and gateway proxy together in one cluster, as shown in the following diagram.

  • Gloo Mesh Gateway management plane: When you install the Gloo management plane, a deployment named gloo-mesh-mgmt-server is created to translate and implement your Gloo configurations. Because you include the glooAgent.enabled: true setting in the installation values file, the cluster is also registered to be managed by Gloo. A deployment named gloo-mesh-agent is created to run the Gloo agent as part of the Gloo data plane.
  • Gateway proxy: Use the Gloo management plane to install an ingress gateway proxy in your cluster, as part of the Istio lifecycle management. By using a Gloo-managed installation, you no longer need to manually install and manage the istiod control plane and gateway proxy. Instead, you provide the Istio configuration in your gloo-platform Helm chart, and Gloo translates this configuration into a managed istiod control plane and gateway proxy in the cluster.

Figure: Gloo Mesh Gateway single-cluster installation architecture
Figure: Gloo Mesh Gateway single-cluster installation architecture

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

  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.7.0-beta1-fips. Do not include v before the version number.

      export GLOO_VERSION=2.7.0-beta1

  4. Create or use an existing Kubernetes or OpenShift cluster, and save the cluster name in an environment variable. Note: The cluster name must be alphanumeric with no special characters except a hyphen (-), lowercase, and begin with a letter (not a number).

      export CLUSTER_NAME=<cluster_name>
  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 Gateway

  1. Add and update the Helm repository for Gloo.

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

  2. Install the Gloo CRDs.

      helm upgrade -i gloo-platform-crds gloo-platform/gloo-platform-crds \
   --namespace=gloo-mesh \
   --create-namespace \
   --version=$GLOO_VERSION

  3. 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 single-cluster Gloo Mesh Gateway installation.

      curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/gloo-gateway-single.yaml > gloo-single.yaml
open gloo-single.yaml
  
      curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/gloo-gateway-single-openshift.yaml > gloo-single.yaml
open gloo-single.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.

  4. Decide how you want to secure the relay connection between the Gloo management server and agent. In test and POC environments, you can use Gloo 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 the client TLS certificate for the Gloo agent. For more information, see the Bring your own CAs with automatic client TLS certificate rotation.

    1. Create your root CA, intermediate CA credentials, server TLS certificate, and relay identity token, and store them as the following Kubernetes secrets in the gloo-mesh namespace:

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

      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 the relay identity token and the TLS certificate by using OpenSSL.

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

        glooMgmtServer: 
  enabled: true
  registerCluster: true
  serviceType: ClusterIP
  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
glooAgent: 
  enabled: true
  relay:
    authority: gloo-mesh-mgmt-server.gloo-mesh
    serverAddress: gloo-mesh-mgmt-server.gloo-mesh:9900
    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
      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.
      glooAgent.relay.rootTlsSecretAdd the name and namespace of the Kubernetes secret that holds the root CA credentials that you created earlier.
      glooAgent.relay.tokenSecretAdd the name, namespace, and key of the Kubernetes secret that holds the relay identity token that you created earlier.
      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, and client TLS 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, and client TLS certificates, and store them as the following Kubernetes secrets in the gloo-mesh namespace:

      • relay-server-tls-secret that holds the server TLS certificate for the Gloo management server
      • relay-client-tls-cert that holds the client TLS certificate for the Gloo agent
      • telemetry-root-secret that holds the certificate chain information for the telemetry collector agent

      You can use your preferred PKI provider to create the TLS certificates or follow the steps in Create TLS certificates with OpenSSL to create them by using OpenSSL.

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

        
glooMgmtServer:
  enabled: true
  registerCluster: true
  relay:
    disableCa: true
    disableCaCertGeneration: true
    disableTokenGeneration: true
    tlsSecret:
      name: relay-server-tls-secret
      namespace: gloo-mesh
    tokenSecret:
      key: null
      name: null
      namespace: null
  serviceType: ClusterIP
glooAgent:
  enabled: true
  relay:
    clientTlsSecret:
      name: relay-client-tls-cert
      namespace: gloo-mesh
    serverAddress: gloo-mesh-mgmt-server.gloo-mesh:9900
    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
      glooMgmtServer.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.
      glooMgmtServer.relay.disableCaCertGenerationDisable the generation of self-signed certificates to secure the relay connection between the Gloo management server and agent.
      glooMgmtServer.relay.disableTokenGenerationDisable the generation of relay identity tokens.
      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.tokenSecretSet all values to null to instruct the Gloo management server to not use identity tokens to establish initial trust with Gloo agents.
      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.tokenSecretSet all values to null to instruct the Gloo agent to not use identity tokens to establish initial trust with the Gloo management server.
      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. For more information, see Self-signed CAs with automatic client certificate rotation.

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

      
glooMgmtServer:
  enabled: true
glooAgent: 
  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 the server TLS certificate and certificate chain information. To create the TLS certificate, you can use your preferred PKI provider or follow the steps in BYO server certificates to create a custom server TLS certificate by using OpenSSL. Store this information in the following secrets in the gloo-mesh namespace.
      • 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.
      • telemetry-root-secret: The root CA certificate for the certificate chain.
    2. In your Helm values file, add the following values.
        
glooMgmtServer:
  serviceType: ClusterIP
  registerCluster: true
  enabled: true
  relay: 
    tlsSecret:
      name: relay-server-tls-secret-custom
      namespace: gloo-mesh
  extraEnvs: 
    RELAY_TOKEN: 
      value: "My token"
    RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION: 
      value: "true" 
glooAgent:
  enabled: true
  relay:
    serverAddress: gloo-mesh-mgmt-server.gloo-mesh:9900
  extraEnvs:
    RELAY_TOKEN: 
      value: "My token"
    RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION: 
      value: "true"
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
      glooMgmtServer.relay.tlsSecret.nameThe name and namespace of the Kubernetes secret where you stored your custom server TLS certificate.
      glooMgmtServer.extraEnvs.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 to allow the Gloo agent to connect to the Gloo management server.
      glooMgmtServer.extraEnvs.
      RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION      		Set 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.
      glooAgent.extraEnvs.
      RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION      		Set 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.

    Use Gloo Mesh Gateway to create a self-signed server TLS certificate that the Gloo management server presents when the Gloo agent connects. For more information, see Self-signed server TLS certificate.

    In your Helm values file, add the following values.

      
glooMgmtServer:
  serviceType: ClusterIP
  registerCluster: true
  enabled: true
  extraEnvs: 
    RELAY_TOKEN: 
      value: "My token"
    RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION: 
      value: "true" 
glooAgent:
  enabled: true
  relay:
    serverAddress: gloo-mesh-mgmt-server.gloo-mesh:9900
  extraEnvs:
    RELAY_TOKEN: 
      value: "My token"
    RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION: 
      value: "true"
    Helm valueDescription
    glooMgmtServer.extraEnvs.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. You must set the same value in glooAgent.extraEnvs.RELAY_TOKEN.value to allow the Gloo agent to connect to the Gloo management server.
    glooMgmtServer.extraEnvs.
    RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION    		Set 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.
    glooAgent.extraEnvs.RELAY_TOKENUse the same value that you set in glooMgmtServer.extraEnvs.RELAY_TOKEN.
    glooAgent.extraEnvs.
    RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION    		Set 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.

  5. 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-agent pod, such as cpu: 500m and memory: 512Mi.
    glooAnalyzer.enabled
    glooInsightsEngine.enabled    		Enable the Gloo insights engine and analyzer, which are recommended to help you improve the security and observability of your environment by creating actionable Istio insights.
    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.
    extAuthService.enabledSet to true to install the external auth server add-on.
    istioInstallationsThe default supported version of Istio is used to install the managed gateway proxies. You can instead choose the Istio version you want to use for your gateway proxy. For an example of how this section might look, see Example istioInstallations settings.
    NOTE: To manage the gateway proxies yourself instead of the gateway lifecycle manager in this Helm chart, set istioInstallations.enabled to false, and manually deploy gateway proxies.
    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.
    rateLimiter.enabledSet to true to install the rate limit server add-on.
    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.

  6. Use the customizations in your Helm values file to install the Gloo Mesh Gateway components in your cluster.

      helm upgrade -i gloo-platform gloo-platform/gloo-platform \
    -n gloo-mesh \
    --version $GLOO_VERSION \
    --values gloo-single.yaml \
    --set common.cluster=$CLUSTER_NAME \
    --set licensing.glooGatewayLicenseKey=$GLOO_MESH_GATEWAY_LICENSE_KEY

    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:gloo-mesh
oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
oc adm policy add-scc-to-group anyuid system:serviceaccounts:gloo-mesh-gateways
oc adm policy add-scc-to-group anyuid system:serviceaccounts:gm-iop-1-23

    2. Create the gloo-mesh-gateways project, and create a NetworkAttachmentDefinition custom resource for the project.

        kubectl create ns gloo-mesh-gateways

cat <<EOF | oc -n gloo-mesh-gateways create -f -
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: istio-cni
EOF

    3. Install Gloo Mesh Gateway.

        helm upgrade -i gloo-platform gloo-platform/gloo-platform \
    -n gloo-mesh \
    --version $GLOO_VERSION \
    --values gloo-single.yaml \
    --set common.cluster=$CLUSTER_NAME \
    --set licensing.glooGatewayLicenseKey=$GLOO_MESH_GATEWAY_LICENSE_KEY

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

Verify the installation

  1. 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 license is 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 Gloo agent is running and connected to the management server.
      meshctl check

    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 | ext-auth-service               | 1/1   | Healthy
gloo-mesh | gloo-mesh-agent                | 1/1   | Healthy
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 | prometheus-server              | 1/1   | Healthy
gloo-mesh | rate-limiter                   | 1/1   | Healthy

🟢 Mgmt server connectivity to workload agents

Cluster | Registered | Connected Pod                                   
test    | true       | gloo-mesh/gloo-mesh-mgmt-server-558cddbbd7-rf2hv

Connected Pod                                    | Clusters
gloo-mesh/gloo-mesh-mgmt-server-558cddbbd7-rf2hv | 1

  2. Verify that the gateway proxy service is created and assigned an external address. It might take a few minutes for the load balancer to deploy. Note: If you did not deploy a managed gateway proxy through the Helm installation, manually deploy the gateway proxy instead.

      kubectl get svc -n gloo-mesh-gateways

    Example output:

      NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                                      AGE
istio-ingressgateway       LoadBalancer   10.XX.X.XXX    34.XXX.XXX.XXX   15021:30826/TCP,80:31257/TCP,443:30673/TCP,15443:30789/TCP   48s

Example istioInstallations settings

You can customize the istioInstallations section of your Helm values files in the following ways.

  • hub: Specify a Solo repo key that you can get by logging in to the Support Center and reviewing the Istio images built by Solo.io support article.
  • tag: Specify the version that you downloaded and append the solo tag, which is required to use many enterprise features, such as 1.23.2-patch1-solo. You can append other tags for the Solo distribution of Istio, as described in About the Solo distribution of Istio. Note: The Istio lifecycle manager is supported only for Istio versions 1.15.4 or later.
  • revision and gatewayRevision: Take the Istio major and minor versions and replace the period with a hyphen, such as 1-23. Note: For testing environments only, you can deploy a revisionless installation by omitting the revision and gatewayRevision fields entirely. Revisionless installations permit in-place upgrades, which are quicker than the canary-based upgrades that are required for revisioned installations. Note that if you deploy multiple Istio installations in the same cluster, only one installation can be revisionless.
  • k8s.serviceAnnotations: You can optionally provide cloud provider-specific service annotations for the gateway load balancer, such as the following annotations for AWS.
  • skipUpgradeValidation: When set to true, the lifecycle manager allows you to perform in-place upgrades by skipping checks that are required for canary upgrades. In production environments, canary upgrades are recommended for updating the minor version. To update the patch version or make configuration changes within the same version, you can use in-place upgrades. Be sure to test in-place upgrades in development or staging environments first.
  
istioInstallations:
  controlPlane:
    enabled: true
    installations:
      - istioOperatorSpec:
          hub: $repo_key
          tag: 1.23.2-patch1-solo
        revision: 1-23
        skipUpgradeValidation: true
  enabled: true
  northSouthGateways:
    - enabled: true
      name: istio-ingressgateway
      installations:
        - clusters:
          - activeGateway: true
            name: $CLUSTER_NAME
          skipUpgradeValidation: true
          gatewayRevision: 1-23
          istioOperatorSpec:
            hub: $repo_key
            tag: 1.23.2-patch1-solo
            # Optional load balancer annotations
            components:
              ingressGateways:
              - enabled: true
                k8s:
                  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

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:

  • Monitor and observe your environment with Gloo Mesh Gateway’s built-in telemetry tools.
    • Enable insights to review and improve your setup’s health and security posture.

    Help and support: