← Problem Library
K8s L6 K8S 1343 · 15 min

An OpenSearch operator rollout restarts pods forever because one validating webhook still points at the previous service name after a Helm release rename

The new operator is up, yet resource admission loops because a leftover webhook configuration still references the old service endpoint.

K8sPlatform ReliabilityLevel 6Pro15 min
Scenario

A chart rename seems harmless and later one custom resource keeps failing reconcile with admission or validation errors.

What to check first
  • Identify the primary failure signal in the The Cluster Admitted Against a Service Name the New Release No Longer Owned 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 cluster-scoped webhook objects after chart renames before editing the resource spec again.

Questions worth viewing together
What should you verify first when An OpenSearch operator rollout restarts pods forever appears?

Community-field Kubernetes problem inspired by operator community patterns where a stale validating webhook still pointed at the previous Helm release s... Helm release renames can strand cluster-scoped objects that still control admission for new workloads.

What usually causes An OpenSearch operator rollout restarts pods forever in production?

Teams often blame CRD version drift when the webhook simply points to an old service name.

What should you document after resolving An OpenSearch operator rollout restarts pods forever?

Operators that install cluster-scoped webhooks need explicit cleanup on rename or migration.