Dev Note

Kubernetes Gateway API: The Future of Ingress Management in 2026
The Kubernetes Ingress resource has served us well, but it’s showing its age. In 2026, the Gateway API — GA since Kubernetes 1.28 — has become the standard for managing cluster ingress, traffic routing, and service mesh integration. If your team is still using networking.k8s.io/v1 Ingress, it’s time to understand what you’re missing.
Photo by Jordan Harrison on Unsplash
What’s Wrong with Ingress?
The classic Ingress resource works, but has well-documented limitations:
Annotation sprawl — features like SSL passthrough, rate limiting, and auth are implemented via controller-specific annotations. Moving between NGINX and Traefik ingress controllers means rewriting all annotations.
No role separation — cluster operators and application developers share the same resource. A developer can accidentally overwrite cluster-wide TLS settings.
Limited traffic semantics — no built-in support for traffic splitting, header-based routing, or request mirroring at the spec level.
No service mesh integration — Ingress knows nothing about east-west traffic.
Gateway API solves all of these with a cleaner, extensible model.
Gateway API Concepts
The Gateway API introduces four core resource types:
GatewayClass
Defines the controller implementation. Think of it like a StorageClass for networking:
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: cilium
spec:
  controllerName: io.cilium/gateway-controller
Gateway
Defines a specific load balancer/proxy instance and its listeners. Managed by cluster operators:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: infrastructure
spec:
  gatewayClassName: cilium
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - name: prod-tls-cert
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            gateway-access: "allowed"
The allowedRoutes field is key — cluster operators control which namespaces can attach routes. No more developer accidents.
HTTPRoute
Defines routing rules. Managed by application developers:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: my-app  # developer-owned namespace
spec:
  parentRefs:
  - name: prod-gateway
    namespace: infrastructure  # references the cluster operator's gateway
  hostnames:
  - "api.mycompany.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v2/
    backendRefs:
    - name: api-v2-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /v1/
    backendRefs:
    - name: api-v1-service
      port: 8080
ReferenceGrant
Enables cross-namespace references (explicit, auditable):
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-infrastructure-gateway
  namespace: my-app
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: infrastructure
  to:
  - group: ""
    kind: Service
Advanced Traffic Management
Canary Deployments (Native)
Gateway API supports weight-based traffic splitting natively — no Argo Rollouts required for basic canaries:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-deploy
spec:
  parentRefs:
  - name: prod-gateway
  hostnames:
  - "app.mycompany.com"
  rules:
  - backendRefs:
    - name: app-stable
      port: 8080
      weight: 90
    - name: app-canary
      port: 8080
      weight: 10
Shift traffic gradually by updating the weight values.
Header-Based Routing
Route internal users to a new version while serving stable to everyone else:
rules:
- matches:
  - headers:
    - name: "X-Beta-User"
      value: "true"
  backendRefs:
  - name: app-beta
    port: 8080
- backendRefs:
  - name: app-stable
    port: 8080
Request/Response Modification
Built-in header manipulation (no annotations needed):
rules:
- matches:
  - path:
      type: PathPrefix
      value: /api/
  filters:
  - type: RequestHeaderModifier
    requestHeaderModifier:
      add:
      - name: X-Request-Origin
        value: gateway
      remove:
      - X-Internal-Token
  - type: URLRewrite
    urlRewrite:
      path:
        type: ReplacePrefixMatch
        replacePrefixMatch: /
  backendRefs:
  - name: api-service
    port: 8080
Migration from Ingress
Step 1: Audit Your Existing Ingress Resources
kubectl get ingress -A -o yaml > ingress-backup.yaml
# Look for annotations that need to be translated
grep -E "nginx.ingress.kubernetes.io|traefik.io" ingress-backup.yaml
Step 2: Install a Gateway API Controller
Most major ingress controllers now support Gateway API:
# Cilium (if already using Cilium CNI)
helm upgrade cilium cilium/cilium \
  --set gatewayAPI.enabled=true
# Nginx Gateway Fabric
helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
  --create-namespace \
  -n nginx-gateway
# Istio
istioctl install --set profile=minimal \
  --set values.pilot.env.PILOT_ENABLE_GATEWAY_API=true
Step 3: Create Equivalent Gateway + HTTPRoute
# Install Gateway API CRDs (if not already present)
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml
Before (Ingress):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
  - hosts:
    - app.mycompany.com
    secretName: app-tls
  rules:
  - host: app.mycompany.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
After (Gateway API):
# Cluster operator creates:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: infrastructure
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    hostname: "*.mycompany.com"
    tls:
      certificateRefs:
      - name: wildcard-tls
        namespace: infrastructure
---
# Developer creates:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
  namespace: my-app
spec:
  parentRefs:
  - name: main-gateway
    namespace: infrastructure
  hostnames:
  - "app.mycompany.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
  - filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
  - backendRefs:
    - name: api-service
      port: 8080
TLS Policy Management
CertificateRefs now support cert-manager integration directly:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: app-cert
  namespace: infrastructure
spec:
  secretName: app-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - app.mycompany.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
spec:
  listeners:
  - name: https
    tls:
      certificateRefs:
      - name: app-tls  # references the cert-manager secret
Service Mesh Integration (East-West Traffic)
The real power of Gateway API is its extension into service mesh territory. With GAMMA (Gateway API for Mesh Management and Administration), the same API now covers east-west (service-to-service) traffic:
# HTTPRoute for east-west traffic
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payment-service-route
spec:
  parentRefs:
  - group: ""
    kind: Service  # Note: Service as parent, not Gateway!
    name: payment-service
    port: 8080
  rules:
  - matches:
    - headers:
      - name: "X-API-Version"
        value: "v2"
  - backendRefs:
    - name: payment-service-v2
      port: 8080
  - backendRefs:
    - name: payment-service-v1
      port: 8080
One API, both north-south (external) and east-west (internal) traffic.
Observability
Gateway API controllers emit standardized metrics. With Cilium Gateway API + Prometheus:
# Grafana dashboard queries
# Request rate by route
rate(gateway_http_requests_total[5m])
# P95 latency by hostname
histogram_quantile(0.95, 
  rate(gateway_http_request_duration_seconds_bucket[5m])
)
# Error rate
rate(gateway_http_requests_total{response_code=~"5.."}[5m])
  / rate(gateway_http_requests_total[5m])
Should You Migrate Now?
Yes, if:
You’re starting a new cluster
You’re changing ingress controllers
You’re adopting a service mesh
You have complex routing requirements
Wait, if:
Your current setup is stable and simple
You’re on an older Kubernetes version (< 1.26)
Your chosen controller doesn’t have stable Gateway API support yet
The migration path is incremental — you can run Ingress and Gateway API side by side during transition.
Conclusion
Gateway API isn’t just “better Ingress” — it’s a rethinking of how Kubernetes handles network routing. The role-based model (operators own Gateways, developers own Routes) solves real organizational problems. The native support for traffic splitting, header routing, and service mesh integration eliminates entire categories of third-party tooling.
The Ingress resource will remain supported for years, but new Kubernetes networking features are being built on Gateway API exclusively. The migration investment pays dividends in flexibility and operational clarity.
Tags: Kubernetes, Gateway API, DevOps, Cloud Native, Cilium, Networking, Ingress

Kubernetes Gateway API: The Future of Ingress Management in 2026

댓글