Rancher UI node selector vs kubectl Pod Topology Spread Constraints for multi‑zone workloads

Trade‑off: UI node selector or raw manifests

The Rancher UI offers a quick path to deploy workloads, exposing only a basic node selector. When a cluster spans multiple availability zones, the UI cannot express the full Pod Topology Spread Constraints required for even distribution and high availability.

Direct application of manifests via kubectl or a GitOps workflow allows explicit topology constraints, but introduces a separate management surface and the risk of configuration drift if UI changes are not mirrored in the source of truth.

What decision factors should influence the choice between the UI’s simplified node selector and the granular scheduling available in raw manifests? How can teams ensure that changes made through the UI are reflected in the underlying GitOps source to avoid drift? Are there documented limitations that prevent the UI from preserving custom scheduling fields when using the Edit as YAML feature?