← Problem Library
K8s L5 K8S 1316 · 15 min

A mutating webhook seems available and pod creation still slows to a crawl

Endpoints are updated, yet admission remains sluggish because one node path still reuses stale connection tracking against the previous service destination.

K8sPlatform ReliabilityLevel 5Pro15 min
Scenario

A webhook rollout or service recreation finishes and later some nodes alone still show slow or failing admissions.

What to check first
  • Identify the primary failure signal in the Webhook Endpoints Updated but Old Conntrack Still Won 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

Compare node-local conntrack and service-IP history before rotating webhook certificates or timeouts.

Questions worth viewing together
What should you verify first when A mutating webhook seems available and pod creation still slows to a crawl appears?

Community-field Kubernetes problem inspired by webhook troubleshooting patterns where stale conntrack kept targeting an old backend. Fresh endpoints do not guarantee fresh dataplane state on every node.

What usually causes A mutating webhook seems available and pod creation still slows to a crawl in production?

Teams often blame DNS or TLS when stale conntrack is still steering to the old backend.

What should you document after resolving A mutating webhook seems available and pod creation still slows to a crawl?

Control-plane style traffic can still depend on ordinary node dataplane state in surprising ways.