管理 Workflow

• 1: 调整组件设置
• 2: 配置 DNS
• 3: 部署钩子
• 4: 平台日志
• 5: 平台监控
• 6: 升级 Workflow
• 7: 生产部署

1 - 调整组件设置

在添加 Drycc Chart Repository 后，您可以在使用 helm install 完成安装之前，使用 helm inspect values drycc/workflow > values.yaml 来自定义图表。

有几种方法可以自定义相应组件：

• 如果值在上面派生的 values.yaml 文件中暴露，可以修改组件的部分来调整这些设置。修改的值将在图表安装或发布升级时通过以下两个相应命令之一生效：

   $ helm install drycc oci://registry.drycc.cc/charts/workflow \
       -n drycc \
       --namespace drycc \
       -f values.yaml
   $ helm upgrade drycc oci://registry.drycc.cc/charts/workflow \
       -n drycc \
       --namespace drycc \
       -f values.yaml
  

• 如果值尚未在 values.yaml 文件中暴露，可以编辑组件部署以调整设置。这里我们编辑 drycc-controller 部署：

   $ kubectl --namespace drycc edit deployment drycc-controller
  

  在 env 部分下通过适当的环境变量和值添加/编辑设置并保存。更新后的部署将使用新的/修改的设置重新创建组件 pod。

• 最后，可以获取并编辑版本控制/图表仓库本身提供的图表：

   $ helm fetch oci://registry.drycc.cc/charts/workflow --untar
   $ $EDITOR workflow/charts/controller/templates/controller-deployment.yaml
  

  然后运行 helm install ./workflow --namespace drycc --name drycc 来应用更改，或者如果集群已经在运行，则运行 helm upgrade drycc ./workflow。

设置资源限制

您可以通过修改之前获取的 values.yaml 文件来为 Workflow 组件设置资源限制。此文件为每个 Workflow 组件都有一个部分。要为任何 Workflow 组件设置限制，只需在部分中添加 resources 并将其设置为适当的值。

以下是设置了 CPU 和内存限制的 values.yaml 中 builder 部分的样子示例：

builder:
  imageOrg: "drycc"
  imagePullPolicy: "Always"
  imageTag: "canary"
  resources:
    limits:
      cpu: 1000m
      memory: 2048Mi
    requests:
      cpu: 500m
      memory: 1024Mi

自定义 Builder

Builder 组件可以调整以下环境变量：

自定义 Controller

Controller 组件可以调整以下环境变量：

LDAP 认证设置

LDAP 认证的配置选项详细说明此处。

Passport 组件中启用用户账户 LDAP 认证的可用环境变量如下：

全局和每个应用程序设置

有关这些的更多详细信息，请参阅[部署应用][]指南。

自定义数据库

Database 组件可以调整以下环境变量：

自定义 Fluentbit

以下值可以在 values.yaml 文件中更改，或使用 Helm CLI 的 --values 标志。

有关可以设置的各种变量的更多信息，请参阅 fluentbit。

自定义监控

Grafana

我们直接在图表中暴露了一些更有用的配置值。这允许使用 values.yaml 文件或 Helm CLI 的 --set 标志来设置它们。您可以在下面看到这些选项：

有关可以使用环境变量设置的其他选项列表，请参阅 Github 中的配置文件。

Victoriametrics

您可以在此处找到可以使用环境变量设置的值列表。

自定义注册表

Registry 组件可以通过遵循 distribution config doc 来调整。

2 - 配置 DNS

例如，假设 example.com 是集群的域：

• 控制器应该可以在 drycc.example.com 访问
• 应用程序应该默认可以在 <application name>.example.com 访问

鉴于这种情况，配置 DNS 的主要目标是将集群域的所有子域的流量定向到托管平台的路由器组件的集群节点，该组件能够将流量引导到集群内的正确端点。

使用负载均衡器

通常，建议使用 [load balancer][] 将入站流量定向到一个或多个路由器。在这种情况下，配置 DNS 就像在 DNS 中定义一个指向负载均衡器的通配符记录一样简单。

例如，假设域为 example.com：

