Ingress and Egress Control
The features on the other pages mostly govern traffic between services already inside the mesh. Istio also controls traffic at the edge of the mesh: requests coming in from outside the cluster (ingress) and requests going out to external systems (egress).
Ingress
An Istio ingress gateway manages traffic entering the mesh. It runs as a dedicated Envoy proxy at the edge and is configured with Istio traffic policy, so the same routing, resilience, and security rules you use inside the mesh also apply at the entry point.
An ingress gateway commonly works with:
- A Kubernetes
Serviceof typeLoadBalancerthat exposes the gateway - An Istio
Gatewayresource that defines ports, hosts, and protocols - An Istio
VirtualServicethat routes matching inbound traffic to in-mesh services
This lets you, for example, route /api and /web to different services, split inbound traffic between versions, match on headers, or terminate TLS at the edge.
Info
The ingress gateway is required only for traffic entering the mesh from outside the cluster. It is not required for routing traffic between services that are already in the mesh - that is handled by VirtualService and DestinationRule on their own. See Traffic Management
.
Egress
Egress control manages traffic leaving the mesh to external services. An egress gateway gives you a single, policy-controlled exit point, which is useful when you need to monitor, secure, or restrict outbound calls (for example, to meet compliance requirements).
| Resource | Purpose |
|---|---|
Gateway | Defines how traffic enters or exits the mesh at a gateway proxy |
ServiceEntry | Registers an external service so the mesh can route to and apply policy to it |
Sidecar | Scopes which services a workload’s proxy knows about, including egress reachability |
When to Use It
- Exposing mesh services to users with consistent edge policy
- Terminating TLS and applying routing at a single managed entry point
- Forcing outbound traffic through a controlled, observable exit point