Helm 安装

Spring Cloud Data Flow 提供了一个 Helm Chart，用于将 Spring Cloud Data Flow 服务器及其所需服务部署到 Kubernetes 集群。

以下部分介绍如何初始化 Helm 并在 Kubernetes 集群上安装 Spring Cloud Data Flow。

安装 Spring Cloud Data Flow 服务器和所需服务

适用于 Spring Cloud Data Flow 的 Bitnami 软件包

Spring Cloud Data Flow 是一个基于微服务的工具包，用于在 Cloud Foundry 和 Kubernetes 中构建流式和批处理数据处理管道。

Spring Cloud Data Flow 概述

太长不看版

helm install my-release oci://registry-1.docker.io/bitnamicharts/spring-cloud-dataflow

希望在生产环境中使用 Spring Cloud Data Flow？试试 VMware Tanzu 应用目录，Bitnami 应用目录的企业版。

简介

此图表使用 Helm 包管理器在 Kubernetes 集群上引导 Spring Cloud Data Flow 部署。

Bitnami 图表可以与 Kubeapps 一起使用，以便在集群中部署和管理 Helm 图表。

先决条件

• Kubernetes 1.23+
• Helm 3.8.0+
• 底层基础架构中的 PV 配置器支持

安装图表

要使用发行版名称 my-release 安装图表

helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/spring-cloud-dataflow

注意：您需要将占位符 REGISTRY_NAME 和 REPOSITORY_NAME 替换为对您的 Helm 图表注册表和存储库的引用。例如，在 Bitnami 的情况下，您需要使用 REGISTRY_NAME=registry-1.docker.io 和 REPOSITORY_NAME=bitnamicharts。

这些命令使用默认配置在 Kubernetes 集群上部署 Spring Cloud Data Flow。参数 部分列出了可以在安装过程中配置的参数。

提示：使用 helm list 列出所有发行版

配置和安装细节

资源请求和限制

Bitnami 图表允许为图表部署内的所有容器设置资源请求和限制。这些都在 resources 值内（请查看参数表）。设置请求对于生产工作负载至关重要，并且应根据您的特定用例进行调整。

为了简化此过程，图表包含 resourcesPreset 值，该值会根据不同的预设自动设置 resources 部分。在 bitnami/common 图表 中查看这些预设。但是，在生产工作负载中，不建议使用 resourcePreset，因为它可能无法完全适应您的特定需求。在 Kubernetes 官方文档 中查找有关容器资源管理的更多信息。

滚动标签与不可变标签

强烈建议在生产环境中使用不可变标签。这可以确保如果使用不同的镜像更新了相同的标签，您的部署不会自动更改。

如果存在主要容器的新版本、重大更改或严重漏洞，Bitnami 将发布更新其容器的新图表。

特性

如果只需要部署任务和计划，则可以禁用流式传输和 Skipper

server.configuration.batchEnabled=true
server.configuration.streamingEnabled=false
skipper.enabled=false
rabbitmq.enabled=false

如果只需要部署流，则可以禁用任务和计划

server.configuration.batchEnabled=false
server.configuration.streamingEnabled=true
skipper.enabled=true
rabbitmq.enabled=true

注意：server.configuration.batchEnabled 和 server.configuration.streamingEnabled 不应同时设置为 false。

消息传递解决方案

此图表中支持两种消息传递解决方案

• RabbitMQ（默认）
• Kafka

要将消息传递层更改为 Kafka，请使用以下参数

rabbitmq.enabled=false
kafka.enabled=true

在给定时间只能使用一个消息传递层。

使用外部数据库

有时，您可能希望 Spring Cloud 组件连接到外部数据库，而不是在集群内部安装数据库，例如使用托管数据库服务，或者对所有应用程序使用单个数据库服务器。为此，该图表允许您在 externalDatabase 参数 下指定外部数据库的凭据。您还应该使用 mariadb.enabled 选项禁用 MariaDB 安装。例如，使用以下参数

mariadb.enabled=false
externalDatabase.scheme=mariadb
externalDatabase.host=myexternalhost
externalDatabase.port=3306
externalDatabase.password=mypassword
externalDatabase.dataflow.user=mydataflowuser
externalDatabase.dataflow.database=mydataflowdatabase
externalDatabase.skipper.user=myskipperuser
externalDatabase.skipper.database=myskipperdatabase

注意：当使用各个属性（方案、主机、端口、数据库、可选的 jdbcParameters）时，此图表将 JDBC URL 格式化为 jdbc:{scheme}://{host}:{port}/{database}{jdbcParameters}。URL 格式遵循 MariaDB 数据库驱动的格式，但可能不适用于其他数据库供应商。

要使用备用数据库供应商（MariaDB 除外），您可以使用 externalDatabase.dataflow.url 和 externalDatabase.skipper.url 属性分别为数据流服务器和 skipper 提供 JDBC URL。如果定义了这些属性，则它们将优先于各个属性。例如配置外部 MS SQL Server 数据库

