Scenario
A scheduled maintenance task unexpectedly runs twice during a node pressure event and causes duplicate downstream effects.
A CronJob fires twice (cronjob-duplicate-run-after-eviction)
The schedule appears normal, yet the job executes twice because eviction timing exposed a window where replacement and late original shutdown overlap.
What to check first
- Identify the primary failure signal in the Eviction Turned a Single Schedule Into Two Real Executions scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Review concurrency semantics and external idempotency before blaming the scheduler clock.
Questions worth viewing together
Community-field Kubernetes problem inspired by community CronJob discussions where eviction led to duplicate execution. Cluster scheduling guarantees do not replace application-level idempotency for CronJobs.
Teams often suspect clock skew when the duplicate came from eviction and replacement timing.
Batch controllers still need downstream lock or idempotency design under disruption conditions.
Similar cases seen in the field