> ## 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.
# Demo Your First Gateway with NGINX Gateway Fabric
> Hands-on demo for installing Gateway API CRDs, deploying NGINX Gateway Fabric control plane, and verifying resources to create Gateways and Routes
Welcome to this hands‑on demo. In this lesson you'll install the Kubernetes Gateway API CRDs, deploy the NGINX Gateway Fabric control plane, and verify the installed resources so you can begin creating Gateways and Routes.
This walkthrough follows the NGINX Gateway Fabric public documentation. If you need deeper configuration examples, consult the official docs linked at the end.
Overview
* Install the Kubernetes Gateway API CRDs required by Gateway API types.
* Install the NGINX Gateway Fabric control plane with Helm.
* Verify namespace, pods, services, and the available GatewayClass.
Prerequisites
* A Kubernetes cluster (local clusters like kind or Docker Desktop are fine).
* kubectl configured to talk to your cluster.
* Helm 3.x installed.
Tip: For a local test environment use a `kind` cluster. In cloud environments you typically expose the control plane using a `LoadBalancer` service type instead of `NodePort`.
## Install the Gateway API CRDs
NGINX Gateway Fabric relies on Gateway API types (GatewayClass, Gateway, HTTPRoute, GRPCRoute, etc.). Install the Gateway API custom resource definitions (CRDs) provided by the NGINX repo:
```bash theme={null}
kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.5.0" | kubectl apply -f -
```
Expected (trimmed) confirmation output:
```bash theme={null}
customresourcedefinition.apiextensions.k8s.io/backendtlspolicies.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/gateways.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/grpcroutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/listenersets.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/referencegrants.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/tlsroutes.gateway.networking.k8s.io created
validatingadmissionpolicy.admissionregistration.k8s.io/safe-upgrades.gateway.networking.k8s.io created
validatingadmissionpolicybinding.admissionregistration.k8s.io/safe-upgrades.gateway.networking.k8s.io created
```
These CRDs make the Gateway API resource types available in your cluster.
## Install the NGINX Gateway Fabric Helm chart
Install the NGINX Gateway Fabric control plane into a dedicated namespace (`nginx-gateway`). For local clusters without a cloud load balancer we’ll expose the NGINX service as `NodePort`. In production or cloud environments prefer `LoadBalancer`.
Command:
```bash theme={null}
helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
--create-namespace -n nginx-gateway \
--set nginx.service.type=NodePort \
--set-json 'nginx.service.nodePorts=[{"port":31437,"listenerPort":80},{"port":30478,"listenerPort":8443}]'
```
What these flags do:
| Flag | Purpose | Example / Notes |
| - | - | - |
| `oci://ghcr.io/...` | Chart OCI location | Pulls the NGINX Gateway Fabric chart from GitHub Container Registry |
| `--create-namespace -n nginx-gateway` | Create/use namespace for installation | Installs into `nginx-gateway` |
| `--set nginx.service.type=NodePort` | Service exposure type for NGINX | Useful for local clusters without a cloud load balancer |
| `--set-json 'nginx.service.nodePorts=[...]'` | Map host NodePort numbers to listener ports | Example: `--set-json 'nginx.service.nodePorts=[{"port":31437,"listenerPort":80},{"port":30478,"listenerPort":8443}]'` |
Warning: Using `NodePort` binds ports on cluster nodes. For production or cloud deployments use `LoadBalancer` or an Ingress controller integrated with your cloud provider.
Example trimmed Helm output:
```bash theme={null}
Pulled: ghcr.io/nginx/charts/nginx-gateway-fabric:2.5.1
Digest: sha256:74a0c11f25c25851ae19f71af6cc075d201db8bdc6e38f1e499b3e9172a19439
I0411 16:35:20.030525 16603 warnings.go:110] "Warning: unrecognized format \"int64\""
I0411 16:35:20.084464 16603 warnings.go:110] "Warning: unrecognized format \"int32\""
NAME: ngf
LAST DEPLOYED: Sat Apr 11 16:35:20 2026
NAMESPACE: nginx-gateway
STATUS: deployed
REVISION: 1
TEST SUITE: None
```
Note: the `Warning: unrecognized format "int32"/"int64"` messages are informational OpenAPI warnings and can usually be ignored.
## Verify the installation
1. Confirm the namespace exists:
```bash theme={null}
kubectl get namespaces
```
Example output:
```bash theme={null}
NAME STATUS AGE
default Active 6m1s
kube-system Active 6m1s
local-path-storage Active 5m57s
nginx-gateway Active 29s
```
2. Inspect resources in the `nginx-gateway` namespace:
```bash theme={null}
kubectl get all -n nginx-gateway
```
Example output:
```bash theme={null}
NAME READY STATUS RESTARTS AGE
pod/ngf-nginx-gateway-fabric-c98866d6f-n5xgs 1/1 Running 0 34s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ngf-nginx-gateway-fabric ClusterIP 10.96.100.43 443/TCP 34s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ngf-nginx-gateway-fabric 1/1 1 1 34s
NAME DESIRED CURRENT READY AGE
replicaset.apps/ngf-nginx-gateway-fabric-c98866d6f 1 1 1 34s
```
Conceptual notes: control plane vs data plane
* The pods you see in the `nginx-gateway` namespace are the control plane components. The control plane stores configuration and watches Gateway API resources.
* When you create a Gateway and attach Routes, the control plane configures the corresponding data plane (NGINX instances or sidecars) that actually process the application traffic.
* The control plane manages lifecycle, configuration distribution, and reconciliation for data plane instances.
## Check available GatewayClass resources
GatewayClass objects advertise which controller/author manages Gateways of that class. After installation you should see a GatewayClass for NGINX.
List GatewayClass objects cluster-wide:
```bash theme={null}
kubectl get gatewayclass -A
```
Example output:
```bash theme={null}
NAME CONTROLLER ACCEPTED AGE
nginx gateway.nginx.org/nginx-gateway-controller True 108s
```
When you create a Gateway, select the `GatewayClass` you want the controller to manage. If you install other implementations (HAProxy, Envoy, Istio, etc.) you'll see additional GatewayClass entries.
Quick reference — common next steps
* Create a Gateway resource that references the `nginx` GatewayClass.
* Create HTTPRoute or GRPCRoute resources to attach services to Gateway listeners.
* Inspect control plane logs and data plane resources to see configuration propagation.
## Closing
You now have the Gateway API CRDs installed and the NGINX Gateway Fabric control plane running in your cluster. From here you can create Gateways and Routes and watch how the control plane configures data plane instances to handle traffic.
Links and references
* Gateway API: [https://gateway-api.sigs.k8s.io/](https://gateway-api.sigs.k8s.io/)
* NGINX Gateway Fabric docs: [https://docs.nginx.com/nginx-gateway-fabric/latest/](https://docs.nginx.com/nginx-gateway-fabric/latest/)
* kind (Kubernetes in Docker): [https://kind.sigs.k8s.io/](https://kind.sigs.k8s.io/)
If you try this at home and run into issues, leave a comment and we’ll help troubleshoot.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.