| 此功能已在 2020.0 版本中弃用。请看 替代方式的 null 控制器 以实现相同的功能。 |
| 此功能已在 2020.0 版本中弃用。请看 替代方式的 null 控制器 以实现相同的功能。 |
某些应用程序可能需要检测外部属性源上的更改并更新其内部状态以反映新配置。
Spring Cloud Kubernetes 的重新加载功能能够在相关或更改时触发应用程序重新加载。ConfigMapSecret
默认情况下，此功能处于禁用状态。可以使用配置属性（例如，在文件中）启用它。
请注意，这将仅启用对配置映射的监控（即：将设置为 ）。
如果要启用对机密的监视，则必须通过以下方式显式完成此操作。spring.cloud.kubernetes.reload.enabled=trueapplication.propertiesspring.cloud.kubernetes.reload.monitoring-config-mapstruespring.cloud.kubernetes.reload.monitoring-secrets=true
支持以下级别的重新加载（通过设置属性）：spring.cloud.kubernetes.reload.strategy
-
refresh（缺省）：仅装入注解或重新装入的配置 Bean。 此重新加载级别利用了 Spring Cloud Context 的刷新功能。@ConfigurationProperties@RefreshScope -
restart_context：整个Spring优雅地重启。Bean 将使用新配置重新创建。 为了使重启上下文功能正常工作，必须启用并公开重启执行器端点ApplicationContext
management:
endpoint:
restart:
enabled: true
endpoints:
web:
exposure:
include: restart
-
shutdown：关闭 Spring 以激活容器的重新启动。 使用此级别时，请确保所有非守护进程线程的生命周期都绑定到 容器，并且复制控制器或副本集配置为重新启动容器。ApplicationContextApplicationContext
假设使用默认设置（ 模式）启用了重新加载功能，则当配置映射更改时，将刷新以下 Bean：refresh
@Configuration
@ConfigurationProperties(prefix = "bean")
public class MyConfig {
private String message = "a message that can be changed live";
// getter and setters
}
要查看更改是否有效发生，您可以创建另一个定期打印消息的 Bean，如下所示
@Component
public class MyBean {
@Autowired
private MyConfig config;
@Scheduled(fixedDelay = 5000)
public void hello() {
System.out.println("The message is: " + config.getMessage());
}
}您可以使用 更改应用程序打印的消息，如下所示：ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: reload-example
data:
application.properties: |-
bean.message=Hello World!对与容器关联的 中命名的属性的任何更改都反映在
输出。更一般地说，与以注释字段定义的值为前缀的属性关联的更改将被检测并反映在应用程序中。本章前面介绍了如何将 ConfigMap 与 Pod 关联。bean.messageConfigMapprefix@ConfigurationProperties
重新加载功能支持两种操作模式：
-
事件（默认）：使用 Kubernetes API（Web 套接字）监视配置映射或密钥中的更改。 任何事件都会生成对配置的重新检查，并在发生更改时重新加载。 服务帐户上的角色是必需的，以便侦听配置映射更改。机密需要更高级别的角色（如 ） （默认情况下，不监视机密）。
viewedit -
轮询：定期从配置映射和密钥重新创建配置，以查看它是否已更改。 可以使用该属性配置轮询周期，默认为 15 秒。 它需要与受监视的属性源相同的角色。 这意味着，例如，在文件挂载的机密源上使用轮询不需要特定权限。
spring.cloud.kubernetes.reload.period