5. Kubernetes PropertySource 实现
配置 Spring Boot 应用程序的最常见方法是创建一个application.properties或application.yaml或 一application-profile.properties或application-profile.yaml包含键值对的文件，这些键值对为您的应用程序或 Spring Boot Starters提供自定义值。您可以通过指定系统属性或环境来覆盖这些属性 变量。
5.1. 使用ConfigMap PropertySource
Kubernetes 提供了一个名为ConfigMap将参数以键值对的形式传递给您的应用程序，或嵌入application.properties或application.yaml文件。 Spring Cloud Kubernetes Config 项目使 KubernetesConfigMap可用的实例在应用程序引导期间，并在检测到更改时触发 bean 或 Spring 上下文的热重载 观察ConfigMap实例。
默认行为是创建Fabric8ConfigMapPropertySource基于 KubernetesConfigMap有一个metadata.name值您的 Spring 应用程序（由其spring.application.name属性）或在bootstrap.propertiesfile 在以下键下：spring.cloud.kubernetes.config.name.
但是，可以在可以使用多个ConfigMap实例。 这spring.cloud.kubernetes.config.sourceslist 使这成为可能。例如，您可以定义以下内容ConfigMap实例：
spring:
application:
name: cloud-k8s-app
cloud:
kubernetes:
config:
name: default-name
namespace: default-namespace
sources:
# Spring Cloud Kubernetes looks up a ConfigMap named c1 in namespace default-namespace
- name: c1
# Spring Cloud Kubernetes looks up a ConfigMap named default-name in whatever namespace n2
- namespace: n2
# Spring Cloud Kubernetes looks up a ConfigMap named c3 in namespace n3
- namespace: n3
name: c3在前面的示例中，如果spring.cloud.kubernetes.config.namespace没有设定， 这ConfigMap叫c1将在应用程序运行的命名空间中查找。请参阅命名空间解析以更好地了解命名空间的应用程序是如何解析的。
任何匹配ConfigMap找到的处理方式如下：
-
应用单个配置属性。
-
申请为
yaml名为application.yaml. -
将名为
application.properties.
上述流的唯一例外是当ConfigMap包含一个键，指示该文件是 YAML 或属性文件。在这种情况下，键的名称不必是application.yaml或application.properties（可以是任何东西），并且属性的值会得到正确处理。此功能有助于用例，其中ConfigMap是通过使用如下内容创建的：
kubectl create configmap game-config --from-file=/path/to/app-config.yaml假设我们有一个名为demo使用以下属性读取其线程池 配置。
-
pool.size.core -
pool.size.maximum
这可以外部化为 config map 中的yaml格式如下：
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
pool.size.core: 1
pool.size.max: 16在大多数情况下，单个属性工作正常。但是，有时，嵌入yaml更方便。在这种情况下，我们使用名为application.yaml嵌入我们的yaml如下：
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
application.yaml: |-
pool:
size:
core: 1
max:16以下示例也有效：
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
custom-name.yaml: |-
pool:
size:
core: 1
max:16您还可以根据合并在一起的活动配置文件以不同的方式配置 Spring Boot 应用程序当ConfigMap读取。您可以使用application.properties或application.yaml属性，指定特定于配置文件的值，每个值都在自己的文档中（由序列指示），如下所示：---
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
application.yml: |-
greeting:
message: Say Hello to the World
farewell:
message: Say Goodbye
---
spring:
profiles: development
greeting:
message: Say Hello to the Developers
farewell:
message: Say Goodbye to the Developers
---
spring:
profiles: production
greeting:
message: Say Hello to the Ops在前面的情况下，使用development简介如下：
greeting:
message: Say Hello to the Developers
farewell:
message: Say Goodbye to the Developers但是，如果productionprofile 处于活动状态时，配置变为：
greeting:
message: Say Hello to the Ops
farewell:
message: Say Goodbye如果两个配置文件都处于活动状态，则最后显示的属性在ConfigMap覆盖任何前面的值。
另一种选择是为每个配置文件创建不同的配置映射，spring boot 将根据在活动配置文件上自动获取它
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
application.yml: |-
greeting:
message: Say Hello to the World
farewell:
message: Say Goodbyekind: ConfigMap
apiVersion: v1
metadata:
name: demo-development
data:
application.yml: |-
spring:
profiles: development
greeting:
message: Say Hello to the Developers
farewell:
message: Say Goodbye to the Developerskind: ConfigMap
apiVersion: v1
metadata:
name: demo-production
data:
application.yml: |-
spring:
profiles: production
greeting:
message: Say Hello to the Ops
farewell:
message: Say Goodbye告诉 Spring Boot 哪个profile应该在引导时启用，你可以将SPRING_PROFILES_ACTIVE环境变量。 为此，您可以使用环境变量启动 Spring Boot 应用程序，您可以在容器规范的 PodSpec 中定义该环境变量。部署资源文件，如下所示：
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-name
labels:
app: deployment-name
spec:
replicas: 1
selector:
matchLabels:
app: deployment-name
template:
metadata:
labels:
app: deployment-name
spec:
containers:
- name: container-name
image: your-image
env:
- name: SPRING_PROFILES_ACTIVE
value: "development"您可能会遇到以下情况：有多个配置映射具有相同的属性名称。例如：
kind: ConfigMap
apiVersion: v1
metadata:
name: config-map-one
data:
application.yml: |-
greeting:
message: Say Hello from one和
kind: ConfigMap
apiVersion: v1
metadata:
name: config-map-two
data:
application.yml: |-
greeting:
message: Say Hello from two取决于您放置这些内容的顺序bootstrap.yaml|properties，您最终可能会得到一个意外的结果（最后一个配置映射获胜）。例如：
spring:
application:
name: cloud-k8s-app
cloud:
kubernetes:
config:
namespace: default-namespace
sources:
- name: config-map-two
- name: config-map-one将导致属性greetings.message存在Say Hello from one.
有一种方法可以通过指定useNameAsPrefix.例如：
spring:
application:
name: with-prefix
cloud:
kubernetes:
config:
useNameAsPrefix: true
namespace: default-namespace
sources:
- name: config-map-one
useNameAsPrefix: false
- name: config-map-two这样的配置将导致生成两个属性：
-
greetings.message等于Say Hello from one. -
config-map-two.greetings.message等于Say Hello from two
请注意spring.cloud.kubernetes.config.useNameAsPrefix优先级低于spring.cloud.kubernetes.config.sources.useNameAsPrefix.
这允许您为所有源设置“默认”策略，同时只允许覆盖少数源。
如果无法使用配置映射名称，则可以指定不同的策略，称为：explicitPrefix.由于这是一个显式前缀，因此
选择，则只能提供给sources水平。同时，它的优先级高于useNameASPrefix.假设我们有第三个配置映射，其中包含这些条目：
kind: ConfigMap
apiVersion: v1
metadata:
name: config-map-three
data:
application.yml: |-
greeting:
message: Say Hello from three如下所示的配置：
spring:
application:
name: with-prefix
cloud:
kubernetes:
config:
useNameAsPrefix: true
namespace: default-namespace
sources:
- name: config-map-one
useNameAsPrefix: false
- name: config-map-two
explicitPrefix: two
- name: config-map-three将导致生成三个属性：
-
greetings.message等于Say Hello from one. -
two.greetings.message等于Say Hello from two. -
config-map-three.greetings.message等于Say Hello from three.
| 您应该检查安全配置部分。要从 Pod 内部访问配置映射，您需要拥有正确的 Kubernetes 服务帐户、角色和角色绑定。 |
使用另一种选择ConfigMap实例是通过运行 Spring Cloud Kubernetes 应用程序将它们挂载到 Pod 中
并让 Spring Cloud Kubernetes 从文件系统中读取它们。
此行为由spring.cloud.kubernetes.config.paths财产。您可以在以下领域使用它
添加到或代替前面描述的机制。
您可以在spring.cloud.kubernetes.config.paths通过使用,定界符。
| 您必须提供每个属性文件的完整确切路径，因为目录不会被递归解析。 |
如果您使用spring.cloud.kubernetes.config.paths或spring.cloud.kubernetes.secrets.path自动重新加载
功能将不起作用。您需要制作一个POST请求/actuator/refreshendpoint 或
重新启动/重新部署应用程序。 |
| 名称 | 类型 | 默认值 | 描述 |
|---|---|---|---|
|
|
|
启用 ConfigMap |
|
|
|
设置 |
|
|
客户端命名空间 |
设置要查找的 Kubernetes 命名空间 |
|
|
|
设置路径，其中 |
|
|
|
启用或禁用消费 |
5.2. 机密属性源
Kubernetes 具有用于存储敏感数据（例如密码、OAuth Tokens等）的密钥概念。该项目提供与Secrets制作秘密可由 Spring Boot 应用程序访问。您可以通过设置spring.cloud.kubernetes.secrets.enabled财产。
启用后，Fabric8SecretsPropertySource查找 Kubernetes 以查找Secrets来自以下来源：
-
从机密挂载中递归读取
-
以应用程序命名（定义为
spring.application.name) -
匹配一些标签
注意：
默认情况下，出于安全原因，未启用通过 API 使用机密（上述第 2 点和第 3 点）。机密的权限“列表”允许客户端检查指定命名空间中的机密值。 此外，我们建议容器通过挂载的卷共享机密。
如果您通过 API 启用使用密钥，我们建议您使用授权策略（例如 RBAC）来限制对密钥的访问。 有关通过 API 使用 Secret 时的风险和最佳实践的更多信息，请参阅此文档。
如果找到机密，则其数据将提供给应用程序。
假设我们有一个名为demo使用属性读取其数据库
配置。我们可以使用以下命令创建 Kubernetes 密钥：
kubectl create secret generic db-secret --from-literal=username=user --from-literal=password=p455w0rd前面的命令将创建以下密钥（您可以通过使用kubectl get secrets db-secret -o yaml):
apiVersion: v1
data:
password: cDQ1NXcwcmQ=
username: dXNlcg==
kind: Secret
metadata:
creationTimestamp: 2017-07-04T09:15:57Z
name: db-secret
namespace: default
resourceVersion: "357496"
selfLink: /api/v1/namespaces/default/secrets/db-secret
uid: 63c89263-6099-11e7-b3da-76d6186905a8
type: Opaque请注意，数据包含由create命令。
然后，您的应用程序可以使用此密钥，例如，通过将密钥的值导出为环境变量：
apiVersion: v1
kind: Deployment
metadata:
name: ${project.artifactId}
spec:
template:
spec:
containers:
- env:
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: db-secret
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: password您可以通过多种方式选择要使用的密钥：
-
通过列出映射密钥的目录：
-Dspring.cloud.kubernetes.secrets.paths=/etc/secrets/db-secret,etc/secrets/postgresql如果将所有密钥映射到公共根，则可以按如下方式设置它们：
-Dspring.cloud.kubernetes.secrets.paths=/etc/secrets -
通过设置命名密钥：
-Dspring.cloud.kubernetes.secrets.name=db-secret -
通过定义标签列表：
-Dspring.cloud.kubernetes.secrets.labels.broker=activemq -Dspring.cloud.kubernetes.secrets.labels.db=postgresql
就像ConfigMap，也可以进行更高级的配置，其中您可以使用多个Secret实例。这spring.cloud.kubernetes.secrets.sourceslist 使这成为可能。例如，您可以定义以下内容Secret实例：
spring:
application:
name: cloud-k8s-app
cloud:
kubernetes:
secrets:
name: default-name
namespace: default-namespace
sources:
# Spring Cloud Kubernetes looks up a Secret named s1 in namespace default-namespace
- name: s1
# Spring Cloud Kubernetes looks up a Secret named default-name in namespace n2
- namespace: n2
# Spring Cloud Kubernetes looks up a Secret named s3 in namespace n3
- namespace: n3
name: s3在前面的示例中，如果spring.cloud.kubernetes.secrets.namespace没有设定， 这Secret叫s1将在应用程序运行的命名空间中查找。
请参阅 namespace-resolution 以更好地了解命名空间如何
的申请已解决。
| 名称 | 类型 | 默认值 | 描述 |
|---|---|---|---|
|
|
|
启用机密 |
|
|
|
设置要查找的密钥的名称 |
|
|
客户端命名空间 |
设置要查找的 Kubernetes 命名空间 |
|
|
|
设置用于查找机密的标签 |
|
|
|
设置装载机密的路径（示例 1） |
|
|
|
启用或禁用通过 API 使用机密（示例 2 和 3） |
笔记：
-
这
spring.cloud.kubernetes.secrets.labels属性的行为由基于 Map 的绑定定义。 -
这
spring.cloud.kubernetes.secrets.paths属性的行为由基于集合的绑定定义。 -
出于安全原因，通过 API 访问机密可能会受到限制。首选方法是将密钥挂载到 Pod 上。
您可以找到使用密钥的应用程序示例（尽管它尚未更新为使用新的spring-cloud-kubernetes项目）在 spring-boot-camel-config
5.3. 命名空间解析
查找应用程序命名空间是在尽力而为的基础上进行的。我们按顺序迭代一些步骤 找到它。最简单和最常见的一种是在正确的配置中指定它，例如：
spring:
application:
name: app
cloud:
kubernetes:
secrets:
name: secret
namespace: default
sources:
# Spring Cloud Kubernetes looks up a Secret named 'a' in namespace 'default'
- name: a
# Spring Cloud Kubernetes looks up a Secret named 'secret' in namespace 'b'
- namespace: b
# Spring Cloud Kubernetes looks up a Secret named 'd' in namespace 'c'
- namespace: c
name: d请记住，配置映射也可以执行相同的作。如果未指定这样的命名空间，则将读取它（按以下顺序）：
-
从财产
spring.cloud.kubernetes.client.namespace -
来自驻留在文件中的字符串，以
spring.cloud.kubernetes.client.serviceAccountNamespacePath属性 -
来自驻留在
/var/run/secrets/kubernetes.io/serviceaccount/namespace文件 （Kubernetes 默认命名空间路径） -
从指定的客户端方法调用（例如 fabric8 的 ：
KubernetesClient::getNamespace），如果客户端提供 这样的方法。
如果无法从上述步骤中找到命名空间，将导致引发异常。
5.4.PropertySource重新加载
| 此功能已在 2020.0 版本中弃用。请看 Spring Cloud Kubernetes Configuration Watcher 控制器的替代方法 以实现相同的功能。 |
某些应用程序可能需要检测外部属性源的更改并更新其内部状态以反映新配置。Spring Cloud Kubernetes 的重新加载功能能够在相关ConfigMap或Secret变化。
默认情况下，此功能处于禁用状态。您可以使用spring.cloud.kubernetes.reload.enabled=trueconfiguration 属性（例如，在application.properties文件）。
支持以下级别的重新加载（通过将spring.cloud.kubernetes.reload.strategy属性）：
-
refresh（默认）：仅配置 bean 用@ConfigurationProperties或@RefreshScope被重新加载。此重新加载级别利用了 Spring Cloud Context 的刷新功能。 -
restart_context：整个SpringApplicationContext正常重新启动。使用新配置重新创建 Bean。为了使重新启动上下文功能正常工作，您必须启用并公开重新启动执行器端点
management:
endpoint:
restart:
enabled: true
endpoints:
web:
exposure:
include: restart
-
shutdown：SpringApplicationContext关闭以激活容器的重启。使用此级别时，请确保所有非守护进程线程的生命周期都绑定到ApplicationContext并且复制控制器或副本集配置为重新启动容器。
假设使用默认设置 （refreshmode），当配置映射更改时，以下 bean 将刷新：
@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!对名为bean.message在ConfigMap与 Pod 关联的 输出。 更一般地说，与属性相关的更改以prefix字段的@ConfigurationProperties注释被检测并反映在应用程序中。关联一个ConfigMap带吊舱在本章前面对此进行了解释。
重新加载功能支持两种作模式：
* 事件（默认）：使用 Kubernetes API（Web 套接字）监视配置映射或密钥的更改。
任何事件都会对配置进行重新检查，如果发生更改，则会重新加载。
这view需要角色才能监听配置映射更改。更高级别的角色（例如edit） 是机密所必需的
（默认情况下，不监控机密）。
* 轮询：定期从配置映射和密钥重新创建配置，以查看它是否已更改。
您可以使用spring.cloud.kubernetes.reload.period属性，默认为 15 秒。它需要与受监视的属性源相同的角色。这意味着，例如，对文件装载的机密源使用轮询不需要特定权限。
| 名称 | 类型 | 默认值 | 描述 |
|---|---|---|---|
|
|
|
支持监控属性源和重新加载配置 |
|
|
|
允许监控配置映射中的更改 |
|
|
|
允许监视机密中的更改 |
|
|
|
发射装弹时使用的策略 （ |
|
|
|
指定如何侦听属性源 （ |
|
|
|
使用 |
笔记：
* 您不应使用spring.cloud.kubernetes.reload在配置映射或密钥中。在运行时更改此类属性可能会导致意外结果。
* 删除属性或整个配置映射不会恢复 bean 的原始状态，当您使用refresh水平。