Prompt and scope
The migration must preserve externally observed status codes, paths, headers, and backend selection while moving from Ingress resources and controller-specific annotations to Gateway API resources. The core skill is compatibility engineering at a proxy boundary, so this question belongs to backend. The Kubernetes blog documents several Ingress-NGINX behaviors that are easy to miss, including host-wide regex effects, implicit redirects, and normalization.
What interviewers assess
Look for an inventory of actual traffic behavior rather than a YAML translation exercise. Strong candidates separate portable Gateway API semantics from implementation-specific regular expressions, identify implicit behavior that needs an explicit filter, and propose differential tests with rollback. They should also discuss ownership, certificate and listener dependencies, observability, and a staged DNS or traffic cutover.
Questions to clarify first
- Which Ingress-NGINX version, annotations, Gateway API controller, and conformance level are deployed?
- Which hosts use
use-regex,rewrite-target, auth, canary, or custom snippets? - Are clients dependent on 301 redirects, path case, duplicate slashes, or encoded segments?
- Can the new Gateway run in parallel and receive mirrored or sampled traffic?
- Who owns Gateway, HTTPRoute, backend policy, and TLS resources?
- What is the rollback trigger and how quickly can traffic return to the old controller?
30-second answer framework
“I would first capture a behavior inventory from manifests, access logs, and black-box probes. I would generate Gateway API resources per behavior, explicitly modeling regex, rewrites, redirects, and TLS instead of assuming annotations translate. Then I would run differential tests against old and new controllers, shadow or canary traffic, compare status, location, selected backend, and latency, and keep DNS or routing rollback ready. Only after zero unexplained differences would I migrate each host.”
Step-by-step answer
Step 1: Inventory observed contracts
Parse every host and path, but verify it with requests. Ingress-NGINX regex matching can be case-insensitive and prefix-based, and an annotation can affect all paths for a host across Ingress objects. Record redirects, normalized paths, headers, authentication, timeouts, and backend choices as testable contracts.
Step 2: Classify portable and controller-specific behavior
Map ordinary host/path routing to Gateway and HTTPRoute. Treat regular-expression matching as implementation-specific and verify the selected controller’s semantics. Convert rewrite and redirect behavior to explicit HTTPRoute filters where supported. Unsupported annotations or snippets become migration blockers with an owner and replacement design.
Step 3: Build a differential test matrix
For each contract, test normal and adversarial paths: case variants, trailing slash, . and .. segments, duplicate slashes, encoded characters, missing routes, and backend failures. Compare status, Location, path received by the backend, headers, selected service, and error body. Use the same fixtures and request headers for both controllers.
Step 4: Prove controller and policy readiness
Check Gateway and HTTPRoute status conditions, listener attachment, certificate readiness, cross-namespace reference policy, and implementation support for each filter. A resource accepted by the API is not proof that the dataplane implements every requested feature.
Step 5: Canary and rollback
Run a parallel Gateway with a small host or traffic slice. Mirror safe idempotent requests where possible; otherwise replay sanitized fixtures. Abort on unexplained routing differences, 4xx/5xx changes, redirect drift, or latency regression. Keep the old controller and DNS or traffic weights unchanged until the observation window closes.
Model answer
“I would treat current Ingress-NGINX behavior as an external contract. After inventorying manifests, annotations, logs, and probes, I would model each contract explicitly in Gateway and HTTPRoute resources. Regex, rewrites, trailing-slash redirects, and URL normalization need controller-specific verification; some implicit behaviors must become explicit filters. I would run a differential matrix covering status, Location, backend path, headers, and service selection, then canary with rollback weights. Gateway status conditions and conformance claims are necessary but not sufficient, so I would retain black-box evidence before changing DNS.”
Common mistakes
- Translating YAML one-to-one → annotations may carry hidden host-wide effects → inventory runtime behavior and test it.
- Assuming
Exactmeans identical matching → the old controller may have regex or normalization side effects → probe case, slash, and encoded variants. - Relying on resource Accepted status → dataplane support can still be incomplete → check conditions and black-box responses.
- Cutting DNS first → rollback becomes slow and opaque → canary traffic while the old path remains available.
- Ignoring backend-visible paths → rewrites can break applications → assert the path and headers received by the backend.
- Testing only happy paths → outages hide in redirects and malformed URLs → include negative and adversarial fixtures.
Follow-up questions
Follow-up 1: Why can regex migration change traffic?
Ingress-NGINX can apply case-insensitive prefix-like regex behavior across paths for a host. Gateway API regular expressions are implementation-specific, while Exact and Prefix do not silently become regexes.
Follow-up 2: How do you preserve a trailing-slash redirect?
Model it explicitly with an HTTP redirect filter and test both slash variants. Do not assume a Gateway implementation adds the old 301 automatically.
Follow-up 3: What is a safe rollback signal?
Use unexplained differences in status, Location, backend path, service selection, error rate, or latency, evaluated against a fixed baseline and a bounded observation window.
Follow-up 4: What does migration tooling prove?
A converter can accelerate inventory and produce candidate resources, but it cannot prove controller-specific semantics, hidden annotation interactions, or application compatibility. Keep differential tests as the release gate.