PropertySource Reload

此功能已在 2020.0 版本中弃用。请参阅 null 控制器,了解实现相同功能的替代方法。

This functionality has been deprecated in the 2020.0 release. Please see the null controller for an alternative way to achieve the same functionality.

某些应用程序可能需要检测外部属性源上的更改并更新其内部状态以反映新配置。Spring Cloud Kubernetes 的重新加载功能能够在相关的 “ConfigMap” 或 “Secret” 发生更改时触发应用程序重新加载。

Some applications may need to detect changes on external property sources and update their internal status to reflect the new configuration. The reload feature of Spring Cloud Kubernetes is able to trigger an application reload when a related ConfigMap or Secret changes.

默认情况下,此功能被禁用。您可以通过使用 spring.cloud.kubernetes.reload.enabled=true 配置属性(例如,在 application.properties 文件中)启用此功能。请注意,这只会启用 configmaps 的监视(即:spring.cloud.kubernetes.reload.monitoring-config-maps 将设置为 true)。如果您想启用 Secrets 的监视,则必须显式地通过 spring.cloud.kubernetes.reload.monitoring-secrets=true 完成此操作。

By default, this feature is disabled. You can enable it by using the spring.cloud.kubernetes.reload.enabled=true configuration property (for example, in the application.properties file). Please notice that this will enable monitoring of configmaps only (i.e.: spring.cloud.kubernetes.reload.monitoring-config-maps will be set to true). If you want to enable monitoring of secrets, this must be done explicitly via : spring.cloud.kubernetes.reload.monitoring-secrets=true.

以下重新加载级别受支持(通过设置 spring.cloud.kubernetes.reload.strategy 属性):

The following levels of reload are supported (by setting the spring.cloud.kubernetes.reload.strategy property):

  • refresh (default): Only configuration beans annotated with @ConfigurationProperties or @RefreshScope are reloaded. This reload level leverages the refresh feature of Spring Cloud Context.

  • restart_context: the whole Spring ApplicationContext is gracefully restarted. Beans are recreated with the new configuration. In order for the restart context functionality to work properly you must enable and expose the restart actuator endpoint

management:
  endpoint:
    restart:
      enabled: true
  endpoints:
    web:
      exposure:
        include: restart
  • shutdown: the Spring ApplicationContext is shut down to activate a restart of the container. When you use this level, make sure that the lifecycle of all non-daemon threads is bound to the ApplicationContext and that a replication controller or replica set is configured to restart the pod.

假设使用默认设置(“刷新”模式)启用了重新加载功能,则会在 config map 更改时刷新以下 bean:

Assuming that the reload feature is enabled with default settings (refresh mode), the following bean is refreshed when the config map changes:

@Configuration
@ConfigurationProperties(prefix = "bean")
public class MyConfig {

    private String message = "a message that can be changed live";

    // getter and setters

}

要查看更改是否有效地生效,您可以创建另一个 bean 以按周期打印消息,如下所示:

To see that changes effectively happen, you can create another bean that prints the message periodically, as follows

@Component
public class MyBean {

    @Autowired
    private MyConfig config;

    @Scheduled(fixedDelay = 5000)
    public void hello() {
        System.out.println("The message is: " + config.getMessage());
    }
}

您可以使用 “ConfigMap” 更改应用程序打印的消息,如下所示:

You can change the message printed by the application by using a ConfigMap, as follows:

apiVersion: v1
kind: ConfigMap
metadata:
  name: reload-example
data:
  application.properties: |-
    bean.message=Hello World!

对关联 Pod 中 ConfigMap 中名为 bean.message 的属性执行的任何更改都反映在输出中。更笼统地说,检测到了与 Kubernetes prefix 设置的 @ConfigurationProperties 注释中的 prefix 字段值相关的属性前缀关联的更改,并将其反映在应用程序中。本章稍早解释了 Associating a ConfigMap with a pod

Any change to the property named bean.message in the ConfigMap associated with the pod is reflected in the output. More generally speaking, changes associated to properties prefixed with the value defined by the prefix field of the @ConfigurationProperties annotation are detected and reflected in the application. Associating a ConfigMap with a pod is explained earlier in this chapter.

重新加载功能支持两种操作模式:

The reload feature supports two operating modes:

  • Event (default): Watches for changes in config maps or secrets by using the Kubernetes API (web socket). Any event produces a re-check on the configuration and, in case of changes, a reload. The view role on the service account is required in order to listen for config map changes. A higher level role (such as edit) is required for secrets (by default, secrets are not monitored).

  • Polling: Periodically re-creates the configuration from config maps and secrets to see if it has changed. You can configure the polling period by using the spring.cloud.kubernetes.reload.period property and defaults to 15 seconds. It requires the same role as the monitored property source. This means, for example, that using polling on file-mounted secret sources does not require particular privileges.