• 枚举每个负载均衡器 IP 的 A 记录（即 DNS 轮询）
• 引用负载均衡器现有完全限定域名的 CNAME 记录
  • 根据 AWS 自己的文档，当使用 AWS Elastic Load Balancers 时，这是推荐策略，因为 ELB IP 可能会随时间变化。

对于使用"自定义域"（不是集群自己域的子域的完全限定域名）的任何应用程序的 DNS，可以通过创建引用上述通配符记录的 CNAME 记录来配置。

虽然这取决于您的 Kubernetes 发行版和底层基础设施，但在许多情况下，可以使用 kubectl 工具直接确定负载均衡器的 IP 或现有完全限定域名：

$ kubectl --namespace=istio-nginx describe service | grep "LoadBalancer"
LoadBalancer Ingress:	a493e4e58ea0511e5bb390686bc85da3-1558404688.us-west-2.elb.amazonaws.com

LoadBalancer Ingress 字段通常描述现有域名或公共 IP。请注意，如果 Kubernetes 能够为您自动提供负载均衡器，它会异步执行此操作。如果在 Workflow 安装后不久发出上述命令，负载均衡器可能尚不存在。

没有负载均衡器

在某些平台（例如 Minikube）上，提供负载均衡器不是一件容易或实际的事情。在这些情况下，可以直接识别托管路由器 pod 的 Kubernetes 节点的公共 IP，并使用该信息来配置本地 /etc/hosts 文件。

因为通配符条目在本地 /etc/hosts 文件中不起作用，使用此策略可能导致频繁编辑该文件，为添加到该集群的每个应用程序添加集群的完全限定子域。因此，更可行的选项可能是利用 xip.io 服务。

一般来说，对于任何 IP a.b.c.d，完全限定域名 any-subdomain.a.b.c.d.xip.io 将解析为 IP a.b.c.d。这可能非常有用。

首先，使用 kubectl 查找托管路由器实例的节点：

$ kubectl --namespace=istio-ingress describe pod | grep Node:
Node:       ip-10-0-0-199.us-west-2.compute.internal/10.0.0.199
Node:       ip-10-0-0-198.us-west-2.compute.internal/10.0.0.198

该命令将显示每个路由器 pod 的信息。对于每个，Node 字段中显示节点名称和 IP。如果这些字段中出现的 IP 是公共的，则可以使用其中任何一个来配置您的本地 /etc/hosts 文件，或与 xip.io 一起使用。如果显示的 IP 不是公共的，则可能需要进一步调查。

您可以使用 kubectl 列出节点的 IP 地址：

$ kubectl describe node ip-10-0-0-199.us-west-2.compute.internal
# ...
Addresses:	10.0.0.199,10.0.0.199,54.218.85.175
# ...

在这里，Addresses 字段列出了节点的所有 IP。如果其中任何一个是公共的，则可以再次使用它们来配置您的本地 /etc/hosts 文件，或与 xip.io 一起使用。

教程：使用 Google Cloud DNS 配置 DNS

在本节中，我们将描述如何配置 Google Cloud DNS 以将您的域名路由到您的 Drycc 集群。

在本节中，我们假设以下内容：

• 您的入口服务前面有一个负载均衡器。
  • 负载均衡器不必基于云，它只需要提供稳定的 IP 地址或稳定的域名
• 您在注册商处注册了 mystuff.com 域名
  • 在以下说明中用您的域名替换 mystuff.com
• 您的注册商允许您更改域名的名称服务器（大多数注册商都这样做）

以下是配置云 DNS 以路由到您的 drycc 集群的步骤：

1. 获取负载均衡器 IP 或域名

• 如果您在 Google Container Engine 上，可以运行 kubectl get svc -n istio-ingress 并查找 LoadBalancer Ingress 列以获取 IP 地址

