← Problem Library
K8s L4 K8S 1308 · 14 min

An ingress controller never reloads one new config because the watched namespace split during deployment and the ConfigMap now lives outside the controller's watch scope

Most ingress changes apply, yet one setting never lands because the controller is not actually watching the namespace that now holds the config object.

K8sPlatform ReliabilityLevel 4Pro14 min
Scenario

A platform team separates controller and configuration namespaces and later one class of ingress settings silently stops applying.

What to check first
  • Identify the primary failure signal in the Controller Healthy, Config Outside Its Watch Boundary 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 controller watch flags with the new ConfigMap location before rolling the deployment again.

Questions worth viewing together
What should you verify first when An ingress controller never reloads one new config appears?

Community-field Kubernetes problem inspired by community discussions where ingress settings stopped applying after namespace watch scope drift. Healthy controllers can ignore config simply because the object moved outside their scope.

What usually causes An ingress controller never reloads one new config in production?

Teams often blame the ingress template when the controller never watched the new config namespace.

What should you document after resolving An ingress controller never reloads one new config?

Namespace hygiene refactors often create watch-scope drift in controllers.