← Problem Library
K8s L6 K8S 1303 · 16 min

Leader election looks healthy until the controller is Helm-migrated because the lease object remained in the old namespace while the new deployment watches the new one

Controllers restart and never stabilize because they compete through different lease namespaces after a chart migration split the config.

K8sPlatform ReliabilityLevel 6Pro16 min
Scenario

A controller is reinstalled or moved between namespaces and begins flapping without an obvious RBAC denial.

What to check first
  • Identify the primary failure signal in the Controller Moved, Lease Namespace Stayed Behind scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Check the actual Lease object location before chasing resource pressure or image bugs.

Questions worth viewing together
What should you verify first when Leader election looks healthy until the controller is Helm-migrated appears?

Community-field Kubernetes problem inspired by Discuss Kubernetes cases where leader-election failed after namespace or Helm migration drift. Leader election failures after migration often come from object placement drift, not from the controller logic itself.

What usually causes Leader election looks healthy until the controller is Helm-migrated in production?

Teams often blame restart loops on probes while two controllers are reading different lease identities.

What should you document after resolving Leader election looks healthy until the controller is Helm-migrated?

Helm migrations can split controller flags and lease storage assumptions across namespaces.