快速开始
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部分。
一旦您已在 Kubernetes 上安装了 Data Flow 服务器，可能就希望开始编排部署现成的预构建应用程序，以构建连贯的流处理或批处理数据管道。我们提供了相关指南，帮助您快速入门流处理和批处理。
5.1. 应用程序和服务器属性
本节介绍如何自定义应用程序的部署。您可以使用多个属性来影响已部署应用程序的设置。这些属性可以针对单个应用程序进行设置，也可以在相应的服务器配置中为所有已部署的应用程序统一应用。
| 针对每个应用程序设置的属性始终优先于服务器配置中设置的属性。这种安排允许您针对每个应用程序覆盖全局服务器级别的属性。 |
为所有已部署的任务（Tasks）定义的属性位于 src/kubernetes/server/server-config-[binder].yaml 文件中，而流（Streams）的属性则位于 src/kubernetes/skipper/skipper-config-[binder].yaml 文件中。请将 [binder] 替换为您所使用的消息中间件，例如 rabbit 或 kafka。
5.1.1. 内存和 CPU 设置
应用程序使用默认的内存和 CPU 设置进行部署。如有需要，您可以调整这些值。以下示例展示了如何将 Limits 的 1000m 设置为 CPU，内存的 1024Mi 设置为 Requests，并将 800m 的 640Mi 设置为 7，内存的 8 设置为 9：
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 部署器属性。
例如，在生产环境中常见的一个需求是调整 JVM 内存参数。
你可以通过使用 JAVA_TOOL_OPTIONS 环境变量来实现这一点，如下例所示：
deployer.<application>.kubernetes.environmentVariables=JAVA_TOOL_OPTIONS=-Xmx1024menvironmentVariables 属性接受一个以逗号分隔的字符串。如果某个环境变量的值本身也是一个以逗号分隔的字符串，则必须用单引号括起来——例如，
spring.cloud.deployer.kubernetes.environmentVariables=spring.cloud.stream.kafka.binder.brokers='somehost:9092,
anotherhost:9093' |
这将覆盖指定 <application> 的 JVM 内存设置（请将 <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 Secret中的凭据来访问受保护的探针端点。您可以使用现有的 Secret，前提是凭据包含在该 Secret 的 credentials 块中、键名为 data 的字段下。您可以针对每个应用程序单独配置探针认证。启用后，该配置将同时应用于 liveness（存活）和 readiness（就绪）探针端点，并使用相同的凭据和认证类型。目前仅支持 Basic（基本）认证。
要创建一个新的密钥：
-
生成用于访问受保护探针端点的凭据的 Base64 字符串。
基本认证将用户名和密码以
username:password的格式编码为 Base64 字符串。以下示例（包含输出结果，您应将其中的
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 环境变量来设置 Data Flow 服务器属性（包括 Maven 仓库配置），这些属性在所有 Data Flow 服务器实现中都是通用的。这些设置应放在部署 YAML 文件中容器的 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 替换为您之前创建的密钥名称。
您还可以在全局服务器级别配置镜像拉取密钥。
以下示例展示了如何对流（streams）进行此操作：
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 对象添加注解（annotations）。支持的对象类型包括 Pod、Deployment、Service 和 Job。注解以 key:value 格式定义，多个注解之间用逗号分隔。有关注解的更多信息和使用场景，请参阅注解（Annotations）。
以下示例展示了如何配置应用程序以使用注解：
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：将所有应用程序属性和命令行参数作为环境变量传递。每个应用程序属性或命令行参数都会被转换为大写字符串，并将其中的.字符替换为_。 -
boot：创建一个名为SPRING_APPLICATION_JSON的环境变量，其中包含所有应用程序属性的 JSON 表示形式。来自部署请求的命令行参数将被设置为容器参数。
| 在所有情况下，服务器级别配置中定义的环境变量以及每个应用程序单独设置的环境变量都会原封不动地传递给容器。 |
您可以按如下方式配置应用程序：
deployer.<application>.kubernetes.entryPointStyle=<Entry Point Style>将 <application> 替换为您的应用程序名称，将 <Entry Point Style> 替换为您所需的入口点样式。
你也可以在全局服务器级别配置入口点样式。
以下示例展示了如何对流（streams）进行此操作：
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 其中一种入口点（Entry Point）风格，以对应容器 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 替换为您的服务账户名称。
您还可以在全局服务器级别配置服务账户名称。
以下示例展示了如何对流（streams）进行此操作：
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 替换为您所需的镜像拉取策略。
您可以在全局服务器级别配置镜像拉取策略。
以下示例展示了如何对流（streams）进行此操作：
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相关的对象上设置自定义标签。有关标签的更多信息，请参阅Labels。标签以key:value格式指定。
以下示例展示了如何单独配置应用程序：
deployer.<application>.kubernetes.deploymentLabels=myLabelName:myLabelValue将 <application> 替换为您的应用程序名称，将 myLabelName 替换为您的标签名称，并将 myLabelValue 替换为您的标签值。
此外，您还可以应用多个标签，如下例所示：
deployer.<application>.kubernetes.deploymentLabels=myLabelName:myLabelValue,myLabelName2:myLabelValue25.1.11. 容忍度
容忍（Tolerations）与污点（Taints）配合使用，以确保 Pod 不会被调度到特定的节点上。 容忍设置在 Pod 的配置中，而污点则设置在节点上。 更多信息请参阅 Kubernetes 官方文档中的污点与容忍章节。
以下示例展示了如何单独配置应用程序：
deployer.<application>.kubernetes.tolerations=[{key: 'mykey' operator: 'Equal', value: 'myvalue', effect: 'NoSchedule'}]将 <application> 替换为您的应用程序名称，并根据您期望的容忍（toleration）配置替换相应的键值对。
你也可以在全局服务器级别配置容忍（tolerations）。
以下示例展示了如何对流（streams）进行此操作：
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根据您期望的容忍（toleration）配置，替换 tolerations 键值对。
5.1.12. 密钥引用
可以引用 Secret，并将其全部数据内容解码后作为单独的变量插入到 Pod 的环境中。 更多信息，请参阅 Kubernetes 官方文档中的将 Secret 中的所有键值对配置为容器环境变量部分。
以下示例展示了如何单独配置应用程序：
deployer.<application>.kubernetes.secretRefs=testsecret你也可以指定多个密钥，如下所示：
deployer.<application>.kubernetes.secretRefs=[testsecret,anothersecret]将 <application> 替换为您的应用程序名称，并将 secretRefs 属性替换为适用于您的应用程序环境和密钥的相应值。
你也可以在全局服务器级别配置密钥引用。
以下示例展示了如何对流（streams）进行此操作：
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，并将其解码后的值插入到 Pod 的环境变量中。 有关更多信息，请参阅 Kubernetes 官方文档中的将 Secret 用作环境变量一节。
以下示例展示了如何单独配置应用程序：
deployer.<application>.kubernetes.secretKeyRefs=[{envVarName: 'MY_SECRET', secretName: 'testsecret', dataKey: 'password'}]将 <application> 替换为您的应用程序名称，并将 envVarName、secretName 和 dataKey 属性替换为适用于您的应用程序环境和密钥的相应值。
你也可以在全局服务器级别配置密钥引用。
以下示例展示了如何对流（streams）进行此操作：
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 引用。
以下示例展示了如何对流（streams）进行此操作。编辑相应的 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 引用。
以下示例展示了如何对流（streams）进行此操作。编辑相应的 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）下运行进程。
当您不想使用默认的 root UID 和 GID 运行进程时，这非常有用。
您可以定义 runAsUser（UID）或 fsGroup（GID），也可以将它们配置为协同工作。
更多信息请参阅 Kubernetes 参考文档中的安全上下文部分。
以下示例展示了如何单独配置应用程序的 Pod：
deployer.<application>.kubernetes.podSecurityContext={runAsUser: 65534, fsGroup: 65534}将 <application> 替换为您的应用程序名称，并将 runAsUser 和/或 fsGroup 属性替换为适用于您的容器环境的相应值。
你也可以在全局服务器级别配置 Pod 安全上下文。
以下示例展示了如何对流（streams）进行此操作。编辑相应的 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. 服务端口
部署应用程序时，会创建一个 Kubernetes Service 对象，默认端口为 8080。如果设置了 server.port 属性，则会覆盖默认端口值。您可以根据每个应用程序向 Service 对象添加额外的端口。多个端口之间使用逗号分隔。
以下示例展示了如何为应用程序的 Service 对象配置额外的端口：
deployer.<application>.kubernetes.servicePorts=5000
deployer.<application>.kubernetes.servicePorts=5000,9000将 <application> 替换为您的应用程序名称和端口值。
5.1.18. StatefulSet 初始化容器
使用 StatefulSet 部署应用程序时，会使用一个 Init 容器来设置 Pod 中的实例索引。
默认使用的镜像是 busybox，您可以对其进行自定义。
以下示例展示了如何单独配置应用程序的 Pod：
deployer.<application>.kubernetes.statefulSetInitContainerImageName=myimage:mylabel将 <application> 替换为您的应用程序名称，并将 statefulSetInitContainerImageName 属性替换为您环境中相应的值。
您也可以在全局服务器级别配置 StatefulSet 的 Init 容器。
以下示例展示了如何对流（streams）进行此操作。编辑相应的 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 容器。 有关更多信息，请参阅 Kubernetes 参考文档中的Init 容器部分。
以下示例展示了如何为应用程序配置一个 Init 容器：
deployer.<application>.kubernetes.initContainer={containerName: 'test', imageName: 'busybox:latest', commands: ['sh', '-c', 'echo hello']}将 <application> 替换为您的应用程序名称，并根据您的 Init 容器设置 initContainer 属性的相应值。
5.1.20. 生命周期支持
部署应用程序时，您可以附加 postStart 和 preStop 生命周期处理器（Lifecycle handlers） 来执行命令。
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）模式或适配器（adapter）模式。
以下示例展示了如何为应用程序配置额外的容器：
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']}]