Demo Your First Gateway with NGINX Gateway Fabric

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:

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:

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:

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:

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

Confirm the namespace exists:

kubectl get namespaces

Example output:

NAME                 STATUS   AGE
default              Active   6m1s
kube-system          Active   6m1s
local-path-storage   Active   5m57s
nginx-gateway        Active   29s

Inspect resources in the nginx-gateway namespace:

kubectl get all -n nginx-gateway

Example output:

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    <none>        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:

kubectl get gatewayclass -A

Example output:

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/
NGINX Gateway Fabric docs: https://docs.nginx.com/nginx-gateway-fabric/latest/
kind (Kubernetes in Docker): https://kind.sigs.k8s.io/

If you try this at home and run into issues, leave a comment and we’ll help troubleshoot.

Introduction & Why Gateway API

Core Gateway API Resources

Advanced Traffic Management

TLS and Cross-Namespace Security

Troubleshooting and Best Practices

Demo Your First Gateway with NGINX Gateway Fabric

Install the Gateway API CRDs

Install the NGINX Gateway Fabric Helm chart

Verify the installation

Check available GatewayClass resources

Closing

Watch Video

​Install the Gateway API CRDs

​Install the NGINX Gateway Fabric Helm chart

​Verify the installation

​Check available GatewayClass resources

​Closing

Watch Video

Install the Gateway API CRDs

Install the NGINX Gateway Fabric Helm chart

Verify the installation

Check available GatewayClass resources

Closing