Transit runs more than one Ingress controller in the cluster and must ensure a new portal Ingress is handled by the nginx implementation. What should they set?
Select an answer to reveal the explanation.
Short Explanation
When several controllers share a cluster, IngressClass is the name tag that says “this rule set is for nginx,” not the other edge. Point the Ingress at the right class so the right controller claims it.
Full Explanation
When transit runs more than one Ingress controller, IngressClass (or the Ingress’s class field / annotation equivalent in older styles) associates a new portal Ingress with the intended implementation—such as nginx. The class is the name tag on the rule set so the correct controller claims it and others ignore it. Without the right class in a multi-controller cluster, routes may never program on the edge you expect.
PriorityClass equal to a controller Deployment name affects Pod scheduling priority, not which controller consumes an Ingress. TopologySpreadConstraint on an Ingress object is not how controller affinity for Ingress claiming works—Ingress is not scheduled like a Pod. Renaming a Service externalTrafficPolicy field to a controller namespace is invalid and unrelated to IngressClass selection.
Exam caveat: some clusters define a default IngressClass; omitting the field can silently bind to the default controller. Explicit class is safer when nginx and another implementation coexist.
Operational check: kubectl get ingressclass, set spec.ingressClassName on the portal Ingress to the nginx class, watch only the nginx controller logs/status update, and verify the portal hostname responds via that controller’s Service.