Kubernetes 提供了一个名为 ConfigMap
的资源来外部化
以键值对或嵌入或文件的形式传递给应用程序的参数。
Spring Cloud Kubernetes Config 项目使 Kubernetes 实例可用
在应用程序启动期间,并在检测到
观察到的实例。application.properties
application.yaml
ConfigMap
ConfigMap
下面的所有内容主要参考使用 ConfigMap 的示例进行解释,但同样代表 机密,即:两者都支持每个功能。
默认行为是基于 Kubernetes 创建(或 )具有以下任一功能之一:Fabric8ConfigMapPropertySource
KubernetesClientConfigMapPropertySource
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
ConfigMap
c1
找到的任何匹配项都将按如下方式处理: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
Plain 属性
加载属性的顺序如下:
-
首先从中加载所有属性
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
上述流的唯一例外是当包含指示的单个键时
该文件是 YAML 或属性文件。在这种情况下,键的名称不必是 或(它可以是任何内容),并且属性的值会正确处理。
此功能有助于使用如下内容创建的用例:ConfigMap
application.yaml
application.properties
ConfigMap
kubectl create configmap game-config --from-file=/path/to/app-config.yaml
假设我们有一个名为 Spring Boot 的应用程序,该应用程序使用以下属性来读取其线程池
配置。demo
-
pool.size.core
-
pool.size.maximum
这可以外化为配置映射,格式如下:yaml
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
pool.size.core: 1
pool.size.max: 16
在大多数情况下,单个属性工作正常。但是,有时嵌入式更方便。在这种情况下,我们
使用名为 to embing our 的单个属性,如下所示: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
这将搜索命名空间中具有标签的每个配置映射。重要的
这里需要注意的是,与按名称读取 ConfigMap 不同,这可能会导致读取多个 Config Map。
像往常一样,机密支持相同的功能。spring-k8s
{letter : a}
您还可以根据合并在一起的活动配置文件以不同的方式配置 Spring Boot 应用程序
当读取时。您可以使用 or 属性为不同的配置文件提供不同的属性值,指定特定于配置文件的值,每个值都在其自己的文档中
(由序列表示),如下所示: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
在上述情况下,使用配置文件加载到 Spring Application 中的配置如下所示:development
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
另一种选择是为每个配置文件创建一个不同的配置映射,Spring Boot 将根据 在活动配置文件上
kind: ConfigMap
apiVersion: v1
metadata:
name: demo
data:
application.yml: |-
greeting:
message: Say Hello to the World
farewell:
message: Say Goodbye
kind: 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 Developers
kind: 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 应该启用哪个,请参阅 Spring Boot 文档。
在部署到 Kubernetes 时激活特定配置文件的一个选项是使用环境变量启动 Spring Boot 应用程序,您可以在容器规范的 PodSpec 中定义该变量。
部署资源文件,如下所示:profile
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
与为 configmap 配置前缀的方式相同,您也可以为 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
在生成属性源时,与配置映射相同的处理规则适用。唯一的区别是
潜在地,通过标签查找秘密可能意味着我们找到了多个来源。在这种情况下,前缀(如果通过 )
将是为这些特定标签找到的所有机密的名称。useNameAsPrefix
要记住的另一件事是,我们支持每个来源,而不是每个秘密。解释这一点的最简单方法是通过一个例子:prefix
spring:
application:
name: prefix-based-secrets
cloud:
kubernetes:
secrets:
enableApi: true
useNameAsPrefix: true
namespace: spring-k8s
sources:
- labels:
color: blue
useNameAsPrefix: true
假设匹配此类标签的查询将提供两个密钥,因此:和 。
这两个密钥具有相同的属性名称:和 。它是未定义的,最终将作为属性源的一部分,但它的前缀将是(自然排序的串联,机密的名称)。secret-a
secret-b
color=sea-blue
color=ocean-blue
color
secret-a.secret-b
如果您需要更细粒度的结果,可以选择添加更多标签以唯一标识密钥。
默认情况下,除了读取配置中指定的配置图外,Spring 还会尝试读取
来自“配置文件感知”来源的所有属性。解释这一点的最简单方法是通过一个例子。假设您的应用程序
启用名为“dev”的配置文件,并且您具有如下所示的配置:sources
spring:
application:
name: spring-k8s
cloud:
kubernetes:
config:
namespace: default-namespace
sources:
- name: config-map-one
除了阅读,Spring也会尝试阅读;按此特定顺序。每个活动配置文件
生成这样的配置文件感知配置映射。config-map-one
config-map-one-dev
尽管应用程序不应受到此类配置映射的影响,但如果需要,可以禁用它:
spring:
application:
name: spring-k8s
cloud:
kubernetes:
config:
includeProfileSpecificSources: false
namespace: default-namespace
sources:
- name: config-map-one
includeProfileSpecificSources: false
请注意,就像以前一样,您可以在两个级别指定此属性:对于所有配置映射或 对于个人的;后者具有更高的优先级。
您应该检查安全配置部分。要从 pod 内部访问配置映射,您需要拥有正确的 Kubernetes 服务帐户、角色和角色绑定。 |
您应该检查安全配置部分。要从 pod 内部访问配置映射,您需要拥有正确的 Kubernetes 服务帐户、角色和角色绑定。 |
使用实例的另一种选择是通过运行 Spring Cloud Kubernetes 应用程序将它们挂载到 Pod 中
并让 Spring Cloud Kubernetes 从文件系统中读取它们。ConfigMap
此功能已弃用,并将在将来的版本中删除(改用)。
此行为由属性控制。您可以在
添加或代替前面描述的机制。 需要每个属性文件的完整路径列表,因为目录不会被递归解析。例如:spring.config.import spring.cloud.kubernetes.config.paths spring.cloud.kubernetes.config.paths |
此功能已弃用,并将在将来的版本中删除(改用)。
此行为由属性控制。您可以在
添加或代替前面描述的机制。 需要每个属性文件的完整路径列表,因为目录不会被递归解析。例如: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 POST /actuator/refresh |
如果您使用或自动重新加载
功能将不起作用。您需要向终端节点发出请求,或者
重新启动/重新部署应用程序。spring.cloud.kubernetes.config.paths spring.cloud.kubernetes.secrets.path POST /actuator/refresh |
在某些情况下,您的应用程序可能无法使用 Kubernetes API 加载您的某些内容。
如果希望应用程序在这种情况下启动过程失败,可以设置为使应用程序启动失败并出现异常。ConfigMaps
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 ConfigMap PropertySources spring.cloud.kubernetes.config.retry.enabled=false |
如果您由于某种原因已经拥有 和 在类路径上
并希望启用快速失败,但不希望启用重试;您可以通过设置 来禁用重试。spring-retry spring-boot-starter-aop ConfigMap PropertySources spring.cloud.kubernetes.config.retry.enabled=false |
名字 | 类型 | 违约 | 描述 |
---|---|---|---|
|
|
|
启用 ConfigMap |
|
|
|
设置要查找的名称 |
|
|
客户端命名空间 |
设置要查找的 Kubernetes 命名空间 |
|
|
|
设置挂载实例的路径 |
|
|
|
通过 API 启用或禁用消费实例 |
|
|
|
启用或禁用在加载 |
|
|
|
启用或禁用配置重试。 |
|
|
|
初始重试间隔(以毫秒为单位)。 |
|
|
|
最大尝试次数。 |
|
|
|
退避的最大间隔。 |
|
|
|
下一个间隔的乘数。 |