|
对于最新稳定版本,请使用Spring Cloud Kubernetes 5.0.0! |
使用配置地图 地产来源
Kubernetes 提供了一个名为配置地图将
以键值对或嵌入式形式传递给你的应用程序的参数application.properties或application.yaml文件。
Spring Cloud Kubernetes 配置项目让 Kubernetes 成为配置地图可用的实例
在应用启动时,检测到更改时会触发 Java 的热重载或 Spring context
观察配置地图实例。
以下内容主要参考使用ConfigMaps的示例来解释,但原理相同 秘密,即:所有功能都支持两者。
默认行为是创建Fabric8ConfigMapPropertySource(或KubernetesClientConfigMapPropertySource)基于Kubernetes。配置地图该metadata.name以下两者:
-
值
spring.cloud.kubernetes.config.name -
你的 Spring 应用的值(定义为
spring.application.name财产) -
字符串字面值
“应用”
不过,也可以有更高级的配置,可以同时使用多个配置地图实例。
这spring.cloud.kubernetes.config.sources清单让这成为可能。
例如,你可以定义以下内容配置地图实例:
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会在应用程序运行的命名空间中查找。
请参见命名空间解析,以更好地理解命名空间的运作方式
申请已解决。
任何匹配配置地图得到的 处理方式如下:
-
应用各个配置属性。
-
申请
YAML音乐(或性能) 任何由 值命名的性质的内容spring.application.name(如果不存在,则由application.yaml/properties) -
作为属性文件申请上述名称的内容+每个活跃档案。
举个例子应该会更有意义。假设spring.application.name=my-app并且
我们有一个单一的活跃配置文件,叫做K8.以下配置如下:
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被忽视,因为开发不是活跃的配置文件 -
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
处理完这样的配置图后,你会在属性中得到以下内容:key1=valueD,key2=valueB.
上述流的唯一例外是当配置地图包含一个表示
该文件是 YAML 或属性文件。在这种情况下,密钥的名称不必是application.yaml或application.properties(它可以是任何东西)并且物业的价值被正确处理。
这一特性有助于实现配置地图是通过类似的做法创建的:
kubectl create configmap game-config --from-file=/path/to/app-config.yaml
假设我们有一个名为 的 Spring Boot 应用程序演示该应用使用以下属性读取其线程池
配置。
-
pool.size.core -
泳池。大小。最大值
这可以外部化到配置映射中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有标签的{信件:a}.重要
需要注意的是,与按名称读取配置文件映射不同,这可能导致多个配置文件映射被读取。
和往常一样,秘密也支持同样的功能。
你也可以根据合并的活跃配置文件不同配置 Spring Boot 应用
当配置地图被阅读。您可以通过以下方式为不同档案提供不同的房产价值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中时,发展简介如下:
greeting:
message: Say Hello to the Developers
farewell:
message: Say Goodbye to the Developers
然而,如果生产配置文件激活时,配置变为:
greeting:
message: Say Hello to the Ops
farewell:
message: Say Goodbye
如果两个档案都活跃,最后出现的属性会在配置地图覆盖之前所有的值。
另一种选择是为每个配置文件创建不同的配置映射,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的靴子轮廓应启用,详见 Spring Boot 文档。
在部署到Kubernetes时激活特定配置文件的一个方法是,在容器规范的PodSpec中自定义环境变量启动Spring Boot应用。
部署资源文件,具体如下:
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
将导致财产问候.信息存在向其中一个打个招呼.
可以通过指定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
这种配置会产生两个属性:
-
问候.信息等于向其中一个打个招呼. -
config-map-two.greetings.message等于来自两个人的问候
请注意spring.cloud.kubernetes.config.useNameAsPrefix优先级低于spring.cloud.kubernetes.config.sources.useNameAsPrefix.
这样你可以为所有来源设置“默认”策略,同时只覆盖少数来源。
如果无法使用配置映射名称,你可以指定一个不同的策略,称为:explicitPrefix.由于这是一个显式前缀
你选择,只能提供给来源水平。同时,它比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
将生成三个属性:
-
问候.信息等于向其中一个打个招呼. -
二。问候。信息等于来自两个人的问候. -
config-map-three.greetings.message等于三点打个招呼.
就像你配置配置文件地图的前缀一样,你也可以对秘密配置;这两者都是基于名字的秘密 以及基于标签的。例如:
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)
将是这些标签中发现的秘密名称。
还有一点要记住,我们支持前缀秘密。最简单的解释方式是举个例子:
spring:
application:
name: prefix-based-secrets
cloud:
kubernetes:
secrets:
enableApi: true
useNameAsPrefix: true
namespace: spring-k8s
sources:
- labels:
color: blue
useNameAsPrefix: true
假设匹配此类标签的查询会返回两个秘密:秘密A和秘密B.
这两个秘密的属性名称相同:颜色=海蓝色和颜色=海洋蓝.因为useNamesAsPrefix=true,将加载两个属性源:
-
secretA.color=海蓝色 -
secretB.color=海洋蓝
默认情况下,除了读取配置文件映射外,这些配置映射在来源配置,Spring也会尝试读取
所有房源均来自“Profile Aware”来源。最简单的解释方式是用一个例子。假设你的申请
启用了一个叫“dev”的配置文件,配置就像下面这样:
spring:
application:
name: spring-k8s
cloud:
kubernetes:
config:
namespace: default-namespace
sources:
- name: config-map-one
除了阅读config-map-oneSpring也会尝试阅读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 服务账户、角色和角色绑定。 |
另一种使用配置地图实例是通过运行 Spring Cloud Kubernetes 应用程序将它们挂载到 Pod 中
并让 Spring Cloud Kubernetes 从文件系统读取这些文件。
该功能已被弃用,未来版本将被移除(使用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自动换弹
功能性无法正常工作。你需要做一个发布向/执行器/刷新端点或
重启/重新部署应用程序。 |
在某些情况下,你的应用可能无法加载部分内容配置地图使用Kubernetes API。
如果你希望你的应用在这种情况下启动失败,可以设置Spring.cloud.Kubernetes.config.fail-fast=true使应用程序启动失败并设置异常。
你也可以让应用重试加载配置地图关于失败的财产来源。首先,你需要
设置Spring.cloud.Kubernetes.config.fail-fast=true.然后你需要添加春季重试和Spring Boot启动 AOP去你的班级路径。你可以配置重试属性,比如
最大尝试次数、退避选项如初始间隔、乘数、通过设置的最大间隔Spring.cloud.kubernetes.config.retry.*性能。
如果你已经有过春季重试和Spring Boot启动 AOP不知为何在 classpath 上
并且希望启用 fail-fast,但不希望重试被启用;你可以禁用重试配置地图 地产来源按环境分类spring.cloud.kubernetes.config.retry.enabled=false. |
| 名称 | 类型 | 默认值 | 描述 |
|---|---|---|---|
|
|
|
启用配置地图 |
|
|
|
集合 的名称为 |
|
|
客户端命名空间 |
设置 Kubernetes 命名空间的查找位置 |
|
|
|
设置路径,其中 |
|
|
|
启用或禁用消费 |
|
|
|
在加载 a 时发生错误时,启用或禁用应用程序启动失败 |
|
|
|
启用或禁用配置重试。 |
|
|
|
初始重试间隔以毫秒计。 |
|
|
|
最多尝试次数。 |
|
|
|
最大后退间隔。 |
|
|
|
下一个间隔的乘数。 |