bitnamicharts/argo-workflows

Bitnami Argo Workflows 图表

Argo Workflows用于并行编排Kubernetes作业，它使用有向无环图（DAG）和基于步骤的工作流。

https://argoproj.github.io/workflows

商标声明：本软件列表由Bitnami打包。产品中提及的各个商标分别归其各自公司所有，使用这些商标并不意味着任何关联或认可。

TL;DR

console
helm install my-release oci://registry-1.docker.io/bitnamicharts/argo-workflows

希望在生产环境中使用Argo Workflows？请尝试VMware Tanzu Application Catalog，即Bitnami目录的商业版。

⚠️ 重要通知：Bitnami目录即将发生的变更

自2025年8月28日起，Bitnami将改进其公共目录，在新的Bitnami Secure Images计划下提供精选的强化、安全聚焦的镜像集。作为此过渡的一部分：

• 首次向社区用户提供热门容器镜像的安全优化版本访问权限。
• Bitnami将开始在其免费层级中弃用对非强化、基于Debian的软件镜像的支持，并将逐步从公共目录中移除非最新标签。因此，社区用户将只能访问数量减少的强化镜像。这些镜像仅以“latest”标签发布，旨在用于开发目的。
• 从8月28日开始，在两周内，所有现有容器镜像（包括旧版本或特定版本标签，例如2.50.0、10.6）将从公共目录（docker.io/bitnami）迁移到“Bitnami Legacy”仓库（docker.io/bitnamilegacy），迁移后将不再接收更新。
• 对于生产工作负载和长期支持，建议用户采用Bitnami Secure Images，其中包括强化容器、更小的***面、CVE透明度（通过VEX/KEV）、SBOM以及企业支持。

这些变更旨在通过推广软件供应链完整性和最新部署的最佳实践，提高所有Bitnami用户的安全态势。有关更多详细信息，请访问https://github.com/bitnami/containers/issues/83267%E3%80%82

简介

此图表使用Helm包管理器在Kubernetes集群上引导https://argoproj.github.io/workflows%E9%83%A8%E7%BD%B2%E3%80%82

前提条件

• Kubernetes 1.23+
• Helm 3.8.0+
• 底层基础设施支持PV供应器
• 用于部署扩展的ReadWriteMany卷

安装图表

要使用发布名称my-release安装图表：

console
helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/argo-workflows

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

该命令以默认配置在Kubernetes集群上部署Argo Workflows。参数部分列出了安装期间可配置的参数。

提示：使用helm list列出所有发布。

配置和安装详情

资源请求和限制

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

为简化此过程，图表包含resourcesPreset值，可根据不同预设自动设置resources部分。在https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15%E4%B8%AD%E6%9F%A5%E7%9C%8B%E8%BF%99%E4%BA%9B%E9%A2%84%E8%AE%BE%E3%80%82%E4%BD%86%E6%98%AF%EF%BC%8C%E5%9C%A8%E7%94%9F%E4%BA%A7%E5%B7%A5%E4%BD%9C%E8%B4%9F%E8%BD%BD%E4%B8%AD%E4%B8%8D%E5%BB%BA%E8%AE%AE%E4%BD%BF%E7%94%A8%60resourcesPreset%60%EF%BC%8C%E5%9B%A0%E4%B8%BA%E5%AE%83%E5%8F%AF%E8%83%BD%E6%97%A0%E6%B3%95%E5%AE%8C%E5%85%A8%E9%80%82%E5%BA%94%E6%82%A8%E7%9A%84%E7%89%B9%E5%AE%9A%E9%9C%80%E6%B1%82%E3%80%82%E6%9C%89%E5%85%B3%E5%AE%B9%E5%99%A8%E8%B5%84%E6%BA%90%E7%AE%A1%E7%90%86%E7%9A%84%E6%9B%B4%E5%A4%9A%E4%BF%A1%E6%81%AF%EF%BC%8C%E8%AF%B7%E5%8F%82%E9%98%85Kubernetes%E5%AE%98%E6%96%B9%E6%96%87%E6%A1%A3%E3%80%82

滚动标签与不可变标签

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

如果主容器有新版本、重大变更或严重漏洞，Bitnami将发布新图表更新其容器。

Prometheus指标

