|
请使用 Spring Cloud Kubernetes 5.0.1（最新稳定版本）！ |
使用 ConfigMap PropertySource
Kubernetes 提供了一个名为 ConfigMap 的资源，用于将参数外部化以传递给您的应用程序，形式为键值对或嵌入的 application.properties 或 application.yaml 文件。Spring Cloud Kubernetes Config 项目在应用启动期间使 Kubernetes ConfigMap 实例可用，并在检测到所观察的 ConfigMap 实例发生变更时触发 Bean 或 Spring 上下文的热重载。
以下所有内容主要通过 ConfigMaps 的示例进行说明，但同样适用于 Secrets，即：所有功能均同时支持两者。
默认行为是根据 Kubernetes ConfigMap 创建一个 Fabric8ConfigMapPropertySource（或一个 KubernetesClientConfigMapPropertySource），该 Kubernetes ConfigMap 具有以下任一类型的 metadata.name：
-
值为
spring.cloud.kubernetes.config.name -
您的 Spring 应用程序的值（由
spring.application.name属性定义） -
字符串字面量
"application"
然而，更高级的配置也是可能的，您可以在其中使用多个 ConfigMap 实例。spring.cloud.kubernetes.config.sources 列表使这种可能性成为现实。例如，您可以定义以下 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，则名为c1的ConfigMap将在应用程序运行的命名空间中查找。有关应用程序命名空间如何解析的更多信息，请参阅命名空间解析。
任何找到的匹配项 ConfigMap 都按如下方式处理：
-
应用单独的配置属性。
-
以
yaml（或properties）的值作为任何属性的内容，该属性的名称由spring.application.name的值指定（若其不存在，则由application.yaml/properties指定） -
将上述名称的属性文件内容应用于每个活动的配置文件。
一个示例应该会清晰很多。假设 spring.application.name=my-app，并且我们有一个名为 k8s 的活动配置文件。对于如下配置：
kind: ConfigMap
apiVersion: v1
metadata:
name: my-app
data:
my-app.yaml: |-
...
my-app-k8s.yaml: |-
..
my-app-dev.yaml: |-
..
not-my-app.yaml: |-
..
someProp: someValue这是我们最终将加载的内容：
-
my-app.yaml被视为一个文件 -
my-app-k8s.yaml被视为一个文件 -
my-app-dev.yaml被忽略，因为dev不是活动的配置文件 -
not-my-app.yaml忽略，因为它不匹配spring.application.name -
someProp: someValue普通属性
属性加载的顺序如下：
-
首次加载所有来自
my-app.yaml的属性 -
然后所有来自基于配置文件的源：
my-app-k8s.yaml -
然后所有普通属性
someProp: someValue
这意味着基于配置文件的源优先于非配置文件的源（就像在标准 Spring 应用中一样）；而普通属性则优先于基于配置文件和非配置文件的源。以下是示例：
kind: ConfigMap
apiVersion: v1
metadata:
name: my-app
data:
my-app-k8s.yaml: |-
key1=valueA
key2=valueB
my-app.yaml: |-
key1=valueC
key2=valueA
key1: valueD处理完这样的 ConfigMap 后，您将在属性中得到：key1=valueD、key2=valueB。
上述流程的唯一例外情况是，当 ConfigMap 包含一个单一键，且该键指示文件为 YAML 或属性文件时。在此情况下，该键的名称不一定要是 application.yaml 或 application.properties（可以是任意值），且该属性的值将被正确处理。此特性便于以下用例：ConfigMap 是通过类似如下方式创建的：
kubectl create configmap game-config --from-file=/path/to/app-config.yaml假设我们有一个名为 demo 的 Spring Boot 应用程序，它使用以下属性来读取其线程池配置。
-
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:
application:
name: labeled-configmap-with-prefix
cloud:
kubernetes:
config:
enableApi: true
useNameAsPrefix: true
namespace: spring-k8s
sources:
- labels:
letter: a这将搜索命名空间 spring-k8s 中所有具有标签 {letter : a} 的配置映射（configmap）。需要注意的是，与按名称读取配置映射不同，此操作可能导致读取 多个 配置映射。像往常一样，该功能同样适用于密钥（secrets）。
您还可以根据激活的配置文件以不同方式配置 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 配置文件加载到您的 Spring 应用程序中的配置如下：
greeting:
message: Say Hello to the Developers
farewell:
message: Say Goodbye to the Developers然而，如果 production 配置文件处于激活状态，则配置变为：
greeting:
message: Say Hello to the Ops
farewell:
message: Say Goodbye如果两个配置文件均处于激活状态，则在 ConfigMap 中最后出现的属性将覆盖任何先前的值。
另一种选择是为每个配置文件创建不同的配置映射（config map），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要告诉SpringBoot哪个profile应该被激活，请查看SpringBoot文档。
在Kubernetes上部署时，一种激活特定配置文件的选项是使用环境变量启动您的SpringBoot应用，您可以在容器规范中的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.messageequal toSay 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。
同样的方式，你可以为 secrets 配置前缀，无论是基于名称的 secrets 还是基于标签的 secrets。例如：
spring:
application:
name: prefix-based-secrets
cloud:
kubernetes:
secrets:
enableApi: true
useNameAsPrefix: true
namespace: spring-k8s
sources:
- labels:
letter: a
useNameAsPrefix: false
- labels:
letter: b
explicitPrefix: two
- labels:
letter: c
- labels:
letter: d
useNameAsPrefix: true
- name: my-secret生成属性源的处理规则与config maps相同。唯一不同的是，通过标签查找密钥时可能会找到多个源。在这种情况下，如果通过useNameAsPrefix指定了前缀，则该前缀将作为为这些特定标签找到的密钥的名称。
One more thing to bear in mind is that we support prefix per secret. The easiest way to explain this is via an example:
spring:
application:
name: prefix-based-secrets
cloud:
kubernetes:
secrets:
enableApi: true
useNameAsPrefix: true
namespace: spring-k8s
sources:
- labels:
color: blue
useNameAsPrefix: true假设查询匹配这样的标签将返回两个秘密作为结果： secretA 和 secretB。这两个秘密具有相同的属性名称： color=sea-blue 和 color=ocean-blue。因为 useNamesAsPrefix=true，将加载两个属性源：
-
secretA.color=sea-blue -
secretB.color=ocean-blue
默认情况下，除了读取在sources配置中指定的配置映射外，Spring 还会尝试从“基于 profile 的”源读取所有属性。最简单的方式来解释这一点是通过一个示例。假设您的应用程序启用了名为 "dev" 的 profile，且您有一个如下所示的配置：
spring:
application:
name: spring-k8s
cloud:
kubernetes:
config:
namespace: default-namespace
sources:
- name: config-map-one除了阅读代码config-map-one，Spring还会尝试读取代码1>；在这种特定的顺序中。每个活动配置文件都会生成这样一个与配置文件相关的映射。
即使你的应用程序不受此 config 映射的影响，如果需要也可以将其禁用：
spring:
application:
name: spring-k8s
cloud:
kubernetes:
config:
includeProfileSpecificSources: false
namespace: default-namespace
sources:
- name: config-map-one
includeProfileSpecificSources: false注意，就像之前一样，在两个级别都可以指定此属性：对于所有配置映射或 单独的映射；后者优先级更高。
| 您应该检查安全配置部分。要从 pod 内部访问 config 映射，您需要具有正确的 Kubernetes 服务帐户、角色和角色绑定。 |
另一种使用ConfigMap个实例的方法是运行Spring Cloud Kubernetes应用程序，让Spring Cloud Kubernetes从文件系统中读取它们，通过挂载它们到Pod中。
该功能已过时，将在以后的版本中删除（改用spring.config.import）。 此行为由spring.cloud.kubernetes.config.paths属性控制。您可以将其与先前描述的机制一起或替代使用。 spring.cloud.kubernetes.config.paths需要每个属性文件的完整路径列表，因为不进行递归解析。例如： |
spring:
cloud:
kubernetes:
config:
paths:
- /tmp/application.properties
- /var/application.yaml如果使用 spring.cloud.kubernetes.config.paths 或 spring.cloud.kubernetes.secrets.path，自动重新加载功能将无法工作。您需要向 /actuator/refresh 端点发送 POST 请求，或者重启/重新部署应用程序。 |
在某些情况下，您的应用程序可能会无法加载Kubernetes API的一些ConfigMaps。如果希望您的应用程序在这些情况下失败启动过程，则可以设置spring.cloud.kubernetes.config.fail-fast=true，使应用程序启动失败，抛出异常。
你可以通过设置 spring.cloud.kubernetes.config.fail-fast=true 属性来使应用程序在出现故障时重试加载 ConfigMap 个属性源。首先，您需要
设置 spring.cloud.kubernetes.config.fail-fast=true。然后，您需要将 spring-retry
和 spring-boot-starter-aop 添加到您的类路径中。您可以设置
spring.cloud.kubernetes.config.retry.* 属性来配置重试属性，例如
最大尝试次数、退避选项（如初始间隔、乘数、最大间隔）。
如果因为某些原因已经在类路径上拥有spring-retry和spring-boot-starter-aop，但想要启用快速失败，却不希望启用重试；可以对ConfigMapPropertySources进行禁用重试，通过设置spring.cloud.kubernetes.config.retry.enabled=false。 |
| 姓名 | 类型 | 默认 | 描述 |
|---|---|---|---|
|
|
|
启用配置映射 0 |
|
|
|
设置要查找的 |
|
|
Client 命名空间 |
设置要在其中查找的 Kubernetes 命名空间 |
|
|
|
设置为零个实例挂载的路径 |
|
|
|
启用或禁用通过API消费 |
|
|
|
设置在配置类上，以编程方式控制是否在从注册表加载时使应用程序启动失败。如果未设置，则默认值为抛出异常，除非有其他特殊规则。 |
|
|
|
启用或禁用配置重试。 |
|
|
|
初始重试间隔（毫秒数）。 |
|
|
|
当前最大尝试次数。 |
|
|
|
最大回退间隔。 |
|
|
|
乘数用于下一个间隔。 |