Introduction

In Istio, exposing traffic from outside the cluster usually means configuring two resources together: a Gateway that defines what the ingress proxy should listen for, and a VirtualService that decides where matching requests should go. If one of those is missing or mismatched, external traffic will not reach your workload.

Understand the Pieces First

The ingress path usually looks like this:

1. External client sends a request.
2. Istio ingress gateway receives it.
3. A Gateway resource matches the host and port.
4. A VirtualService routes the request to a Kubernetes service inside the mesh.

That means ingress setup is not just "open a port." You must align listeners, hosts, and destinations across multiple resources.

Create a Gateway

This example exposes HTTP traffic for example.com on port 80:

1apiVersion: networking.istio.io/v1
2kind: Gateway
3metadata:
4  name: web-gateway
5  namespace: default
6spec:
7  selector:
8    istio: ingressgateway
9  servers:
10    - port:
11        number: 80
12        name: http
13        protocol: HTTP
14      hosts:
15        - example.com

The selector must match the labels on the ingress gateway workload installed in your cluster. In default Istio installations, istio: ingressgateway is common, but you should verify the labels on your actual gateway deployment or service.

Route Traffic With a VirtualService

The VirtualService connects the external host to an internal Kubernetes service:

1apiVersion: networking.istio.io/v1
2kind: VirtualService
3metadata:
4  name: web-routing
5  namespace: default
6spec:
7  hosts:
8    - example.com
9  gateways:
10    - web-gateway
11  http:
12    - match:
13        - uri:
14            prefix: /
15      route:
16        - destination:
17            host: my-app.default.svc.cluster.local
18            port:
19              number: 8080

The host in the VirtualService must align with what the Gateway accepts. The destination host should be the Kubernetes service that fronts your application pods.

Apply and Verify the Configuration

Apply the manifests:

kubectl apply -f gateway.yaml
kubectl apply -f virtualservice.yaml

Then inspect the resources:

kubectl get gateway -n default
kubectl get virtualservice -n default
kubectl get svc -n istio-system

The ingress gateway service in istio-system usually exposes the external IP or load balancer hostname you need to test. If DNS is not configured yet, you can test with a manual Host header:

curl -H "Host: example.com" http://INGRESS_IP/

That is often the fastest way to confirm whether the routing rules are correct before waiting on DNS.

Add HTTPS Later, Not as a Guess

TLS configuration belongs on the Gateway resource. A basic HTTPS server block looks like this:

1servers:
2  - port:
3      number: 443
4      name: https
5      protocol: HTTPS
6    tls:
7      mode: SIMPLE
8      credentialName: example-com-tls
9    hosts:
10      - example.com

This assumes the TLS secret is already available to the ingress gateway through the expected credential mechanism. Do not add TLS blocks blindly. Verify how your cluster manages certificates first.

Debugging a Broken Ingress Path

When ingress does not work, check these in order:

• Does the ingress gateway service have an external address?
• Does the Gateway selector match the actual ingress gateway labels?
• Do the hosts values match the incoming request host?
• Does the VirtualService reference the correct gateway name?
• Does the destination service exist and expose the expected port?

If those line up, then inspect workload-level logs and, if needed, use Istio analysis tools to catch config mismatches before digging deeper.

Common Pitfalls

• Creating a Gateway but forgetting the matching VirtualService.
• Using a host name in the VirtualService that does not match the Gateway or client request.
• Pointing the destination to a pod port conceptually instead of the actual Kubernetes service and service port.
• Assuming the default ingress gateway labels without checking the installed deployment.
• Mixing TLS and HTTP settings without verifying which port and protocol the client is actually using.

Summary

• Istio ingress usually requires both a Gateway and a VirtualService.
• The Gateway defines external listeners; the VirtualService defines routing.
• Hosts, gateway names, selectors, and destination service ports must all align.
• Test early with curl and a manual Host header before blaming DNS.
• Most ingress failures come from mismatched config, not from Istio being opaque.