Navigation :

Installation options

Learn about your options for installing Gloo Gateway in your environment.

meshctl profiles

In Gloo Gateway version 2.3 and later, you can use profiles that are packaged in the meshctl CLI for quick Gloo Gateway installations. Profiles provide basic Helm settings for a minimum installation, and are suitable for testing setups.

In your meshctl install and meshctl cluster register commands, you can specify one or more profiles in the --profile flag. Multiple profiles can be applied in a comma-delimited list, in which merge priority is left to right. Note that any values you specify in --set or --gloo-mesh-agent-chart-values flags have highest merge priority.

The following profiles are supported. You can review the Helm settings in a profile by running curl https://storage.googleapis.com/gloo-platform/helm-profiles/2.4.2/<profile>.yaml > profile-values.yaml. You can also check out Gloo Mesh-specific profiles in the Gloo Mesh setup documentation.

Demo profiles

The following profiles provide “all-in-one” setups that are suitable for demo environments. To set up Gloo Gateway with these profiles, see the single-cluster or multicluster getting started guides.

Kubernetes
OpenShift

Profile	Use case	Deployed components
`gloo-gateway-demo`	Set up a Gloo Gateway demo environment in a single-cluster Kubernetes setup.	Gloo management server, Gloo agent, Gloo external auth server, Gloo rate limiting server, Gloo UI, Prometheus, Redis, Gloo OpenTelemetry (OTel) collector agents, managed gateway proxy

Profile	Use case	Deployed components
`gloo-gateway-demo-openshift`	Set up a Gloo Gateway demo environment in a single-cluster OpenShift setup. Includes required settings for Istio functionality in OpenShift.	Gloo management server, Gloo agent, Gloo external auth server, Gloo rate limiting server, Gloo UI, Prometheus, Redis, Gloo OTel collector agents, managed gateway proxy

Standard profiles

The following profiles provide standard setups, which can be useful starting points for building a customized and robust set of Helm installation values. To set up Gloo Gateway with these profiles, see the single-cluster or multicluster setup guides.

Kubernetes
OpenShift

Profile	Use case	Deployed components
`gloo-gateway-single`	Set up all Gloo Gateway components in a single-cluster Kubernetes setup.	Gloo management server, Gloo agent, Gloo UI, Prometheus, Redis, Gloo OTel collector agents, managed gateway proxy
`mgmt-server`	Set up a Gloo Platform product in the management cluster in a multicluster Kubernetes setup. Default profile for `meshctl install`.	Gloo management server, Gloo UI, Prometheus, Redis, Gloo OTel gateway
`agent`	Register a workload cluster in a multicluster Kubernetes setup. Default profile for `meshctl cluster register`.	Gloo agent, Gloo OTel collector agents

Profile	Use case	Deployed components
`gloo-gateway-single-openshift`	Set up all Gloo Gateway components in a single-cluster OpenShift setup. Includes required settings for Istio functionality in OpenShift.	Gloo management server, Gloo agent, Gloo UI, Prometheus, Redis, Gloo OTel collector agents, managed gateway proxy
`mgmt-server-openshift`	Set up a Gloo Platform product in the management cluster in a multicluster OpenShift setup. Includes required settings for Istio functionality in OpenShift.	Gloo management server, Gloo UI, Prometheus, Redis, Gloo OTel gateway
`agent-openshift`	Register a workload cluster in a multicluster OpenShift setup. Includes required settings for Istio functionality in OpenShift.	Gloo agent, Gloo OTel collector agents

Add-on profiles

The following profiles install Gloo Platform add-ons, which are often used additively with standard profiles. To set up add-ons with these profiles, see the rate limiting and external authentication or portal setup guides.

Kubernetes
OpenShift

Profile	Use case	Deployed components
`extauth`	Use external authentication in a single-cluster setup or in a workload cluster in a multicluster setup.	Gloo external auth server
`portal`	Deploy Gloo Portal in a single-cluster setup or in a workload cluster in a multicluster Kubernetes setup. Uses the local Redis instance as the backing storage.	Gloo Portal server, Gloo external auth server, Gloo rate limiting server
`ratelimit`	Use rate limiting in a single-cluster setup or in a workload cluster in a multicluster setup.	Gloo rate limiting server

Profile	Use case	Deployed components
`extauth`	Use external authentication in a single-cluster setup or in a workload cluster in a multicluster setup.	Gloo external auth server
`portal-openshift`	Deploy Gloo Portal in a single-cluster setup or in a workload cluster in a multicluster OpenShift setup. Uses the local Redis instance as the backing storage. Includes required settings for Istio functionality in OpenShift.	Gloo Portal server, Gloo external auth server, Gloo rate limiting server
`ratelimit`	Use rate limiting in a single-cluster setup or in a workload cluster in a multicluster setup.	Gloo rate limiting server

