Dify 工作流服务在 K8s 集群中配置自动扩缩容，主要通过 Kubernetes HPA 针对 API 服务进行负载扩容，或使用 KEDA 针对 Celery Worker 进行队列长度扩容，适用场景为无状态服务组件，风险边界在于数据库和缓存等有状态服务不可直接水平扩缩容。

命令速用版

若已部署 Dify 的 Helm Chart 或手动 Deployment，可使用以下命令快速启用基于 CPU 的 HPA 策略。

kubectl autoscale deployment dify-api `--cpu-percent`=50 `--min`=2 `--max`=10
kubectl get hpa dify-api `--watch`

对于 Worker 服务，建议配置 KEDA ScaledObject 监听 Redis 队列长度，避免 CPU 指标滞后。

为什么会这样

K8s 自动扩缩容依赖指标采集和无状态架构，Dify 的 API 服务无本地会话状态，适合 HPA 扩容。

Dify 架构中，api 和 worker 组件设计为无状态，请求可分发至任意 Pod，满足水平扩缩容前提。数据库（PostgreSQL）和缓存（Redis）属于有状态服务，直接扩容会导致数据不一致，通常采用主从复制或集群模式而非 K8s HPA。Worker 服务基于任务队列，CPU 使用率可能不高但队列积压严重，因此基于队列长度的事件驱动扩缩容（KEDA）比传统 HPA 更准确。

分步处理

按以下顺序配置扩缩容策略，确保先满足前置依赖再应用策略。

步骤 1：确认指标服务可用

HPA 依赖 metrics-server 获取 CPU/内存数据。执行命令检查接口是否正常返回数据。

kubectl top nodes
kubectl top pods -n dify

若无数据，需先部署 metrics-server。对于 Worker 队列扩容，需部署 KEDA 控制器。

步骤 2：识别可扩容组件

检查 Dify 部署清单，仅对 dify-api 和 dify-worker 的 Deployment 资源应用策略。不要对 dify-db 或 dify-redis 应用 HPA。

步骤 3：应用 HPA 策略

创建 HPA 资源文件，指定最小和最大副本数及阈值。示例配置如下：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: dify-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: dify-api
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

步骤 4：配置 Worker 队列扩容（可选）

若使用 KEDA，创建 ScaledObject 监听 Redis 流长度。需确保 Dify Worker 使用 Redis 作为 Celery Broker。

怎么验证是否生效

通过 kubectl 命令观察 HPA 状态和 Pod 数量变化，确认指标采集正常且触发阈值。

检查 HPA 状态：执行kubectl get hpa -n dify，观察 TARGETS 列是否显示具体数值而非unknown。若显示unknown，说明 metrics-server 未正常工作。

观察 Pod 变化：执行kubectl get pods -n dify -w，在负载增加时观察 Pod 是否从 minReplicas 增加至 maxReplicas 范围内。

查看事件日志：执行kubectl describe hpa dify-api-hpa -n dify，查看 Events 部分是否有SuccessfulRescale记录。

常见坑

配置过程中容易忽略资源请求值和会话保持问题，导致扩缩容失败或服务中断。

• 未设置 Request 值：HPA 基于资源请求值（requests）计算利用率，若 Deployment 未设置 CPU/Memory requests，HPA 无法计算百分比，需先补全资源限制。
• 有状态服务误扩：切勿对 PostgreSQL 或 Redis 的 StatefulSet 使用 HPA 进行水平扩容，这会导致数据分片错误或连接失败。
• 会话保持缺失：若 Dify 配置了本地会话存储，扩容后用户请求可能被分发到新 Pod 导致登录态丢失，需确保会话存储于 Redis 等外部中间件。
• 扩容震荡：阈值设置过敏感导致 Pod 频繁启停，建议在 HPA 中配置behavior策略增加稳定窗口。

常见问题

HPA 状态显示 unknown 怎么办？

通常是因为集群未安装 metrics-server 或资源请求值缺失。

首先检查kubectl top pods是否有数据，若无数据需安装 metrics-server 插件。若 metrics-server 正常，检查 Dify 的 Deployment YAML 中是否设置了resources.requests.cpu，HPA 必须基于请求值计算利用率。

Worker 服务能否只用 CPU 扩容？

可以但不推荐，基于队列长度扩容响应更快。

仅使用 CPU 扩容在任务积压但计算量不大时可能无法触发扩容，导致任务处理延迟。建议引入 KEDA 配合 Redis 队列长度指标进行事件驱动扩容，能更精准匹配工作流任务负载。

扩容后服务出现 502 错误？

可能是新 Pod 未完全就绪就接收了流量。

检查 Deployment 中的readinessProbe配置，确保探针检测通过后再将 Pod 加入 Service 端点。同时确认 K8s Service 的sessionAffinity设置是否符合业务需求，避免请求分发异常。

参考来源

• 来源名：Dify GitHub Repository
• 页面标题：langgenius/dify - Helm Chart & Docker Compose
• URL：https://github.com/langgenius/dify

• 来源名：Kubernetes Documentation
• 页面标题：Horizontal Pod Autoscaler
• URL：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/