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 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 Developer Portal Routing features are designed to explicitly address these problems. The Developer Portal Routing features automatically configure the underlying networking implementation (Istio or Gloo) using supported API Specifications as the source of configuration.
Developer Portal users bundle and expose their APIs in the form of API Products, 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 Developer Portal’s Auth Server and Rate Limiter to apply security and usage policies defined in each Product.
Automatic Istio Routing
When targeting Istio Gateways, the Developer Portal manages a set of Istio Custom Resource Definitions (CRDs) on behalf of users:
VirtualServices: The Developer 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.
EnvoyFilters: The Developer Portal generates EnvoyFilters to configure the Istio Gateway (Envoy) to communicate with the Developer Portal ExtAuth amd RateLimit services. Additional EnvoyFilters are generated to apply per-route auth and rate limit policies.
Automatic Gloo Routing
When targeting Gloo Gateways, the Developer Portal manages a set of Gloo Custom Resource Definitions (CRDs) on behalf of users:
VirtualServices: The Developer Portal generates a Gloo 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.
Upstreams: The Developer Portal generates a Gloo Upstream for each unique destination references in an API Product route.