Source File: github.com/solo-io/gloo/projects/gateway/api/v1/virtual_service.proto
The VirtualService is the root Routing object for the Gloo Gateway. A virtual service describes the set of routes to match for a set of domains.
It defines: - a set of domains - the root set of routes for those domains - an optional SSL configuration for server TLS Termination - VirtualHostPlugins that will apply configuration to all routes that live on the VirtualService.
Domains must be unique across all virtual services within a gateway (i.e. no overlap between sets).
VirtualServices can delegate routing behavior to the RouteTable resource by using the
delegateAction on routes.
An example configuration using two VirtualServices (one with TLS termination and one without) which share a RouteTable looks as follows:
# HTTP VirtualService: apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: name: 'http' namespace: 'usernamespace' spec: virtualHost: domains: - '*.mydomain.com' - 'mydomain.com' routes: - matcher: prefix: '/' # delegate all traffic to the `shared-routes` RouteTable delegateAction: name: 'shared-routes' namespace: 'usernamespace'
# HTTPS VirtualService: apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: name: 'https' namespace: 'usernamespace' spec: virtualHost: domains: - '*.mydomain.com' - 'mydomain.com' routes: - matcher: prefix: '/' # delegate all traffic to the `shared-routes` RouteTable delegateAction: name: 'shared-routes' namespace: 'usernamespace' sslConfig: secretRef: name: gateway-tls namespace: gloo-system
# the RouteTable shared by both VirtualServices: apiVersion: gateway.solo.io/v1 kind: RouteTable metadata: name: 'shared-routes' namespace: 'usernamespace' spec: routes: - matcher: prefix: '/some-route' routeAction: single: upstream: name: 'some-upstream' ...
Delegated Routes are routes that use the
delegateAction routing action. Delegated Routes obey the following
- delegate routes must use
- delegated routes cannot specify header, query, or methods portion of the normal route matcher.
routePluginconfiguration will be inherited from parent routes, but can be overridden by the child
"virtualHost": .gateway.solo.io.VirtualHost "sslConfig": .gloo.solo.io.SslConfig "displayName": string "status": .core.solo.io.Status "metadata": .core.solo.io.Metadata
||.gateway.solo.io.VirtualHost||The VirtualHost contains the The list of HTTP routes define routing actions to be taken for incoming HTTP requests whose host header matches this virtual host. If the request matches more than one route in the list, the first route matched will be selected. If the list of routes is empty, the virtual host will be ignored by Gloo.|
||.gloo.solo.io.SslConfig||If provided, the Gateway will serve TLS/SSL traffic for this set of routes.|
||Display only, optional descriptive name. Unlike metadata.name, DisplayName can be any string and can be changed after creating the resource.|
||.core.solo.io.Status||Status indicates the validation status of this resource. Status is read-only by clients, and set by gloo during validation.|
||.core.solo.io.Metadata||Metadata contains the object metadata for this resource.|
Virtual Hosts serve an ordered list of routes for a set of domains.
An HTTP request is first matched to a virtual host based on its host header, then to a route within the virtual host.
If a request is not matched to any virtual host or a route therein, the target proxy will reply with a 404.
Unlike the Gloo Virtual Host,
Gateway* Virtual Hosts can delegate their routes to
"name": string "domains": string "routes": gateway.solo.io.Route "virtualHostPlugins": .gloo.solo.io.VirtualHostPlugins "corsPolicy": .gloo.solo.io.CorsPolicy
||deprecated. this field is ignored.|
||The list of domains (i.e.: matching the
||gateway.solo.io.Route||The list of HTTP routes define routing actions to be taken for incoming HTTP requests whose host header matches this virtual host. If the request matches more than one route in the list, the first route matched will be selected. If the list of routes is empty, the virtual host will be ignored by Gloo.|
||.gloo.solo.io.VirtualHostPlugins||Virtual host plugins contain additional configuration to be applied to all traffic served by the Virtual Host. Some configuration here can be overridden by Route Plugins.|
||.gloo.solo.io.CorsPolicy||Defines a CORS policy for the virtual host If a CORS policy is also defined on the route matched by the request, the policies are merged. DEPRECATED set cors policy through the Virtual Host Plugin.|
A route specifies how to match a request and what action to take when the request is matched.
When a request matches on a route, the route can perform one of the following actions:
- Route the request to a destination
- Reply with a Direct Response
- Send a Redirect response to the client
- Delegate the action for the request to a top-level
DelegateActions can be used to delegate the behavior for a set out routes with a given prefix to
"matcher": .gloo.solo.io.Matcher "routeAction": .gloo.solo.io.RouteAction "redirectAction": .gloo.solo.io.RedirectAction "directResponseAction": .gloo.solo.io.DirectResponseAction "delegateAction": .core.solo.io.ResourceRef "routePlugins": .gloo.solo.io.RoutePlugins
||.gloo.solo.io.Matcher||The matcher contains parameters for matching requests (i.e.: based on HTTP path, headers, etc.) For delegated routes, the matcher must contain only a
||.gloo.solo.io.RouteAction||This action is the primary action to be selected for most routes. The RouteAction tells the proxy to route requests to an upstream. Only one of
||.gloo.solo.io.RedirectAction||Redirect actions tell the proxy to return a redirect response to the downstream client. Only one of
||.gloo.solo.io.DirectResponseAction||Return an arbitrary HTTP response directly, without proxying. Only one of
||.core.solo.io.ResourceRef||delegate routing actions for the given matcher to a RouteTable the delegateAction config is simply the
||.gloo.solo.io.RoutePlugins||Route Plugins extend the behavior of routes. Route plugins include configuration such as retries, rate limiting, and request/response transformation. RoutePlugin behavior will be inherited by delegated routes which do not specify their own