This Post

I covered ASM egress and a bit of ingress in another post

Using ASM

Egress and Ingress Gateways.

Outbound

If running ASM in strict outbound mode - which should be the case if it’s not a development environment then we need to use a ServiceEntry.

There are multiple options and this post: ISTIO Egress Performance shows everything we need to know about the different options for egress.

I want to talk about 2: 1. ServiceEntry 2. Egress Gateway with mTLS.

ServiceEntry

A ServiceEntry allows adding a traffic route beyond what is already in the internal service registry, including external services. In other words, it’s used to define the IPs for hosts that are not part of the service mesh so the auto-discovery feature, part of service mesh, can route requests for that host…

⚠️ ServiceEntry can be namespace scoped or cluster wide. By default it’s cluster wide, so be careful allowing clients/tenants to declare cluster wide ServiceEntry as it can impact the entire cluster.

Create your own ServiceEntry: ISTIO ServiceEntry

Image from ISTIO Egress Performance: ServiceEntry example

Always prefer mTLS over TLS for more secure connections. It’s more work but if it’s a critical infrastructure then it’s worthy it.

Egress Gateway is probably the way to go if you are in a heavily regulated industry. With it you can use taints and tolerations to separate the egress gateway pods from the rest and better manage DLPs, filtering, etc in egress traffic.

Egress Gateway documentation - shows how to create your own.

How to configure components to use a EgressGateway - shows how to route traffic to Egress Gateway.

Image from ISTIO Egress Performance: Egress Gateway with mTLS

Taint and Toleration with nodeselector: Taint and Toleration with nodeselector

Just Taint and Toleration - We need a taint in the other nodepool so egress gateway doesnt get scheduled there: Just Taint and Toleration

Inbound

ASM Ingress is in another post.

VirtualService

VirtualService documentation

DestinationRule

A common use case for DestinationRule is that we can define “subsets” and with that we can change our VirtualService to route traffic based on that path. It’s useful in DR scenarios (another post) and blue/green deployments, for example.

DestinationRule documentation