Navigation :

Routing

Learn about how routing works in Gloo Portal.

Overview

Normally when service APIs are exposed to ingress traffic in Kubernetes, a separate routing configuration is required, such as Kubernetes Ingress Objects, Istio Virtual Services, or . Gloo Edge Virtual Services.

The HTTP configurations specified in these ingress routes must match exactly with the service APIs provided by the backend, or risk bugs, service outages, and undefined behaviors. Furthermore, correlating the traffic handled by the ingress with the APIs it exposes is a tedious task, requiring network administrators to have intricate knowledge of Developer APIs, or place the burden of network administration directly on developers.

Using this kind of “raw ingress” to track client identity and enforce policy is even more complex. Typically, API vendors wish to expose the same API functionality with policies that differ depending on the client, such as the ability to differentiate between “basic” and “premium” usage plans.

The Gloo Portal Routing features are designed to explicitly address these problems. Routing is defined in each version of an API Product. Rate limiting and authorization are defined per instance of an API Product in an Environment.

The Gloo Portal Routing features automatically configure the underlying networking implementation (Istio or Gloo Edge) using supported API Specifications as the source of configuration.

Gloo Portal users bundle their APIs into API Products and expose them through Environments, wherein they define ingress, authorization, and rate limiting policies which will automatically be attached to the exposed API endpoints.

Routes generated directly from these API Products provide per-API access logging and monitoring. These routes are automatically integrated with the Gloo Portal's Auth Server and Rate Limiter to apply security and usage policies defined in each Environment.

Automatic Istio Routing

When targeting Istio Gateways, Gloo Portal manages a set of Istio Custom Resource Definitions (CRDs) on behalf of users:

VirtualServices: The Gloo Portal generates an Istio VirtualService for each API Product. The VirtualService contains a single HTTP route for each API operation exposed in the product. Routes are named and their matchers are derived from the OpenAPI definition.
DestinationRules: The Gloo Portal generates an Istio DestinationRule for each unique Kubernetes Service Subset defined as an API Product destination.
EnvoyFilters: The Gloo Portal generates EnvoyFilters to configure the Istio Gateway (Envoy) to communicate with the Gloo Portal ExtAuth amd RateLimit services. Additional EnvoyFilters are generated to apply per-route auth and rate limit policies.

Automatic Gloo Edge Routing

When targeting Gloo Edge, Gloo Portal manages a set of Gloo Edge Custom Resource Definitions (CRDs) on behalf of users:

RouteTables: Gloo Portal generates a Gloo Edge RouteTable for each APIProduct version published in an Environment. Each RouteTable will contain an HTTP route for each API operation exposed in the APIProduct.
VirtualServices: Gloo Portal generates a Gloo Edge VirtualService for each Environment. The VirtualService will delegate routing decisions to the RouteTables that have been generated for the APIProduct versions that are published in the Environment.

Shared routing for API Products in an Environment

Gloo Portal generates a route for each API operation in each API Product. As such, you might have multiple API Products in the same Environment share the same route name. In such cases, traffic on that route works for one API Product’s route, but not for any other. For example, if both API Products use API Key auth, then API keys for exactly one API Product are authorized while others get 4xx responses. You cannot set which API Product works through the Portal resource, and the API Product can change whenever the Portal resource is modified.

Instead, you can use shared routes. With this feature enabled, if you have an API Key or API Key plus OAuth auth policies that grant access to a shared route, auth will work as expected for all API Products that share the route. Portal will use metadata from the auth configuration to associate requests with the correct API Products and apply subsequent policies like rate limiting accordingly.

Warning: Shared routes are a beta feature, and available only for Gloo Edge routing, not Istio.

When you enable shared routes, the following Portal features are not supported:

OAuth-only Usage Plans
Unauthorized Usage Plans

To enable routing using shared routes among API Products in an Environment, reinstall Gloo with additional Helm values. You can follow the setup instructions. In step 2, include the following values in the Helm values override file:

cat << EOF > gloo-values.yaml
glooEdge:
  enabled: true
licenseKey:
  secretRef:
    name: license
    namespace: gloo-system
    key: license-key
glooPortal:
  env:
  - name: FEATURE_SHARED_API_DOCS
    value: "true"
EOF