Third Party Load Balancers
Istio provides both an ingress and service mesh implementation, which can be used together or separately. While these are designed to work together seamlessly, there are times when integrating with a third party ingress is required. This could be for migration purposes, feature requirements, or personal preferences.
Integration Modes
In “standalone” mode, the third party ingress is directly sending to backends. In this case, the backends presumably have Istio sidecars injected.
In this mode, things mostly just work. Clients in a service mesh do not need to be aware that the backend they are connecting to has a sidecar. However, the ingress will not use mTLS, which may lead to undesirable behavior. As a result, most of the configuration for this setup is around enabling mTLS.
In “chained” mode, we use both the third party ingress and Istio’s own Gateway in sequence. This can be useful when you want the functionality of both layers. In particular, this is useful with managed cloud load balancers, which have features like global addresses and managed certificates.
Cloud Load Balancers
Generally, cloud load balancers will work out of the box in standalone mode without mTLS. Vendor specific configuration is required to support chained mode or standalone with mTLS.
Google HTTP(S) Load Balancer
Integration with Google HTTP(S) Load Balancers only works out of the box with standalone mode if mTLS is not required as mTLS is not supported.
Chained mode is possible. See Google documentation for setup instructions.
In-Cluster Load Balancers
Generally, in-cluster load balancers will work out of the box in standalone mode without mTLS.
Standalone mode with mTLS can be achieved by inserting a sidecar into the Pod of the in-cluster load balancer. This typically involves two steps beyond standard sidecar injection:
Disable inbound traffic redirection. While not required, typically we only want to use the sidecar for outbound traffic - inbound connection from clients is already handled by the load balancer itself. This also allows preserving the original client IP address, which would otherwise be lost by the sidecar. This mode can be enabled by inserting the
traffic.sidecar.istio.io/includeInboundPorts: ""
annotation on the load balancerPod
s.Enable Service routing. Istio sidecars can only properly function when requests are sent to Services, not to specific pod IPs. Most load balancers will send to specific pod IPs by default, breaking mTLS. Steps to do this are vendor specific; a few examples are listed below but consulting with the specific vendor’s documentation is recommended.
Alternatively, setting the
Host
header to the service name can also work. However, this can result in unexpected behavior; the load balancer will pick a specific pod, but Istio will ignore it. See here for more information on why this works.
ingress-nginx
ingress-nginx
can be configured to do service routing by inserting an annotation on Ingress
resources:
nginx.ingress.kubernetes.io/service-upstream: "true"
Emissary-Ingress
Emissary-ingress defaults to using Service routing, so no additional steps are required.