This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Cloud Kubernetes 3.2.0! |
Reload namespace and label filtering
By default, a namespace chosen using the steps outlined in Namespace resolution will be used to listen to changes in configmaps and secrets. i.e.: if you do not tell reload what namespaces and configmaps/secrets to watch for, it will watch all configmaps/secrets from the namespace that will be computed using the above algorithm.
On the other hand, you can define a more fine-grained approach. For example, you can specify the namespaces where changes will be monitored:
spring:
application:
name: event-reload
cloud:
kubernetes:
reload:
enabled: true
strategy: shutdown
mode: event
namespaces:
- my-namespace
Such a configuration will make the app watch changes only in the my-namespace
namespace. Mind that this will
watch all configmaps/secrets (depending on which one you enable). If you want an even more fine-grained approach,
you can enable "label-filtering". First we need to enable such support via : enable-reload-filtering: true
spring:
application:
name: event-reload
cloud:
kubernetes:
reload:
enabled: true
strategy: shutdown
mode: event
namespaces:
- my-namespaces
monitoring-config-maps: true
enable-reload-filtering: true
What this will do, is watch configmaps/secrets that only have the spring.cloud.kubernetes.config.informer.enabled: true
label.
Name | Type | Default | Description |
---|---|---|---|
|
|
|
Enables monitoring of property sources and configuration reload |
|
|
|
Allow monitoring changes in config maps |
|
|
|
Allow monitoring changes in secrets |
|
|
|
The strategy to use when firing a reload ( |
|
|
|
Specifies how to listen for changes in property sources ( |
|
|
|
The period for verifying changes when using the |
|
|
namespaces where we should watch for changes |
|
|
|
enabled labeled filtering for reload functionality |
Notes:
-
You should not use properties under
spring.cloud.kubernetes.reload
in config maps or secrets. Changing such properties at runtime may lead to unexpected results. -
Deleting a property or the whole config map does not restore the original state of the beans when you use the
refresh
level.