tigera-operator pod re-schedules onto cordoned node during EKS managed node group rolling updates, causing PodEvictionFailure

Summary During EKS managed node group rolling updates, the tigera-operator deployment's replacement pod repeatedly lands back on the node being drained, preventing the node from ever becoming empty. This causes the update to fail with PodEvictionFailure after the drain window expires. The issue is intermittent — it depends on scheduler scoring conditions at the time of the drain, not on any cluster-specific configuration difference.

Environment Calico Open Source: v3.32.1 Tigera Operator: v1.42.3 Kubernetes: v1.35 Helm-based installation

Current Tigera Operator Tolerations The Tigera Operator deployment contains the following tolerations:

YAML 1 tolerations: 2 - effect: NoExecute 3 operator: Exists 4 - effect: No Schedule 5 operator: Exists

Observed Behaviour During a managed node group rolling update:

A node is cordoned and drained. The Tigera Operator pod is evicted successfully. The Deployment immediately creates a replacement pod. The replacement pod is scheduled back onto the node currently being drained. The drain process evicts the pod again. The cycle repeats until the EKS drain timeout expires. The node group update fails with PodEvictionFailure.

Observed Characteristics The behaviour appears intermittent. Under identical configuration:

Some upgrades complete successfully. Some upgrades fail.

Is the current toleration configuration expected? Should the Tigera Operator tolerate all NoSchedule taints via:

YAML 1 - effect: NoSchedule 2 operator: Exists

We are looking for a supported, long-term solution that:

Prevents operator rescheduling onto draining nodes Avoids upgrade-related PodEvictionFailure Remains compatible with future Calico/Tigera upgrades Does not introduce operational risk to existing workloads

Any guidance or recommended configuration patterns would be greatly appreciated.

Tigera Team: Has the Calico/Tigera team observed similar behaviour during EKS managed node group upgrades, and if so, what is the officially recommended deployment pattern for the Tigera Operator in EKS environments?