Gateway API resources define how traffic should flow (desired state)
They don’t handle any traffic.
The actual traffic is managed by the data plane proxy pods (Ex: NGINX / Envoy)
First lets look at the gateway API resources (left side):
- 𝗚𝗮𝘁𝗲𝘄𝗮𝘆𝗖𝗹𝗮𝘀𝘀 (cluster scoped): Defines who (which controller) manages your gateways. It can be Nginx Envoy, Istio etc..
- 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 (namespace scoped) defines entry point. Creating a Gateway triggers the controller to provision a real cloud Load Balancer. It defines listeners, ports, TLS etc
- 𝗛𝗧𝗧𝗣𝗥𝗼𝘂𝘁𝗲 (namespace scoped): Defines routing rules (Paths, headers, traffic splits etc..)
- 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 is the backendRef. Forwards to pods
- 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 𝗔𝗣𝗜 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗿: Watches all of these through the Kubernetes API. When any cofig changes, it reconciles and configures the proxy (NGINX) pod accordingly.
Now lets understand the Data Plane (right side):
Data plane proxy pod is what actually handles the actual traffic. Here is the flow:
- Client does DNS resolution, opens TCP to the Load Balancer
- Load Balancer forwards to the Proxy Pod
- Proxy Pod (NGINX/Envoy) reads its rules, matches the path, selects the backend service.
- Then sends the traffic straight to the pod IP
Here is the key thing to understand.
The controller never handles the traffic. It programs the proxy pod, and the proxy pod handles the actual traffic.
It is why Gateway API scales better than Ingress. Because, config and traffic are two separate planes
If you want to deep dive in toGateway API using Nignx Gateway fabric, refer our detailed blog.
𝗗𝗲𝘁𝗮𝗶𝗹𝗲𝗱 𝗕𝗹𝗼𝗴:
devopscube.com/kubernetes-ga…
----
Important Note: In the diagram we used NGINX Gateway Fabric for illustration. The actual workflow (proxy, load balancer, and data plane) depends on your Gateway API controller implementation.
#Kubernetes #DevOps #GatewayAPI