Service Mesh Ingress: The Doorkeeper for Your Mesh

Why it exists

In a complex microservices architecture, you need a single, consistent way to manage how external users access your services. Without a centralized entry point, every service might expose itself differently, creating security holes and operational chaos. An Ingress Gateway was created to centralize this control at the edge of the mesh.

The mental model

Think of an Ingress Gateway as the main entrance and security desk for a large office building (your service mesh). It is the only way in for outside visitors. The security guard (the gateway) checks IDs (authentication), inspects packages (security policies), and directs visitors (routing) to the right floor (service). Internal employees (services) can move freely between floors (east-west traffic) via hallways (sidecar proxies), but all outside visitors (north-south traffic) must pass through the main desk.

How it works

The Ingress Gateway is a standalone Envoy proxy that runs in a pod at the edge of your cluster. You configure it with a Gateway resource (defining the port and protocol) and a VirtualService resource (defining the routing rules, like 'requests to /api/v1 go to the users-service'). When external traffic hits your cluster's load balancer, it's forwarded to the Ingress Gateway proxy. The gateway then applies your rules and forwards the request to the appropriate internal service, all within the mesh's secure and observable environment.

When to use it

Use an Ingress Gateway when you need to expose services in a service mesh to the outside world. It's essential for applying consistent security policies (like TLS termination), advanced traffic management (canary deployments, A/B testing), and getting uniform observability (metrics, logs, traces) for all incoming traffic. It is the standard, most powerful way to handle ingress in meshes like Istio.

When not to use it

For very simple applications with a single entry point and no need for advanced routing or mesh-specific policies, a standard Kubernetes Ingress object might be sufficient. If you are not using a service mesh at all, you would not use a service mesh ingress gateway, as it is specifically for managing traffic entering a mesh.

One canonical example

In Istio, you define a Gateway resource to open port 443 for HTTPS traffic. Then, you bind a VirtualService to that gateway, which says 'for requests to api.example.com, route traffic to the api-service on port 8080.' This decouples the exposure of the port from the routing logic, allowing you to change routing without touching the edge configuration.