Stop reading whenever you have enough

Gateways, in twelve questions.

Each one is the question the previous answer makes you ask. The ones that matter come with the manifest or the command, because that is the part you meet at work.

Not technical? The first three questions are written for you, and they are enough to follow any conversation about this.

Rungs
12
Hands on
6
Read
~8 min
01

What it is

01–03

Everything so far was traffic between services. This is the front door for traffic from outside.

three minutes, no cluster needed · for anyone

  1. 01

    What is a gateway, physically?

    Not knowing this costs

    It scales, restarts and fails like any deployment, because it is one.

    • A standalone Envoy deployment at the cluster edge
    • No application beside it, proxy only
    • Reached through a normal LoadBalancer service
  2. 02

    Why does the edge need its own resource?

    Not knowing this costs

    Rules written for service to service traffic say nothing about arrival.

    • Mesh routing assumes both ends have proxies
    • A browser has no sidecar and no mesh identity
    • The edge terminates the outside world into the mesh
  3. 03

    What does the Gateway resource actually control?

    Not knowing this costs

    Layer four opens the door. Layer seven still decides the corridor.

    • Ports, hostnames and TLS at the edge proxy
    • Nothing about where traffic goes afterwards
    • Routing stays with VirtualService, bound to it

Before you scroll on

0/3

You should now be able to

02

The YAML you will see

04–05

One file opens the door and holds the certificate. Another decides where arrivals go.

the pair of resources and the TLS block · for whoever writes the manifests

  1. 04

    What does the open door look like?

    hands on

    Not knowing this costs

    A certificate in the wrong namespace serves handshake errors, not warnings.

    • A selector picking the gateway deployment
    • A server block per port and host
    • credentialName pointing at the TLS secret
    manifestHTTPS terminated at the edge
    apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: shop-gateway
  namespace: shop
spec:
  selector:
    istio: ingressgateway        # which gateway pods serve this
  servers:
    - port: { number: 443, name: https, protocol: HTTPS }
      hosts:
        - "shop.example.com"
      tls:
        mode: SIMPLE
        credentialName: shop-example-com-cert
    Trap one: the secret named by credentialName must live in the gateway pods namespace, usually istio-system, not beside this resource. Wrong namespace fails silently.
  2. 05

    How do arrivals reach a service?

    hands on

    Not knowing this costs

    Adding a gateway to a VirtualService has broken internal traffic in most meshes once.

    • A VirtualService lists the gateway in gateways
    • Its hosts must overlap the Gateway hosts
    • Then ordinary routes take over
    manifestthe binding, and trap two
    apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: shop-web
  namespace: shop
spec:
  hosts:
    - "shop.example.com"
  gateways:
    - shop/shop-gateway
    - mesh          # keep in-mesh callers working too
  http:
    - route:
        - destination:
            host: web.shop.svc.cluster.local
    Trap two: gateways defaults to mesh when absent. Naming a gateway replaces that default, so adding the edge silently breaks every in mesh caller unless mesh stays listed.

Before you scroll on

0/3

You should now be able to

03

Proving it works

06–07

From outside the cluster, with curl, like your users arrive.

