Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
41 lines (28 sloc) 3.01 KB

Traffic routing

Public end-user traffic routing


Public facing applications are named by default, and a wildcard DNS entry will make sure this hostname resolves to the cloud provider's load-balancer.
(Additional names can be added as a configuration parameter in the Application definition.)
The loadbalancer will forward traffic to the cluster's public Istio ingress gateway, who in turn sends traffic to the application.

Private end-user traffic routing

The same application will also receive a name and and ingress that is only accessible from a private network The difference from the public facing route, is that the application's internal URI's are exposed. Internal URI's can be defined in the Application definition and is enforced by an Istio virtual service

External to internal service routing

If an application running in a public cloud environment needs to communicate with an on-premise application, a configuration parameter needs to be added to the Application definition. This will create an Istio destination rule that allows egress traffic from the cluster. Once traffic has been allowed out of the cluster, it will traverse a VPN connection terminated on-premise. The only services available directly on the VPN are those who have implemented the Azure AD token authorization flow.

On-prem applications that haven't yet implemented token authentication will only be available through the use of either API-gateway or service-gateway.


Public end-user traffic to on-prem cluster

When routing end-user traffic to on-prem cluster, applications will be presented on, and the default policy is to forward traffic to the AM policy enforcement point. If the path match not-enforced-urls or has a valid token, the traffic will be forwarded to the internal loadbalancer, which in turn directs the traffic to the cluster's ingress controller.

All default routing is automatically configured for the application, but AM configuration is required: AM configuration toonprem

Internal traffic cluster flow

For our internal cluster we have four separate loadbalancers in front. Two of them are only exposed on our internal network, and all applications with an ingress on the cluster will be exposed on both appname.clustername._internal.domain and The two remaining loadbalancers are exposed to external networks.
One of them is a dedicated virtual server in front of the API-server, the other is for applications that are secured using Azure AD token authorization


You can’t perform that action at this time.