Replace Ingress with NGINX Gateway Fabric: A Step‑by‑Step Guide

The Kubernetes ecosystem is shifting away from the Ingress NGINX controller, which will become read‑only after 2025‑11‑12. Organizations running Kubernetes should evaluate the Gateway API as a future‑proof, standardized alternative. NGINX Gateway Fabric (NGF) implements the Gateway API with a high‑performance NGINX data plane and offers advanced features such as blue‑green and canary deployments, A/B testing, request/response manipulation, and role‑based multi‑tenant governance.

Step 1: Define and Deploy Sample Applications

Create a demo namespace and deploy two Deployment objects (one for a web service and one for an API service) together with corresponding ClusterIP services.

---
apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  namespace: demo
  labels:
    app: demo-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:latest
        args:
        - "-text=Demo App v1"
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: demo
spec:
  selector:
    app: demo-app
  ports:
  - port: 80
    targetPort: 5678
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
  namespace: demo
  labels:
    app: demo-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:latest
        args:
        - "-text=API Service v1"
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: demo-api
  namespace: demo
spec:
  selector:
    app: demo-api
  ports:
  - port: 80
    targetPort: 5678

Apply the YAML and verify that the pods and services are running:

kubectl get pods,svc -n demo

Step 2: Deploy NGINX Gateway Fabric

Install the Gateway API CRDs required by NGF:

kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.2.1" \ 
  | kubectl apply -f -

Confirm the CRDs are present:

kubectl get crd | grep gateway.networking.k8s.io

Deploy NGF using the official Helm chart. The example sets the service type to NodePort; in managed clouds you may prefer LoadBalancer.

helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
  --create-namespace \
  -n nginx-gateway \
  --set nginx.service.type=NodePort

Verify the NGF pods and service:

kubectl get pods,svc -n nginx-gateway

Step 3: Create a Gateway Resource

Define a Gateway that will listen on port 80 and allow routes from all namespaces:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-gateway
  namespace: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

Apply the gateway definition and confirm its creation:

kubectl apply -f gateway.yaml
kubectl get pods,svc -n nginx-gateway

Step 4: Define HTTPRoutes for the Sample Apps

Create an HTTPRoute that maps /web to the demo-app service and /api to the demo-api service. The route references the gateway created in the previous step.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo-route
  namespace: demo
spec:
  parentRefs:
  - name: demo-gateway
    namespace: nginx-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /web
    backendRefs:
    - name: demo-app
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: demo-api
      port: 80

Apply the route:

kubectl apply -f route.yaml

Step 5: Test the Exposed Endpoints

With the NGF service exposed as a NodePort (31678 in this example), you can reach the routes from the host machine:

curl http://192.168.2.5:31678/web
curl http://192.168.2.5:31678/api

The demo confirms that the Gateway API successfully routes external traffic to the internal services. Future tutorials will cover TLS‑enabled routes.