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.
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 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
Deploy NGF via Helm into the
nginx-gatewaynamespace (new namespace — no conflict with existing resources)Create the
internal-gatewayandexternal-gatewayGateway resourcesCreate the
ReferenceGrantallowing HTTPRoutes innginx-gatewayto target Services iningress-nginxnginx-intreleases hostPorts 80/443 —internal-gatewayDaemonSet takes themnginx-extreleases hostPorts 8081/8443 —external-gatewayDaemonSet takes themCreate catch-all HTTPRoutes:
internal-gateway→nginx-intClusterIP,external-gateway→nginx-extClusterIPF5 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:
Create an
HTTPRoutewith the exact hostname pointing directly to the backendServiceDelete the corresponding
IngressresourceVerify — 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
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
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.
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.).
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.
Summary Timeline
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