2. 创建新的 Cloud DNS Zone（在控制台上：Networking => Cloud DNS，然后点击 Create Zone）
3. 命名您的区域，并将 DNS 名称设置为 mystuff.com.（注意末尾的 .
4. 点击 Create 按钮
5. 在结果页面上点击 Add Record Set 按钮
6. 如果您的负载均衡器提供稳定的 IP 地址，请在结果表单中输入以下字段：
7. DNS Name: *
8. Resource Record Type: A
9. TTL: 您选择的 DNS TTL。如果您正在测试或预计您会随着时间推移拆除和重建许多 drycc 集群，我们推荐较低的 TTL
10. IPv4 Address: 您在第一步中获得的 IP
11. 点击 Create 按钮
12. 如果您的负载均衡器提供稳定的域名 lbdomain.com，请在结果表单中输入以下字段：
13. DNS Name: *
14. Resource Record Type: CNAME
15. TTL: 您选择的 DNS TTL。如果您正在测试或预计您会随着时间推移拆除和重建许多 drycc 集群，我们推荐较低的 TTL
16. Canonical name: lbdomain.com.（注意末尾的 .）
17. 点击 Create 按钮
18. 在您的域注册商中，将您的 mystuff.com 域的名称服务器设置为同一页面上 NS 记录的 data 列下的名称服务器。它们通常如下所示（注意尾随 . 字符）。

ns-cloud-b1.googledomains.com.
ns-cloud-b2.googledomains.com.
ns-cloud-b3.googledomains.com.
ns-cloud-b4.googledomains.com.

注意：如果您必须重新创建您的 drycc 集群，只需返回步骤 6.4 或 7.4（取决于您的负载均衡器）并将 IP 地址或域名更改为新值。您可能必须等待您设置的 TTL 到期。

测试

要测试流量是否到达其预期目的地，可以像这样向 Drycc 控制器发送请求（不要忘记尾随斜杠！）：

curl http://drycc.example.com/v2/

或：

curl http://drycc.54.218.85.175.xip.io/v2/

由于此类请求需要身份验证，以下响应应被视为成功的指标：

{"detail":"Authentication credentials were not provided."}

3 - 部署钩子

它有助于让开发团队了解部署情况，同时也可以用于将不同系统集成在一起。

设置一个或多个钩子后，钩子输出和错误会出现在您的Drycc Grafana应用程序日志中：

2011-03-15T15:07:29-07:00 drycc[api]: Deploy hook sent to http://drycc.rocks

部署钩子是一个通用的 HTTP 钩子。管理员可以通过 调整控制器设置 来创建和配置多个部署钩子。

HTTP POST 钩子

HTTP 部署钩子对 URL 执行 HTTP POST。请求中包含的参数与钩子消息中可用的变量相同：app、release、release_summary、sha 和 user。请参见下面的描述：

app=secure-woodland&release=v4&release_summary=gabrtv%20deployed%35b3726&sha=35b3726&user=gabrtv

可选地，如果通过 调整控制器设置 将部署钩子密钥添加到控制器，则 POST 请求中将存在新的 Authorization 标头。此标头的值是使用密钥作为密钥计算的请求 URL 的 HMAC 十六进制摘要。

为了验证此请求是否来自 Workflow，请使用密钥、完整 URL 和 HMAC-SHA1 哈希算法来计算签名。在 Python 中，这看起来像这样：

import hashlib
import hmac

hmac.new("my_secret_key", "http://drycc.rocks?app=secure-woodland&release=v4&release_summary=gabrtv%20deployed%35b3726&sha=35b3726&user=gabrtv", digestmod=hashlib.sha1).hexdigest()

如果计算的 HMAC 十六进制摘要的值和 Authorization 标头中的值相同，则请求来自 Workflow。

4 - 平台日志

我们正在与 Quickwit 合作，为您提供应用程序日志集群和搜索界面。

架构图

┌───────────┐                   ┌───────────┐
│ Container │                   │  Grafana  │
└───────────┘                   └───────────┘
      │                               ^
     log                              |
      │                               |
      ˅                               │
┌───────────┐                   ┌───────────┐
│ Fluentbit │─────otel/grpc────>│  Quickwit │
└───────────┘                   └───────────┘

默认配置

Fluent Bit 基于可插拔架构，其中不同的插件在数据管道中发挥主要作用，有 70 多个内置插件可用。 请参考 charts values.yaml 以获取特定配置。

5 - 平台监控

描述

我们现在为运行中的 Kubernetes 集群提供了一个监控堆栈，用于内省。该堆栈包括 4 个组件：

