Open-data platform engineers copy an Ingress that relies on many vendor annotations when switching controllers and routing breaks. What lesson should they take?
Select an answer to reveal the explanation.
Short Explanation
Those annotations are often dialect, not universal language. Switch controllers and the sticky notes may mean nothing—which is a big reason Gateway API tries to standardize more routing intent.
Full Explanation
When open-data engineers copy an Ingress full of vendor annotations to a new controller and routing breaks, the lesson is portability: many Ingress annotations encode implementation-specific behavior—rewrites, affinity, configuration snippets, canary weights—and are not a Kubernetes core guarantee across controllers. Changing IngressClass does not translate those sticky notes into another dialect. That pain is a major reason municipal platforms look to Gateway API’s richer standard resources for routing intent.
Annotations are not always identical across every Ingress controller. They are not ignored at runtime with only the Ingress object name programming the data plane—recognized keys actively change controller behavior. Annotations do not automatically rewrite themselves when IngressClass changes.
Exam caveat: hosts, paths, backend Services, and spec.tls.secretName are the relatively portable core; advanced edge behavior is where lock-in appears. Gateway API improves the contract but still needs a controller implementation.
Operational check: inventory annotation keys before migration, identify non-portable ones, pilot a single hostname on the new controller or Gateway API using standard fields, and compare request paths without pasting opaque snippets blindly.