☰
Navigation :

Deployment Options

Gloo Gateway is a flexible architecture that can be deployed on a range of infrastructure stacks. If you’ll recall from the Architecture document, Gloo Gateway contains the following components at a logical level.

Component Architecture

In an actual deployment of Gloo Gateway, components like storage, secrets, and endpoint discovery must be supplied by the infrastructure stack. Gloo Gateway also requires a place to launch the containers that comprise both Gloo Gateway and Envoy. The following sections detail potential deployment options along with links to the installation guide for each option.

The options included are:

It is also possible to use Docker Compose for container management and the local file system for configuration and secrets management. These are development scenarios and should not be considered for a production deployment. Using Kubernetes or HashiCorp products are the two major ways to provide the necessary storage, secrets, and container management components in a production scenario.

Kubernetes using Kubernetes primitives

The simplest and most common deployment option for Gloo Gateway is using Kubernetes to orchestrate the deployment of Gloo Gateway, and using Kubernetes primitives like Custom Resources and Config Maps. The diagram below shows an example of how Gloo Gateway might be deployed on Kubernetes and how each primitive is leveraged to match the component architecture.

Kubernetes Architecture

Pods and Deployments

The following components of Gloo Gateway are deployed as separate pods and deployments:

Each deployment creates a replica set for the pods, which can be used to scale the number of pods and perform rolling upgrades.

Services

Along with the pods and deployments, three services are created.

The gloo service is what exposes the xDS Server running in Gloo Gateway.

ConfigMaps

There are two ConfigMaps created by default:

The gateway-proxy-envoy-config ConfigMap does not contain information about the routing, Upstreams, or Virtual Services. It only contains information about the Envoy configuration itself. This ConfigMap is mounted as a volume on any gateway-proxy pods.

Secrets

Gloo Gateway makes use of secrets in Kubernetes to store tokens, certificates, and Helm release info. The following secrets should be present by default.

Gloo Gateway makes use of certificates for validation and authentication. When Gloo Gateway is installed in gateway mode, it runs a job to generate certificates. The resulting certificate is stored in a Kubernetes secret called gateway-validation-certs, and mapped as a volume to the gloo pods.

Custom Resource Definitions

When Gloo Gateway is installed on Kubernetes, it creates a number of Custom Resource Definitions that Gloo Gateway can use to store data. The following table describes each Custom Resource Definition, its grouping, and its purpose.

Name Grouping Purpose
Settings gloo.solo.io Global settings for all Gloo Gateway components.
Gateway gateway.solo.io Describes a single Listener and the routing Upstreams reachable via the Gateway Proxy.
VirtualService gateway.solo.io Describes the set of routes to match for a set of domains.
RouteTable gateway.solo.io Child Routing object for the Gloo Gateway.
Proxy gloo.solo.io A combination of Gateway resources to be pushed by Gloo Gateway to the Envoy proxy.
Upstream gloo.solo.io Upstreams represent destinations for routing HTTP requests.
UpstreamGroup gloo.solo.io Defining multiple Upstreams or external endpoints for a Virtual Service.
AuthConfig enterprise.gloo.solo.io User-facing authentication configuration

You can find out more about deploying Gloo Gateway on Kubernetes by following this guide.

HashiCorp Consul, Vault, and Nomad

Gloo Gateway can use some of the HashiCorp products to provide the necessary primitives for container management, persistent storage, and secrets management. The diagram below provides and example of how HashiCorp products could be used to host a Gloo Gateway deployment.

HashiCorp Example

Containers and Jobs

HashiCorp’s Nomad is a a popular workload scheduler that can be used in place of, or in combination with Kubernetes as a way of running long-lived processes on a cluster of hosts. Nomad supports native integration with Consul and Vault, making configuration, service discovery, and credential management easy for application developers.

Nomad is used to deploy the Gloo Gateway containers by using Gloo Gateway deployment jobs. Similar to a Kubernetes deployment, each Nomad job defines a set of deployment tasks for the various Gloo Gateway components. There are four jobs in total which deploy the following container groups:

Within the definition of each task is the port mappings and service names for each group of containers.

Services and Configuration

HashiCorps’s Consul is a service networking solution to connect and secure services across multiple platforms. It can also store arbitrary key/value pairs. In the case of a Gloo Gateway deployment, Consul is used to publish and resolve the networking services published by the Gloo Gateway container groups and hold configuration information about Gloo Gateway objects like Upstreams, Envoy configs, and Virtual Services.

The Services component of Consul publishes the services: consul, gateway-proxy, gloo-xds, nomad, and nomad-client. It will also publish other services deployed through Nomad, which the Discovery service can find and push into the Upstream listing.

The Key/Value component of Consul holds data at the following paths:

The configuration data that would typically be housed in a ConfigMap or Custom Resource on Kubernetes is instead held in one of the above paths on Consul’s Key/Value store.

Consul also supports service discovery, which is added to Gloo Gateway by publishing a Key/Value entry to the path gloo/gloo.solo.io/v1/Upstream.

Secrets

HashiCorp’s Vault is secrets lifecycle management solution providing secure, tightly controlled access to tokens, passwords, certificates, and encryption keys.

You can find out more about deploying Gloo Gateway using HashiCorp solutions by following Gateway guides.

Next Steps

Now that you have a basic understanding of the deployment options for Gloo Gateway, there are number of potential next steps that we’d like to recommend.