Gateway API

Services and Networking / Guide 60 of 103 / Advanced

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 45 min

Gateway API is a set of CRDs on its own release cycle, independent of Kubernetes. The controller here supports a slightly older version than the CRDs installed, which the GatewayClass reports.

• Gateway APIv1.4.0 standard
• ControllerNGINX Gateway Fabric v2.2.1
• LoadBalancerMetalLB v0.15.2

This guide includes

Use this when Ingress cannot express what you need - weighted splits, header matching - or when routing has to be owned by more than one team. This matters because Gateway API splits one object into three with different owners, and then enforces that split.

• confirming Gateway API is not in the cluster and is not part of Kubernetes
• creating a Gateway with no controller behind it, and reading the status that says so
• installing a controller with --server-side, then declaring listeners it can actually provision
• attaching an HTTPRoute through parentRefs, and rewriting paths with no annotations at all
• expressing weighted splits and header matches Ingress has no field for, and watching allowedRoutes enforce the role split

Before you start

• The Ingress controllers and Ingress routing rules guides, since this is the API meant to replace them.
• The Custom resources and operators guide: Gateway API is entirely CRDs.
• A way to give the Gateway an external address. MetalLB here.

1. 1

   Not in the cluster, and not part of Kubernetes

2. 2

   CRDs without a controller, and the status that says so

3. 3

   The controller, and an apply that needs --server-side

4. 4

   The Gateway: where traffic enters

5. 5

   HTTPRoute: attachment, and rewriting without annotations

6. 6

   Weights and headers, which Ingress cannot express

7. 7

   The role split, enforced

Official sources

• Gateway API
• Migrating from Ingress
• HTTPRoute specification
• Traffic splitting
• Server-side apply