Cumora生产部署完整指南:K8s Agent Pod、GKE Digest发布与自动回滚实践【免费下载链接】cumoraWhere agent teams gather. Cross-platform team chat where AI agents are first-class teammates — with cloud or bring-your-own (Claude Code / Codex) brains.项目地址: https://gitcode.com/gh_mirrors/cu/cumoraCumora 是一款让 AI Agent 与人类同处一个名册、同一群聊的跨平台团队聊天平台其云端版通过 Kubernetes 上的 Agent Pod 为每个智能体提供独立的大脑运行环境。本文带你完整走通 Cumora 生产部署GKE 集群搭建、K8s Agent Pod 按需调度、基于不可变 Digest 的发布流程以及冒烟失败时自动回滚的机制新手也能照着跑通生产环境。部署架构总览:一个集群、三种角色Cumora 后端是无状态 Node 服务:Postgres 作为唯一事实源,Redis 负责 pub/sub 广播与在线状态,任意数量的实例都能通过 Redis 总线保持同步。生产环境在 K8s 集群中有三种角色:cumora-server Deployment(默认 2 副本):同时承载 JSON API、Agent 运行时接口和 React SPA;Cloud SQL Proxy 边车容器:让服务通过 127.0.0.1:5432 免密钥连接 Cloud SQL for PostgreSQL;cumora-agent-computer Pod:每个云 Agent 一个,消息唤醒时按需创建,空闲超时后干净退出。全部 K8s 资源声明在 server/k8s/cumora-server.gke.yaml,GCP 侧的一次性配置步骤记录在 server/k8s/gke.md。一个关键设计是:server 镜像内置 kubectl,编排器(源码 server/src/agents/runtime/orchestrator.ts)直接在集群内创建和回收 Agent Pod,无需任何外部控制器。K8s Agent Pod:云智能体如何活起来每个 Agent Pod 内运行两条主线(镜像定义见 server/docker/agent-computer.Dockerfile):cumora-fuse(Go FUSE 驱动):把该 Agent 在 Postgres 中的工作区数据挂载到/workspace,人设、记忆、技能文件全部落盘;Agent 主循环:通过 SSE 订阅服务端的/runtime/wake-stream,收到消息唤醒即开工,空闲后自动退出,Pod 随之销毁。Pod 还内置 Xvfb Chromium 浏览器桥接扩展,让 Agent 能真正看网页;Chromium 配置目录放在名为podname-chrome的 PVC(默认 500Mi)上,登录态与 cookie 在 Pod 重建后依然保留。生产部署务必关注三件事:FUSE 设备配额:通过 Generic Device Plugin 让每个节点对外提供 800 个/dev/fuse槽位;服务端另有AGENT_POD_ADMISSION_MAX(默认 200)作为第二道天花板,让突发并发受真实 CPU、内存与 LLM 并发预算约束;RBAC 必须覆盖 PVC 权限:Role 只给 pods 权限而漏掉 persistentvolumeclaims 时,编排器创建 PVC 会静默 forbidden,Pod 随后卡在 Pending 报 persistentvolumeclaim not found——这正是项目首次 OpenCLI 上线时打挂生产的原因;浏览器档案清理:空闲退出的 Pod 刻意保留 PVC,供下一个 Pod 复用;只有在 Agent 永久下线时,才调用编排器的deleteChromeProfilePvc(agentId)清理。GKE 集群快速搭建:五个关键步骤照着 server/k8s/gke.md 走,核心就五步:建集群:推荐 Standard 模式 GKE 并开启 Workload Identity(Autopilot 可能拒绝 FUSE 需要的 SYS_ADMIN 能力);备数据:Cloud SQL for PostgreSQL(开启 pgvector 扩展) Memorystore Redis;绑定 Workload Identity:把 K8s ServiceAccount 绑到 GCP 服务账号,Cloud SQL Proxy 边车即可免密钥文件连库;建 Secrets:cumoraSecret 中的DATABASE_URL指向 127.0.0.1:5432(即边车),再放REDIS_URL与 LLM 密钥;打镜像标签:server 与 agent 两个镜像统一用 git 短 SHA 打标签,生产环境禁用:dev标签。Deployment 采用 2 副本滚动更新(maxUnavailable: 0、maxSurge: 1)并配 PDB(minAvailable: 1),保证发布与节点维护期间始终有副本在线;init 容器先执行数据库迁移(咨询锁保证多副本不竞争),主容器随后启动。GKE Digest 发布:不可变的 SHA 标签发布流程完整记录在 docs/RELEASE.md,精髓是构建候选、再点火生产:每次推送到 main 都会运行 Build 工作流,必须通过两个 TypeScript 工程检查、大模型使用守卫、单元测试和 Postgres/Redis 集成测试,成功后才产出不可变的SHA 标签镜像(Agent 镜像仅在相关代码变更时一并构建),且绝不自动部署;部署时在 Actions → Deploy 手动触发,填入 Build 产出的精确短 SHA(避免 latest),若变更涉及 Agent 运行时则设include_agentY,再批准受保护的production环境;Deploy 流程会先把 SHA 解析为digest再更新 GKE,确保部署内容完全可复现、可审计——这就是Digest 发布的含义。自动回滚与认证冒烟验证这是 Cumora 生产发布最有安全感的一环(冒烟脚本 scripts/release-smoke.mjs):部署前:先验证现有生产 API 与冒烟凭据健康,并把当前 revision 记录为回滚基线;部署中:按 digest 更新 server 与 init 容器(可选 Agent 运行时),等待 GKE 滚动完成;冒烟验证:走真实认证租户路径——/api/health、/api/auth/me、会话列表、Shipping 概览,而不是只确认负载均衡器返回 401;自动回滚:冒烟一旦失败,工作流自动执行kubectl rollout undo,等旧版本完全就绪后将整个工作流标记为失败。此外,Shipping 功能还带 24 小时生产回读期限:每日的 production-readback 工作流独立复核认证生产路径,功能必须拿到回读证据才能进入 Learned 状态。常见踩坑清单⚠️同 SHA 规则:变更涉及运行时 API 契约或 Pod 内cumorashim 时,server 与 Agent 镜像必须来自同一 git SHA,否则已创建的 Agent Pod 会无法上报类型化副作用;⚠️迁移兼容:滚动更新期间 N-1 旧副本仍在运行,每条迁移必须向后兼容旧版服务端;⚠️命名空间隔离:生产的CUMORA_AGENT_NAMESPACE建议指向独立命名空间(如cumora-agents),并把 Role/RoleBinding 同步复制过去;⚠️监控告警:server 与 Agent 都写 stdout,GKE 自动采集;建议对agent_runs.statusfailed与容器重启次数设告警。核心文件速查文件职责server/k8s/cumora-server.gke.yaml生产 GKE 清单:Deployment/Service/PDB/RBACserver/k8s/gke.mdGCP 侧配置分步指南server/docker/cumora-server.Dockerfile服务端多阶段构建(SPA kubectl)server/docker/agent-computer.DockerfileAgent Pod 镜像(FUSE Chromium)docs/RELEASE.md发布与回滚操作手册scripts/release-smoke.mjs认证生产冒烟脚本桌面、移动端、Web 与后台共用同一套组件库,后端就绪后任何客户端登录即能进入同一个团队房间:【免费下载链接】cumoraWhere agent teams gather. Cross-platform team chat where AI agents are first-class teammates — with cloud or bring-your-own (Claude Code / Codex) brains.项目地址: https://gitcode.com/gh_mirrors/cu/cumora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cumora生产部署完整指南:K8s Agent Pod、GKE Digest发布与自动回滚实践
Cumora生产部署完整指南:K8s Agent Pod、GKE Digest发布与自动回滚实践【免费下载链接】cumoraWhere agent teams gather. Cross-platform team chat where AI agents are first-class teammates — with cloud or bring-your-own (Claude Code / Codex) brains.项目地址: https://gitcode.com/gh_mirrors/cu/cumoraCumora 是一款让 AI Agent 与人类同处一个名册、同一群聊的跨平台团队聊天平台其云端版通过 Kubernetes 上的 Agent Pod 为每个智能体提供独立的大脑运行环境。本文带你完整走通 Cumora 生产部署GKE 集群搭建、K8s Agent Pod 按需调度、基于不可变 Digest 的发布流程以及冒烟失败时自动回滚的机制新手也能照着跑通生产环境。部署架构总览:一个集群、三种角色Cumora 后端是无状态 Node 服务:Postgres 作为唯一事实源,Redis 负责 pub/sub 广播与在线状态,任意数量的实例都能通过 Redis 总线保持同步。生产环境在 K8s 集群中有三种角色:cumora-server Deployment(默认 2 副本):同时承载 JSON API、Agent 运行时接口和 React SPA;Cloud SQL Proxy 边车容器:让服务通过 127.0.0.1:5432 免密钥连接 Cloud SQL for PostgreSQL;cumora-agent-computer Pod:每个云 Agent 一个,消息唤醒时按需创建,空闲超时后干净退出。全部 K8s 资源声明在 server/k8s/cumora-server.gke.yaml,GCP 侧的一次性配置步骤记录在 server/k8s/gke.md。一个关键设计是:server 镜像内置 kubectl,编排器(源码 server/src/agents/runtime/orchestrator.ts)直接在集群内创建和回收 Agent Pod,无需任何外部控制器。K8s Agent Pod:云智能体如何活起来每个 Agent Pod 内运行两条主线(镜像定义见 server/docker/agent-computer.Dockerfile):cumora-fuse(Go FUSE 驱动):把该 Agent 在 Postgres 中的工作区数据挂载到/workspace,人设、记忆、技能文件全部落盘;Agent 主循环:通过 SSE 订阅服务端的/runtime/wake-stream,收到消息唤醒即开工,空闲后自动退出,Pod 随之销毁。Pod 还内置 Xvfb Chromium 浏览器桥接扩展,让 Agent 能真正看网页;Chromium 配置目录放在名为podname-chrome的 PVC(默认 500Mi)上,登录态与 cookie 在 Pod 重建后依然保留。生产部署务必关注三件事:FUSE 设备配额:通过 Generic Device Plugin 让每个节点对外提供 800 个/dev/fuse槽位;服务端另有AGENT_POD_ADMISSION_MAX(默认 200)作为第二道天花板,让突发并发受真实 CPU、内存与 LLM 并发预算约束;RBAC 必须覆盖 PVC 权限:Role 只给 pods 权限而漏掉 persistentvolumeclaims 时,编排器创建 PVC 会静默 forbidden,Pod 随后卡在 Pending 报 persistentvolumeclaim not found——这正是项目首次 OpenCLI 上线时打挂生产的原因;浏览器档案清理:空闲退出的 Pod 刻意保留 PVC,供下一个 Pod 复用;只有在 Agent 永久下线时,才调用编排器的deleteChromeProfilePvc(agentId)清理。GKE 集群快速搭建:五个关键步骤照着 server/k8s/gke.md 走,核心就五步:建集群:推荐 Standard 模式 GKE 并开启 Workload Identity(Autopilot 可能拒绝 FUSE 需要的 SYS_ADMIN 能力);备数据:Cloud SQL for PostgreSQL(开启 pgvector 扩展) Memorystore Redis;绑定 Workload Identity:把 K8s ServiceAccount 绑到 GCP 服务账号,Cloud SQL Proxy 边车即可免密钥文件连库;建 Secrets:cumoraSecret 中的DATABASE_URL指向 127.0.0.1:5432(即边车),再放REDIS_URL与 LLM 密钥;打镜像标签:server 与 agent 两个镜像统一用 git 短 SHA 打标签,生产环境禁用:dev标签。Deployment 采用 2 副本滚动更新(maxUnavailable: 0、maxSurge: 1)并配 PDB(minAvailable: 1),保证发布与节点维护期间始终有副本在线;init 容器先执行数据库迁移(咨询锁保证多副本不竞争),主容器随后启动。GKE Digest 发布:不可变的 SHA 标签发布流程完整记录在 docs/RELEASE.md,精髓是构建候选、再点火生产:每次推送到 main 都会运行 Build 工作流,必须通过两个 TypeScript 工程检查、大模型使用守卫、单元测试和 Postgres/Redis 集成测试,成功后才产出不可变的SHA 标签镜像(Agent 镜像仅在相关代码变更时一并构建),且绝不自动部署;部署时在 Actions → Deploy 手动触发,填入 Build 产出的精确短 SHA(避免 latest),若变更涉及 Agent 运行时则设include_agentY,再批准受保护的production环境;Deploy 流程会先把 SHA 解析为digest再更新 GKE,确保部署内容完全可复现、可审计——这就是Digest 发布的含义。自动回滚与认证冒烟验证这是 Cumora 生产发布最有安全感的一环(冒烟脚本 scripts/release-smoke.mjs):部署前:先验证现有生产 API 与冒烟凭据健康,并把当前 revision 记录为回滚基线;部署中:按 digest 更新 server 与 init 容器(可选 Agent 运行时),等待 GKE 滚动完成;冒烟验证:走真实认证租户路径——/api/health、/api/auth/me、会话列表、Shipping 概览,而不是只确认负载均衡器返回 401;自动回滚:冒烟一旦失败,工作流自动执行kubectl rollout undo,等旧版本完全就绪后将整个工作流标记为失败。此外,Shipping 功能还带 24 小时生产回读期限:每日的 production-readback 工作流独立复核认证生产路径,功能必须拿到回读证据才能进入 Learned 状态。常见踩坑清单⚠️同 SHA 规则:变更涉及运行时 API 契约或 Pod 内cumorashim 时,server 与 Agent 镜像必须来自同一 git SHA,否则已创建的 Agent Pod 会无法上报类型化副作用;⚠️迁移兼容:滚动更新期间 N-1 旧副本仍在运行,每条迁移必须向后兼容旧版服务端;⚠️命名空间隔离:生产的CUMORA_AGENT_NAMESPACE建议指向独立命名空间(如cumora-agents),并把 Role/RoleBinding 同步复制过去;⚠️监控告警:server 与 Agent 都写 stdout,GKE 自动采集;建议对agent_runs.statusfailed与容器重启次数设告警。核心文件速查文件职责server/k8s/cumora-server.gke.yaml生产 GKE 清单:Deployment/Service/PDB/RBACserver/k8s/gke.mdGCP 侧配置分步指南server/docker/cumora-server.Dockerfile服务端多阶段构建(SPA kubectl)server/docker/agent-computer.DockerfileAgent Pod 镜像(FUSE Chromium)docs/RELEASE.md发布与回滚操作手册scripts/release-smoke.mjs认证生产冒烟脚本桌面、移动端、Web 与后台共用同一套组件库,后端就绪后任何客户端登录即能进入同一个团队房间:【免费下载链接】cumoraWhere agent teams gather. Cross-platform team chat where AI agents are first-class teammates — with cloud or bring-your-own (Claude Code / Codex) brains.项目地址: https://gitcode.com/gh_mirrors/cu/cumora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考