必须用kubernetes解决单机dify的资源隔离差、无法弹性伸缩、依赖混乱和升级风险高等问题，其核心是围绕高可用、配置即代码、数据持久化与服务网格重构交付链路。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要在生产环境中稳定运行Dify AI工作流平台，必须解决单机部署带来的资源隔离差、无法弹性伸缩、服务依赖混乱和升级风险高等问题，而Kubernetes正是应对这些挑战的标准化基础设施。这套实践不是简单把Docker Compose文件翻译成YAML，而是围绕高可用、配置即代码、数据持久化与服务网格治理重构整个交付链路。
准备K8s集群与基础组件
确认集群节点状态正常：执行 kubectl get nodes，所有节点必须显示 【Ready】 状态；若存在 NotReady 节点，后续所有 Deployment 都可能因调度失败而卡在 Pending 阶段。
创建独立命名空间避免资源污染：运行 kubectl create namespace dify，所有Dify相关资源均限定在此命名空间内，防止与其他业务组件产生端口、ConfigMap或Service名称冲突。
验证集群是否已启用动态存储供给能力：执行 kubectl get storageclass，至少存在一个 【reclaimPolicy: Retain】 的StorageClass——这是保障PostgreSQL和Weaviate数据不随Pod重建丢失的前提，否则需手动创建NFS或云厂商提供的SC。
部署有状态依赖服务
方法一：使用Helm快速拉起PostgreSQL与Redis
添加Bitnami Helm仓库：helm repo add bitnami https://charts.bitnami.com/bitnami → 更新本地索引：helm repo update → 安装PostgreSQL（启用持久卷与密码认证）：helm install pg bitnami/postgresql --namespace dify --set auth.postgresPassword=pg123456,global.storageClass=your-sc-name,persistence.size=20Gi。
方法二：手动部署Weaviate向量数据库（需显式配置gRPC通信）
下载官方K8s manifest模板后，修改 weaviate-deployment.yaml 中的 env 区块，确保 QUERY_DEFAULTS_LIMIT 设为 1000 以上，否则知识库检索将默认截断结果；同时将 CLUSTER_HOSTNAME 改为 weaviate.dify.svc.cluster.local，否则Worker节点无法通过Service DNS发现该实例。
配置Dify核心服务参数
第一步：创建Secret管理敏感凭证
将OPENAI_API_KEY、DATABASE_URL等密钥转为Base64编码后写入Secret YAML，注意 【DATABASE_URL必须包含完整连接串，如 postgresql://postgres:pg123456@pg-postgresql.dify.svc.cluster.local:5432/dify】，少一个斜杠或端口都会导致API Server启动失败并反复CrashLoopBackOff。
第二步：编写ConfigMap统一定义非密级配置
在data字段中明确指定 LOG_LEVEL: "INFO" 和 CELERY_BROKER_URL: "redis://redis-master.dify.svc.cluster.local:6379/0"，这两项若遗漏，Worker将无法连接消息队列，所有异步任务（如知识库切片、模型调用）均会堆积在Redis中无响应。
第三步：为Web前端注入反向代理规则
在Nginx ConfigMap中添加 location /api/ { proxy_pass http://dify-api; }，确保前端请求/api路径时能正确转发至API Service，否则登录页提交表单后始终返回404。
编排Dify无状态服务
部署API Server：应用 dify-api-deployment.yaml，其中 livenessProbe 必须指向 /health 端点且超时设为5秒以内，否则K8s会在服务尚未完成数据库迁移时就判定其不健康并强制重启，造成迁移脚本重复执行报错。
部署Worker：使用单独Deployment，镜像标签必须与API Server严格一致（如 difyai/dify:1.1.3），否则Celery任务序列化协议不兼容，Worker会静默丢弃来自API的任何任务。
部署Web前端：挂载ConfigMap作为Nginx配置文件，并设置 readinessProbe 检查 /favicon.ico 是否返回200，这比检查根路径更可靠——因为根路径可能被重定向到登录页，而/favicon.ico是静态资源，响应最稳定。
暴露服务与验证连通性
创建Ingress资源，host字段填写你已备案的域名（如 ai.example.com），tls部分引用预先创建的Secret名称；若跳过此步直接用NodePort访问，前端JS将因混合内容（HTTP API + HTTPS页面）被浏览器拦截跨域请求。
等待Ingress Controller就绪后，执行 kubectl -n dify get ingress 查看ADDRESS列是否输出有效IP；若为空，说明Ingress Controller未运行或未监听该命名空间，此时访问域名会直接超时。
在集群内调试连通性：运行 kubectl -n dify exec -it deploy/dify-web -- curl -I http://dify-api:8000/health，返回HTTP/1.1 200表示API服务可达；若返回Connection refused，检查Service selector是否匹配API Pod的label，常见错误是把 app: dify-api 写成 app: api。
