用 KEDA 按排队扩容 Worker并用 GitLab 与 Argo CD 纳管工作负载本文记录这一阶段在现网上的做法安装 KEDA 2.21.0让 Dify 的 worker 在 vLLM 排队超过 10 时扩到最多 3 个副本安装 Argo CD 3.5.4把llm、dify、observability的工作负载收进 GitLab CE 的私有仓库由 Application 自动同步。本章目录是cicd。机器是prod102地址10.0.1.47。集群、探针、GPU Operator 和 Vault 写在同级目录k8s-从零部署、k8s-迁移、k8s-探针与密钥。流程对照页是同目录的《走一遍 GitOpsKEDA、GitLab 和 Argo CD.html》。scripts/10、scripts/12、scripts/13发现现网已经装过就会停住。不要在这台机器上再执行一遍。scripts/11会短时间把 worker 扩到 3 再缩回 1复习时看记录即可。登录口令沿用现网值。Vault 根令牌、Langfuse 的NEXTAUTH_SECRET、SALT、ENCRYPTION_KEY、Redis 口令、MinIO 口令、kubeadm 加入令牌以及 Argo CD 仓库 Secret 里的个人访问令牌不写进本文。不要把本文发到公网。一、这三样各自做什么请求路径没有变浏览器打开 Dify对话从 Dify 到 New-API再到 vLLM 的qwen3.6-27b。这一阶段在这条路径旁边加了两层控制。1. KEDAKEDA 按外部指标修改 Deployment 的副本数。本机的指标来自 Prometheus查询是sum(vllm:num_requests_waiting{model_nameqwen3.6-27b})Prometheus 地址是http://prometheus.observability.svc.cluster.local:9090。threshold和activationThreshold都是10。排队人数小于或等于 10 时触发器不激活dify/worker保持 1 个副本。超过 10 之后期望副本是排队人数除以 10 再向上取整上限 3。伸缩对象是 worker不包括 vLLM也不包括worker-beat。KEDA 会创建 HPAkeda-hpa-dify-worker。副本下限已经是 1又没有空闲副本KEDA 提示pollingInterval和cooldownPeriod不参与伸缩改副本数的是这条 HPA。2. Argo CDArgo CD 把 Git 仓库里的 YAML 当成集群的期望状态。Applicationplatform盯着仓库的manifests目录发现差异就提交到集群。selfHeal为 true有人直接改集群时会拉回 Git 上的内容。prune为 falseGit 里没有的对象不会被删掉。dify/worker的/spec/replicas写在ignoreDifferences里。KEDA 把副本改成 2 或 3 时Argo CD 不会把它改回 Git 里的 1。3. GitLab CEGit 仓库放在 GitLab Community Edition 19.4.2。这是 GitLab 的开源版本。网页是http://10.0.1.47:8929登录root/R3po-Argo-2026。项目gitops/platform是私有的默认分支main。Argo CD 在集群内使用http://gitlab.gitlab.svc.cluster.local:8929/gitops/platform.git拉仓库的用户名是oauth2口令是个人访问令牌放在 Secretargocd/gitops-repo。令牌本身不写进本文。二、动手前现网是什么样vLLM、Dify、监控已经在跑环境变量已经由 Vault 和 External Secrets 同步。节点可分配的nvidia.com/gpu是 1。vLLM、Xinference 和宿主机 Python 都不申请这个资源。写 ScaledObject 和导出清单时没有改 vLLM 镜像没有给 vLLM 加上nvidia.com/gpu也没有重启 New-API。三、安装 KEDAHelm release 名keda命名空间kedachart 版本 2.21.0。三个镜像都在ghcr.dockerproxy.net/kedacore标签2.21.0拉取策略IfNotPresent。安装时三个 Pod 各重启过一次随后保持 1/1。config/scaledobject-dify-worker.yaml就是现网对象。scripts/10-安装KEDA.sh在 prod102 上发现 release 已存在会退出。四、模拟一次排队scripts/11-模拟排队扩容.sh把查询临时写成vector(25)并把 HPA 的扩容、缩容稳定窗口设为 0。worker 从 1 个就绪变成 3 个就绪。HPA 先显示25/10三个副本就绪后显示约8334m/10。脚本退出时把查询改回真实的sum()副本回到 1。vLLM 的/health保持 200。现网查询已经是真实的sum()。不要把vector(25)留在 ScaledObject 上。五、安装 Argo CD版本 v3.5.4。安装对象都在config/argocd-install.yaml这是官方install.yaml换过镜像之后的同一份大约 3.4 万行CRD 占了绝大部分。提交时用kubectl apply --server-side --force-conflicts因为客户端 apply 会在applicationsets.argoproj.io的注解长度上失败。镜像组件镜像argocdm.daocloud.io/quay.io/argoproj/argocd:v3.5.4dexghcr.dockerproxy.net/dexidp/dex:v2.45.1redisdocker.m.daocloud.io/redis:8.2.3-alpine上游清单里的imagePullPolicy: Always已改成IfNotPresent。argocd-cmd-params-cm里server.insecure为true。argocd-cm的调和超时是 30 秒对外地址是http://10.0.1.47:8080管理员账号允许登录。scripts/12-部署ArgoCD.sh看到argocd-server已在就会退出。网页不直接暴露 argocd-server。config/argocd-ui-proxy.yaml用 nginx 把节点8080转到argocd-server.argocd.svc.cluster.local:80。转发的头是 Host、X-Forwarded-For、X-Forwarded-Proto、X-Forwarded-Host。Deployment 策略是 Recreate同一时间只有一个 Pod 占用 8080。登录http://10.0.1.47:8080admin/Argocd-git-2026。这组账号的会话接口返回 200浏览器也能进入 Applications。六、把现有工作负载收进 Git导出程序是scripts/export_gitops.py。范围是三个命名空间里的 Deployment、Service、ExternalSecret、ScaledObject。Secret 不导出。对象上的 uid、resourceVersion、managedFields 和 status 会去掉。创建 Application 之前用 dry-run 对比过每个 Deployment 的 Pod 模板。模板一致第一次同步没有新建 Pod。vLLM 的 Pod 仍是vllm-67b8d8c9f6-vvfsquid26326358-d9a7-4eec-8b13-df4d800d2ae5。演示提交只改了导航页模板注解gitops.local/demonav-1。硬刷新后导航页 Pod 带上这行注解。导航页策略是 Recreate所以换的是导航页自己的 Pod。vLLM 没有换。/health仍是 200。作业里更换 vLLM 镜像那一步没有做。那两个标签和现网镜像对不上改镜像会重启正在服务的模型。scripts/13-纳管GitOps.sh看到 Applicationplatform已在就会退出。现网不要再跑它。config/argocd-app-platform.yamlapiVersion:argoproj.io/v1alpha1kind:Applicationmetadata:name:platformnamespace:argocdspec:project:defaultsource:repoURL:http://gitlab.gitlab.svc.cluster.local:8929/gitops/platform.gittargetRevision:mainpath:manifestsdirectory:recurse:truedestination:server:https://kubernetes.default.svcnamespace:defaultsyncPolicy:automated:prune:falseselfHeal:truesyncOptions:-ApplyOutOfSyncOnlytrue-RespectIgnoreDifferencestrueignoreDifferences:-group:appskind:Deploymentname:workernamespace:difyjsonPointers:-/spec/replicas七、GitLab CE镜像docker.m.daocloud.io/gitlab/gitlab-ce:19.4.2-ce.0。数据目录/usr/cluster/gitlab挂到容器的/var/opt/gitlab、/var/log/gitlab、/etc/gitlab。节点端口 8929。容器内 SSH 不对节点发布。捆绑 Prometheus 关闭。内存请求 4Gi上限 8Gi。/dev/shm用 512Mi 的内存卷。/-/readiness在这版、并且关闭捆绑监控之后返回 404。探针使用/users/sign_inHTTP 200 才算就绪。更新策略是 Recreate。GitLab 拒绝了含有产品名的初始口令。网页账号是root/R3po-Argo-2026。浏览器已经用这组账号打开gitops/platform。注册已关闭。仓库main上有两个提交当前修订e07c4aa6f11d5740bc1dd0759a0003d2b2d23814。Application 指向 GitLab 之后仍是 Synced、HealthyvLLM 的 uid 没有变。早先的 Gitea 工作负载已经删除。数据目录/usr/cluster/gitea还在磁盘上当前同步不读它。清单在config/gitlab.yaml。prod102 上 GitLab 已经在跑不要再提交一份会滚动它的安装。八、做完时的核对检查结果KEDAkeda-operator、metrics-apiserver、admission-webhooks 均为 1/1ScaledObjectReady 为 TrueActive 为 False查询为真实sum()worker副本 1就绪 1Argo CD各组件 1/1。platformSynced、Healthy修订e07c4aa仓库GitLab 集群内地址。登录页 HTTP 200代理argocd-ui-proxy策略 Recreate就绪 1vLLMuid26326358-d9a7-4eec-8b13-df4d800d2ae5/health为 200Gitea 命名空间已删除再看一眼kubectl-ndify get scaledobject dify-worker kubectl-ndify get deploy worker kubectl-nargocd get application platform kubectl-ngitlab get pods kubectl-nllm get pod-lappvllmcurl-s-o/dev/null-w%{http_code}\nhttp://127.0.0.1:8000/healthcurl-s-o/dev/null-w%{http_code}\nhttp://127.0.0.1:8080/curl-s-o/dev/null-w%{http_code}\nhttp://127.0.0.1:8929/users/sign_in九、文件文件作用config/keda-values.yamlKEDA 2.21.0 的镜像和副本数config/scaledobject-dify-worker.yaml现网 ScaledObject查询必须保持真实sum()scripts/10-安装KEDA.sh安装 KEDA 并提交 ScaledObject。release 已在时退出scripts/11-模拟排队扩容.sh用vector(25)扩到 3 再缩回 1结束时恢复真实查询config/argocd-install.yamlArgo CD 3.5.4 的安装清单。镜像、明文访问和对外地址已经写在里面config/argocd-ui-proxy.yaml节点 8080 到 argocd-server 的反代策略 Recreateconfig/argocd-app-platform.yamlApplicationplatform仓库指向 GitLabconfig/gitlab.yamlGitLab CE。数据在/usr/cluster/gitlab端口 8929scripts/12-部署ArgoCD.sh安装 Argo CD 3.5.4。server 已在时退出scripts/13-纳管GitOps.sh早期纳管步骤。Application 已在时退出现网不要再跑scripts/export_gitops.py导出 Deployment、Service、ExternalSecret、ScaledObject走一遍 GitOpsKEDA、GitLab 和 Argo CD.html按真实结果整理的流程说明
用 KEDA 按排队扩容 Worker并用 GitLab 与 Argo CD 纳管工作负载本文记录这一阶段在现网上的做法安装 KEDA 2.21.0让 Dify 的 worker 在 vLLM 排队超过 10 时扩到最多 3 个副本安装 Argo CD 3.5.4把llm、dify、observability的工作负载收进 GitLab CE 的私有仓库由 Application 自动同步。本章目录是cicd。机器是prod102地址10.0.1.47。集群、探针、GPU Operator 和 Vault 写在同级目录k8s-从零部署、k8s-迁移、k8s-探针与密钥。流程对照页是同目录的《走一遍 GitOpsKEDA、GitLab 和 Argo CD.html》。scripts/10、scripts/12、scripts/13发现现网已经装过就会停住。不要在这台机器上再执行一遍。scripts/11会短时间把 worker 扩到 3 再缩回 1复习时看记录即可。登录口令沿用现网值。Vault 根令牌、Langfuse 的NEXTAUTH_SECRET、SALT、ENCRYPTION_KEY、Redis 口令、MinIO 口令、kubeadm 加入令牌以及 Argo CD 仓库 Secret 里的个人访问令牌不写进本文。不要把本文发到公网。一、这三样各自做什么请求路径没有变浏览器打开 Dify对话从 Dify 到 New-API再到 vLLM 的qwen3.6-27b。这一阶段在这条路径旁边加了两层控制。1. KEDAKEDA 按外部指标修改 Deployment 的副本数。本机的指标来自 Prometheus查询是sum(vllm:num_requests_waiting{model_nameqwen3.6-27b})Prometheus 地址是http://prometheus.observability.svc.cluster.local:9090。threshold和activationThreshold都是10。排队人数小于或等于 10 时触发器不激活dify/worker保持 1 个副本。超过 10 之后期望副本是排队人数除以 10 再向上取整上限 3。伸缩对象是 worker不包括 vLLM也不包括worker-beat。KEDA 会创建 HPAkeda-hpa-dify-worker。副本下限已经是 1又没有空闲副本KEDA 提示pollingInterval和cooldownPeriod不参与伸缩改副本数的是这条 HPA。2. Argo CDArgo CD 把 Git 仓库里的 YAML 当成集群的期望状态。Applicationplatform盯着仓库的manifests目录发现差异就提交到集群。selfHeal为 true有人直接改集群时会拉回 Git 上的内容。prune为 falseGit 里没有的对象不会被删掉。dify/worker的/spec/replicas写在ignoreDifferences里。KEDA 把副本改成 2 或 3 时Argo CD 不会把它改回 Git 里的 1。3. GitLab CEGit 仓库放在 GitLab Community Edition 19.4.2。这是 GitLab 的开源版本。网页是http://10.0.1.47:8929登录root/R3po-Argo-2026。项目gitops/platform是私有的默认分支main。Argo CD 在集群内使用http://gitlab.gitlab.svc.cluster.local:8929/gitops/platform.git拉仓库的用户名是oauth2口令是个人访问令牌放在 Secretargocd/gitops-repo。令牌本身不写进本文。二、动手前现网是什么样vLLM、Dify、监控已经在跑环境变量已经由 Vault 和 External Secrets 同步。节点可分配的nvidia.com/gpu是 1。vLLM、Xinference 和宿主机 Python 都不申请这个资源。写 ScaledObject 和导出清单时没有改 vLLM 镜像没有给 vLLM 加上nvidia.com/gpu也没有重启 New-API。三、安装 KEDAHelm release 名keda命名空间kedachart 版本 2.21.0。三个镜像都在ghcr.dockerproxy.net/kedacore标签2.21.0拉取策略IfNotPresent。安装时三个 Pod 各重启过一次随后保持 1/1。config/scaledobject-dify-worker.yaml就是现网对象。scripts/10-安装KEDA.sh在 prod102 上发现 release 已存在会退出。四、模拟一次排队scripts/11-模拟排队扩容.sh把查询临时写成vector(25)并把 HPA 的扩容、缩容稳定窗口设为 0。worker 从 1 个就绪变成 3 个就绪。HPA 先显示25/10三个副本就绪后显示约8334m/10。脚本退出时把查询改回真实的sum()副本回到 1。vLLM 的/health保持 200。现网查询已经是真实的sum()。不要把vector(25)留在 ScaledObject 上。五、安装 Argo CD版本 v3.5.4。安装对象都在config/argocd-install.yaml这是官方install.yaml换过镜像之后的同一份大约 3.4 万行CRD 占了绝大部分。提交时用kubectl apply --server-side --force-conflicts因为客户端 apply 会在applicationsets.argoproj.io的注解长度上失败。镜像组件镜像argocdm.daocloud.io/quay.io/argoproj/argocd:v3.5.4dexghcr.dockerproxy.net/dexidp/dex:v2.45.1redisdocker.m.daocloud.io/redis:8.2.3-alpine上游清单里的imagePullPolicy: Always已改成IfNotPresent。argocd-cmd-params-cm里server.insecure为true。argocd-cm的调和超时是 30 秒对外地址是http://10.0.1.47:8080管理员账号允许登录。scripts/12-部署ArgoCD.sh看到argocd-server已在就会退出。网页不直接暴露 argocd-server。config/argocd-ui-proxy.yaml用 nginx 把节点8080转到argocd-server.argocd.svc.cluster.local:80。转发的头是 Host、X-Forwarded-For、X-Forwarded-Proto、X-Forwarded-Host。Deployment 策略是 Recreate同一时间只有一个 Pod 占用 8080。登录http://10.0.1.47:8080admin/Argocd-git-2026。这组账号的会话接口返回 200浏览器也能进入 Applications。六、把现有工作负载收进 Git导出程序是scripts/export_gitops.py。范围是三个命名空间里的 Deployment、Service、ExternalSecret、ScaledObject。Secret 不导出。对象上的 uid、resourceVersion、managedFields 和 status 会去掉。创建 Application 之前用 dry-run 对比过每个 Deployment 的 Pod 模板。模板一致第一次同步没有新建 Pod。vLLM 的 Pod 仍是vllm-67b8d8c9f6-vvfsquid26326358-d9a7-4eec-8b13-df4d800d2ae5。演示提交只改了导航页模板注解gitops.local/demonav-1。硬刷新后导航页 Pod 带上这行注解。导航页策略是 Recreate所以换的是导航页自己的 Pod。vLLM 没有换。/health仍是 200。作业里更换 vLLM 镜像那一步没有做。那两个标签和现网镜像对不上改镜像会重启正在服务的模型。scripts/13-纳管GitOps.sh看到 Applicationplatform已在就会退出。现网不要再跑它。config/argocd-app-platform.yamlapiVersion:argoproj.io/v1alpha1kind:Applicationmetadata:name:platformnamespace:argocdspec:project:defaultsource:repoURL:http://gitlab.gitlab.svc.cluster.local:8929/gitops/platform.gittargetRevision:mainpath:manifestsdirectory:recurse:truedestination:server:https://kubernetes.default.svcnamespace:defaultsyncPolicy:automated:prune:falseselfHeal:truesyncOptions:-ApplyOutOfSyncOnlytrue-RespectIgnoreDifferencestrueignoreDifferences:-group:appskind:Deploymentname:workernamespace:difyjsonPointers:-/spec/replicas七、GitLab CE镜像docker.m.daocloud.io/gitlab/gitlab-ce:19.4.2-ce.0。数据目录/usr/cluster/gitlab挂到容器的/var/opt/gitlab、/var/log/gitlab、/etc/gitlab。节点端口 8929。容器内 SSH 不对节点发布。捆绑 Prometheus 关闭。内存请求 4Gi上限 8Gi。/dev/shm用 512Mi 的内存卷。/-/readiness在这版、并且关闭捆绑监控之后返回 404。探针使用/users/sign_inHTTP 200 才算就绪。更新策略是 Recreate。GitLab 拒绝了含有产品名的初始口令。网页账号是root/R3po-Argo-2026。浏览器已经用这组账号打开gitops/platform。注册已关闭。仓库main上有两个提交当前修订e07c4aa6f11d5740bc1dd0759a0003d2b2d23814。Application 指向 GitLab 之后仍是 Synced、HealthyvLLM 的 uid 没有变。早先的 Gitea 工作负载已经删除。数据目录/usr/cluster/gitea还在磁盘上当前同步不读它。清单在config/gitlab.yaml。prod102 上 GitLab 已经在跑不要再提交一份会滚动它的安装。八、做完时的核对检查结果KEDAkeda-operator、metrics-apiserver、admission-webhooks 均为 1/1ScaledObjectReady 为 TrueActive 为 False查询为真实sum()worker副本 1就绪 1Argo CD各组件 1/1。platformSynced、Healthy修订e07c4aa仓库GitLab 集群内地址。登录页 HTTP 200代理argocd-ui-proxy策略 Recreate就绪 1vLLMuid26326358-d9a7-4eec-8b13-df4d800d2ae5/health为 200Gitea 命名空间已删除再看一眼kubectl-ndify get scaledobject dify-worker kubectl-ndify get deploy worker kubectl-nargocd get application platform kubectl-ngitlab get pods kubectl-nllm get pod-lappvllmcurl-s-o/dev/null-w%{http_code}\nhttp://127.0.0.1:8000/healthcurl-s-o/dev/null-w%{http_code}\nhttp://127.0.0.1:8080/curl-s-o/dev/null-w%{http_code}\nhttp://127.0.0.1:8929/users/sign_in九、文件文件作用config/keda-values.yamlKEDA 2.21.0 的镜像和副本数config/scaledobject-dify-worker.yaml现网 ScaledObject查询必须保持真实sum()scripts/10-安装KEDA.sh安装 KEDA 并提交 ScaledObject。release 已在时退出scripts/11-模拟排队扩容.sh用vector(25)扩到 3 再缩回 1结束时恢复真实查询config/argocd-install.yamlArgo CD 3.5.4 的安装清单。镜像、明文访问和对外地址已经写在里面config/argocd-ui-proxy.yaml节点 8080 到 argocd-server 的反代策略 Recreateconfig/argocd-app-platform.yamlApplicationplatform仓库指向 GitLabconfig/gitlab.yamlGitLab CE。数据在/usr/cluster/gitlab端口 8929scripts/12-部署ArgoCD.sh安装 Argo CD 3.5.4。server 已在时退出scripts/13-纳管GitOps.sh早期纳管步骤。Application 已在时退出现网不要再跑scripts/export_gitops.py导出 Deployment、Service、ExternalSecret、ScaledObject走一遍 GitOpsKEDA、GitLab 和 Argo CD.html按真实结果整理的流程说明