mariadb.enabled=false
externalDatabase.password=mypassword
externalDatabase.dataflow.url=jdbc:sqlserver://mssql-server:1433
externalDatabase.dataflow.user=mydataflowuser
externalDatabase.skipper.url=jdbc:sqlserver://mssql-server:1433
externalDatabase.skipper.user=myskipperuser
externalDatabase.hibernateDialect=org.hibernate.dialect.SQLServer2012Dialect

注意：如果您按上述方式禁用 MariaDB，则必须为 externalDatabase 连接提供值。

添加额外的标志

如果您想向任何 Spring Cloud 组件添加额外的环境变量，可以使用 XXX.extraEnvs 参数，其中 XXX 是您需要替换为实际组件的占位符。例如，要向 Spring Cloud Data Flow 添加额外的标志，请使用

server:
  extraEnvs:
    - name: FOO
      value: BAR

使用自定义 Dataflow 配置

此 Helm 图表支持对 Dataflow 服务器使用自定义配置。

您可以通过将 server.existingConfigmap 参数设置为包含配置文件的外部 ConfigMap 来指定 Dataflow 服务器的配置。

使用自定义 Skipper 配置

此 Helm chart 支持为 Skipper 服务器使用自定义配置。

您可以通过将 skipper.existingConfigmap 参数设置为包含配置文件的外部 ConfigMap 来指定 Skipper 服务器的配置。

边车和初始化容器

如果您需要在与 Dataflow 或 Skipper 组件相同的 pod 中运行其他容器（例如，额外的指标或日志导出器），您可以通过 XXX.sidecars 参数来实现，其中 XXX 是您需要替换为实际组件的占位符。您只需根据 Kubernetes 容器规范定义您的容器即可。

server:
  sidecars:
    - name: your-image-name
      image: your-image
      imagePullPolicy: Always
      ports:
        - name: portname
          containerPort: 1234

类似地，您可以使用 XXX.initContainers 参数添加额外的初始化容器。

server:
  initContainers:
    - name: your-image-name
      image: your-image
      imagePullPolicy: Always
      ports:
        - name: portname
          containerPort: 1234

入口

此 chart 支持 Ingress 资源。如果您的集群上安装了 ingress 控制器，例如 nginx-ingress-controller 或 contour，则可以使用 ingress 控制器来为您的应用程序提供服务。

要启用 ingress 集成，请将 server.ingress.enabled 设置为 true

主机

您很可能只希望有一个主机名映射到此 Spring Cloud Data Flow 安装。如果是这种情况，则可以使用属性 server.ingress.hostname 进行设置。但是，也可以有多个主机。为了方便起见，可以将 server.ingress.extraHosts 对象指定为数组。您还可以使用 server.ingress.extraTLS 为额外主机添加 TLS 配置。

对于 server.ingress.extraHosts 中指示的每个主机，请指明 name、path 以及您希望 ingress 控制器了解的任何 annotations。

有关注释，请参阅本文档。并非所有 ingress 控制器都支持所有注释，但本文档很好地指出了哪些注释受许多流行的 ingress 控制器支持。

TLS

此图表将有助于创建用于 ingress 控制器的 TLS 密钥，但这并非必需的。有四种常见用例

• Helm 根据参数生成/管理证书密钥。
• 用户单独生成/管理证书。
• Helm 创建自签名证书并生成/管理证书密钥。
• 一个额外的工具（如 cert-manager）管理应用程序的密钥。在前两种情况下，需要证书和密钥。我们希望它们看起来像这样

• 证书文件应该看起来像（如果存在证书链，则可以有多个证书）

  复制

  -----BEGIN CERTIFICATE-----
  MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
  ...
  jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7
  -----END CERTIFICATE-----

• 密钥应该看起来像

  复制

  -----BEGIN RSA PRIVATE KEY-----
  MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4
  ...
  wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc=
  -----END RSA PRIVATE KEY-----

• 如果您打算使用 Helm 根据参数管理证书，请将这些值复制到给定 server.ingress.secrets 条目的 certificate 和 key 值中。
• 如果您打算单独管理 TLS 密钥，请使用名称 INGRESS_HOSTNAME-tls 创建一个 TLS 密钥（其中 INGRESS_HOSTNAME 是一个占位符，将替换为您使用 server.ingress.hostname 参数设置的主机名），并在 server.ingress.secrets 中仅提供其名称，而无需 certificate 和 key 条目。
• 要使用 Helm 创建的自签名证书，请将 server.ingress.tls 设置为 true，并将 server.ingress.certManager 设置为 false。
• 如果您的集群具有 cert-manager 附加组件来自动管理和颁发 TLS 证书，请将 server.ingress.certManager 布尔值设置为 true 以启用 cert-manager 的相应注释。

设置 Pod 的亲和性

此图表允许您使用 XXX.affinity 参数设置自定义亲和性。在 kubernetes 文档 中查找有关 Pod 亲和性的更多信息。

或者，您可以使用 bitnami/common 图表中提供的 Pod 亲和性、Pod 反亲和性和节点亲和性的预设配置。为此，请设置 XXX.podAffinityPreset、XXX.podAntiAffinityPreset 或 XXX.nodeAffinityPreset 参数。