通过将controller.metrics.enabled设置为true，此图表可与Prometheus集成。这将在容器和服务中公开Argo Workflows原生Prometheus端口。服务还将具有必要的注解，以便被Prometheus自动抓取。

Prometheus要求

要使集成正常工作，需要安装Prometheus或Prometheus Operator。安装https://github.com/bitnami/charts/tree/main/bitnami/prometheus%E6%88%96https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus%EF%BC%8C%E5%8F%AF%E8%BD%BB%E6%9D%BE%E5%9C%A8%E9%9B%86%E7%BE%A4%E4%B8%AD%E9%83%A8%E7%BD%B2%E5%8F%AF%E7%94%A8%E7%9A%84Prometheus%E3%80%82

与Prometheus Operator集成

该图表可以部署ServiceMonitor对象，以与Prometheus Operator安装集成。为此，将值controller.metrics.serviceMonitor.enabled设置为true。确保集群中安装了Prometheus OperatorCustomResourceDefinitions，否则将失败并显示以下错误：

text
no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"

安装https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus%E4%BB%A5%E8%8E%B7%E5%8F%96%E5%BF%85%E8%A6%81%E7%9A%84CRD%E5%92%8CPrometheus Operator。

数据库支持

您可能希望Argo Workflows控制器连接到数据库以存储控制器证据。为此，图表可以部署PostgreSQL或MySQL依赖项（请参阅下一节配置外部数据库而非使用依赖项）。要配置数据库，只需将postgresql.enabled=true（默认配置）或mysql.enabled=true。数据库将自动配置。例如：

console
postgresql.enabled=true

如果您的安装不需要存储控制器证据，可以通过设置postgresql.enabled=false、mysql.enabled=false和externalDatabase.enabled=false来禁用控制器持久性。

外部数据库

您可能希望Argo Workflows控制器连接到外部数据库以存储控制器证据。为此，图表允许您指定外部数据库（使用PostgreSQL或MySQL）的凭据（使用controller.persistence.postgresql.enabled或controller.persistence.mysql.enabled参数）。您还应将persistence.enabled设置为true。例如：

console
externalDatabase.enabled=true
externalDatabase.type=postgresql
externalDatabase.host=<database_host>
externalDatabase.port=5432
externalDatabase.user=<database_user>
externalDatabase.password=<database_password>
externalDatabase.database=bitnami_workflows

备份和恢复

要在Kubernetes上备份和恢复Helm图表部署，需要从源部署备份持久卷，并使用Velero（Kubernetes备份/恢复工具）将其附加到新部署。在本指南中查找使用Velero的说明。

Ingress

此图表提供对Ingress资源的支持。如果集群上安装了Ingress控制器（例如https://github.com/bitnami/charts/tree/main/bitnami/nginx-ingress-controller%E6%88%96https://github.com/bitnami/charts/tree/main/bitnami/contour%EF%BC%89%EF%BC%8C%E6%82%A8%E5%8F%AF%E4%BB%A5%E5%88%A9%E7%94%A8Ingress%E6%8E%A7%E5%88%B6%E5%99%A8%E4%B8%BA%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E6%8F%90%E4%BE%9B%E6%9C%8D%E5%8A%A1%E3%80%82%E8%A6%81%E5%90%AF%E7%94%A8Ingress%E9%9B%86%E6%88%90%EF%BC%8C%E5%B0%86%60ingress.enabled%60%E8%AE%BE%E7%BD%AE%E4%B8%BA%60true%60%E3%80%82

最常见的场景是将一个主机名映射到部署。在这种情况下，可以使用ingress.hostname属性设置主机名。ingress.tls参数可用于为此主机添加TLS配置。

但是，也可以有多个主机。为此，可以使用ingress.extraHosts参数（如果可用），将主机名指定为数组。ingress.extraTLS参数（如果可用）也可用于为额外主机添加TLS配置。

注意：对于ingress.extraHosts参数中指定的每个主机，需要设置名称、路径以及Ingress控制器应了解的任何注解。并非所有注解都受所有Ingress控制器支持，但https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md%E5%88%97%E5%87%BA%E4%BA%86%E8%AE%B8%E5%A4%9A%E6%B5%81%E8%A1%8CIngress%E6%8E%A7%E5%88%B6%E5%99%A8%E6%94%AF%E6%8C%81%E7%9A%84%E6%B3%A8%E8%A7%A3%E3%80%82

