Gateways - KodeKloud

A Gateway in Istio is the entry and exit point between the service mesh and the outside world. Gateways are optional — if your workloads only communicate inside the mesh, you may not need one. For internal routing, a VirtualService alone is often sufficient. Gateways let you:

Expose services to external clients (Ingress Gateway).
Control and centralize outbound traffic from the mesh (Egress Gateway).
Perform TLS termination, protocol handling, and host/port binding at the mesh boundary.

When to use a Gateway

Use an Ingress Gateway to expose services to external users or APIs.
Use an Egress Gateway to centralize outbound policies, logging, or TLS for traffic leaving the mesh.
Skip Gateways if services are internal-only and no external exposure or control is required.

Types of Gateways

Gateway Type	Purpose	Typical Use Case
Ingress Gateway	Manages incoming traffic to the mesh	Expose web services to the public (HTTP(S), gRPC)
Egress Gateway	Manages outgoing traffic from the mesh	Centralize outbound TLS, logging, or egress policies

A schematic diagram titled "Egress Gateway" showing a Kubernetes namespace with deployments, pods/containers and a service, with dashed arrows routing outgoing traffic to an external Egress Gateway (cloud) icon.

Enabling Gateways via Istio Operator You choose which gateways to enable when installing Istio. Profiles (such as default, demo, minimal, remote, empty, preview, and ambient) include different core components. For example, the demo profile commonly includes both ingress and egress gateways, while minimal might include only ingress.

After installation, verify gateway pods in the Istio system namespace with:

kubectl get pods -n istio-system

You will see Envoy-based pods for ingress (and egress if enabled). Gateways are selected by label selectors configured in Gateway resources, so make sure selectors match the labels on those pods.

Ensure the Gateway selector matches the label on the gateway pods. Common labels are istio=ingressgateway or istio=egressgateway (labels vary by installation). If the selector is incorrect, the Gateway resource will not be bound to the gateway pods and external traffic will not be routed.

TLS termination, protocols, and routing Gateways commonly perform TLS termination (managing encryption/decryption and certificates) and support multiple protocols: HTTP(S), TCP, and gRPC. Gateways can route traffic based on ports, headers, and URL paths, but most advanced routing rules are defined in VirtualService objects.

A diagram titled "TLS Termination" showing an ingress gateway forwarding encrypted traffic into a Kubernetes namespace to a service, replica set and deployment that route to multiple pods and containers. Lock icons indicate where TLS encryption/decryption occurs.

A slide titled "Protocols" with three colored boxes labeled HTTP/S, TCP, and gRPC. Each box briefly explains routing: HTTP/S routes HTTP traffic, TCP routes based on TCP connections, and gRPC routes traffic based on gRPC calls.

Key configuration objects

Gateway — declares ports, protocols, hostnames to listen on and uses a selector to target gateway pods.
VirtualService — defines routing rules (host, path, headers) and is how you bind Gateway traffic to services.
DestinationRule — optional for basic routing but required for subsets, load balancing policies, connection pools, or TLS settings.

Comparison at a glance:

Resource	Primary Responsibility	Required to expose service externally?
Gateway	Bind Envoy gateway pods to ports/protocols/hosts	Yes (for external traffic)
VirtualService	Route traffic to service destinations and define match rules	No (can work for internal-only)
DestinationRule	Configure subsets, LB, TLS for destinations	No (but needed for subsets/advanced features)

Example: VirtualService + DestinationRule (internal routing and traffic-splitting)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ingress-app-vs
  namespace: frontend
spec:
  hosts:
  - app-svc
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: app-svc.frontend.svc.cluster.local
        port:
          number: 80
        subset: v1
      weight: 50
    - destination:
        host: app-svc.frontend.svc.cluster.local
        port:
          number: 80
        subset: v2
      weight: 50
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: app-ds
  namespace: frontend
spec:
  host: app-svc
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Expose the service externally: Gateway + VirtualService A Gateway resource defines which ports, hosts, and protocols the gateway listens on and must target gateway pods via a selector. Example (Ingress Gateway):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ingress-app-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - app.example.com

Notes:

The selector above targets ingress gateway pods in the istio-system namespace. If your installation used a different label (for example istio=ingress), change the selector accordingly.
For production, use port 443 and HTTPS with proper tls server settings.