gloo-platform Helm chart

In Gloo Platform version 2.3 and later, all Gloo Platform components are available in a single Helm chart, gloo-platform. Additionally, the custom resource definitions (CRDs) that are required by Gloo Platform controllers are maintained by the gloo-platform-crds Helm chart.

Helm installations allow for extensive customization of Gloo settings, and are suitable for proof-of-concept or production setups. Within the gloo-platform chart, you can find the configuration options for all components in the following sections.

Component section	Description
`clickhouse`	Configuration for the Clickhouse deployment, which stores logs from Gloo Platform Telemetry Collectors. See the Bitnami Clickhouse Helm chart for the complete set of values.
`common`	Common values shared across components. When applicable, these can be overridden in specific components.
`demo`	Demo-specific features that improve quick setups. Do not use in production.
`experimental`	Experimental features for Gloo Platform. Disabled by default. Do not use in production.
`extAuthService`	Configuration for the Gloo external authentication service.
`glooAgent`	Configuration for the Gloo agent.
`glooMgmtServer`	Configuration for the Gloo management server.
`glooNetwork`	Gloo Network configuration options.
`glooPortalServer`	Configuration for the Gloo Platform Portal server deployment.
`glooSpireServer`	Configuration for the Gloo Platform Spire server deployment.
`glooUi`	Configuration for the Gloo UI.
`istioInstallations`	Configuration for deploying managed Istio control plane and gateway installations by using the Istio lifecycle manager.
`jaeger`	Configuration for the Gloo Platform Jaeger instance.
`legacyMetricsPipeline`	Configuration for the legacy metrics pipeline, which is unsupported in Gloo Platform version 2.4 and later.
`licensing`	Gloo Platform product licenses.
`postgresql`	Configuration for Gloo Platform PostgreSQL instance.
`prometheus`	Helm values for configuring Prometheus. See the Prometheus Helm chart for the complete set of values.
`rateLimiter`	Configuration for the Gloo rate limiting service.
`redis`	Configuration for the default Redis instance.
`sidecarAccel`	Experimental: Configuration for eBPF sidecar acceleration. Do not use in production.
`telemetryCollector`	Configuration for the Gloo Platform Telemetry Collector. See the OpenTelemetry Helm chart for the complete set of values.
`telemetryCollectorCustomization`	Optional customization for the Gloo Platform Telemetry Collector.
`telemetryGateway`	Configuration for the Gloo Platform Telemetry Gateway. See the OpenTelemetry Helm chart for the complete set of values.
`telemetryGatewayCustomization`	Optional customization for the Gloo Platform Telemetry Gateway.

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.4.2 > all-values.yaml. You can also see these fields in the Helm values documentation.

To set up Gloo Gateway with Helm, see the single-cluster or multicluster setup guides.

Looking for Helm charts such as gloo-mesh-enterprise and gloo-mesh-agent? In Gloo Platform 2.5 and later, these Helm charts are unsupported, and are replaced by the gloo-platform chart. For more information, see the migration guide.

Supported platforms

You can install Gloo Mesh on Kubernetes or OpenShift clusters. For more information about the requirements for clusters on each platform, see the System requirements.

Kubernetes

Gloo Gateway and Istio are fully supported on Kubernetes clusters. Throughout the installation guides, use installation commands that are labeled for use with Kubernetes.

OpenShift

Gloo Gateway is fully supported on OpenShift clusters. However, there are some changes you must make to allow Istio to run on an OpenShift cluster. To make these changes, use commands througout the installation guides that are labeled for use with OpenShift. For more information about the required changes, see the Istio on OpenShift documentation.

Dynamic user ID: The pods of all the Gloo Gateway component's deployments must be assigned a dynamic user ID for the Istio sidecar to use. However, this user ID is not permitted in OpenShift by default. In the installation guides, follow the OpenShift commands to use OpenShift-specific install profiles, which include the floatingUserId=true installation setting for each Gloo Gateway component. For example, you might use the gloo-gateway-single-openshift profile.
Service account permissions: For any pods that require an Istio sidecar, you must elevate the permissions of the service account for that namespace. For example, in Gloo Gateway, the ingress gateway proxy requires an Istio sidecar. If you also use Gloo Mesh, your workload pods also require sidecars to be included in your service mesh. These elevated permissions allow the pods to make use of a user ID that is normally restricted by OpenShift. In the installation guides, you follow the OpenShift commands to elevate the service account permissions for the Istio namespaces.
Network attachment definition: The CNI on OpenShift requires a NetworkAttachmentDefinition in each workload project in order to invoke the istio-cni plug-in. For example, in Gloo Gateway, you must create a NetworkAttachmentDefinition in the ingress gateway namespace, and in each workload namespace where you run applications in your service mesh.