Learn Istio - Gateways, Ingress & Egress

#Introduction

Traffic inside the mesh can now be managed. But applications do not live alone: users come from outside, and services sometimes need to call third-party APIs. Episode 6 covers those two directions of communication — ingress (into the mesh) and egress (out of the mesh) — along with the components that manage them: Gateway, edge VirtualService, and ServiceEntry.

One common misunderstanding to clear up right away: the Istio gateway is not a replacement for the Kubernetes Ingress Controller. A Gateway is a configuration spec for a load-balancer proxy that handles traffic at the edge of the mesh.

#Ingress Gateway and Egress Gateway

#Ingress Gateway

The ingress gateway is an Envoy placed at the edge of the mesh to accept traffic from outside. It is represented as a Deployment with a Service of type LoadBalancer, and its behavior is controlled by a Gateway resource:

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: bookstore-gateway
  namespace: default
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "bookstore.example.com"
    - "api.example.com"

selector points to the istio: ingressgateway label on the ingress gateway Deployment. Once the Gateway is defined, the same VirtualService is used for routing:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bookstore-vs
spec:
  hosts:
  - "bookstore.example.com"
  gateways:
  - bookstore-gateway
  http:
  - route:
    - destination:
        host: bookstore
        port:
          number: 8000

This VirtualService captures traffic from bookstore-gateway and routes it to the bookstore service on port 8000. Without the gateways line, a VirtualService only applies to internal mesh traffic.

#Egress Gateway

The egress gateway moves outbound mesh traffic through a centralized proxy. Its purpose is more niche: you can apply the same policies (outbound mTLS, audit, rate limiting) to all traffic leaving the mesh. For simple needs, sidecars talking directly to the internet are enough; we will cover when an egress gateway is required in the ServiceEntry section.

#TLS Termination and SNI Routing

#TLS Termination at the Gateway

A Gateway can terminate TLS so the applications behind it keep receiving plain HTTP:

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: tls-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: tls-secret
    hosts:
    - "bookstore.example.com"

tls.mode: SIMPLE uses a certificate from the Kubernetes Secret tls-secret. Other modes include PASSTHROUGH (TLS forwarded without inspection, suited to SNI routing) and MUTUAL (requires a client certificate).

#HTTP to HTTPS Redirect

To force all visitors to use HTTPS, define a port 80 server with a redirect:

spec:
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "bookstore.example.com"
    tls:
      httpsRedirect: true
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: tls-secret
    hosts:
    - "bookstore.example.com"

tls.httpsRedirect: true makes the gateway respond to HTTP requests with a redirect to the HTTPS version, without any application logic.

#SNI-Based Routing

With PASSTHROUGH mode, the gateway does not terminate TLS but reads the SNI to choose the destination. This lets many services share a single gateway while keeping certificates in each service.

#ServiceEntry for External Services

By default, the sidecar blocks access to unknown external domains. ServiceEntry registers external services so they can be called and governed by policies:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-payment
spec:
  hosts:
  - api.payment.example.com
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL

resolution: DNS means Envoy resolves the name via DNS. The other options:

• NONE: Envoy forwards to the destination address without resolution — suitable when the IP is already fixed.
• STATIC: endpoints are given directly as a list of IP addresses in the endpoints field.
• DNS: the name is resolved and endpoints can change dynamically.

With a ServiceEntry, you can apply traffic policies (retry, timeout, outbound mTLS) and observability to external services as if they were part of the mesh.

#Summary

Episode 6 connected the mesh to the outside world: Gateway and VirtualService for ingress with TLS termination and HTTPS redirects, PASSTHROUGH mode for SNI routing, and ServiceEntry with DNS, STATIC, or NONE resolution strategies to control egress.

Key takeaways:

• A Gateway describes the edge load balancer; a VirtualService directs its traffic.
• The Istio Gateway differs from the Kubernetes Ingress Controller.
• SIMPLE mode is for TLS termination; PASSTHROUGH for SNI routing.
• httpsRedirect forces visitors onto HTTPS.
• ServiceEntry registers external services into the mesh.
• resolution determines how Envoy finds endpoints: NONE, STATIC, or DNS.
• The egress gateway is useful for centralized outbound traffic policies.

In the next episode, episode 7, we will make the mesh more resilient: resilience patterns — retries with retry budgets, timeouts, circuit breakers via outlier detection, and fault injection for chaos testing.