开始
3. 入门 - 本地
有关设置 docker compose 和手动安装的更多信息，请参阅微型网站的 Local Machine 部分。
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].yamlfile 和src/kubernetes/skipper/skipper-config-[binder].yaml.取代[binder]使用您正在使用的消息传递中间件 — 例如，rabbit或kafka.
5.1.1. 内存和 CPU 设置
应用程序使用默认内存和 CPU 设置进行部署。如果需要，您可以调整这些值。以下示例演示如何设置Limits自1000m为CPU和1024Mifor memory 和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.environmentVariablesdeployer 属性。
例如，生产环境中的常见要求是影响 JVM 内存参数。
您可以使用JAVA_TOOL_OPTIONS环境变量，如下例所示：
deployer.<application>.kubernetes.environmentVariables=JAVA_TOOL_OPTIONS=-Xmx1024m这environmentVariablesproperty 接受逗号分隔的字符串。如果环境变量包含值
这也是一个逗号分隔的字符串，它必须用单引号引起来——例如，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对于 both 和 aperiod之60和10分别。您可以在部署流时使用 Deployer 属性更改这些默认值。liveness 和 readiness 探测仅适用于流。
以下示例将liveness探针（将<application>替换为您的应用程序名称），方法是设置 Deployer 属性：
deployer.<application>.kubernetes.livenessProbePath=/health
deployer.<application>.kubernetes.livenessProbeDelay=120
deployer.<application>.kubernetes.livenessProbePeriod=20您可以声明 Same as the part of the server global configuration for streams，如下例所示：
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
livenessProbePath: /health
livenessProbeDelay: 120
livenessProbePeriod: 20同样，您可以交换liveness为readiness以覆盖默认值readiness设置。
默认情况下，端口 8080 用作探测端口。您可以更改两者的默认值liveness和readiness使用 Deployer 属性探测端口，如下例所示：
deployer.<application>.kubernetes.readinessProbePort=7000
deployer.<application>.kubernetes.livenessProbePort=7000您可以将 SAME 声明为 AS the PART of the global configuration for streams，如下例所示：
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 编码值。 -
使用 创建 secret
kubectl，如下例所示：$ kubectl create -f ./myprobesecret.yml secret "myprobesecret" created -
将以下 Deployer 属性设置为在访问探测端点时使用身份验证，如下例所示：
deployer.<application>.kubernetes.probeCredentialsSecret=myprobesecret取代
<application>替换为要应用身份验证的应用程序的名称。
5.1.4. 使用SPRING_APPLICATION_JSON
您可以使用SPRING_APPLICATION_JSON环境变量设置数据流服务器属性（包括 Maven 存储库设置的配置），这些属性在所有数据流服务器实现中都是通用的。这些设置位于容器中的服务器级别env部分。以下示例显示了如何执行此作：
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 镜像。首先，您必须在集群中创建一个密钥。按照 从私有注册表拉取映像 指南创建密钥。
创建 secret 后，您可以使用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：将所有应用程序属性和命令行参数作为环境变量传递。每个 applicationor 命令行参数属性都转换为一个大写字符串，并且.字符替换为 。_ -
boot：创建一个名为SPRING_APPLICATION_JSON，其中包含所有应用程序属性的 JSON 表示形式。部署请求中的命令行参数设置为 container args。
| 在所有情况下，在服务器级配置和基于每个应用程序定义的环境变量都会按原样发送到容器。 |
您可以按如下方式配置应用程序：
deployer.<application>.kubernetes.entryPointStyle=<Entry Point Style>取代<application>替换为您的应用程序名称，并将<Entry Point Style>替换为所需的入口点样式。
您还可以在 Global Server 级别配置入口点样式。
以下示例显示如何对流执行此作：
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替换为所需的入口点样式。
您应该选择 Entry Point Style （入口点样式）exec或shell，以对应ENTRYPOINT语法在容器的Dockerfile.有关更多信息和使用案例exec对shell，请参阅 Docker 文档的 ENTRYPOINT 部分。
使用boot入口点样式对应于使用exec风格ENTRYPOINT.部署请求中的命令行参数将传递到容器，并添加应用程序属性映射到SPRING_APPLICATION_JSON环境变量，而不是命令行参数。
当您使用bootEntry Point 样式、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. 部署标签
您可以为与 Deployment 相关的对象设置自定义标签。有关标签的更多信息，请参阅标签。标签在key:value格式。
以下示例显示了如何单独配置应用程序：
deployer.<application>.kubernetes.deploymentLabels=myLabelName:myLabelValue取代<application>替换为您的应用程序名称，myLabelName替换为您的标签名称，以及myLabelValue替换为标签的值。
此外，您还可以应用多个标签，如下例所示：
deployer.<application>.kubernetes.deploymentLabels=myLabelName:myLabelValue,myLabelName2:myLabelValue25.1.11. 容忍度
容忍度与污点一起工作，以确保 Pod 不会被调度到特定节点上。 容忍度被设置到 Pod 配置中，而污点被设置到节点上。 有关更多信息，请参阅 Kubernetes 参考的污点和容忍度部分。
以下示例显示了如何单独配置应用程序：
deployer.<application>.kubernetes.tolerations=[{key: 'mykey' operator: 'Equal', value: 'myvalue', effect: 'NoSchedule'}]取代<application>替换为您的应用程序名称和键值对，具体取决于您所需的容忍度配置。
您也可以在 Global Server 级别配置容忍度。
以下示例显示如何对流执行此作：
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属性替换为您的应用程序环境和密钥的相应值。
您也可以在全局服务器级别配置 secret 引用。
以下示例显示如何对流执行此作：
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替换为一个或多个 secret 名称。
5.1.13. Secret Key 引用
可以引用 Secret，并且可以将其解码值插入到 Pod 环境中。 有关更多信息，请参阅 Kubernetes 参考的 Using Secrets as Environment Variables 部分。
以下示例显示了如何单独配置应用程序：
deployer.<application>.kubernetes.secretKeyRefs=[{envVarName: 'MY_SECRET', secretName: 'testsecret', dataKey: 'password'}]取代<application>替换为您的应用程序名称，并使用envVarName,secretName和dataKey属性替换为您的应用程序环境和密钥的适当值。
您还可以在 Global Server 级别配置密钥引用。
以下示例显示如何对流执行此作：
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)使用相应的 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替换为一个或多个 secret 名称。
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)使用相应的 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）下运行进程。
当您不想在默认rootUID 和 GID。
您可以定义runAsUser（UID） 或fsGroup（GID） 进行 Git Git作，您可以将它们配置为协同工作。
有关更多信息，请参阅 Kubernetes 参考的 Security Context 部分。
以下示例显示了如何单独配置应用程序 Pod：
deployer.<application>.kubernetes.podSecurityContext={runAsUser: 65534, fsGroup: 65534}取代<application>替换为您的应用程序名称，并使用runAsUser和/或fsGroup属性替换为您的容器环境的适当值。
你也可以在全局服务器级别配置 Pod 安全上下文。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml取代(binder)使用相应的 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. 服务端口
部署应用程序时，将创建一个默认端口为8080.如果server.port属性，它会覆盖默认端口值。您可以基于每个应用程序向 Service 对象添加其他端口。您可以使用逗号分隔符添加多个端口。
以下示例显示了如何在应用程序的 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 Init Container。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml取代(binder)使用相应的 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 Container。 有关更多信息，请参阅 Kubernetes 参考的 Init Containers 部分。
以下示例说明如何为应用程序配置 Init 容器：
deployer.<application>.kubernetes.initContainer={containerName: 'test', imageName: 'busybox:latest', commands: ['sh', '-c', 'echo hello']}取代<application>替换为您的应用程序名称，并将initContainer适用于您的 Init Container 的属性。
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. 其他容器
部署应用程序时，可能需要将一个或多个容器与主容器一起部署。 这将允许您调整一些部署模式，例如 sidecar、适配器（在多容器 pod 设置的情况下）。
以下示例显示了如何为应用程序配置其他容器：
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']}]