← Problem Library
K8s L6 K8S 1399 · 15 min

A kube-proxy replacement migration works on worker nodes and one control...

Services remain reachable from pods, yet one host-network workload on control-plane nodes loses service access after the dataplane migration.

K8sPlatform ReliabilityLevel 6Pro15 min
Scenario

A dataplane migration improves pod traffic and later only host-network agents on control-plane nodes fail service lookups or service access.

What to check first
  • Identify the primary failure signal in the The Cluster Switched Dataplanes and the Host-Network Exception Stayed Behind 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

Map host-network exception behavior before reverting the dataplane or debugging CoreDNS.

Questions worth viewing together
What should you verify first when A kube-proxy replacement migration works on worker nodes and one control... appears?

Community-field Kubernetes problem inspired by dataplane migration discussions where host-network service exceptions were lost. Pod path success does not prove host-network exception behavior survived a dataplane migration.

What usually causes A kube-proxy replacement migration works on worker nodes and one control... in production?

Teams often blame DNS or service objects when host-network exception rules were simply never migrated.

What should you document after resolving A kube-proxy replacement migration works on worker nodes and one control...?

Dataplane migrations should explicitly test host-network consumers, especially control-plane daemons and agents.