yldmdocs

Argo Workflows · 集群内的工作流编排引擎

Argo Workflows 是这套集群里的 Kubernetes 原生工作流引擎，跑在 argo-workflows 命名空间。它由两个 Deployment 组成：workflow-controller 负责调度并执行 Workflow / CronWorkflow，argo-server 提供 Web UI 与 API。集群把它当作通用的 CI/批处理底座——一批数据库备份、恢复演练、镜像清理、夜间构建和 GitHub 部署回写的 CronWorkflow 都跑在它上面。

制品与日志归档落到集群内 MinIO，工作流状态归档进 PostgreSQL，登录走 Dex SSO。这三个依赖的密钥全部通过 ExternalSecret 从 Vault 拉取，git 里没有明文。

部署形态

整个目录是一个 kustomize root，把 CRD、RBAC、ConfigMap、ExternalSecret、两个 Deployment、Service、Ingress、监控、网络策略、配额，以及 ClusterWorkflowTemplate 和 CronWorkflow 一次性纳管。kustomization.yaml 里没有 images: 块，镜像版本直接写在各 Deployment 的容器 image 字段上。

  • Name
    命名空间
    Description
    argo-workflows（带 ResourceQuota 上限 50 pods / requests 4 CPU·8Gi / limits 16 CPU·32Gi，以及容器级 LimitRange 默认值）。
  • Name
    workflow-controller
    Description
    Deployment，单副本，镜像 quay.io/argoproj/workflow-controller:v4.0.6，执行器镜像 quay.io/argoproj/argoexec:v3.6.4（--executor-image）。启动参数含 --workflow-workers 32，开启 leader election。健康检查走 :6060/healthz，指标端口 :9090。priorityClassName: system-cluster-critical。
  • Name
    argo-server
    Description
    Deployment，单副本，镜像 quay.io/argoproj/argocli:v4.0.6，启动参数 server --auth-mode=sso --auth-mode=server --secure=false，监听 :2746。挂一个 emptyDir 到 /tmp。
  • Name
    安全上下文
    Description
    两者都 runAsNonRoot、readOnlyRootFilesystem、drop ALL capabilities、seccompProfile: RuntimeDefault、allowPrivilegeEscalation: false。
  • Name
    调度
    Description
    仅 nodeSelector: kubernetes.io/os: linux，未绑定特定 workload 节点标签。
  • Name
    PDB
    Description
    argo-server 与 workflow-controller 各一个 PodDisruptionBudget，均 maxUnavailable: 1。
  • Name
    PriorityClass
    Description
    额外定义三个非全局默认的工作流优先级：workflow-high-priority(1000)、workflow-normal-priority(100)、workflow-low-priority(10)，供工作流 pod 选用。

配置与依赖

控制器的全部行为由 ConfigMap workflow-controller-configmap 驱动。关键项如下：

  • 制品库（MinIO）：S3 兼容，endpoint minio.minio.svc.cluster.local:9000，bucket argo-workflows，insecure: true、archiveLogs: true、createBucketIfNotPresent，凭据取自 Secret argo-workflows-minio 的 accesskey/secretkey。
  • 状态归档（PostgreSQL）：nodeStatusOffLoad: true、archive: true、archiveTTL: 180d，连 postgres-primary.postgres.svc.cluster.local:5432，库 argo_workflows、表 argo_workflows，用户名/密码取自 Secret argo-workflows-postgres。
  • SSO：issuer https://dex.yldm.tech，回调 https://argo-workflows.yldm.tech/oauth2/callback，scopes openid/profile/email/groups，rbac.enabled: true，client 凭据取自 Secret argo-workflows-sso。
  • 并发与限流：parallelism: 10、namespaceParallelism: 5、resourceRateLimit limit 10 / burst 1。
  • 默认与保留：workflowDefaults 指定 serviceAccountName: argo-workflow、ttlStrategy（成功后 1h、完成后 24h、失败后 48h 清理）、podGC: OnPodCompletion（延迟 300s）；retentionPolicy 保留 completed 100 / failed 50 / errored 50。
  • 外链：在 UI 里挂了指向 Grafana Loki 的 Workflow Logs / Pod Logs 探查链接。

