Skip to content

Understand the Benefits of Gateway API over Ingress: CCA practice questions

Gateway API was created by Kubernetes SIG Network as the successor to Ingress, and the Kubernetes documentation now recommends it. The Ingress API is frozen. It remains generally available and there are no plans to remove it, but it will receive no further changes, so new routing features only arrive in Gateway API.

By Ibrahim Yesilay · Published · Updated

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

What Understand the Benefits of Gateway API over Ingress covers in CCA

Gateway API was created by Kubernetes SIG Network as the successor to Ingress, and the Kubernetes documentation now recommends it. The Ingress API is frozen. It remains generally available and there are no plans to remove it, but it will receive no further changes, so new routing features only arrive in Gateway API.

The Cilium migration guide names three limitations of Ingress. Advanced routing is thin: Ingress supports host and path rules, but not traffic splitting, header modification or URL rewriting. Protocol support is narrow: Ingress covers HTTP and HTTPS only. And it fits multi-team clusters with shared load balancing infrastructure badly. To fill the gaps, each controller added its own annotations, which is why moving an application between Ingress controllers so often breaks: the annotations of one vendor mean nothing to another.

Gateway API answers with four design principles described on the Kubernetes site. It is role-oriented: GatewayClass, Gateway and the route kinds map to the infrastructure provider, cluster operator and application developer, so a developer can be allowed to create HTTPRoutes in a namespace without gaining the right to change the Gateway. It is portable: the APIs are custom resources implemented by many controllers, and common features are part of the specification rather than annotations. It is expressive: header-based matching and weighted traffic splitting are built in. And it is extensible, with defined places to attach custom resources.

The resource model also adds an explicit trust relationship. A Gateway listener decides which Routes may attach through allowedRoutes, and by default only Routes from the namespace of the Gateway are accepted. A Route in another namespace therefore stays detached until the Gateway owner opens the listener to it, which is how shared load balancing infrastructure can be delegated safely.

Cilium implements Gateway API v1.6.3 and passes the Core conformance tests. Besides HTTPRoute it supports GRPCRoute, TLSRoute, TCPRoute, UDPRoute, BackendTLSPolicy, ReferenceGrant and ListenerSet, which covers the non-HTTP cases that Ingress cannot represent.

Migration can be done by hand or with the ingress2gateway project, which reads Ingress objects through the current kubeconfig and prints equivalent Gateway API YAML. The tool is experimental and the Cilium guide does not recommend it for production, so its output should be reviewed and run in parallel with the existing Ingress before traffic is moved and the old objects are removed.

Key points

  • Ingress is frozen: still GA and not scheduled for removal, but no longer developed.
  • Vendor-specific annotations are the main reason Ingress configurations are not portable.
  • By default a Gateway listener accepts Routes only from its own namespace.
  • ingress2gateway is experimental and only prints YAML; it does not change the cluster.

Three sample questions

9 CCA questions on Understand the Benefits of Gateway API over Ingress, 9 with explanations. How practice works

Question 1

Which API does Cilium implement to provide advanced traffic routing capabilities beyond Kubernetes Ingress?
  1. A.Istio Virtual Service API
  2. B.Gateway API
  3. C.NGINX Controller API
  4. D.Traefik IngressRoute API

Correct answer: B

Cilium implements the Gateway API, which is a new standard API for Kubernetes that provides more advanced traffic routing capabilities beyond the traditional Ingress resource.

Question 2

Which Gateway API feature allows for traffic splitting between different backend services?
  1. A.Configuring backendRefs with different weights
  2. B.Using the trafficSplit field
  3. C.Implementing a GatewayCanary resource
  4. D.Setting the loadBalancer.weightedTargets field

Correct answer: A

In the Gateway API, traffic splitting between different backend services is achieved by configuring multiple backendRefs with different weights. This allows for proportional traffic distribution, which is useful for canary deployments or A/B testing.

Question 3

What does the Kubernetes documentation say about the current status of the Ingress API?
  1. A.It is frozen: GA and kept, but no longer developed
  2. B.It is deprecated and will be removed in the next minor release
  3. C.It is being extended with TCP and UDP routing
  4. D.It has been merged into Gateway API as Ingress v2

Correct answer: A

The Kubernetes Ingress page says the project recommends Gateway instead of Ingress and that the Ingress API has been frozen: it stays GA with its stability guarantees and there are no plans to remove it, but it will receive no further changes or updates. Why the other options are wrong. "It is deprecated and will be removed in the next minor ...": Kubernetes states it has no plans to remove Ingress. "It is being extended with TCP and UDP routing": the API is frozen, so no new features are added; TCP/UDP routing lives in Gateway API. "It has been merged into Gateway API as Ingress v2": Gateway API is a separate set of resources, not a new version of Ingress.

Sources: CNCF CCA curriculum (CCA_Curriculum.pdf), Kubernetes: Ingress, Cilium docs: Migrating from Ingress to Gateway

Practice this topic

Focus mode keeps every question on Understand the Benefits of Gateway API over Ingress 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.