For the complete documentation index, see llms.txt. This page is also available as Markdown.

Migrate to NGF Gateway API

Step-by-step migration plan from NGINX Ingress Controller to NGINX Gateway Fabric (NGF) on cegedim.cloud clusters

Context

NGINX Ingress Controller (ingress-nginx) has reached end-of-life. The upstream project no longer receives feature development — security patches only, for a limited period. NGINX Gateway Fabric (NGF) is its replacement on cegedim.cloud, implementing the standard Kubernetes Gateway API.

This guide covers the migration of existing clusters from ingress-nginx to NGF.

Clusters provisioned with Traefik or Istio already support Gateway API natively — this migration plan applies only to clusters using NGINX Ingress Controller (ingress-nginx).

For a full explanation of Gateway API and NGF, see Gateway API.

RFC Process

Migration of existing clusters is handled via two RFCs — not one RFC per cluster:

RFC
Scope
Condition

RFC 1

All non-production clusters

Validates the procedure across all non-prod environments in a single coordinated operation

RFC 2

All production clusters

Applies the validated procedure to all prod clusters after successful non-prod RFC

Current State

Target State

Day 1 — Platform Migration (Zero Customer Impact)

Day 1 is performed by the cegedim.cloud platform team. No changes to F5, no changes to customer Ingress resources, no service interruption.

Traffic Flow During Day 1

Day 1 Steps

  1. Deploy NGF via Helm into the nginx-gateway namespace (new namespace — no conflict with existing resources)

  2. Create the internal-gateway and external-gateway Gateway resources

  3. Create the ReferenceGrant allowing HTTPRoutes in nginx-gateway to target Services in ingress-nginx

  4. nginx-int releases hostPorts 80/443 — internal-gateway DaemonSet takes them

  5. nginx-ext releases hostPorts 8081/8443 — external-gateway DaemonSet takes them

  6. Create catch-all HTTPRoutes: internal-gateway → nginx-int ClusterIP, external-gateway → nginx-ext ClusterIP

  7. F5 config: no change. Customers: no impact. Traffic flows NGF → nginx-int/nginx-ext → backends, unchanged.

Day 2+ — Application Migration Playbook

After Day 1, application teams can migrate their services independently, in any order, at their own pace. There is no deadline — legacy Ingress resources continue to work through the catch-all route until explicitly migrated.

Per-Service Migration Steps

For each service:

  1. Create an HTTPRoute with the exact hostname pointing directly to the backend Service

  2. Delete the corresponding Ingress resource

  3. Verify — hostname specificity ensures the new route takes precedence over the catch-all automatically

Example: Simple Service Migration

Example: Partial Path Migration

Migrate a subset of paths for one hostname while the rest still flows through nginx-int via the catch-all:

Annotation Migration Reference

NGINX Ingress Annotation
NGF Equivalent
Effort

rewrite-target: /$2 (prefix strip)

URLRewrite + ReplacePrefixMatch

Low

rewrite-target: /static-path

URLRewrite + ReplaceFullPath

Low

use-regex: "true"

path.type: RegularExpression

Low

server-snippet / configuration-snippet (headers)

ResponseHeaderModifier filter

Low

permanent-redirect

RequestRedirect filter (statusCode: 301)

Low

proxy-read/send/connect-timeout

UpstreamSettingsPolicy

Low

proxy-body-size

ClientSettingsPolicy

Low

x-forwarded-prefix

RequestHeaderModifier filter

Low

auth-type: basic

AuthenticationFilter (alpha)

Medium

whitelist-source-range

SnippetsFilter (alpha)

Medium

Rate limiting (limit-rps / limit-rpm)

RateLimitPolicy (alpha)

Medium

use-regex + capture group rewrite

SnippetsFilter (alpha) + rewrite directive

Medium

Alpha features (AuthenticationFilter, RateLimitPolicy, SnippetsFilter) are functional but carry API stability risk on NGF upgrades. SnippetsFilter is disabled by default and must be enabled by the platform team. Contact ITCare if your application uses these patterns.

