docs: add RFC 0007 for Gateway API ingress migration - #7
Conversation
github-actions
Bot
added
rfc
71f6a59 to
8728f4c
Compare
yatharthranjan
left a comment
yatharthranjan
left a comment
There was a problem hiding this comment.
Thanks Mani, great work. Just some comments.
Also had a question on other redirect / proxy properties that we configure for some of the components such as path rewrites/redirects, rate limiting, etc. Is there provision for these already?
|
|
||
| Summary | ||
| ------- | ||
| This RFC proposes migrating RADAR-base ingress from the annotation-driven [NGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx) to the [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/), implemented by [NGINX Gateway Fabric (NGF)](https://github.com/nginx/nginx-gateway-fabric). The two stacks run **in parallel**: NGINX Ingress keeps serving production traffic on its own load balancer while the Gateway API stack is stood up alongside it, validated one service at a time, and cut over per-service. The rollout starts on the **stage** cluster with **radar-gateway** as the first migrated service. Everything is delivered as Helm charts and wired through Helmfile behind `_install` flags, so the entire stack is GitOps-managed and reversible. |
There was a problem hiding this comment.
since this is open-source radar-base RFC, leave out any specifics of KCL deployments. You can mention using generic canary releases or blue-green deployment as a good to have.
There was a problem hiding this comment.
Updated ✅ - removed the KCL-specifics - cluster name, hostname and infra IDs from the diagram and rollout, and framed the parallel run + per-service DNS cutover as a generic canary / blue-green pattern (weighted split noted as a good-to-have).
| 6. Repeat step-by-step for remaining services. Only after all are migrated, plan NGINX Ingress removal (separate RFC/PR). | ||
| 7. Promote the same flow to production once stage is stable. | ||
|
|
||
| **Resource footprint (NGF):** one controller Deployment plus per-Gateway nginx data-plane pods; sizeable but comparable to the existing ingress controller. Node placement can be constrained via `nodeSelector`/`tolerations` under the `nginx_gateway_fabric` values. |
There was a problem hiding this comment.
Do we have an indication for initial setting of requests and limits?
|
|
||
| Open questions | ||
| -------------- | ||
| - **Gateway naming:** the chart names the Gateway `radar-base` (via `fullnameOverride`); the old manual stage Gateway was `nginx` (now deleted). `radar-base` is uncontested going forward — confirm we standardise on it. |
There was a problem hiding this comment.
should we name it radar-base-k8s-gateway ?
| Open questions | ||
| -------------- | ||
| - **Gateway naming:** the chart names the Gateway `radar-base` (via `fullnameOverride`); the old manual stage Gateway was `nginx` (now deleted). `radar-base` is uncontested going forward — confirm we standardise on it. | ||
| - **Migration order:** sequence of services after `radar-gateway`, and any that need special routing (redirects, path rewrites) not yet covered by the HTTPRoute template. |
There was a problem hiding this comment.
This should be discussed or checked (via existing helm-charts / production.yaml files) before cutting over
There was a problem hiding this comment.
Agreed. Before any service is cut over, I audit its ingress annotations against the existing helm-charts / per-cluster values and reproduce each as an HTTPRoute filter or NGF policy — a per-service gate, not a global one. I've inventoried the annotations in use across all services; the ones needing extra care are those relying on CORS preflight, session-cookie affinity, basic auth, or raw config snippets (which use NGF's SnippetsFilter).
As discussed, radar-gateway (first) needs a URL rewrite, CORS headers, a body-size policy, and one small snippet.
The full mapping is in the new "Routing feature parity" section, and each service's HTTPRoute is validated with curl --resolve against the new NLB before its DNS moves.
| -------------- | ||
| - **Gateway naming:** the chart names the Gateway `radar-base` (via `fullnameOverride`); the old manual stage Gateway was `nginx` (now deleted). `radar-base` is uncontested going forward — confirm we standardise on it. | ||
| - **Migration order:** sequence of services after `radar-gateway`, and any that need special routing (redirects, path rewrites) not yet covered by the HTTPRoute template. | ||
| - **NGF sizing / placement:** dedicated nodes or tolerations for the NGF data plane on stage/production? |
There was a problem hiding this comment.
lets use DMZ (public subnet) ones, same as nginx currently
Yes, mostly. I've added a "Routing feature parity" section mapping every ingress annotation we actually use to its Gateway API equivalent: Redirects (HTTP→HTTPS) — already in our HTTPRoute template (RequestRedirect filter). |
2 participants
Summary
Adds RFC 0007 proposing the migration of RADAR-base ingress from the annotation-driven NGINX Ingress Controller to the Kubernetes Gateway API, implemented with NGINX Gateway Fabric (NGF) 2.6.6.
The two stacks run in parallel: NGINX Ingress keeps serving production on its own NLB while the Gateway API stack is stood up alongside it, validated one service at a time, and cut over per-service via DNS. The rollout starts on the stage cluster with radar-gateway as the first migrated service. The whole stack is Helm/Helmfile-managed behind opt-in
_installflags and is fully reversible.What's included
radar-gatewayService.Notes