Bind the Gateway to routes by referencing it from a VirtualService. Place the VirtualService in the same namespace as the Gateway to refer to it by name, or prefix with the namespace when in another namespace.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ingress-app-vs
  namespace: istio-system
spec:
  hosts:
  - app-svc
  - "app.example.com"
  gateways:
  - ingress-app-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: app-svc.frontend.svc.cluster.local
        port:
          number: 80
        subset: v1
      weight: 50
    - destination:
        host: app-svc.frontend.svc.cluster.local
        port:
          number: 80
        subset: v2
      weight: 50

app-svc allows internal service-to-service routing rules to match.
"app.example.com" applies the same routing for external requests coming through the Gateway.

Incoming traffic flow (high level)

External client sends HTTP/HTTPS to the Ingress Gateway public IP (e.g., app.example.com).
The Ingress Gateway (Envoy) receives the request and optionally terminates TLS.
Envoy uses the Gateway configuration to determine port/protocol handling.
The request is matched by a VirtualService (host/path) to select routing.
Traffic is forwarded to the Kubernetes Service and then to the target pods.
The service responds and the response flows back to the client.

A flowchart titled "Incoming Traffic Flow" that diagrams how an external HTTP/HTTPS request travels through an Ingress Gateway and Envoy proxy, consults a Virtual Service, and is forwarded to a workload. The final step shows the service processing the request and sending a response.

Important relationships

A Gateway needs a corresponding VirtualService to route traffic into the mesh.
A VirtualService can operate without a Gateway for internal routing.
DestinationRules are optional for simple routing but required when using subsets, load balancing, or connection pool/TLS settings.

Egress Gateway (outgoing traffic control) An Egress Gateway centralizes outbound traffic control and is useful for logging, monitoring, policy enforcement, and centralized TLS. You can allow specific outbound hosts or use a wildcard to permit all. Example Egress Gateway allowing HTTP and HTTPS:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: egress-app-gateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*"

Using "*" in hosts permits outbound connections to any host (subject to additional mesh policies). Restrict outbound traffic by listing specific hostnames instead of "*" when required. To force traffic through the egress gateway:

Create a ServiceEntry (if the external host is not part of the mesh DNS) to allow mesh resolution/reachability.
Create a VirtualService that references the egress Gateway (use namespace/gateway-name if in different namespaces).

Example VirtualService that forces traffic to api.example.com through the egress gateway:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: egress-app-vs
  namespace: frontend
spec:
  hosts:
  - api.example.com
  gateways:
  - istio-system/egress-app-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: api.example.com
        port:
          number: 443

Outgoing traffic flow (high level)

A workload’s sidecar Envoy intercepts outbound traffic.
The VirtualService routing rules send matching outbound requests to the Egress Gateway.
The Egress Gateway applies policies, logging, and TLS, then forwards the request to the external service.
Responses return via the Egress Gateway back to the originating workload.

A slide titled "Outgoing Traffic Flow" showing a four-step flow diagram: Envoy proxy intercepts outbound traffic, routes it to an Egress Gateway which processes the request, and the gateway handles the external client response.

Gateway configuration notes There are fewer configuration options on Gateways than on VirtualServices or DestinationRules, but Gateways support:

TLS modes and serverTLSSettings
Port and protocol definitions
Host binding and redirects

Consult the Istio Gateway reference for full options and examples.

A presentation slide titled "Gateway Options" containing documentation-style boxes and tables that describe Gateway, TLS mode, Port, and ServerTLSSettings (Istio networking configuration). The slide includes a KodeKloud copyright and a link to istio.io at the bottom.

Tip: Review the “Reference: Networking — Gateway” section in the Istio docs for examples on tls settings, serverTLSSettings, and protocol handling: https://istio.io/latest/docs/reference/config/networking/gateway/. Understanding Gateway selectors, servers, and how VirtualService integrates with Gateways is key for deployment and certification exams.

Summary This article covered:

What Istio Gateways are and when to use them.
Differences between Ingress and Egress Gateways and how they integrate with VirtualService and DestinationRule.
Example YAMLs for VirtualService, DestinationRule, Ingress Gateway, and Egress Gateway.
High-level incoming and outgoing traffic flows and configuration considerations.

Next steps

Practice configuring a Gateway + VirtualService end-to-end.
Test TLS termination and host/path-based routing.
Explore ServiceEntry + Egress Gateway patterns for controlled outbound access.

Documentation Index

Watch Video