Q: Why is Kubernetes Gateway API replacing the standard Ingress resource in modern platform engineering, and how do you design GatewayClass, Gateway, and HTTPRoute hierarchies to enable self-service routing while maintaining perimeter security?

Establish clear boundaries: Infrastructure providers define GatewayClass (e.g., Envoy Gateway, Cilium); Platform Engineers provision the Gateway resource managing public/private load balancers, TLS certificates (via cert-manager), and allowed namespace listeners; Application Developers own HTTPRoute resources specifying path matching, canaries, and rewrites.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: internal-gateway
  namespace: platform-ingress
spec:
  gatewayClassName: cilium
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      certificateRefs:
      - name: wildcard-tls-cert
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            ingress-enabled: 'true'

Configure AllowedRoutes on the Gateway's listeners using namespace label selectors (namespaces.from: Selector). This ensures developer teams in specific namespaces can bind their HTTPRoutes to the shared perimeter Gateway without granting them access to alter edge TLS certificates or listener ports.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: order-routing
  namespace: team-orders
spec:
  parentRefs:
  - name: internal-gateway
    namespace: platform-ingress
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /orders
    backendRefs:
    - name: order-service
      port: 8080

Enable developers to independently configure progressive canary rollouts, header-based routing, URL rewrites, and request mirroring directly through native HTTPRoute spec without needing ingress controller custom CRDs or annotations.

backendRefs:
- name: order-service-v1
  port: 8080
  weight: 90
- name: order-service-v2
  port: 8080
  weight: 10