← Problem Library
K8s L6 K8S 1355 · 15 min

An OpenSearch cluster on Kubernetes stays yellow because topology spread and anti-affinity now conflict after a zone label migration, leaving one replica perpetually unschedulable

The workload spec is valid, yet the scheduler cannot satisfy both the old anti-affinity rule and the new zone spread expectation at once.

K8sPlatform ReliabilityLevel 6Pro15 min
Scenario

A zone-label migration is rolled out and later stateful search replicas remain Pending even though enough nodes exist in the cluster.

What to check first
  • Identify the primary failure signal in the The Scheduler Was Given Two Placement Rules That No Longer Shared the Same Labels 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 placement rule inputs after the label migration before scaling the cluster out.

Questions worth viewing together
What should you verify first when An OpenSearch cluster on Kubernetes stays yellow appears?

Community-field Kubernetes problem inspired by OpenSearch and scheduler discussions where zone-label changes made topology spread and anti-affinity rule... Scheduler conflicts often appear only after label migrations make two formerly compatible rules diverge.

What usually causes An OpenSearch cluster on Kubernetes stays yellow in production?

Teams often blame lack of capacity when the real issue is contradictory placement logic.

What should you document after resolving An OpenSearch cluster on Kubernetes stays yellow?

Label migrations should include a scheduler policy audit for StatefulSets with both spread and anti-affinity rules.