Spring Cloud Kubernetes watcher scope: filter before broadcasting refresh

Last updated: 1 Oct 20264 min read

tutorial

A configuration watcher should react only to the namespace and objects owned by the workload.

A watch can be too broad

A cluster has dozens of dispatch deployments. If every service watches every ConfigMap, a routine edit can produce irrelevant refresh work across replicas. Spring Cloud Kubernetes exposes reload namespace and label filters for event-based monitoring. Tie each application to its named source and test the label scheme. RBAC is the access boundary; a label filter is only operational scoping.

Choose what refresh means

Even a correctly filtered event does not ensure a pooled client adopts new credentials. Use the reload contract to decide between property refresh and a controlled restart. Keep a per-pod configuration revision in observability so operators can see whether every replica has advanced.

Test one relevant and one irrelevant change

Update the target ConfigMap and require exactly the intended services to adopt it. Update an unrelated ConfigMap in the same namespace and verify no refresh. Then remove a watched key and confirm the application's documented fallback or failure behavior rather than assuming old bean state disappeared.

Implementation sketch

spring:
  cloud:
    kubernetes:
      reload:
        enabled: true
        mode: event
        namespaces: [dispatch]
        monitoring-config-maps: true
        monitoring-secrets: false

Cost and verification

A watch keeps an API connection and processes change events. Narrow scopes reduce unnecessary reloads, but verification still needs an end-to-end deployment test.

Common Mistakes

Do not treat a label filter as a security boundary.
Do not refresh every replica for an unrelated namespace's edit.
Do not claim a watcher updated a bean that only reads its value at construction.