Use Case Examples

The following 15 use cases were validated on cegedim.cloud clusters. Each shows the original NGINX Ingress resource and its NGF equivalent.

Use cases marked (alpha) rely on NGF-specific resources (SnippetsFilter, AuthenticationFilter, RateLimitPolicy, ClientSettingsPolicy) whose API may change on NGF upgrades. SnippetsFilter is disabled by default — open an ITCare ticket to request it.

01 — Prefix strip

Strip a path prefix before forwarding to the backend (e.g. /myapp/hello → /hello).

02 — Static path rewrite

Replace the entire request path with a fixed value (/probe → /health).

03 — Regex path match

Match paths using a regular expression (e.g. /api/v1/resource and /api/v42/resource match; /api/vX/resource does not).

04 — Security response headers

Inject standard security headers (Content-Security-Policy, X-Content-Type-Options, X-XSS-Protection) on every response.

05 — Basic authentication (alpha)

Protect a route with HTTP Basic Auth backed by an htpasswd secret.

06 — IP allowlist (alpha)

Allow requests only from specific CIDR ranges; deny all others with 403.

07 — Permanent redirect

Redirect a path to a different host and/or path with HTTP 301.

08 — Proxy timeouts (alpha)

Set NGINX proxy timeouts per route: connect, send, and read.

09 — Request body size limit (alpha)

Limit the maximum request body size (e.g. reject uploads above 700 KB with 413).

10 — Rate limiting (alpha)

Limit requests per client IP. The NGF RateLimitPolicy uses NGINX limit_req semantics — the reject code is configurable (503 on ingress-nginx by default, 429 with NGF).

11 — Regex capture group rewrite (alpha)

Reorder path segments using regex capture groups (e.g. /foo/status/bar → /bar/foo). There is no standard Gateway API equivalent — SnippetsFilter is required.

12 — Dynamic headers via NGINX variables (alpha)

Inject headers using NGINX runtime variables ($host, $request_id, etc.) in responses to the client or in requests to the backend. The standard ResponseHeaderModifier and RequestHeaderModifier filters only support static values — use SnippetsFilter for dynamic ones.

13 — Retry on upstream failure (alpha)

Transparently retry failed requests on another pod before returning an error to the client. Prevents a single unhealthy pod from causing 502 errors when healthy replicas are available.

14 — X-Forwarded-Prefix

Inform the backend of the public path prefix under which it is mounted. Required when the gateway strips a prefix and the backend generates absolute URLs or redirects (Spring Boot, Django, etc.).

The nginx.ingress.kubernetes.io/x-forwarded-prefix annotation is unreliable since ingress-nginx v1.12+. Use configuration-snippet with proxy_set_header directly, as shown below.

15 — Real client IP from F5 (alpha)

Restore the actual client IP from the X-Forwarded-For header set by the F5 load balancer. Without this, backends see F5's IP on every request.

As an alternative to SnippetsFilter (per-route scope), the platform team can configure real IP rewriting globally for all routes via an NginxProxy resource. Contact ITCare if a cluster-wide configuration is preferable.

Summary Timeline

Phase
Who
Description

Day 1

Platform team

NGF deployed; nginx-int/nginx-ext release hostPorts; catch-all HTTPRoutes created; F5 unchanged; zero customer impact

Day 2+

Application teams

Teams migrate Ingress resources to HTTPRoutes, service by service, in any order

Day N

Platform team

nginx-int decommissioned once all internal traffic is fully migrated to NGF HTTPRoutes

Day M

Platform team

nginx-ext decommissioned once all external traffic is fully migrated to NGF HTTPRoutes

Support

To request migration assistance or report a compatibility issue, open a ticket via ITCare with the label Gateway API Migration.

For annotation-by-annotation migration guidance beyond the table above, refer to the full NGINX Gateway Fabric migration documentation:

Last updated