Ingress And Routing Model
How Runtime exposes services and routes traffic.
Runtime uses several cooperating components to expose services safely and predictably.
Main roles
| Component | Main role |
|---|---|
| Gateway API (Envoy Gateway) | primary ingress controller for all HTTP(S) traffic |
| MetalLB | provides external load-balancer behavior in self-managed environments |
| External DNS | publishes DNS records for exposed services |
| cert-manager | manages certificates and TLS lifecycle |
Typical traffic path
A common Runtime request path looks like this:
- a hostname is published through External DNS
- TLS is managed through cert-manager
- traffic reaches a service exposed by MetalLB or directly through a cloud load balancer
- Gateway API routes the request based on
HTTPRouterules attached to the sharedGatewayresource - the request is forwarded to the target Runtime or higher-layer service
Gateway API
The platform uses Gateway API (Envoy Gateway) as the primary ingress controller. Each platform component defines its own HTTPRoute resource that registers its endpoints with a shared Gateway.
This model replaces the previous NGINX and APISIX-based ingress stack. Key differences:
- HTTPRoute resources replace
Ingressresources — routing is defined per-component, not centrally - Envoy is the data plane — the
EnvoyProxyconfiguration andGatewayClassare managed by the platform - Gateway is a shared cluster resource — all components route through it, with TLS certificates referenced from cert-manager
Previous ingress components
NGINX and APISIX were used in previous versions of the platform. They have been replaced by Gateway API starting with version 1.2.0. See the NGINX and APISIX pages for reference.
Why this matters
The routing model is one of the most visible parts of Runtime because it defines how users, systems, and services reach the platform. It is also one of the main places where network exposure, DNS, TLS, and access control come together.