Gateways

A Gateway is an entry point that controls traffic between the outside world and the Istio service mesh. Gateways are optional: if your workloads don’t need external exposure, you can rely on VirtualServices alone. Use the Istio Operator to enable or disable gateway components as needed.

Gateways are used only when you need to control ingress or egress traffic at the mesh boundary. Inside the mesh, VirtualServices and DestinationRules control routing and subsets.

Types of Gateways

There are two primary Istio gateway types:

Ingress Gateway — manages incoming traffic from outside the cluster into the Istio mesh.
Egress Gateway — controls outgoing traffic from workloads inside the mesh to external services.

The image illustrates the architecture of an Ingress Gateway used to manage incoming traffic in a Kubernetes environment, showing components like Service, Replica Set, and Pods with containers.

The image illustrates the concept of an Egress Gateway in Kubernetes, showing how outgoing traffic from pods within a namespace is managed and directed to external resources via the gateway.

Istio installs ingress and (optionally) egress gateway components. For example, different Istio installation profiles (default, demo, minimal, etc.) include or exclude specific core components:

To verify installed gateway pods:

# List Istio system pods (example output)
$ kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-egress-cfcd9bc96-p6nsg          1/1     Running   0          19s
istio-ingress-6cf77d4858-725nz        1/1     Running   0          23s
istiod-5fcb7d9676-vwfxj               1/1     Running   0          35s

# Inspect a specific ingress pod (labels may vary)
$ kubectl get pod -n istio-system istio-ingress-6cf77d4858-725nz -o wide
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingress-6cf77d4858-725nz        1/1     Running   0          113s

Gateway selector labels matter. The Gateway spec.selector must match the labels on the gateway pods (e.g., istio=ingress, istio=ingressgateway, or istio=egress). If the selector is wrong, traffic will not be handled by the intended Envoy pods.

TLS termination and protocol support

Gateways are commonly used for TLS termination: the Envoy proxy at the mesh edge can decrypt incoming TLS traffic and forward plaintext traffic inside the mesh, or vice versa for egress. Gateways also support multiple protocols:

HTTP / HTTPS
TCP
gRPC

The image illustrates a TLS termination process in a Kubernetes environment, highlighting the encryption and decryption of traffic at an ingress gateway and the flow within Kubernetes components like services, deployments, replica sets, and pods.

The image illustrates three types of protocols: HTTP/S, TCP, and gRPC, each responsible for routing different types of traffic.

Example: VirtualService and DestinationRule (traffic splitting)

A VirtualService routes requests to one or more destinations. A DestinationRule defines subsets (versions) used by the VirtualService for traffic splitting. VirtualService (50/50 split between v1 and v2):

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

DestinationRule defining subsets:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: app-ds
  namespace: frontend
spec:
  host: app-svc
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Exposing the app with an Ingress Gateway

To expose the frontend application externally you need a Gateway resource. The Gateway configures ports, protocols, and hostnames that the ingress Envoy pods will accept. Example Ingress Gateway:

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: ingress-app-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingress        # must match the gateway pod label exactly
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - app.example.com

Notes:

The selector must match the labels on your ingress gateway pods (e.g., istio: ingress or istio: ingressgateway).
In production, you will typically use port 443 and HTTPS with TLS settings, not port 80.

To allow both internal and external access, add the gateway reference and external host to your VirtualService:

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

When workloads inside the mesh call app-svc.frontend.svc.cluster.local, the VirtualService applies the 50/50 split internally.
When external users access app.example.com, the Gateway matches the host and the same VirtualService routes the request through the ingress gateway into the mesh.

Incoming traffic flow

External client sends HTTP/HTTPS to the Ingress Gateway public IP (DNS: app.example.com).
Envoy (ingress pod) receives and decrypts if required.
Envoy consults the Gateway configuration to determine applicable ports/protocols.
The Gateway references a VirtualService to select the route based on host and path.
Envoy forwards to the Kubernetes Service and workload; response returns to client.

Remember: An ingress Gateway requires a VirtualService to route traffic into the mesh. A VirtualService can operate independently for internal routing without a Gateway.

Egress Gateway

An egress gateway centralizes outbound traffic from the mesh, letting you enforce policies, monitor exits, or lock outbound hosts. Example Egress Gateway listening on 80 and 443:

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

Using "*" (wildcard) allows all outgoing hosts through the egress gateway.
Alternatively, list specific hosts to restrict egress to approved external endpoints.

VirtualService forcing traffic through the egress gateway (example for api.example.com on port 443):

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

Workloads in the frontend namespace that want to call api.example.com will be required to go through the egress gateway and use HTTPS on port 443.

Outgoing traffic flow

Workload sends outbound traffic; sidecar Envoy intercepts.
Envoy routes outbound traffic to the egress gateway (based on VirtualService).
Egress gateway applies policies, monitoring, and any TLS egress behavior.
Egress gateway forwards to external destination; responses return through the gateway to the originating workload.

Egress gateways are less commonly used in many organizations because networking stacks (VPCs, firewalls, NATs) already provide egress control. However, an Istio egress gateway is useful for centralized visibility, policy enforcement, or strict regulatory environments.

Gateway capabilities and options

Gateways can configure:

Ports and protocols (HTTP, HTTPS, TCP, gRPC).
TLS modes and certificate handling (TLS termination / passthrough / mutual TLS).
Host matching and SNI routing.
Per-server TLS settings and redirects.

Refer to the official Gateway reference for details and examples:

Reference: https://istio.io/latest/docs/reference/config/networking/gateway/

The image shows a diagram of "Gateway Options" related to server configurations, including sections on TLS mode, port, and server TLS settings, each with descriptive fields. It appears to be a reference guide from KodeKloud.

Study the Gateway options and examples in the Istio docs—this topic appears on the Istio Certified Associate exam. Practice creating Gateways and the related VirtualServices/DestinationRules in a lab environment.

Quick reference table

Resource Type	Purpose	Example
Gateway	Configure edge Envoy listeners and host/port bindings	`apiVersion: networking.istio.io/v1` Gateway YAML (see above)
VirtualService	Routing rules for requests (host/path matching, traffic splitting)	`apiVersion: networking.istio.io/v1alpha3` VirtualService YAML (see above)
DestinationRule	Define subsets and traffic policies for services	`apiVersion: networking.istio.io/v1` DestinationRule YAML (see above)

Links and references:

Istio Gateway docs: https://istio.io/latest/docs/reference/config/networking/gateway/
VirtualService docs: https://istio.io/latest/docs/reference/config/networking/virtual-service/
DestinationRule docs: https://istio.io/latest/docs/reference/config/networking/destination-rule/

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

Types of Gateways

TLS termination and protocol support

Example: VirtualService and DestinationRule (traffic splitting)

Exposing the app with an Ingress Gateway

Incoming traffic flow

Egress Gateway

Outgoing traffic flow

Gateway capabilities and options

Quick reference table

Watch Video

​Types of Gateways

​TLS termination and protocol support

​Example: VirtualService and DestinationRule (traffic splitting)

​Exposing the app with an Ingress Gateway

​Incoming traffic flow

​Egress Gateway

​Outgoing traffic flow

​Gateway capabilities and options

​Quick reference table

Watch Video

Types of Gateways

TLS termination and protocol support

Example: VirtualService and DestinationRule (traffic splitting)

Exposing the app with an Ingress Gateway

Incoming traffic flow

Egress Gateway

Outgoing traffic flow

Gateway capabilities and options

Quick reference table