参数

全局参数

通用参数

Dataflow 服务器参数

Dataflow Skipper 参数

部署器参数

RBAC 参数

指标参数

初始化容器参数

数据库参数

RabbitMQ 图表参数

Kafka 图表参数

使用 --set key=value[,key=value] 参数为 helm install 指定每个参数。例如，

helm install my-release --set server.replicaCount=2 oci://REGISTRY_NAME/REPOSITORY_NAME/spring-cloud-dataflow

注意：您需要将占位符 REGISTRY_NAME 和 REPOSITORY_NAME 替换为对您的 Helm 图表注册表和存储库的引用。例如，在 Bitnami 的情况下，您需要使用 REGISTRY_NAME=registry-1.docker.io 和 REPOSITORY_NAME=bitnamicharts。

上述命令安装了具有 2 个 Dataflow 服务器副本的 Spring Cloud Data Flow 图表。

或者，可以在安装图表时提供一个 YAML 文件，其中指定了参数的值。例如，

helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/spring-cloud-dataflow

注意：您需要将占位符 REGISTRY_NAME 和 REPOSITORY_NAME 替换为对您的 Helm 图表注册表和存储库的引用。例如，在 Bitnami 的情况下，您需要使用 REGISTRY_NAME=registry-1.docker.io 和 REPOSITORY_NAME=bitnamicharts。 提示：您可以使用默认的 values.yaml

故障排除

在本故障排除指南中查找有关如何处理与 Bitnami Helm 图表相关的常见错误的更多信息。

升级

如果您启用了 RabbitMQ 图表作为 Skipper 用于管理流内容的消息传递解决方案，则在升级时需要设置 rabbitmq.auth.password 和 rabbitmq.auth.erlangCookie 参数，以便准备/活动探测正常工作。检查 RabbitMQ 密钥以获取密码和 Erlang Cookie，然后您可以使用以下命令升级图表

到 28.0.0

此主要版本将 RabbitMQ 子图表更新到其最新主要版本 14.0.0。此处您可以找到有关该版本中引入的更改的更多信息。

到 27.0.0

此主要版本更改了以下安全默认值

• runAsGroup 从 0 更改为 1001
• readOnlyRootFilesystem 设置为 true
• resourcesPreset 从 none 更改为在我们的测试套件中工作的最小大小（注意：resourcesPreset 不适用于生产环境，而应使用适合您的用例的 resources）。
• global.compatibility.openshift.adaptSecurityContext 从 disabled 更改为 auto。

这可能会破坏部署中使用的任何自定义或初始化脚本。如果是这种情况，请将默认值更改为以前的值。

此外，此主要版本将 MariaDB 图表版本提升至 18.x.x；升级过程中预计不会出现重大问题。

到 25.0.0

此主要版本将 Kafka 子图表更新到其最新主要版本 26.0.0。有关此子图表主要版本的更多信息，请参阅Kafka 升级说明。

到 24.0.0

此主要版本将 MariaDB 版本提升至 11.1。升级过程中预计不会出现重大问题。

到 23.0.0

此主要版本将 Kafka 子图表更新到其最新主要版本 25.0.0。有关此子图表主要版本的更多信息，请参阅Kafka 升级说明。

到 22.0.0

此主要更新将 Kafka 子图表更新到其最新主要版本 24.0.0。此新版本重构了 Kafka 图表架构，并且在升级过程中需要手动操作。有关此子图表主要版本的更多信息，请参阅Kafka 升级说明。

影响 spring-cloud-dataflow 图表默认值的最显着变化是

• 值 kafka.replicaCount 已重命名为 kafka.controller.replicaCount。
• 默认值为 1 的值 kafka.offsetsTopicReplicationFactor 现在使用新值 kafka.extraConfig 进行配置。

到 18.0.0

此主要更新将 Kafka 子图表更新到其最新主要版本 22.0.0。此新版本的 Kafka 默认使用 Kraft。有关此子图表主要版本的更多信息，请参阅Kafka 升级说明。

到 17.0.0

此主要版本将 MariaDB 版本提升至 10.11。请按照上游说明从 MariaDB 10.6 升级到 10.11。升级过程中预计不会出现重大问题。

到 16.0.0

此主要更新将 Kafka 子图表更新到其最新主要版本 21.0.0。此处您可以找到有关该版本中引入的更改的更多信息。

到 15.0.0

此主要更新将 Kafka 子图表更新到其最新主要版本 20.0.0。此处您可以找到有关该版本中引入的更改的更多信息。

到 14.0.0

此主要更新将 RabbitMQ 子图表更新到其最新主要版本 11.0.0。此处您可以找到有关该版本中引入的更改的更多信息。

到 13.0.0

此主要更新将 Kafka 子图表更新到其最新主要版本 19.0.0。有关此子图表主要版本的更多信息，请参阅Kafka 升级说明。

到 12.0.0

此主要更新将 Kafka 子图表更新到其最新主要版本 18.0.0。升级过程中预计不会出现重大问题。

到 11.0.0

