> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Gateway API Architecture Persona Model
> Explains Kubernetes Gateway API architecture, NGINX Gateway implementation, data plane provisioning, and role-based responsibilities for infrastructure, platform, and application teams.
After reviewing the limitations of the legacy NGINX Ingress Controller, this lesson introduces the Gateway API — a modern, extensible Kubernetes API designed to express L4–L7 traffic handling, with clearer separation of concerns between platform operators and application developers.
We’ll cover how the Gateway API works, what components it introduces, how a Gateway implementation (controller) is installed and provisioned, and how responsibilities map to personas (infrastructure provider, SRE/platform, and developers).
## Installing an NGINX Gateway implementation
To adopt the Gateway API you first install a Gateway implementation (controller). In these examples we use the NGINX Gateway Fabric Helm chart, which installs the control plane and the CRDs required to create Gateway API objects (GatewayClass, Gateway, HTTPRoute, GRPCRoute, ReferenceGrant, etc.).
Install the CRDs before creating Gateway API objects. Many Helm charts include a CRD installation step; confirm whether your chart installs CRDs or requires a separate apply. Creating Gateways or Routes without CRDs will fail.
When you run `helm install` for the NGINX Gateway Fabric chart, the chart typically creates these resources by default:
| Resource | Purpose | Example notes |
| - | - | - |
| Namespace | Isolates control-plane components (recommended) | Use a dedicated namespace to centralize control-plane resources |
| CRDs | Provide Gateway API kinds (GatewayClass, Gateway, HTTPRoute, GRPCRoute, ReferenceGrant) | Enables creation of Gateway API resources |
| Deployment | The NGINX control-plane controller (operates as a Kubernetes Deployment) | Follows the operator/controller pattern |
| Service | Internal communication for control-plane pods | Used for control-plane coordination |
| RBAC (Roles/RoleBindings) | Grants necessary permissions for controller reconciliation | Ensures controller can read/write relevant resources |
These resources form the control plane. As you create Gateways and Routes the controller will begin provisioning data-plane components automatically.
## Data plane provisioning and path of traffic
After the controller is installed and a Gateway is created, the controller provisions data-plane pods to implement the actual traffic handling. Typical behavior:
* Creating a Gateway triggers the controller to create a data-plane Deployment in the same namespace.
* The Deployment name often encodes the Gateway name, the word `nginx`, and a unique suffix, for example:
```text theme={null}
my-gateway-nginx-7d9f4b6c
```
* When Routes are attached to the Gateway, the controller translates route rules into NGINX configuration files and writes them to the data-plane pods (for example, `/etc/nginx/conf.d`).
Key implementation details to keep in mind:
* The control plane translates Gateway and Route resources into the concrete configuration for the data plane.
* Data-plane pods serve traffic and mount the generated configuration at the expected path (e.g., `/etc/nginx/conf.d`).
* Multiple Gateways can be reconciled by the same controller and may result in separate data-plane deployments per Gateway, depending on the controller’s design and the Gateway configuration.
## Gateway API: logical components
Conceptually the Gateway API introduces a small set of logical components that map to responsibilities and allow better role separation.
* GatewayClass — Declares which controller implementation will reconcile Gateways that reference it (examples: NGINX, Istio, HAProxy, Envoy).
* Gateway — Represents the network boundary that exposes your application traffic. Configure listeners, TLS, allowed routes, and the set of namespaces or origins that can attach Routes.
* Routes (HTTPRoute, GRPCRoute, etc.) — Define how requests are matched and forwarded to backend `Service` objects. Routes express routing rules, header manipulation, retries, timeouts, and other request-level behavior.
The Gateway API encourages clear ownership:
* GatewayClass is typically provisioned and maintained by infrastructure providers or platform maintainers.
* Gateways (and the controller lifecycle) are typically managed by SREs or platform engineers.
* Routes are authored by application developers to express application-specific routing and policies.
Recommended responsibilities:
* Infrastructure Provider: publish and maintain a `GatewayClass` and the controller distribution.
* SRE / Platform Engineers: operate the control plane, manage namespaces, RBAC, and the lifecycle of Gateways.
* Developers: create `HTTPRoute`/`GRPCRoute` manifests to expose application services safely and with application-level policies.
## Next steps
In subsequent lessons you’ll create and delete Gateway API objects, customize listener and route behavior, and test traffic flows through the NGINX data plane. Practice creating a `GatewayClass`, provisioning a `Gateway`, and attaching an `HTTPRoute` to see the controller generate data-plane configuration.
## Links and references
* Gateway API: [https://gateway-api.sigs.k8s.io/](https://gateway-api.sigs.k8s.io/)
* Kubernetes Concepts: [https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
* NGINX Gateway Fabric (product docs): [https://www.nginx.com/products/nginx-gateway-fabric/](https://www.nginx.com/products/nginx-gateway-fabric/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.