• kube-state-metrics，kube-state-metrics (KSM) 是一个简单的服务，它监听 Kubernetes API 服务器并生成关于对象状态的指标。
• Node Exporter，Prometheus 导出器，用于 *NIX 内核暴露的硬件和操作系统指标。
• Victoriametrics，一个 Cloud Native Computing Foundation 项目，是一个系统和服务监控系统。
• Grafana，时序数据的图形化工具

架构图

┌────────────────┐                                                        
│ HOST           │                                                        
│  node-exporter │◀──┐                          ┌──────────────────┐         
└────────────────┘   │                          │kube-state-metrics│         
                     │                          └──────────────────┘         
┌────────────────┐   │                                    ▲                    
│ HOST           │   │    ┌─────────────────┐             │                    
│  node-exporter │◀──┼────│ victoriametrics │─────────────┘                    
└────────────────┘   │    └─────────────────┘                                  
                     │             ▲                                         
┌───────────────┐    │             │                                         
│ HOST          │    │             ▼                                         
│  node-exporter│◀───┘       ┌──────────┐                                    
└───────────────┘            │ Grafana  │                                    
                             └──────────┘                                    

Grafana

Grafana 允许用户创建自定义仪表板，可视化捕获到运行中的 VictoriaMetrics 组件的数据。默认情况下，Grafana 通过路由器使用服务注解暴露在以下 URL：http://grafana.mydomain.com。默认登录是 admin/admin。如果您有兴趣更改这些值，请参阅[调整组件设置][]。

Grafana 将预加载几个仪表板，帮助操作员开始监控 Kubernetes 和 Drycc Workflow。这些仪表板旨在作为起点，并不包括生产安装中可能需要监控的每个项目。

Drycc Workflow 监控默认情况下不会将数据写入主机文件系统或长期存储。如果 Grafana 实例失败，修改的仪表板将丢失。

生产配置

生产安装的 Grafana 应尽可能更改以下配置值：

• 将默认用户名和密码从 admin/admin 更改。密码值以明文传递，因此最好在命令行上设置此值，而不是将其检入版本控制。
• 启用持久性
• 使用受支持的外部数据库，如 mysql 或 postgres。您可以在此处找到更多信息

集群内持久性

启用持久性将允许您的自定义配置在 pod 重启后保持。这意味着如果您升级 Workflow 安装，默认的 sqllite 数据库（存储会话和用户数据等）不会消失。

如果您希望为 Grafana 启用持久性，可以在运行 helm install 之前在 values.yaml 文件中将 enabled 设置为 true。

 grafana:
   # Configure the following ONLY if you want persistence for on-cluster grafana
   # GCP PDs and EBS volumes are supported only
   persistence:
     enabled: true # Set to true to enable persistence
     size: 5Gi # PVC size

集群外 Grafana

如果您希望提供自己的 Grafana 实例，可以在运行 helm install 之前在 values.yaml 文件中设置 grafana.enabled。

VictoriaMetrics

VictoriaMetrics 是一个快速且可扩展的开源时序数据库和监控解决方案，让用户无需扩展性问题和最小的运营负担即可构建监控平台，它与 prometheus 格式完全兼容。

集群内持久性

您可以在 values.yaml 中将 node-exporter 和 kube-state-metrics 设置为 true 或 false。 如果您希望为 VictoriaMetrics 启用持久性，可以在运行 helm install 之前在 values.yaml 文件中将 enabled 设置为 true。

victoriametrics:
  vmstorage:
    replicas: 3
    extraArgs:
    - --retentionPeriod=30d
    temporary:
      enabled: true
      size: 5Gi
      storageClass: "toplvm-ssd"
    persistence:
      enabled: true
      size: 10Gi
      storageClass: "toplvm-hdd"
  node-exporter:
    enabled: true
  kube-state-metrics:
    enabled: true

集群外 VictoriaMetrics

要使用外部 VictoriaMetrics，请在运行 helm install 之前在 values.yaml 文件中提供以下值。

• victoriametrics.enabled=false
• grafana.prometheusUrl="http://my.prometheus.url:9090"
• controller.prometheusUrl="http://my.prometheus.url:9090"

6 - 升级 Workflow

此升级过程需要：

• Helm 版本 2.1.0 或更新
• 配置的集群外存储

升级过程