此图表将 RabbitMQ 版本提升至 3.10.x。升级过程中预计不会出现问题。

到 10.0.0

此主要更新将 Kafka 子图表更新到其最新主要版本 17.0.0。升级过程中预计不会出现重大问题。

到 9.0.0

此主要更新将 RabbitMQ 子图表更新到其最新主要版本 9.0.0。此处您可以找到有关该版本中引入的更改的更多信息。

到 8.0.0

此主要版本将 MariaDB 版本提升至 10.6。请遵循上游说明从 MariaDB 10.5 升级到 10.6。升级过程中预计不会出现重大问题。

到 7.0.0

此主要版本将 Kafka 子图表更新到其最新主要版本 16.0.0。此处您可以找到有关该版本中引入的更改的更多信息。

到 6.0.0

此主要版本将 Kafka 子图表更新到其最新主要版本 15.x.x，其中包含对支持值的若干更改，并将 Kafka 主要版本提升到 3.x 系列（查看升级说明以获取更多信息）。

要使用 Kafka 作为消息传递解决方案从 5.x 升级到 6.0.0，应通过维护 Kafka 2.x 系列来完成。为此，请按照以下说明操作（以下示例假设版本名称为 scdf，版本命名空间为 default）

1. 获取当前版本中的凭据

   复制

   export MARIADB_ROOT_PASSWORD=$(kubectl get secret --namespace default scdf-mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 -d)
   export MARIADB_PASSWORD=$(kubectl get secret --namespace default scdf-mariadb -o jsonpath="{.data.mariadb-password}" | base64 -d)

2. 使用相同的 Kafka 版本升级您的版本

   复制

   $ export CURRENT_KAFKA_VERSION=$(kubectl exec scdf-kafka-0 -- bash -c 'echo $BITNAMI_IMAGE_VERSION')
   helm upgrade scdf oci://REGISTRY_NAME/REPOSITORY_NAME/spring-cloud-dataflow \
     --set rabbitmq.enabled=false \
     --set kafka.enabled=true \
     --set kafka.image.tag=$CURRENT_KAFKA_VERSION \
     --set mariadb.auth.password=$MARIADB_PASSWORD \
     --set mariadb.auth.rootPassword=$MARIADB_ROOT_PASSWORD

   注意：您需要将占位符 REGISTRY_NAME 和 REPOSITORY_NAME 替换为对您的 Helm 图表注册表和存储库的引用。例如，在 Bitnami 的情况下，您需要使用 REGISTRY_NAME=registry-1.docker.io 和 REPOSITORY_NAME=bitnamicharts。

到 5.0.0

此主要版本重命名了此图表中的多个值并添加了缺少的功能，以便与 Bitnami 图表存储库中的其余资产保持一致。

受影响的值

• serviceMonitor.extraLabels 重命名为 serviceMonitor.labels。
• server.strategyType 和 skikker.strategyType 已分别替换为 server.updateStrategy 和 skikker.updateStrategy。虽然 strategyType 被解释为字符串，但 updateStrategy 被解释为对象。
• 服务帐户令牌现在默认设置为自动挂载 false。要更改此设置，请将值 serviceAccount.automountServiceAccountToken 设置为 true。

此外，MariaDB 子图表也更新到了最新的主要版本 10.0.0，其中包含类似的更改。您可以在此处找到有关此版本中引入的更改的更多信息。

到 4.0.0

此主要版本将 Kafka 子图表更新为其最新的主要版本 14.0.0。您可以在此处找到有关此版本中引入的更改的更多信息。

到 3.0.0

此主要版本将 Kafka 子图表更新为其最新的主要版本 13.0.0。有关此子图表主要版本的更多信息，请参阅kafka 升级说明。

到 2.0.0

2020 年 11 月 13 日，Helm v2 支持正式结束，此主要版本是对 Helm Chart 应用必要更改的结果，以便能够合并 Helm v3 中添加的不同功能，并与 Helm 项目本身保持一致，关于 Helm v2 EOL。

此主要版本中引入了哪些更改？

• 此 Helm Chart 的先前版本使用 apiVersion: v1（可由 Helm 2 和 3 安装），此 Helm Chart 已更新为 apiVersion: v2（仅可由 Helm 3 安装）。您可以在此处找到有关 apiVersion 字段的更多信息。
• 将依赖项信息从 requirements.yaml 移动到 Chart.yaml
• 运行 helm dependency update 后，将生成一个 Chart.lock 文件，其中包含与先前 requirements.lock 中使用的结构相同的结构
• Chart.yaml 文件中存在的不同字段已按字母顺序以统一的方式为所有 Bitnami Helm Charts 排序

升级到此版本时的注意事项

• 如果您想从使用 Helm v3 安装的先前版本升级到此版本，则应该不会遇到任何问题。
• 如果您想使用 Helm v2 升级到此版本，则不支持此方案，因为此版本不再支持 Helm v2。
• 如果您使用 Helm v2 安装了先前版本，并且想使用 Helm v3 升级到此版本，请参阅有关从 Helm v2 迁移到 v3 的官方 Helm 文档。

有用链接

