Build a Cloud-Style Fabric Lab, Part 9: Ingress

At the end of Part 8, one /32 was being advertised into the fabric and nothing answered on it. This part makes that address the front door of everything: a Cilium Gateway claims it, a wildcard certificate makes it trustworthy, sixteen HTTPRoutes fan it out to applications, and split-view DNS hands the same hostnames to two audiences with two different, equally honest answers.

One hostname, two journeys: inside clients resolve to the Cilium VIP, outside clients to the edge address through the DNAT, both landing on the same Gateway which terminates TLS and routes by SNI to sixteen HTTPRoutes — Same name, two answers, one Gateway. Everything converges on 192.168.200.0.

The Gateway claims the VIP

Gateway API splits ingress into roles: the Gateway owns the listener (an address, a port, a TLS config), and HTTPRoutes owned by applications attach to it. One Gateway serves this whole lab:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: ai-gw
  namespace: ai
spec:
  gatewayClassName: cilium
  infrastructure:
    labels:
      bgp-announce: "true"      # the consent, inherited by everything generated
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    hostname: "*.ocp.lab"
    tls:
      mode: Terminate
      certificateRefs:
      - name: wildcard-ocp-lab-tls
    allowedRoutes:
      namespaces: {from: All}

The quiet star is infrastructure.labels. When Cilium reconciles this Gateway it generates a LoadBalancer service, and this field stamps that service with the bgp-announce label. Which is Part 8's advertisement selector. Which is what makes the fabric route the VIP. The chain of consent runs Gateway to service to advertisement to leaf, and you can watch it close: