开始
3. 入门 - 本地
4. 入门 - Cloud Foundry
本节介绍如何在 Cloud Foundry 上开始使用 Spring Cloud Data Flow。有关在 Cloud Foundry 上安装 Spring Cloud Data Flow 的更多信息,请参阅微型站点的 Cloud Foundry 部分。
5. 入门 - Kubernetes
Spring Cloud Data Flow 是一个用于构建数据集成和实时数据处理管道的工具包。
管道由使用 Spring Cloud Stream 或 Spring Cloud Task 微服务框架构建的 Spring Boot 应用程序组成。 这使得 Spring Cloud Data Flow 适用于一系列数据处理用例,从导入导出到事件流和预测分析。
该项目支持将 Spring Cloud Data Flow 与 Kubernetes 一起使用作为这些管道的运行时,并将应用程序打包为 Docker 镜像。
有关在 Kubernetes 上安装 Spring Cloud Data Flow 的更多信息,请参阅微型站点的 Kubernetes 部分。
5.1. 应用程序和服务器属性
本部分介绍如何自定义应用程序的部署。您可以使用许多属性来影响已部署应用程序的设置。属性可以基于每个应用程序应用,也可以在所有已部署应用程序的相应服务器配置中应用。
基于每个应用程序设置的属性始终优先于设置为服务器配置的属性。通过这种安排,您可以基于每个应用程序覆盖全局服务器级别属性。 |
要应用于所有已部署任务的属性在src/kubernetes/server/server-config-[binder].yaml
文件和 for Streamssrc/kubernetes/skipper/skipper-config-[binder].yaml
.取代[binder]
使用您正在使用的消息传递中间件 — 例如,rabbit
或kafka
.
5.1.1. 内存和 CPU 设置
应用程序使用默认内存和 CPU 设置进行部署。如果需要,可以调整这些值。以下示例演示如何设置Limits
自1000m
为CPU
和1024Mi
用于记忆和Requests
自800m
用于 CPU 和640Mi
对于内存:
deployer.<application>.kubernetes.limits.cpu=1000m
deployer.<application>.kubernetes.limits.memory=1024Mi
deployer.<application>.kubernetes.requests.cpu=800m
deployer.<application>.kubernetes.requests.memory=640Mi
这些值会导致使用以下容器设置:
Limits:
cpu: 1
memory: 1Gi
Requests:
cpu: 800m
memory: 640Mi
您还可以控制将cpu
和memory
全球。
以下示例显示如何设置流的 CPU 和内存:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
limits:
memory: 640mi
cpu: 500m
以下示例展示了如何设置任务的 CPU 和内存:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
limits:
memory: 640mi
cpu: 500m
到目前为止,我们使用的设置仅影响容器的设置。它们不会影响容器中 JVM 进程的内存设置。如果要设置 JVM 内存设置,可以设置一个环境变量来执行此作。有关详细信息,请参阅下一节。
5.1.2. 环境变量
要影响给定应用程序的环境设置,您可以使用spring.cloud.deployer.kubernetes.environmentVariables
deployer 属性。
例如,生产环境中的一个常见要求是影响 JVM 内存参数。
您可以使用JAVA_TOOL_OPTIONS
环境变量,如以下示例所示:
deployer.<application>.kubernetes.environmentVariables=JAVA_TOOL_OPTIONS=-Xmx1024m
这environmentVariables 属性接受逗号分隔的字符串。如果环境变量包含值
这也是一个逗号分隔的字符串,它必须用单引号括起来——例如,spring.cloud.deployer.kubernetes.environmentVariables=spring.cloud.stream.kafka.binder.brokers='somehost:9092,
anotherhost:9093'
|
这将覆盖所需 JVM 内存设置<application>
(将<application>
替换为您的应用程序名称)。
5.1.3. 活体和就绪探针
这liveness
和readiness
探测器使用名为/health
和/info
分别。他们使用delay
之10
对于两者和period
之60
和10
分别。使用部署程序属性部署流时,可以更改这些缺省值。活跃度和就绪性探测仅应用于流。
以下示例将liveness
探针(将<application>
替换为应用程序的名称),通过设置部署程序属性:
deployer.<application>.kubernetes.livenessProbePath=/health
deployer.<application>.kubernetes.livenessProbeDelay=120
deployer.<application>.kubernetes.livenessProbePeriod=20
您可以声明相同的内容作为流的服务器全局配置的一部分,如以下示例所示:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
livenessProbePath: /health
livenessProbeDelay: 120
livenessProbePeriod: 20
同样,您可以交换liveness
为readiness
以覆盖默认值readiness
设置。
默认情况下,端口 8080 用作探头端口。您可以更改两者的默认值liveness
和readiness
使用部署程序属性探测端口,如以下示例所示:
deployer.<application>.kubernetes.readinessProbePort=7000
deployer.<application>.kubernetes.livenessProbePort=7000
您可以声明相同的内容作为流的全局配置的一部分,如以下示例所示:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
readinessProbePort: 7000
livenessProbePort: 7000
默认情况下,
要自动将两者
|
可以使用存储在 Kubernetes 机密中的凭据访问受保护的探测终结点。您可以使用现有密钥,前提是凭据包含在credentials
密钥的密钥名称data
块。您可以基于每个应用程序配置探测身份验证。启用后,它将应用于liveness
和readiness
使用相同的凭据和身份验证类型探测终结点。目前,只有Basic
支持身份验证。
要创建新密钥,请执行以下作:
-
使用用于访问安全探测终结点的凭据生成 base64 字符串。
基本身份验证将用户名和密码编码为 base64 字符串,格式为
username:password
.以下示例(包括输出,应在其中将
user
和pass
使用您的值)显示如何生成 base64 字符串:$ echo -n "user:pass" | base64 dXNlcjpwYXNz
-
使用编码的凭据创建一个文件(例如,
myprobesecret.yml
)包含以下内容:apiVersion: v1 kind: Secret metadata: name: myprobesecret type: Opaque data: credentials: GENERATED_BASE64_STRING
-
取代
GENERATED_BASE64_STRING
使用之前生成的 base64 编码值。 -
使用
kubectl
,如以下示例所示:$ kubectl create -f ./myprobesecret.yml secret "myprobesecret" created
-
将以下部署程序属性设置为在访问探测终结点时使用身份验证,如以下示例所示:
deployer.<application>.kubernetes.probeCredentialsSecret=myprobesecret
取代
<application>
替换为要应用身份验证的应用程序的名称。
5.1.4. 使用SPRING_APPLICATION_JSON
您可以使用SPRING_APPLICATION_JSON
环境变量,用于设置数据流服务器属性(包括Maven存储库设置的配置),这些属性在所有数据流服务器实施中都是通用的。这些设置位于容器中的服务器级别env
部署 YAML 的部分。以下示例显示了如何执行此作:
env:
- name: SPRING_APPLICATION_JSON
value: "{ \"maven\": { \"local-repository\": null, \"remote-repositories\": { \"repo1\": { \"url\": \"https://repo.spring.io/libs-snapshot\"} } } }"
5.1.5. 私有 Docker 注册表
您可以按应用程序从专用注册表中提取 Docker 映像。首先,您必须在集群中创建一个密钥。按照从私有注册表拉取映像指南创建密钥。
创建密钥后,您可以使用imagePullSecret
属性来设置要使用的密钥,如以下示例所示:
deployer.<application>.kubernetes.imagePullSecret=mysecret
取代<application>
替换为您的应用程序名称,以及mysecret
替换为您之前创建的密钥的名称。
您还可以在全局服务器级别配置镜像拉取密钥。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
imagePullSecret: mysecret
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
imagePullSecret: mysecret
取代mysecret
替换为您之前创建的密钥的名称。
5.1.6. 注释
您可以按应用程序向 Kubernetes 对象添加注释。支持的对象类型为 podDeployment
,Service
和Job
.注释在key:value
格式,允许用逗号分隔多个注释。有关注释的更多信息和用例,请参阅注释。
以下示例显示如何配置应用程序以使用注释:
deployer.<application>.kubernetes.podAnnotations=annotationName:annotationValue
deployer.<application>.kubernetes.serviceAnnotations=annotationName:annotationValue,annotationName2:annotationValue2
deployer.<application>.kubernetes.jobAnnotations=annotationName:annotationValue
取代<application>
替换为您的应用程序名称和注释的值。
5.1.7. 入口点样式
入口点样式会影响应用程序属性传递到要部署的容器的方式。目前,支持三种样式:
-
exec
(默认):将部署请求中的所有应用程序属性和命令行参数作为容器参数传递。应用程序属性转换为--key=value
. -
shell
:将所有应用程序属性和命令行参数作为环境变量传递。每个 application或命令行参数属性都转换为大写字符串,并且.
字符替换为 ._
-
boot
:创建一个名为SPRING_APPLICATION_JSON
包含所有应用程序属性的 JSON 表示形式。部署请求中的命令行参数设置为容器参数。
在所有情况下,在服务器级配置和每个应用程序的基础上定义的环境变量都会按原样发送到容器。 |
您可以按如下方式配置应用程序:
deployer.<application>.kubernetes.entryPointStyle=<Entry Point Style>
取代<application>
替换为您的应用程序名称,以及<Entry Point Style>
使用您想要的入口点样式。
您还可以在全局服务器级别配置入口点样式。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
entryPointStyle: entryPointStyle
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
entryPointStyle: entryPointStyle
取代entryPointStyle
为所需的入口点样式。
您应该选择 入口点样式exec
或shell
,以对应于ENTRYPOINT
语法在容器的Dockerfile
. 有关更多信息和用例exec
对shell
,请参阅 Docker 文档的 ENTRYPOINT 部分。
使用boot
入口点样式对应于使用exec
风格ENTRYPOINT
. 部署请求中的命令行参数将传递到容器,并将应用程序属性映射到SPRING_APPLICATION_JSON
环境变量而不是命令行参数。
当您使用boot 入口点样式,则deployer.<application>.kubernetes.environmentVariables 属性不得包含SPRING_APPLICATION_JSON . |
5.1.8. 部署服务账号
您可以通过属性为应用程序部署配置自定义服务帐户。您可以使用现有服务帐户或创建一个新服务帐户。创建服务帐户的一种方法是使用kubectl
,如以下示例所示:
$ kubectl create serviceaccount myserviceaccountname
serviceaccount "myserviceaccountname" created
然后,您可以按如下方式配置单个应用程序:
deployer.<application>.kubernetes.deploymentServiceAccountName=myserviceaccountname
取代<application>
替换为您的应用程序名称,以及myserviceaccountname
替换为您的服务帐户名称。
您还可以在全局服务器级别配置服务帐户名称。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
deploymentServiceAccountName: myserviceaccountname
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
deploymentServiceAccountName: myserviceaccountname
取代myserviceaccountname
替换为要应用于所有部署的服务帐户名称。
5.1.9. 镜像拉取策略
映像拉取策略定义何时应将 Docker 映像拉取到本地注册表。目前,支持三种策略:
-
IfNotPresent
(默认):如果镜像已经存在,则不要拉取镜像。 -
Always
:始终拉取图像,无论它是否已经存在。 -
Never
:切勿拉取图像。仅使用已存在的图像。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.imagePullPolicy=Always
取代<application>
替换为您的应用程序名称,以及Always
使用所需的映像拉取策略。
您可以在全局服务器级别配置镜像拉取策略。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
imagePullPolicy: Always
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
imagePullPolicy: Always
取代Always
使用所需的映像拉取策略。
5.1.10. 部署标签
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.deploymentLabels=myLabelName:myLabelValue
取代<application>
替换为您的应用程序名称,myLabelName
替换为您的标签名称,以及myLabelValue
替换为您的标签值。
此外,还可以应用多个标签,如以下示例所示:
deployer.<application>.kubernetes.deploymentLabels=myLabelName:myLabelValue,myLabelName2:myLabelValue2
5.1.11. 容忍
容忍度与污点一起使用,以确保 Pod 不会被调度到特定节点上。 容忍度设置到 Pod 配置中,而污点设置到节点上。 有关更多信息,请参阅 Kubernetes 参考的污点和容忍度部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.tolerations=[{key: 'mykey' operator: 'Equal', value: 'myvalue', effect: 'NoSchedule'}]
取代<application>
替换为您的应用程序名称和键值对,具体取决于您所需的容错配置。
您也可以在全局服务器级别配置容错。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
tolerations:
- key: mykey
operator: Equal
value: myvalue
effect: NoSchedule
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
tolerations:
- key: mykey
operator: Equal
value: myvalue
effect: NoSchedule
将tolerations
键值对。
5.1.12. 秘密引用
可以引用 Secret,并且可以解码其整个数据内容并将其作为单独的变量插入到 Pod 环境中。 有关更多信息,请参阅 Kubernetes 参考的将密钥中的所有键值对配置为容器环境变量部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.secretRefs=testsecret
您还可以指定多个密钥,如下所示:
deployer.<application>.kubernetes.secretRefs=[testsecret,anothersecret]
取代<application>
替换为您的应用程序名称和secretRefs
属性,并指定为您的应用程序环境和密钥提供适当的值。
您也可以在全局服务器级别配置机密引用。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
secretRefs:
- testsecret
- anothersecret
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
secretRefs:
- testsecret
- anothersecret
替换 的项目secretRefs
使用一个或多个机密名称。
5.1.13. 密钥引用
可以引用密钥,并将其解码值插入到 Pod 环境中。 有关更多信息,请参阅 Kubernetes 参考的使用密钥作为环境变量部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.secretKeyRefs=[{envVarName: 'MY_SECRET', secretName: 'testsecret', dataKey: 'password'}]
取代<application>
替换为您的应用程序名称和envVarName
,secretName
和dataKey
属性,并具有适合您的应用程序环境和密钥的值。
您也可以在全局服务器级别配置密钥引用。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
secretKeyRefs:
- envVarName: MY_SECRET
secretName: testsecret
dataKey: password
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
secretKeyRefs:
- envVarName: MY_SECRET
secretName: testsecret
dataKey: password
将envVarName
,secretName
和dataKey
属性,并为您的密钥提供适当的值。
5.1.14. ConfigMap 引用
可以引用 ConfigMap,其整个数据内容可以解码并作为单独的变量插入到 Pod 环境中。 有关更多信息,请参阅 Kubernetes 参考的将 ConfigMap 中的所有键值对配置为容器环境变量部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.configMapRefs=testcm
您还可以指定多个 ConfigMap 实例,如下所示:
deployer.<application>.kubernetes.configMapRefs=[testcm,anothercm]
取代<application>
替换为您的应用程序名称和configMapRefs
属性,并指定为适用于您的应用程序环境和 ConfigMap 的适当值。
您也可以在全局服务器级别配置 ConfigMap 引用。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
configMapRefs:
- testcm
- anothercm
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
configMapRefs:
- testcm
- anothercm
替换 的项目configMapRefs
使用一个或多个机密名称。
5.1.15. ConfigMap 键引用
可以引用 ConfigMap 并将其关联的键值插入到 Pod 环境中。 有关更多信息,请参阅 Kubernetes 参考的 使用 ConfigMap 数据定义容器环境变量 部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.configMapKeyRefs=[{envVarName: 'MY_CM', configMapName: 'testcm', dataKey: 'platform'}]
取代<application>
替换为您的应用程序名称和envVarName
,configMapName
和dataKey
属性,并具有适合您的应用程序环境和 ConfigMap 的值。
您也可以在全局服务器级别配置 ConfigMap 引用。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
configMapKeyRefs:
- envVarName: MY_CM
configMapName: testcm
dataKey: platform
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
configMapKeyRefs:
- envVarName: MY_CM
configMapName: testcm
dataKey: platform
将envVarName
,configMapName
和dataKey
属性,并为您的 ConfigMap 提供适当的值。
5.1.16. Pod 安全上下文
您可以配置 Pod 安全上下文,以便在指定的 UID(用户 ID)或 GID(组 ID)下运行进程。
当您不想在默认root
UID 和 GID。
您可以定义runAsUser
(UID) 或fsGroup
(GID),您可以将它们配置为协同工作。
有关更多信息,请参阅 Kubernetes 参考中的安全上下文部分。
以下示例显示了如何单独配置应用程序 Pod:
deployer.<application>.kubernetes.podSecurityContext={runAsUser: 65534, fsGroup: 65534}
取代<application>
替换为您的应用程序名称和runAsUser
和/或fsGroup
属性,其值适合您的容器环境。
您也可以在全局服务器级别配置容器安全上下文。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
podSecurityContext:
runAsUser: 65534
fsGroup: 65534
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
podSecurityContext:
runAsUser: 65534
fsGroup: 65534
将runAsUser
和/或fsGroup
属性,其值适合您的容器环境。
5.1.17. 服务端口
部署应用程序时,将创建一个 kubernetes 服务对象,默认端口为8080
.如果server.port
属性,则它会覆盖默认端口值。您可以根据每个应用程序向服务对象添加其他端口。您可以使用逗号分隔符添加多个端口。
以下示例演示如何在应用程序的 Service 对象上配置其他端口:
deployer.<application>.kubernetes.servicePorts=5000
deployer.<application>.kubernetes.servicePorts=5000,9000
取代<application>
替换为您的应用程序名称和端口值。
5.1.18. StatefulSet 初始化容器
使用 StatefulSet 部署应用程序时,使用 Init Container 来设置 Pod 中的实例索引。
默认情况下,使用的图像是busybox
,您可以自定义。
以下示例显示了如何单独配置应用程序 Pod:
deployer.<application>.kubernetes.statefulSetInitContainerImageName=myimage:mylabel
取代<application>
替换为您的应用程序名称和statefulSetInitContainerImageName
属性,并指定为您的环境的适当值。
您也可以在全局服务器级别配置 StatefulSet 初始化容器。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
statefulSetInitContainerImageName: myimage:mylabel
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
statefulSetInitContainerImageName: myimage:mylabel
将statefulSetInitContainerImageName
属性,并指定为您的环境的适当值。
5.1.19. 初始化容器
部署应用程序时,可以按应用程序设置自定义 Init 容器。 有关更多信息,请参阅 Kubernetes 参考的 初始化容器 部分。
以下示例显示了如何为应用程序配置初始化容器:
deployer.<application>.kubernetes.initContainer={containerName: 'test', imageName: 'busybox:latest', commands: ['sh', '-c', 'echo hello']}
取代<application>
替换为应用程序的名称,并设置initContainer
属性。
5.1.20. 生命周期支持
部署应用程序时,可以附加postStart
和preStop
用于执行命令的生命周期处理程序。
Kubernetes API 支持其他类型的处理程序,除了exec
.此功能可能会在将来的版本中扩展以支持其他作。
要配置 生命周期处理程序 如上面的链接页面所示,请使用以下属性键将每个命令指定为逗号分隔的列表:
deployer.<application>.kubernetes.lifecycle.postStart.exec.command=/bin/sh,-c,'echo Hello from the postStart handler > /usr/share/message'
deployer.<application>.kubernetes.lifecycle.preStop.exec.command=/bin/sh,-c,'nginx -s quit; while killall -0 nginx; do sleep 1; done'
5.1.21. 附加容器
部署应用程序时,可能需要将一个或多个容器与主容器一起部署。 这将允许您调整一些部署模式,例如在多容器 Pod 设置的情况下的 sidecar、适配器。
以下示例演示如何为应用程序配置其他容器:
deployer.<application>.kubernetes.additionalContainers=[{name: 'c1', image: 'busybox:latest', command: ['sh', '-c', 'echo hello1'], volumeMounts: [{name: 'test-volume', mountPath: '/tmp', readOnly: true}]},{name: 'c2', image: 'busybox:1.26.1', command: ['sh', '-c', 'echo hello2']}]