• https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-resolve-helm2-helm3-post-migration-issues-index.html
• https://helm.kubernetes.ac.cn/docs/topics/v2_v3_migration/
• https://helm.kubernetes.ac.cn/blog/migrate-from-helm-v2-to-helm-v3/

v0.x.x

helm upgrade my-release oci://REGISTRY_NAME/REPOSITORY_NAME/spring-cloud-dataflow --set mariadb.rootUser.password=[MARIADB_ROOT_PASSWORD] --set rabbitmq.auth.password=[RABBITMQ_PASSWORD] --set rabbitmq.auth.erlangCookie=[RABBITMQ_ERLANG_COOKIE]

注意：您需要将占位符 REGISTRY_NAME 和 REPOSITORY_NAME 替换为对您的 Helm 图表注册表和存储库的引用。例如，在 Bitnami 的情况下，您需要使用 REGISTRY_NAME=registry-1.docker.io 和 REPOSITORY_NAME=bitnamicharts。

v1.x.x

helm upgrade my-release oci://REGISTRY_NAME/REPOSITORY_NAME/spring-cloud-dataflow --set mariadb.auth.rootPassword=[MARIADB_ROOT_PASSWORD] --set rabbitmq.auth.password=[RABBITMQ_PASSWORD] --set rabbitmq.auth.erlangCookie=[RABBITMQ_ERLANG_COOKIE]

注意：您需要将占位符 REGISTRY_NAME 和 REPOSITORY_NAME 替换为对您的 Helm 图表注册表和存储库的引用。例如，在 Bitnami 的情况下，您需要使用 REGISTRY_NAME=registry-1.docker.io 和 REPOSITORY_NAME=bitnamicharts。

到 1.0.0

MariaDB 依赖项版本已升级到引入多个不兼容性的新主版本。因此，除非使用外部数据库，否则不保证向后兼容性。查看MariaDB 升级说明了解更多信息。

要升级到1.0.0，您需要重用用于保存先前版本中 MariaDB 数据的 PVC。为此，请按照以下说明操作（以下示例假设版本名称为dataflow）

注意：在执行任何这些操作之前，请创建数据库备份。

获取凭据以及用于在当前版本上保存 MariaDB 数据的 PVC 的名称

export MARIADB_ROOT_PASSWORD=$(kubectl get secret --namespace default dataflow-mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 -d)
export MARIADB_PASSWORD=$(kubectl get secret --namespace default dataflow-mariadb -o jsonpath="{.data.mariadb-password}" | base64 -d)
export MARIADB_PVC=$(kubectl get pvc -l app=mariadb,component=master,release=dataflow -o jsonpath="{.items[0].metadata.name}")
export RABBITMQ_PASSWORD=$(kubectl get secret --namespace default dataflow-rabbitmq -o jsonpath="{.data.rabbitmq-password}" | base64 -d)
export RABBITMQ_ERLANG_COOKIE=$(kubectl get secret --namespace default dataflow-rabbitmq -o jsonpath="{.data.rabbitmq-erlang-cookie}" | base64 -d)

升级您的版本（保持版本不变），禁用 MariaDB 并将数据流副本缩减为 0

helm upgrade dataflow oci://REGISTRY_NAME/REPOSITORY_NAME/spring-cloud-dataflow --version 0.7.4 \
  --set server.replicaCount=0 \
  --set skipper.replicaCount=0 \
  --set mariadb.enabled=false \
  --set rabbitmq.auth.password=$RABBITMQ_PASSWORD \
  --set rabbitmq.auth.erlangCookie=$RABBITMQ_ERLANG_COOKIE

注意：您需要将占位符 REGISTRY_NAME 和 REPOSITORY_NAME 替换为对您的 Helm 图表注册表和存储库的引用。例如，在 Bitnami 的情况下，您需要使用 REGISTRY_NAME=registry-1.docker.io 和 REPOSITORY_NAME=bitnamicharts。

最后，将您的版本升级到 1.0.0，重复使用现有的 PVC，并重新启用 MariaDB

helm upgrade dataflow oci://REGISTRY_NAME/REPOSITORY_NAME/spring-cloud-dataflow \
  --set mariadb.primary.persistence.existingClaim=$MARIADB_PVC \
  --set mariadb.auth.rootPassword=$MARIADB_ROOT_PASSWORD \
  --set mariadb.auth.password=$MARIADB_PASSWORD \
  --set rabbitmq.auth.password=$RABBITMQ_PASSWORD \
  --set rabbitmq.auth.erlangCookie=$RABBITMQ_ERLANG_COOKIE

注意：您需要将占位符 REGISTRY_NAME 和 REPOSITORY_NAME 替换为对您的 Helm 图表注册表和存储库的引用。例如，在 Bitnami 的情况下，您需要使用 REGISTRY_NAME=registry-1.docker.io 和 REPOSITORY_NAME=bitnamicharts。

您应该会在 MariaDB 容器日志中看到以下几行

$ kubectl logs $(kubectl get pods -l app.kubernetes.io/instance=dataflow,app.kubernetes.io/name=mariadb,app.kubernetes.io/component=primary -o jsonpath="{.items[0].metadata.name}")
...
mariadb 12:13:24.98 INFO  ==> Using persisted data
mariadb 12:13:25.01 INFO  ==> Running mysql_upgrade
...

许可证

版权所有 © 2024 Broadcom。“Broadcom”一词指的是 Broadcom Inc. 和/或其子公司。

根据 Apache 许可证 2.0 版（“许可证”）获得许可；除非符合许可证，否则您不得使用此文件。您可以在以下网址获取许可证副本：

https://apache.ac.cn/licenses/LICENSE-2.0

除非适用法律要求或书面同意，否则根据许可证分发的软件按“原样”分发，不提供任何明示或暗示的保证或条件。有关许可证下许可和限制的特定语言，请参阅许可证。

预期输出

发出 helm install 命令后，您应该会看到类似于以下内容的输出

NAME: my-release
LAST DEPLOYED: Sun Nov 22 21:12:29 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
** Please be patient while the chart is being deployed **

Spring Cloud Data Flow 图表是使用以下组件部署的

• Spring Cloud Data Flow 服务器
• Spring Cloud Skipper 服务器

您可以通过集群内的以下 DNS 名称访问 Spring Cloud Data Flow

my-release-spring-cloud-dataflow-server.default.svc.cluster.local (port 8080)

要从集群外部访问 Spring Cloud Data Flow 仪表板，请运行以下命令

1. 通过运行以下命令获取 Data Flow 仪表板 URL

   export SERVICEPORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].port}" services my-release-spring-cloud-dataflow-server) kubectl port-forward --namespace default svc/my-release-spring-cloud-dataflow-server ${SERVICEPORT}:${SERVICEPORT} & echo "http://127.0.0.1:${SERVICEPORT}/dashboard"

2. 打开浏览器并使用获取的 URL 访问 Data Flow 仪表板。

--set server.service.type=ServiceType

minikube service --url my-release-spring-cloud-dataflow-server

您现在已经在 Kubernetes 集群的默认命名空间中创建了一个新版本。应用程序及其所需服务需要几分钟才能启动。您可以通过发出 kubectl get pod -w 命令来检查状态。您需要等待 READY 列为所有 pod 显示 1/1。

当所有 pod 都准备就绪后，您可以通过访问 http://<SERVICE_ADDRESS>/dashboard 来访问 Spring Cloud Data Flow 仪表板，其中 <SERVICE_ADDRESS> 是之前显示的 kubectl 或 minikube 命令返回的地址。

版本兼容性

以下列表显示了 Spring Cloud Data Flow 与相应 Helm Chart 版本的版本兼容性

注册预构建应用程序

所有预构建的流应用程序

• 都可作为 Apache Maven 工件或 Docker 镜像使用。
• 使用 RabbitMQ 或 Apache Kafka。
• 支持通过 Prometheus 和 InfluxDB 进行监控。
• 包含用于 UI 中的应用程序属性的元数据以及 shell 中的代码补全。

您可以使用 app register 功能单独注册应用程序，也可以使用 app import 功能批量注册应用程序。还有一些 dataflow.spring.io 链接，它们代表特定版本的预构建应用程序组，这对于入门很有用。

您可以使用 UI 或 shell 注册应用程序。即使我们只使用两个预构建的应用程序，我们也会注册全套的预构建应用程序。

在 Kubernetes 上安装 Data Flow 的最简单方法是使用 Helm 图表，该图表使用 RabbitMQ 作为默认的消息中间件。导入 RabbitMQ 版本应用程序的命令如下

dataflow:>app import --uri https://dataflow.springframework.org.cn/rabbitmq-docker-latest

如果您在 Helm 图表中设置了 kafka.enabled=true，或者按照基于手动 kubectl 的安装说明在 Kubernetes 上安装 Data Flow 并选择使用 Kafka 作为消息中间件，请将上述 URL 中的 rabbitmq 更改为 kafka。

app register --type source --name time --uri docker://springcloudstream/time-source-rabbit:{docker-time-source-rabbit-version} --metadata-uri maven://org.springframework.cloud.stream.app:time-source-rabbit:jar:metadata:{docker-time-source-rabbit-version}

应用程序和服务器属性

本节介绍如何自定义应用程序的部署。您可以使用许多属性来影响已部署应用程序的设置。属性可以按每个应用程序应用，也可以在所有已部署应用程序的相应服务器配置中应用。

所有已部署任务的属性定义在 src/kubernetes/server/server-config.yaml 文件中，Streams 的属性定义在 src/kubernetes/skipper/skipper-config-(binder).yaml 文件中。将 (binder) 替换为您正在使用的消息中间件，例如 rabbit 或 kafka。

内存和 CPU 设置

应用程序使用默认的内存和 CPU 设置进行部署。如果需要，可以调整这些值。以下示例显示如何将 Limits 设置为 CPU 的 1000m 和内存的 1024Mi，并将 Requests 设置为 CPU 的 800m 和内存的 640Mi

