> For the complete documentation index, see [llms.txt](https://academy.cegedim.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.cegedim.cloud/compute/containers-k8s/k8s-features/gateway-api/gateway-api-ngf.md).

# NGF

Getting started with NGINX Gateway Fabric (NGF) on cegedim.cloud — deploying HTTPRoutes and Ingress migration reference

NGINX Gateway Fabric (NGF) is the Gateway API implementation that replaces the legacy NGINX Ingress Controller on cegedim.cloud. It uses NGINX as its data plane, providing a familiar operational model for teams already using ingress-nginx.

{% embed url="<https://docs.nginx.com/nginx-gateway-fabric/>" %}

**Gateway API conformance for NGF:**

| Route type | Channel      | Version        | NGF support |
| ---------- | ------------ | -------------- | ----------- |
| HTTPRoute  | Standard     | v1 (graduated) | Yes         |
| GRPCRoute  | Standard     | v1 (graduated) | Yes         |
| TLSRoute   | Experimental | v1alpha2       | No          |
| TCPRoute   | Experimental | v1alpha2       | No          |

{% hint style="info" %}
TLSRoute (raw TLS passthrough to backend) is not relevant for cegedim.cloud — HTTPS termination at the gateway level is sufficient for all F5 L4 use cases.
{% endhint %}

## What the platform provides

You do not need to install or configure NGF. The following are deployed and managed by the platform team:

| Component          | Namespace       | Role                                                  |
| ------------------ | --------------- | ----------------------------------------------------- |
| NGF controller     | `nginx-gateway` | Watches HTTPRoute/Gateway resources                   |
| `internal-gateway` | `nginx-gateway` | Entry point for internal traffic (hostPort 80/443)    |
| `external-gateway` | `nginx-gateway` | Entry point for external traffic (hostPort 8081/8443) |
| `ReferenceGrant`   | `nginx-gateway` | Allows cross-namespace HTTPRoute → Gateway references |

The F5 BigIP VIP forwards traffic to the gateway hostPorts. TLS is terminated at the F5 — NGF receives plain HTTP, but always use `https://` in your curl/browser requests. Replace `{{ cluster-name }}` with your actual cluster name (e.g. `prod-paris`, `staging-lyon`) in all examples below.

## Deploying your application

### Prerequisites

* NGF is installed on your cluster (available from the platform team via ITCare)
* The `internal-gateway` (or `external-gateway`) Gateway resource exists in the `nginx-gateway` namespace

### Step 1 — Deploy your workload

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-web
  template:
    metadata:
      labels:
        app: nginx-web
    spec:
      containers:
      - name: nginx
        image: nginx:stable
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-web
spec:
  selector:
    app: nginx-web
  ports:
  - port: 80
    targetPort: 80
```

### Step 2 — Create the HTTPRoute

The `HTTPRoute` is created in your application namespace. It references the `internal-gateway` in the `nginx-gateway` namespace — this cross-namespace reference is permitted by the `ReferenceGrant` the platform team manages.

```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-web
spec:
  parentRefs:
  - name: internal-gateway
    namespace: nginx-gateway
  hostnames:
  - "nginx-web.{{ cluster-name }}.ccs.cegedim.cloud"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: nginx-web
      port: 80
```

### Step 3 — Verify

```bash
# Check HTTPRoute status
kubectl get httproute nginx-web

# Route is ready when status shows Accepted and ResolvedRefs = True
kubectl describe httproute nginx-web

# Test the endpoint
curl https://nginx-web.{{ cluster-name }}.ccs.cegedim.cloud/
```

### Advanced example: Path-based routing with response headers

This routes `/api` traffic to a backend API service and `/` to the NGINX web server, while adding security response headers:

```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-web-advanced
spec:
  parentRefs:
  - name: internal-gateway
    namespace: nginx-gateway
  hostnames:
  - "myapp.{{ cluster-name }}.ccs.cegedim.cloud"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: my-api-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /
    filters:
    - type: ResponseHeaderModifier
      responseHeaderModifier:
        set:
        - name: X-Content-Type-Options
          value: nosniff
        - name: X-Frame-Options
          value: DENY
    backendRefs:
    - name: nginx-web
      port: 80
```

{% hint style="info" %}
HTTPRoute resources in your application namespace automatically take routing precedence over the platform catch-all routes based on hostname specificity — no coordination with the platform team is required when adding or removing routes.
{% endhint %}

## Comparison: Ingress vs HTTPRoute

| Feature          | NGINX Ingress (legacy)        | NGF HTTPRoute                   |
| ---------------- | ----------------------------- | ------------------------------- |
| Routing model    | Single namespace, annotations | Multi-namespace, role-based     |
| Path rewriting   | `rewrite-target` annotation   | `URLRewrite` filter (standard)  |
| Response headers | `configuration-snippet`       | `ResponseHeaderModifier` filter |
| IP allowlisting  | `whitelist-source-range`      | `SnippetsFilter` (alpha)        |
| Basic auth       | `auth-type: basic`            | `AuthenticationFilter` (alpha)  |
| Portability      | Controller-specific           | Works on NGF, Traefik, Istio    |

For a full annotation-by-annotation migration reference with 15 use case examples, see the [Migrate to NGF Gateway API](/compute/containers-k8s/k8s-get-started/k8s-gateway-api-migration.md).

## Clean up

```bash
kubectl delete httproute nginx-web
kubectl delete service nginx-web
kubectl delete deployment nginx-web
```

## Further Reading

{% embed url="<https://gateway-api.sigs.k8s.io/>" %}

{% embed url="<https://docs.nginx.com/nginx-gateway-fabric/overview/gateway-api-compatibility/>" %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://academy.cegedim.cloud/compute/containers-k8s/k8s-features/gateway-api/gateway-api-ngf.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.