← Problem Library
K8s L6 K8S 1347 · 15 min

A kube-proxy migration to IPVS passes and one service blackholes traffic

Most nodes converge, yet one path fails because two proxying models overlap on a subset of hosts.

K8sPlatform ReliabilityLevel 6Pro15 min
Scenario

A networking optimization rollout appears healthy and later one node alone becomes the source of intermittent service traffic loss.

What to check first
  • Identify the primary failure signal in the The Cluster Migrated to a New Proxy Mode and One Node Still Enforced the Old One 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 live proxy mode and residual rules on the affected node before changing Service objects.

Questions worth viewing together
What should you verify first when A kube-proxy migration to IPVS passes and one service blackholes traffic appears?

Community-field Kubernetes problem inspired by kube-proxy migration discussions where stale iptables rules persisted after an uneven IPVS rollout. Mode migrations can fail asymmetrically even when the daemonset rollout is mostly green.

What usually causes A kube-proxy migration to IPVS passes and one service blackholes traffic in production?

Teams often blame CNI or service selector drift when a single node is still enforcing the previous proxy model.

What should you document after resolving A kube-proxy migration to IPVS passes and one service blackholes traffic?

Proxy mode migrations should validate residual state cleanup on every node, not only pod rollout success.