deployer.<app>.kubernetes.limits.cpu=1000m
deployer.<app>.kubernetes.limits.memory=1024Mi
deployer.<app>.kubernetes.requests.cpu=800m
deployer.<app>.kubernetes.requests.memory=640Mi

这些值将导致使用以下容器设置

Limits:
cpu: 1
memory: 1Gi
Requests:
cpu: 800m
memory: 640Mi

您还可以控制全局设置 cpu 和 memory 的默认值。

以下示例显示如何设置 Streams 和 Tasks 的 CPU 和内存

data:
  application.yaml: |-
    spring:
      cloud:
        skipper:
          server:
            platform:
              kubernetes:
                accounts:
                  default:
                    limits:
                      memory: 640mi
                      cpu: 500m

data:
  application.yaml: |-
    spring:
      cloud:
        dataflow:
          task:
            platform:
              kubernetes:
                accounts:
                  default:
                    limits:
                      memory: 640mi
                      cpu: 500m

到目前为止，我们使用的设置仅影响容器的设置。它们不会影响容器中 JVM 进程的内存设置。如果要设置 JVM 内存设置，可以提供一个环境变量来实现。有关详细信息，请参阅下一节。

环境变量

要影响给定应用程序的环境设置，可以使用 spring.cloud.deployer.kubernetes.environmentVariables 部署器属性。例如，生产环境中的一个常见需求是影响 JVM 内存参数。您可以使用 JAVA_TOOL_OPTIONS 环境变量来实现，如下所示

deployer.<app>.kubernetes.environmentVariables=JAVA_TOOL_OPTIONS=-Xmx1024m

spring.cloud.deployer.kubernetes.environmentVariables=spring.cloud.stream.kafka.binder.brokers='somehost:9092, anotherhost:9093'

这样做会覆盖所需 <app> 的 JVM 内存设置（将 <app> 替换为应用程序的名称）。

活跃性和就绪性探针

liveness 和 readiness 探针分别使用名为 /health 和 /info 的路径。它们都使用 10 的 delay，以及分别使用 60 和 10 的 period。您可以在部署流时使用部署器属性更改这些默认值。活跃性和就绪性探针仅适用于 Streams。

以下示例通过设置部署程序属性来更改 liveness 探针（将 <app> 替换为您的应用程序名称）

deployer.<app>.kubernetes.livenessProbePath=/health
deployer.<app>.kubernetes.livenessProbeDelay=120
deployer.<app>.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.<app>.kubernetes.readinessProbePort=7000
deployer.<app>.kubernetes.livenessProbePort=7000

您可以按如下方式将相同内容声明为流的全局配置的一部分

data:
  application.yaml: |-
    spring:
      cloud:
        skipper:
          server:
            platform:
              kubernetes:
                accounts:
                  default:
                    readinessProbePort: 7000
                    livenessProbePort: 7000

deployer.<app>.kubernetes.livenessProbePath=/health
deployer.<app>.kubernetes.readinessProbePath=/info

要针对每个应用程序自动将 liveness 和 readiness 端点设置为默认的 Spring Boot 1.x 路径，您可以设置以下属性

deployer.<app>.kubernetes.bootMajorVersion=1

您可以使用存储在 Kubernetes 密钥 中的凭据来访问受保护的探测端点。您可以使用现有密钥，前提是凭据包含在密钥 data 块的 credentials 密钥名称下。您可以在每个应用程序的基础上配置探测身份验证。启用后，它将使用相同的凭据和身份验证类型应用于 liveness 和 readiness 探测端点。目前，仅支持 Basic 身份验证。

要创建新密钥，请执行以下操作

1. 使用用于访问受保护探测端点的凭据生成 base64 字符串。

   基本身份验证以 username:password 格式将用户名和密码编码为 base64 字符串。

   以下示例（包括输出，您应该将 user 和 pass 替换为您的值）显示了如何生成 base64 字符串

   复制

   echo -n "user:pass" | base64
   dXNlcjpwYXNz

2. 使用编码后的凭据，创建一个文件（例如，myprobesecret.yml），其中包含以下内容

   复制

   apiVersion: v1
   kind: Secret
   metadata:
   name:
   myprobesecret type:
   Opaque data:
   credentials: GENERATED_BASE64_STRING

3. 将 GENERATED_BASE64_STRING 替换为之前生成的 base64 编码值。

4. 使用 kubectl 创建密钥，如下所示

   复制

   kubectl create -f ./myprobesecret.yml
   secret "myprobesecret" created

5. 设置以下部署程序属性以在访问探测端点时使用身份验证，如下所示

   复制

   deployer.<app>.kubernetes.probeCredentialsSecret=myprobesecret

   将 <app> 替换为要应用身份验证的应用程序的名称。

使用 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"
          }
        }
      }
    }

私有 Docker 镜像仓库

您可以针对每个应用程序从私有镜像仓库中提取 Docker 镜像。首先，您必须在集群中创建一个密钥。请按照 从私有镜像仓库中提取镜像 指南创建密钥。

创建密钥后，您可以使用 imagePullSecret 属性设置要使用的密钥，如下所示

