The line worth arguing about in that manifest is `maxAge: 3600` [7]. The field defaults to five seconds [6], so the sample is 720 times the default [12]. That gap is where the compute story lives. A browser may cache a preflight for `maxAge` seconds [6]; at five seconds, a client whose calls are spaced further apart than that re-negotiates every time, so a preflighted endpoint sees two HTTP requests per data fetch [13]. Five seconds of cache is a rounding error against a human clicking around a dashboard.
For the "reduced compute overhead" claim [5] to transfer to your cluster, two things have to be true. Your cross-origin traffic has to be complex enough to trigger preflight in the first place [10], which in practice means `Authorization` headers, `PUT`/`DELETE`, or custom headers. And you have to raise `maxAge` yourself. If your cross-origin surface is simple `GET`s, there is no `OPTIONS` to terminate and the win is config consolidation, not CPU.
The consolidation is real, and it is the part I would migrate for. `type: CORS` sits in `rules[].filters` of an `HTTPRoute` and comes from the upstream Gateway API specification [4], not from a controller-specific string like `nginx.ingress.kubernetes.io/enable-cors` [3]. That changes how the policy reviews: allowed origins, methods, headers, exposed headers, credentials and cache lifetime are typed fields on an API object [8], diffable in the same pull request as the route they protect. Whether another Gateway controller honours the identical filter is not something this write-up establishes.
The sprawl argument only half lands. Google's framing is that dozens of microservices each carrying their own middleware produce discrepancies in allowed headers, exposed headers and origin validation [11]. True. But the filter attaches per route rule, in the workload's own namespace [7], so the drift moves into `HTTPRoute` objects owned by roughly the same teams. Fewer lines, same governance problem.
One migration hazard the article does not close out: it describes the load balancer injecting the three `Access-Control-*` response headers [5] and says nothing about precedence when a backend still emits its own [14]. Ripping out the framework middleware belongs in the same change, with the response headers tested rather than assumed to be won by the edge.
Then the credentials case. Browsers block responses to credentialed requests when `Access-Control-Allow-Origin` is a literal `*` [9], and `allowOrigins` accepts explicit URLs, wildcard patterns, or a bare `*` [8]. The sample pairs `allowCredentials: true` with `https://*.partner-domain.com` [7]. The post's explanation is that the controller dynamically matches and reflects, and the material available to me stops mid-sentence there [9]. Reflection is the standard way to make that combination legal, and it also means every origin your pattern matches becomes a credentialed origin. The published field docs are the place to check that behavior before a wildcard pattern sits next to a cookie.
It is Preview [1], and the design work is worth doing now regardless: the missing capability was the stated blocker in Gateway API migrations [2] and it is no longer missing. The Ingress-Nginx path is still worth keeping warm until the field set stops moving.
