← Problem Library
K8s L4 K8S 1400 · 10 min

A cleanup job deletes old ReplicaSets and one rollback becomes impossible

The workload is healthy, yet operational rollback tooling breaks because history cleanup removed metadata another tool still treats as canonical.

K8sPlatform ReliabilityLevel 4Pro10 min
Scenario

A history-pruning optimization lands and later operators cannot roll back through the usual GitOps or deployment UI path.

What to check first
  • Identify the primary failure signal in the The ReplicaSet Was Safely Pruned and the Rollback UI Lost the Breadcrumb It Needed 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

Audit which history metadata your rollback flow depends on before tightening cleanup windows.

Questions worth viewing together
What should you verify first when A cleanup job deletes old ReplicaSets and one rollback becomes impossible appears?

Community-field Kubernetes problem inspired by GitOps and deployment history discussions where cleanup removed the metadata rollback tooling needed. Operational rollback tooling often depends on annotations and history objects that look safe to prune.

What usually causes A cleanup job deletes old ReplicaSets and one rollback becomes impossible in production?

Teams often blame a broken UI when the cleanup job removed the history markers it relies on.

What should you document after resolving A cleanup job deletes old ReplicaSets and one rollback becomes impossible?

History cleanup policies should be designed with rollback tooling expectations, not only object-count reduction goals.