Post 5/10 — From Ingress to Gateway API: Safer, Smarter Traffic Control

Source: Dev.to

Comparison: Ingress vs. Gateway API

Gateway API Concepts

• GatewayClass – Defines the underlying implementation (e.g., Istio, NGINX).
• Gateway – Deployed by platform teams; represents where traffic enters the cluster.
• HTTPRoute – Attached by application teams; describes how traffic should be routed.

Example Manifests

gateway.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gw
  namespace: platform
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-cert
    allowedRoutes:
      namespaces:
        from: All

route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: shop
spec:
  parentRefs:
  - name: web-gw
    namespace: platform
  hostnames: ["shop.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: shop-svc
      port: 80

Advanced Features

rules:
- matches:
  - headers:
    - name: x-region
      value: eu
  backendRefs:
  - name: shop-svc-eu
    port: 80
filters:
- type: RequestTimeout
  requestTimeout:
    duration: 5s
- type: Retry
  retry:
    count: 3
    statusCodes: ["5xx"]

Weighted traffic splits (first‑class support):

backendRefs:
- name: shop-svc
  port: 80
  weight: 80
- name: shop-svc-canary
  port: 80
  weight: 20

Multiple HTTPRoute objects can safely attach to a single Gateway, each scoped to its own namespace.

Migration: Ingress → Gateway API

Legacy Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts: [shop.example.com]
    secretName: my-cert
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: shop-svc
            port:
              number: 80

After Migration

Apply the gateway.yaml and route.yaml shown above.

Verification

kubectl get gateways -A
kubectl get httproutes -A
kubectl describe httproute shop-route

Canary test

kubectl get endpoints shop-svc-canary -o wide
curl -H "x-canary:true" https://shop.example.com

You’ll observe controlled traffic flow, improved observability, and clearer ownership.

Common Commands

Key fields to remember

• listeners.protocol, tls.mode, allowedRoutes
• rules.matches, filters, backendRefs.weight

Pitfalls to Watch

1. Policy attachment order – Gateway‑level policies are evaluated before Route‑level policies; precedence matters.
2. Overlapping routes – Multiple HTTPRoute objects with the same host/path can lead to controller‑specific priority decisions.
3. Cross‑namespace references – If allowedRoutes.from=Same, development teams cannot attach routes from other namespaces.
4. Controller support – Always check status.conditions on Gateway and HTTPRoute objects to confirm listeners are accepted.

Conclusion

With Gateway API, Kubernetes finally provides policy‑aware traffic control that scales across teams and environments—safer, cleaner, and built for automation.

Next up: Helm Fundamentals (Post 6) – we’ll templatize these Gateway objects and parameterize routes the right way.