步骤 1：应用 Workflow 升级

Helm 将从之前的版本中移除所有组件。通过 Workflow 部署的应用程序流量将在升级期间继续流动。不应发生服务中断。

如果 Workflow 未配置为使用集群外 Postgres，Workflow API 将在数据库从备份恢复时经历短暂的停机时间。

首先，使用 helm ls 查找 helm 给您的部署的版本名称，然后运行

$ helm upgrade <release-name> oci://registry.drycc.cc/charts/workflow

注意： 如果使用 gcs 上的集群外对象存储和/或使用 gcr 的集群外注册表，并打算从 pre-v2.10.0 图表升级到 v2.10.0 或更高版本，现在需要预先 base64 编码 key_json 值。因此，假设其余的自定义/集群外值在用于之前安装的现有 values.yaml 中定义，可以运行以下命令：

$ B64_KEY_JSON="$(cat ~/path/to/key.json | base64 -w 0)"
$ helm upgrade <release_name> drycc/workflow -f values.yaml --set gcs.key_json="${B64_KEY_JSON}",registry-token-refresher.gcr.key_json="${B64_KEY_JSON}"

或者，只需在 values.yaml 中替换适当的值，而不使用 --set 参数。确保用单引号包装，因为双引号会在升级时给出解析器错误。

步骤 2：验证升级

验证所有组件已启动并通过了就绪检查：

$ kubectl --namespace=drycc get pods
NAME                                     READY     STATUS    RESTARTS   AGE
drycc-builder-2448122224-3cibz            1/1       Running   0          5m
drycc-controller-1410285775-ipc34         1/1       Running   3          5m
drycc-controller-celery-694f75749b-cmxxn  3/3       Running   0          5m
drycc-database-e7c5z                      1/1       Running   0          5m
drycc-fluentbit-45h7j                     1/1       Running   0          5m
drycc-fluentbit-4z7lw                     1/1       Running   0          5m
drycc-fluentbit-k2wsw                     1/1       Running   0          5m
drycc-fluentbit-skdw4                     1/1       Running   0          5m
drycc-valkey-8nazu                        1/1       Running   0          5m
drycc-grafana-tm266                       1/1       Running   0          5m
drycc-registry-1814324048-yomz5           1/1       Running   0          5m
drycc-registry-proxy-4m3o4                1/1       Running   0          5m
drycc-registry-proxy-no3r1                1/1       Running   0          5m
drycc-registry-proxy-ou8is                1/1       Running   0          5m
drycc-registry-proxy-zyajl                1/1       Running   0          5m

步骤 3：升级 Drycc 客户端

Drycc Workflow 的用户现在应该升级他们的 drycc 客户端，以避免收到 WARNING: Client and server API versions do not match. Please consider upgrading. 警告。

curl -sfL https://www.drycc.cc/install-cli.sh | bash - && sudo mv drycc $(which drycc)

7 - 生产部署

在生产环境中运行 Workflow 而不使用 drycc 存储

在生产环境中，可以通过运行外部对象存储来实现持久存储。对于 AWS、GCE/GKE 或 Azure 上的用户，Amazon S3、Google GCS 或 Microsoft Azure Storage 的便利性使得运行不使用存储的 Workflow 集群成为相当合理的选择。对于对使用外部对象存储有限制的用户，使用 swift 对象存储可能是一个选项。

运行不使用存储的 Workflow 集群提供了几个优势：

• 从工作节点移除状态
• 减少资源使用
• 减少管理 Workflow 的复杂性和运营负担

有关移除此运营复杂性的详细信息，请参阅Configuring Object Storage。

审查安全注意事项

在生产环境中运行 Workflow 时，有一些额外的安全相关注意事项。有关详细信息，请参阅[Security Considerations][]。

注册仅限管理员

默认情况下，与 Workflow 控制器的注册处于"admin_only"模式。第一个运行 drycc register 命令的用户成为初始"admin"用户，此后的注册将被禁止，除非由管理员请求。

请参阅以下文档了解如何更改注册模式：

• Customizing Controller

禁用 Grafana 注册

还建议禁用 Grafana 仪表板的注册。

请参阅以下文档了解如何禁用 Grafana 注册：

• Customizing Monitor