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:

Automatic Gloo Edge Routing

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

Shared routing for API Products in an Environment

By default, Gloo Portal assumes that an APIDoc resource is bundled into only one APIProduct within an Environment. If you have multiple APIProducts in the same Environment, the same APIDoc cannot be shared between APIProducts because this causes conflicts and unexpected behavior.

If you need to share an APIDoc between multiple APIProducts within the same Environment, you can enable the FEATURE_SHARED_API_DOCS feature in Gloo Edge. This feature ensures that when a user tries to access a route on a shared APIDoc, the user is correctly authorized and rate limited according to the usage plan of the respective APIProduct. For example, let's say you have an APIDoc that defines the GET /foo route. You include this APIDoc in two APIProducts: APIProduct A with a usage plan that allows 5 requests per minute, and APIProduct B with a usage plan that allows 10 requests per minute. If the user uses an API key that is associated with the usage plan in APIProduct A, the user is rate limited after 5 requests per minute. If an API key is used that is associated with APIProduct B, the user is rate limited after 10 requests per minute.

Routing for shared APIDocs within one Environment works only if the route that the user tries to access is exactly the same, meaning that the same backend(s) and the same HTTP option must be used. If the routes are different, such as by pointing to different backends, routing might only work for one APIDoc and not the other.

To enable shared APIDocs, upgrade your Gloo Edge installation and set FEATURE_SHARED_API_DOCS to true in the Gloo Edge Helm chart as shown in the following example. For more information about how to upgrade Gloo Edge, see the setup instructions.

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

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