依赖的密钥全部经 ClusterSecretStore vault-backend 从 Vault 拉取，对应 remoteRef.key：

SecretremoteRef.key用途
argo-workflows-miniominio/root制品库 / 备份上传
argo-workflows-postgresdatabase/prod/postgres工作流状态归档 + PG 备份
argo-workflows-ssodex/clients/argo-workflowsargo-server SSO 登录
argo-workflows-redisdatabase/prod/redisRedis 备份/恢复演练
argo-workflows-mongodbdatabase/prod/mongodbMongoDB 备份/恢复演练
ghcr-credentialsgithub-runner/github-token拉/推 GHCR 镜像
git-ssh-keyargocd/repo/golang-server检出源码仓库
github-deploy-appgithub-runner/github-appGitHub 部署状态回写

此外还有一个 secrets-argo-server-token（SA token，用于 SSO RBAC）。命名空间内有四个 ServiceAccount：argo-server、argo-workflow-controller、argo-workflow（工作流 pod 默认身份）、github-deploy-tracker。

工作流模板与定时任务

仓库预置了四个跨命名空间共享的 ClusterWorkflowTemplate——git-clone、docker-build、golang、notify，以及两个示例 WorkflowTemplate（hello-world、http-example）。它们被下面的 CronWorkflow 复用。所有 CronWorkflow 时区均为 Asia/Shanghai，多数 concurrencyPolicy: Forbid。

CronWorkflow计划作用
mongodb-backup0 2 * * *MongoDB dump 上传 MinIO（错峰最早）
workflow-cleanup0 2 * * *清理过期的已完成/失败 Workflow
redis-backup0 3 * * *Redis dump 上传 MinIO
image-cleanup0 3 * * 0每周日清理旧镜像 / 节点 dangling 镜像
database-backup0 4 * * *PostgreSQL pg_dump 上传 MinIO
mongodb-restore-verify0 5 * * *把 MongoDB 备份还原进临时实例做演练
redis-restore-verify30 5 * * *Redis 备份恢复演练
postgres-restore-verify0 6 * * *PostgreSQL 备份恢复演练
yldm-nightly-build0 0 * * *夜间构建：checkout → lint/test/安全扫描 → 构建 gateway/user 镜像（concurrencyPolicy: Replace）
github-deploy-tracker*/5 * * * *每 5 分钟把 ArgoCD app 的镜像 tag + sync/health 状态回写成对应源码仓库的 GitHub Deployment

备份均上传到 MinIO，三个 restore-verify 在备份完成后错峰运行（恢复进一次性的 in-pod 实例验证可还原性）。database-backup、*-restore-verify 等还导出 backup_workflow_* / restore_verify_* 自定义指标。

github-deploy-tracker 解决 ArgoCD 拉模式下「合并/打 tag 后集群已滚动、但 GitHub 上看不到部署」的问题：它列出所有带 yldm.tech/deploy-tracking=true 注解的 ArgoCD Application，把每个 app 的实时镜像 tag 与状态镜像成源码仓库对应 commit 上的 GitHub Deployment。

访问与监控

  • Service：argo-server 为 ClusterIP，端口 2746；argo-workflow-controller-metrics 为 ClusterIP，端口 9090。
  • Ingress：argo-server-ingress，host argo-workflows.yldm.tech，ingressClassName: traefik，证书由 cert-manager.io/cluster-issuer: letsencrypt-prod 签发到 Secret argo-workflows-tls，并经 external-dns 指向 Cloudflare Tunnel（cloudflare-proxied: true）。
  • 监控：两个 ServiceMonitor——argo-workflow-controller 抓 metrics 端口 /metrics、argo-server 抓 web 端口 /metrics，均 30s 间隔。仓库内未见 PrometheusRule、HPA、VPA。
  • 网络策略：default-deny-ingress 默认拒绝，外加 argo-server 与 workflow-controller 的放行策略。

返回 infrastructure 总览

评论