Reviewing the behavior Ingress2Gateway cannot translate exactly

Ingress2Gateway 1.0 translates Ingress resources and controller-specific configuration into Gateway API resources. The release expands Ingress NGINX annotation support and improves the warnings produced when a translation is incomplete. With Ingress NGINX retirement scheduled for this month, the practical value is a reviewed starting point for migration.

I would make the warnings part of the migration record. A generated manifest can be structurally valid while leaving an application requirement unresolved. This release is useful because its announcement discusses those gaps with concrete examples. Operators need to decide what the replacement should do when the old configuration has no equivalent in the target API.

After eight years with Kubernetes, I place considerable value on configuration that can be reviewed and reconciled. My experience includes Talos clusters with Cilium and GitOps. That makes me interested in a migration tool whose output becomes ordinary declared configuration. It also makes me cautious about accepting generated resources without retaining the reasoning behind manual changes.

Translation has an input and an implementation target

The versioned README describes providers and emitters as separate components. A provider reads Ingress resources and provider-specific custom resources into a generic intermediate representation. An emitter produces the final Gateway API configuration. The standard emitter produces core resources, while implementation-specific emitters can also produce extensions for a selected gateway project.

This separation explains why supporting an input annotation does not always imply a portable output. A requirement may fit an extension provided by one target implementation. I would record that dependency explicitly during controller selection. An extension can be appropriate, but it becomes part of the configuration that a future migration must account for.

For a file-based review, the release documents an invocation of this form:

ingress2gateway print \
  --input-file ingress.yaml \
  --providers=ingress-nginx > gateway.yaml

The input filename is illustrative. This command generates configuration for inspection. I would retain the emitted diagnostics with the output and review both before applying anything. The README also documents cluster reads and namespace selection, but a file-based invocation gives a reviewer an explicit input to compare with the proposed resources.

The release announcement reports support for over thirty common Ingress NGINX annotations, compared with three before this release. It describes controller-level integration tests for supported annotations and representative combinations. Those tests run Ingress NGINX alongside multiple Gateway API controllers and compare request behavior after translation. That is stronger evidence than checking that the generated YAML matches an expected file.

It still leaves a scope question for an individual migration. Representative combinations in the project tests cannot establish every application's requirements. I would use the upstream tests as evidence about the translator and add checks derived from the actual routes and annotations being moved. The migration review should explain any behavior that the application depends on but the test set does not exercise.

Timeouts expose the semantic gap

The announcement's worked example includes Ingress NGINX read and send timeout annotations. Ingress2Gateway warns that these express TCP-level timeouts and that its translation to a Gateway API request timeout is best effort. A field containing a duration does not establish that both controllers measure the same interval.

I would ask the application owner what the timeout is meant to constrain before accepting the translation. The answer should describe the expected request behavior. Merely carrying a number into a differently defined field would preserve the appearance of policy while changing its effect. The release example asks operators to verify whether the generated request timeout meets their requirements.

The example also includes a body-size annotation that has no standard Gateway API equivalent. The standard emitter reports the omission. Implementation-specific emitters may produce additional configuration to capture the requirement. I would verify the chosen implementation's limits using representative requests, including the boundary the application actually expects to support.

Defaults need the same review as explicit fields. The announcement notes that implementations have body-size and buffering defaults, but those defaults are not evidence that a particular application's uploads will work. I would document the required behavior independently of the old annotation and check the new controller against it. That leaves a clear acceptance criterion if the implementation changes again.

Matching behavior needs request-level tests

Regular expressions are another example in the release. Ingress NGINX uses case-insensitive prefix matching for the illustrated regex route. The translator preserves that behavior with a pattern that includes a case-insensitive prefix and a trailing match. The announcement then shows how an operator might deliberately change the expression when the application requires different matching.

I would separate the preservation test from that policy change in review. First establish which requests the existing configuration accepts. Then record which of those requests the owner intends the new configuration to accept. A corrected route and an accidental incompatibility can produce similar-looking diffs without that explanation.

URL normalization requires implementation-specific attention as well. The announcement says standard Gateway API does not configure it and that behavior varies among implementations. I would include request paths relevant to the application in the migration checks. A successful request to the ordinary homepage says little about unusual paths that interact with normalization and routing rules.

The tool also warns about unsupported configuration snippets. Those require examination against the selected controller's documentation. I would avoid treating a warning as an instruction to reproduce every old directive. Some configuration may have no current requirement. Removing it should still be an explicit decision supported by application review.

Cutover needs evidence beyond generation

The release recommends development-cluster testing followed by deploying Gateway API configuration alongside the existing Ingress. It suggests gradually shifting traffic through facilities such as weighted DNS or a load balancer. Only after the traffic has moved does it recommend deleting the Ingress resources and uninstalling the old controller.

I would make the reviewed output and its diagnostics part of the change record before that process begins. Every unresolved warning should have a decision and an owner. The final check should establish that the selected controller implements the agreed behavior and that the retired implementation no longer receives production traffic. The generated manifests provide the configuration to test, while those acceptance criteria determine whether the migration is complete.