deployer.<app>.kubernetes.imagePullSecret=mysecret

将 <app> 替换为您的应用程序名称，并将 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 替换为您之前创建的密钥名称。

卷挂载密钥

Data Flow 使用存储在容器镜像标签中的应用程序元数据。要访问私有注册表中的元数据标签，您必须扩展 Data Flow 部署配置并将注册表密钥挂载为密钥属性源

    spec:
      containers:
      - name: scdf-server
        ...
        volumeMounts:
          - name: mysecret
            mountPath: /etc/secrets/mysecret
            readOnly: true
        ...
      volumes:
        - name: mysecret
          secret:
            secretName: mysecret

注解

您可以为每个应用程序添加 Kubernetes 对象的注解。支持的对象类型为 pod Deployment、Service 和 Job。注解以 key:value 格式定义，允许多个注解之间用逗号分隔。有关注解的更多信息和用例，请参阅注解。

以下示例展示了如何配置应用程序以使用注解

deployer.<app>.kubernetes.podAnnotations=annotationName:annotationValue
deployer.<app>.kubernetes.serviceAnnotations=annotationName:annotationValue,annotationName2:annotationValue2
deployer.<app>.kubernetes.jobAnnotations=annotationName:annotationValue

将 <app> 替换为您的应用程序名称和注解的值。

入口点样式

入口点样式会影响应用程序属性传递到要部署的容器的方式。当前支持三种样式

• exec（默认）：在部署请求中将所有应用程序属性和命令行参数作为容器参数传递。应用程序属性将转换为 --key=value 的格式。
• shell：将所有应用程序属性和命令行参数作为环境变量传递。每个应用程序和命令行参数属性都将转换为大写字符串，并将 . 字符替换为 _。
• boot：创建一个名为 SPRING_APPLICATION_JSON 的环境变量，其中包含所有应用程序属性的 JSON 表示形式。部署请求中的命令行参数将设置为容器参数。

您可以按如下方式配置应用程序

deployer.<app>.kubernetes.entryPointStyle=<Entry Point Style>

将 <app> 替换为您的应用程序名称，并将 <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 作为入口点样式，以对应于容器 Dockerfile 中 ENTRYPOINT 语法的定义方式。有关 exec 与 shell 的更多信息和用例，请参阅 Docker 文档的 ENTRYPOINT 部分。

使用 boot 入口点样式对应于使用 exec 样式的 ENTRYPOINT。部署请求中的命令行参数将传递到容器，并将应用程序属性映射到 SPRING_APPLICATION_JSON 环境变量而不是命令行参数。

部署服务帐户

您可以通过属性为应用程序部署配置自定义服务帐户。您可以使用现有服务帐户或创建新服务帐户。创建服务帐户的一种方法是使用 kubectl，如下所示

kubectl create serviceaccount myserviceaccountname
serviceaccount "myserviceaccountname" created

然后，您可以配置单个应用程序，如下所示

deployer.<app>.kubernetes.deploymentServiceAccountName=myserviceaccountname

将 <app> 替换为您的应用程序名称，并将 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 替换为要应用于所有部署的服务帐户名称。

镜像拉取策略

镜像拉取策略定义了何时应将 Docker 镜像拉取到本地注册表。目前，支持三种策略

• IfNotPresent（默认）：如果镜像已存在，则不拉取。
• Always：始终拉取镜像，无论它是否已存在。
• Never：从不拉取镜像。仅使用已存在的镜像。

以下示例显示了如何单独配置应用程序

deployer.<app>.kubernetes.imagePullPolicy=Always

将 <app> 替换为您的应用程序名称，并将 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 替换为您所需的镜像拉取策略。

部署标签

您可以在与 Deployment 相关的对象上设置自定义标签。有关标签的更多信息，请参阅 标签。标签以 键:值 格式指定。

以下示例显示了如何单独配置应用程序

deployer.<app>.kubernetes.deploymentLabels=myLabelName:myLabelValue

将 <app> 替换为您的应用程序名称，将 myLabelName 替换为您的标签名称，并将 myLabelValue 替换为您的标签值。

此外，您还可以应用多个标签，如下所示

deployer.<app>.kubernetes.deploymentLabels=myLabelName:myLabelValue,myLabelName2:myLabelValue2

NodePort

应用程序使用 Service 类型 ClusterIP 进行部署，这是默认的 Kubernetes Service 类型（除非另有定义）。ClusterIP 服务只能从集群内部访问。

要将已部署的应用程序公开到外部，一种选择是使用 NodePort。有关更多信息，请参阅 NodePort 文档。

以下示例展示了如何使用 Kubernetes 分配的端口单独配置应用程序

deployer.<app>.kubernetes.createNodePort=true

将 <app> 替换为您的应用程序名称。

此外，您可以定义用于 NodePort Service 的端口，如下所示

deployer.<app>.kubernetes.createNodePort=31101

将 <app> 替换为您的应用程序名称，并将 31101 的值替换为您想要的端口。

监控

要详细了解在 Kubernetes 上运行 Prometheus 的数据流中的监控体验，请参阅流监控或任务监控指南。