commands that answer yes or no · for whoever has to sign it off

  1. 06

    Does it work from the outside?

    hands on

    Not knowing this costs

    Green from inside the cluster proves nothing about the door.

    • curl the external address with the real host
    • Like a user, not from inside the cluster
    shellthe arrival test
    GW=$(kubectl get svc istio-ingressgateway -n istio-system \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

curl -sv --resolve shop.example.com:443:$GW \
  https://shop.example.com/ -o /dev/null 2>&1 | grep -E 'HTTP|subject'

# < HTTP/2 200
# subject: CN=shop.example.com     <- the right certificate, serving
    The --resolve flag tests before DNS points anywhere, which is exactly when you want to test. Inside cluster curls skip the entire path users take.
  2. 07

    What was the gateway proxy actually programmed with?

    hands on

    Not knowing this costs

    The edge debugs with tools you already know, or not at all.

    • Same istioctl commands, aimed at the gateway pods
    • Routes there are the Gateway plus bound VirtualServices
    shellthe edge, read like any proxy
    istioctl proxy-config routes deploy/istio-ingressgateway -n istio-system

# NAME          DOMAINS             MATCH   VIRTUAL SERVICE
# https.443...  shop.example.com    /*      shop-web.shop
    The gateway is Envoy, so the whole Envoy ladder applies. An empty VIRTUAL SERVICE column against your domain is the 404 from rung 8, seen from the inside.

Before you scroll on

0/3

You should now be able to

04

When it breaks

08–09

The edge fails as 404s and handshake errors, and both have one line causes.

the failures you will actually hit · for whoever gets paged

  1. 08

    The gateway returns 404 for everything. What is it?

    hands on

    Not knowing this costs

    The gateway 404 is a two file diff wearing an outage costume.

    • The door is open but no route is bound
    • Host mismatch between the two resources, usually
    • Or the VirtualService forgot the gateways entry
    shellthe three line checklist
    istioctl analyze -n shop
# IST0101: Referenced host not found, or gateway not bound

# hosts must match in BOTH files:
kubectl get gateway shop-gateway -n shop -o jsonpath='{.spec.servers[0].hosts}'
kubectl get virtualservice shop-web -n shop -o jsonpath='{.spec.hosts}'
    A 404 from the gateway means Envoy answered and matched nothing: the door works, the binding is broken. www versus apex mismatches cause half of these.
  2. 09

    TLS handshakes fail and the log says no certificate. What is it?

    hands on

    Not knowing this costs

    This failure looks like a TLS mystery and is a namespace typo.

    • credentialName names a secret the gateway cannot see
    • Wrong namespace, wrong name, or not created yet
    • The gateway serves nothing on that host until it loads
    shellconfirm the secret reached the proxy
    kubectl get secret shop-example-com-cert -n istio-system
# must exist HERE, in the gateway namespace

istioctl proxy-config secret deploy/istio-ingressgateway -n istio-system \
  | grep shop-example-com
# present and ACTIVE, or the handshake has nothing to offer
    cert-manager users: the Certificate resource must write its secret into istio-system, which is a field on the Certificate, not a default.

Before you scroll on

0/3

You should now be able to

05

Where it ends

10–12

The door is not the security, and there is a second door for leaving.

the limits, where people get caught · for whoever reviews the design

  1. 10

    Is the gateway authenticating anyone?

    Not knowing this costs

    A terminated handshake is not a login, however green the padlock.

    • TLS termination proves your server to the browser
    • It proves nothing about who the browser is
    • User auth is JWT policy or your app, behind the door
  2. 11

    What about traffic leaving the cluster?

    Not knowing this costs

    Egress gateways earn their complexity only when someone demands the audit.

    • An egress gateway is the same machinery, pointed out
    • Worth it when compliance needs one audited exit
    • Not a default, a deliberate choice
  3. 12

    What is the Kubernetes Gateway API I keep hearing about?

    Not knowing this costs

    Everything on this page transfers; the YAML shape is what changes.

    • The successor shape: Gateway and HTTPRoute, upstream
    • Istio implements it alongside its own resources
    • New edges increasingly start there

Before you scroll on

0/3

You should now be able to

Go deeper

4 links, each earning its place.

Ingress gateway task↗

The official runnable version of rungs 4 to 6.

Secure gateways task↗

The TLS block and credentialName mechanics, including the namespace rule from rung 4.

Egress gateway task↗

The deliberate exit from rung 11, built end to end.

Kubernetes Gateway API with Istio↗

The successor shape from rung 12, in Istio terms.

Where this leaves you

Rungs 4 and 5 hold the two silent traps: the certificate namespace, and the vanishing mesh keyword. Both cost real outages.

If you keep one thing: the Gateway opens the door and the VirtualService assigns the corridor, and every edge 404 is those two files disagreeing.