Kubernetes Gateway API with Cilium: Configuration

Ingress has been the standard way to expose HTTP workloads in Kubernetes for a decade, and it has always been limited: no clean separation of concerns between platform and application teams, no protocol support beyond HTTP, and vendor-specific annotations for anything interesting. Gateway API is the SIG-Network successor, and Cilium implements it on the same eBPF datapath that already handles service routing. This article covers what has to be enabled, a minimal working configuration, and the failure modes that show up on the first deployment.

Prerequisites that are easy to miss

Cilium's Gateway API controller requires the kube-proxy replacement to be enabled and the L7 proxy to be available (it is on by default). Traffic arriving at the Gateway service is transparently forwarded to Envoy using TPROXY, which by default is implemented with iptables — so nodes must ship the netfilter modules listed in the L7 proxy system requirements. On distributions that omit them, connections to the Gateway time out without ever reaching Envoy, and the logs look clean because the packet never arrived.

The Gateway API CRDs are also not installed with Cilium. They must be applied separately, and they must be the version Cilium supports.

kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_gatewayclasses.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_gateways.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml

Enabling the controller

helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \
  --set kubeProxyReplacement=true \
  --set gatewayAPI.enabled=true

kubectl -n kube-system rollout status ds/cilium

If your cluster cannot provide LoadBalancer services, enable host network mode instead so the Gateway binds directly on the node:

helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \
  --set gatewayAPI.enabled=true --set gatewayAPI.hostNetwork.enabled=true

With host networking the listener port is taken from spec.listeners.port, and you should avoid ports below 1024 unless the node is prepared to allow privileged binding.

A minimal Gateway and HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cilium-gateway
  namespace: default
spec:
  gatewayClassName: cilium
  listeners:
  - name: http
    port: 80
    protocol: HTTP
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: default
spec:
  parentRefs:
  - name: cilium-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /app
    backendRefs:
    - name: app-service
      port: 8080

Verification

kubectl get gateway cilium-gateway -o wide
kubectl get httproute app-route -o wide
kubectl describe gateway cilium-gateway | tail -20
kubectl -n kube-system logs ds/cilium --tail=50 | grep -i gateway

The Gateway should show PROGRAMMED: True and an address. If the address is <pending> with LoadBalancer mode, the cluster has no load balancer implementation — switch to host network mode. If it is programmed but requests time out, TPROXY is the first suspect: check for the netfilter modules and confirm bpf.tproxy behaviour against your kernel.

Why teams switch, in practical terms

• Role separation — the platform team owns the Gateway (listeners, TLS, addresses); application teams own HTTPRoutes in their own namespaces. That maps cleanly onto how organisations assign change approval.
• Portability — the same resources work across conformant implementations, so the configuration survives a controller change far better than a pile of vendor annotations.
• Beyond HTTP — TCPRoute, UDPRoute, TLSRoute and GRPCRoute are first-class, which matters for gRPC services that Ingress never handled well.

Adopt it where you have a real multi-team requirement or a protocol Ingress cannot express, and let simple single-team workloads stay on Ingress until something forces the move. Whichever path you take, the CNI datapath underneath is what carries the packets, so verify the health of that layer too — the counters and packet-capture techniques in On-box packet capture with ethanalyzer apply unchanged to pod traffic.

For the datapath comparison underneath the Gateway, see kube-proxy backends compared.

原文链接：https://docs.cilium.io/en/latest/network/servicemesh/gateway-api/gateway-api/