添加TLS参数（如果可用）将导致图表生成HTTPS URL，应用程序将在端口443上可用。TLS密钥不必由此图表生成。但是，如果启用了TLS，Ingress记录在TLS密钥存在之前将无法工作。

了解更多关于Ingress控制器。

使用TLS保护流量

此图表便于创建用于Ingress控制器的TLS密钥（尽管这不是必需的）。有几种常见用例：

• 基于图表参数生成证书密钥。
• 启用外部生成的证书。
• 通过外部服务（如https://github.com/jetstack/cert-manager/%EF%BC%89%E7%AE%A1%E7%90%86%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E8%AF%81%E4%B9%A6%E3%80%82
• 在图表内创建自签名证书（如果支持）。

在前两种情况下，需要证书和密钥。文件应为.pem格式。

以下是证书文件示例：

注意：如果存在证书链，可能有多个证书。

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

以下是证书密钥示例：

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

• 如果使用Helm基于参数管理证书，将这些值复制到给定*.ingress.secrets条目的certificate和key值中。
• 如果单独管理TLS密钥，需要创建名称为INGRESS_HOSTNAME-tls的TLS密钥（其中INGRESS_HOSTNAME是使用*.ingress.hostname参数设置的主机名的占位符）。
• 如果集群有https://github.com/jetstack/cert-manager%E6%8F%92%E4%BB%B6%E6%9D%A5%E8%87%AA%E5%8A%A8%E7%AE%A1%E7%90%86%E5%92%8C%E9%A2%81%E5%8F%91TLS%E8%AF%81%E4%B9%A6%EF%BC%8C%E5%B0%86%E7%9B%B8%E5%BA%94%E7%9A%84%E6%B3%A8%E8%A7%A3%E6%B7%BB%E5%8A%A0%E5%88%B0%60*.ingress.annotations%60%E3%80%82
• 如果使用Helm创建的自签名证书，将*.ingress.tls和*.ingress.selfSigned都设置为true。

额外环境变量

如果要添加额外的环境变量（用于高级操作，如自定义初始化脚本），可以使用extraEnvVars属性。

yaml
argo-workflows:
  extraEnvVars:
    - name: LOG_LEVEL
      value: error

或者，可以使用ConfigMap或Secret存储环境变量。为此，使用extraEnvVarsCM或extraEnvVarsSecret值。

边车容器

如果在与argo-workflows相同的Pod中需要额外的容器（例如额外的指标或日志导出器），可以使用sidecars参数定义它们。

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

如果这些边车容器导出额外端口，可以使用service.extraPorts参数（如果可用）添加额外的端口定义，如下例所示：

yaml
service:
  extraPorts:
  - name: extraPort
    port: 11311
    targetPort: 11311

注意：此Helm图表已包含Prometheus导出器的边车容器（如适用）。可以在部署时添加--enable-metrics=true参数来激活它们。因此，sidecars参数应仅用于任何额外的边车容器。

如果在同一Pod中需要额外的初始化容器，可以使用initContainers参数定义它们。例如：

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

了解更多关于边车容器和初始化容器。

Pod亲和性

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

作为替代方案，可以使用https://github.com/bitnami/charts/tree/main/bitnami/common#affinities%E5%9B%BE%E8%A1%A8%E4%B8%AD%E6%8F%90%E4%BE%9B%E7%9A%84Pod%E4%BA%B2%E5%92%8C%E6%80%A7%E3%80%81Pod%E5%8F%8D%E4%BA%B2%E5%92%8C%E6%80%A7%E5%92%8C%E8%8A%82%E7%82%B9%E4%BA%B2%E5%92%8C%E6%80%A7%E7%9A%84%E9%A2%84%E8%AE%BE%E9%85%8D%E7%BD%AE%E4%B9%8B%E4%B8%80%E3%80%82%E4%B8%BA%E6%AD%A4%EF%BC%8C%E8%AE%BE%E7%BD%AE%60podAffinityPreset%60%E3%80%81%60podAntiAffinityPreset%60%E6%88%96%60nodeAffinityPreset%60%E5%8F%82%E6%95%B0%E3%80%82

参数

全局参数

通用参数

Argo Workflows Server配置参数

注意：此