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

Short answer

If the workload must spread evenly across availability zones, the Rancher UI's node selector is the wrong tool regardless of convenience: a node selector can only pin pods to labeled nodes, it cannot express distribution. Multi-zone high availability requires topologySpreadConstraints, which the Rancher workload form does not expose — so the manifest (via kubectl or GitOps) becomes your authoring surface. The UI is acceptable only for single-zone or placement-tolerant workloads.

Why the node selector falls short

A node selector such as topology.kubernetes.io/zone: us-east-1a forces all replicas into one zone — the opposite of HA. Spreading requires constraints like:

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: my-app

Use whenUnsatisfiable: DoNotSchedule for strict guarantees, but note the trade-off: during a zone outage, remaining zones may be unable to satisfy maxSkew, leaving pods Pending. ScheduleAnyway degrades gracefully to best-effort spreading.

Decision factors

• UI node selector: single-zone clusters, dev/sandbox workloads, operators who need a simple workflow, or cases where uneven placement is tolerable.
• Raw manifests / GitOps: cross-zone skew control, hard anti-affinity, auditable scheduling policy, and any production HA requirement.

The drift problem — and the honest limitation

The risky pattern is mixing surfaces: hand-author YAML with topology constraints, then have someone later edit the workload through the Rancher form UI. Fields the form does not model can be dropped on save. "Edit as YAML" generally preserves what is already in the spec, but round-trip behavior varies by Rancher version — treat this as unverified until you test it on yours:

# 1. Deploy with constraints via YAML
# 2. Open the workload in the Rancher form UI, change something trivial, save
# 3. Diff the result
kubectl get deploy my-app -o yaml | grep -A6 topologySpreadConstraints

If the constraints vanish, that confirms form edits are lossy on your version and the form UI must be off-limits for that workload.

Keeping the UI and GitOps in sync

The reliable answer is to not sync at all — pick one source of truth:

1. GitOps-only (recommended): With Rancher Fleet or Argo CD, the repo is authoritative. Reconciliation reverts UI-made changes, which both prevents drift and makes UI edits pointless for persistent config. Restrict workload-edit RBAC for UI users where possible.
2. Prototype-then-commit: If the UI is needed for discovery, prototype there, export the YAML, commit it, and manage exclusively via GitOps afterward.

Server-side apply (kubectl apply --server-side) surfaces field-ownership conflicts when multiple actors manage one object, but it detects collisions rather than preventing them — discipline still matters.

Caveats worth checking

• topology.kubernetes.io/zone labels are auto-populated by cloud-integrated providers; on bare metal you must label nodes yourself. Verify with kubectl get nodes --show-labels.
• Topology spread constraints act at scheduling time only — they do not rebalance running pods. A rollout (or the Descheduler) is needed to converge existing replicas.
• Confirm actual placement after deploying: kubectl get pods -o wide grouped by node/zone should match your intended maxSkew.

Version note: Rancher's YAML round-trip behavior and UI field coverage change between releases; the diff test above is the dependable check for your environment.