Skip to content

Ingress and Gateway API Routing with Cilium: CCA practice questions

Cilium can act as the entry point for HTTP traffic into a cluster in two ways: as a controller for the classic Kubernetes Ingress resource, and as an implementation of Gateway API. Both are switched on through Helm. The Ingress controller is enabled with ingressController.enabled=true, and ingressController.default=true additionally makes Cilium handle Ingress objects that name no class.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Ingress and Gateway API Routing with Cilium covers in CCA

Cilium can act as the entry point for HTTP traffic into a cluster in two ways: as a controller for the classic Kubernetes Ingress resource, and as an implementation of Gateway API. Both are switched on through Helm. The Ingress controller is enabled with ingressController.enabled=true, and ingressController.default=true additionally makes Cilium handle Ingress objects that name no class. The Gateway API controller is enabled with gatewayAPI.enabled=true, but only after the Gateway API CRDs (GatewayClass, Gateway, HTTPRoute, GRPCRoute, ReferenceGrant, BackendTLSPolicy, TLSRoute) are installed; TCPRoute, UDPRoute and ListenerSet are optional extras.

Both controllers share the same prerequisites. Cilium must run with kubeProxyReplacement=true and with the L7 proxy enabled, which is the default. By default each controller exposes Envoy through a Service of type LoadBalancer, so the environment needs a load balancer implementation such as a cloud provider or Cilium LB-IPAM; NodePort and, since 1.16, a host network mode are alternatives.

An Ingress is picked up when it sets ingressClassName: cilium. Cilium supports a dedicated load balancer mode, where each Ingress gets its own LoadBalancer Service, and a shared mode, where all Ingress resources share one. The annotation ingress.cilium.io/loadbalancer-mode overrides the Helm default per object, which is useful when two teams would otherwise collide on path prefixes. Path matching follows a fixed order in the generated Envoy configuration: Exact paths, then ImplementationSpecific paths, which Cilium interprets as regular expressions, then Prefix paths, and the / prefix always last.

With Gateway API, the Gateway object names gatewayClassName: cilium and declares listeners with a protocol and port, and HTTPRoute objects attach to it through parentRefs and send matching requests to backendRefs. Cilium only programs Gateways whose GatewayClass names its controller, io.cilium/gateway-controller. A healthy Gateway reports Accepted and Programmed conditions and gets an address from its Service; an empty address usually means no load balancer implementation is present. Routes report Accepted and ResolvedRefs, which is the first place to look when a backend Service or parent Gateway is misspelled.

Under the hood, the operator validates Gateway API objects and translates them into CiliumEnvoyConfig resources, and the agent hands that configuration to the per-node Envoy. When a packet reaches the Service port, eBPF intercepts it and forwards it to Envoy with TPROXY, so source IP visibility works without externalTrafficPolicy: Local and backends receive the client address in X-Forwarded-For.

Key points

  • Gateway API support needs the Gateway API CRDs installed before gatewayAPI.enabled=true takes effect.
  • Both controllers require kubeProxyReplacement=true and the L7 proxy.
  • ingress.cilium.io/loadbalancer-mode switches one Ingress between dedicated and shared load balancers.
  • Cilium ignores Gateways whose GatewayClass names another controller.

Three sample questions

11 CCA questions on Ingress and Gateway API Routing with Cilium, 11 with explanations. How practice works

Question 1

Which of the following Gateway API resources would you use to define HTTP routing rules for a Gateway?
  1. A.HTTPRoute
  2. B.RouteRule
  3. C.HTTPProxy
  4. D.GatewayHTTPRoute

Correct answer: A

In the Gateway API, HTTPRoute is the resource used to define HTTP routing rules for a Gateway. It specifies how HTTP traffic should be routed to backend services based on paths, headers, and other criteria.

Question 2

Which of the following Gateway API configurations correctly creates a Gateway listening on port 80 for HTTP traffic?
  1. A.
    apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: cilium
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same
  2. B.
    apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  className: cilium
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    routes:
      namespaces:
        from: Same
  3. C.
    apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: cilium
  ports:
  - name: http
    protocol: HTTP
    number: 80
  routes:
    namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: default
  4. D.
    apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example-gateway
spec:
  controllerName: io.cilium/gateway-controller
  listeners:
  - name: http
    protocol: HTTP
    port: 80

Correct answer: A

This is the correct Gateway API configuration for creating a Gateway listening on port 80 for HTTP traffic with Cilium as the controller. It includes the required fields gatewayClassName, listeners with appropriate protocol and port, and allowedRoutes to specify which routes can attach to this gateway.

Question 3

Which of the following correctly associates an HTTPRoute with a previously created Gateway named "main-gateway"?
  1. A.
    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  gateway: main-gateway
  rules:
  - matches:
    - path: /app
  service: backend-service
  2. B.
    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  gatewayRef:
    name: main-gateway
  rules:
  - matches:
    - path:
        value: /app
    backendRefs:
    - name: backend-service
      port: 8080
  3. C.
    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
  - name: main-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /app
    backendRefs:
    - name: backend-service
      port: 8080
  4. D.
    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  selector:
    gateway: main-gateway
  rules:
  - path: /app
    backend:
      service:
        name: backend-service
        port: 8080

Correct answer: C

This HTTPRoute correctly associates with the "main-gateway" Gateway using the parentRefs field. It also properly defines the path matching and the backend service to route to, following the Gateway API specification.

Practice this topic

Focus mode keeps every question on Ingress and Gateway API Routing with Cilium until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CCA practice across all topics.

Sources

The explanation above was checked against these official documents.

Frequently asked questions

Does traffic through a Cilium Gateway lose the client IP?

Normally not. eBPF forwards the connection to Envoy with TPROXY on the receiving node, and Envoy adds the client address to X-Forwarded-For. The exception is TLS passthrough, where backends see the Envoy address because Envoy opens a new TCP stream.