跳转至

OpenClaw on TKE 架构方案

文档元信息

  • API 版本: 2018-05-25
  • Agent 友好度: ⭐⭐⭐⭐
  • 适用集群版本: 1.20+
  • 预计阅读时间: 15 分钟

功能概述

本文档介绍如何在 TKE 上部署百万级 OpenClaw AI 助手实例的架构方案，适用于企业协作平台（如企业微信、飞书、钉钉）场景。

业务场景

核心特点：

  • 海量用户: 预计百万级用户，每用户独立实例
  • 低活跃度: 用户活跃度不均，需要弹性伸缩和卸载机制
  • 数据隔离: 每用户独立数据、上下文和配置
  • 企业集成: 与企业内部系统（文档、会议、通讯）深度打通

核心挑战

  1. 资源规模: 100 万用户 = 100 万个 Pod，单集群 5-10 万 Pod
  2. 成本压力: 高超卖 + 弹性管理，大幅降低资源成本
  3. 启动速度: 用户卸载后重新加载需在 15 秒内完成
  4. 网络限制: VPC IP 资源有限，无法为每个 Pod 分配独立 IP
  5. 存储性能: CBS 挂载限制（单节点限制、挂载速度），需要通过集群扩展应对
  6. 安全隔离: 跨企业数据隔离，防止容器逃逸

方案一：自管 TKE 集群（推荐）

架构设计

┌──────────────────────────────────────────────────────────────┐
│                        企业微信/飞书/钉钉                           │
│                         用户访问入口                                │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌──────────────────────────────────────────────────────────────┐
│              Ingress (Nginx/Traefik)                          │
│              子域名路由: user-a.openclaw.example.com           │
└────────────────────┬────────────────────────────────────────┘
                     │
        ┌────────────┼────────────┐
        │            │            │
        ▼            ▼            ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Pod A     │ │ Pod B     │ │ Pod C     │ ... (5-8万Pod/集群)
│ OpenClaw  │ │ OpenClaw  │ │ OpenClaw  │
│ 1C2G     │ │ 1C2G     │ │ 1C2G     │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
      │             │             │
      ▼             ▼             ▼
┌──────────────────────────────────────┐
│    CBS 云硬盘（20GB/用户）             │
│    独立挂载，数据持久化                │
└──────────────────────────────────────┘
      │
      ▼
┌──────────────────────────────────────┐
│    NAT 网关 + 流日志审计               │
│    出口流量管控和安全审计              │
└──────────────────────────────────────┘

核心技术组件

1. 网络方案：GlobalRouter + NAT 网关

原理： - GlobalRouter 网段: 集群内私有网段，不消耗 VPC IP 配额 - 母机路由: 在宿主机层面实现 Pod 间通信，集群外不可达 - NAT 出口: 通过 NAT 网关统一出口，配合流日志审计外部访问 - Ingress 入口: 基于子域名（user-a.openclaw.example.com）路由到特定 Pod

优势： - ✅ 不受 VPC IP 配额限制，支持百万级 Pod - ✅ 网络策略灵活，可精细化控制出入口流量 - ✅ 通过流日志实现安全审计和流量追踪

劣势： - ⚠️ NAT 网关的限流/熔断能力需验证 - ⚠️ Ingress 支持 10 万级子域名的性能需压测

成本： - NAT 网关费用按流量计费，具体费用取决于用户规模和流量

2. 存储方案：CBS（云硬盘）

推荐方案：CBS（云硬盘）

原理： - 独立挂载: 每个 Pod 挂载独立的 CBS 云硬盘，保证数据隔离 - 持久化存储: 数据持久化在云硬盘中，Pod 销毁后数据保留 - 按需挂载: Pod 启动时自动挂载，停止时可选择保留或释放

技术限制： - ⚠️ 挂载速度: 10-15 秒（相比 CFS 的 5 秒较慢） - ⚠️ 单节点限制: 单节点挂载数有上限（通常 10-20 块），需通过集群扩展节点数解决 - ⚠️ 并发挂载: 大规模并发创建 Pod 时，CBS 挂载可能成为瓶颈

方案对比：

存储类型 挂载速度 单节点挂载数 性能瓶颈 推荐度
CBS（推荐） 10-15秒 10-20个 挂载慢、单节点限制 ⭐⭐⭐⭐
CFS < 5秒 无限制 小文件读写需分片 ⭐⭐⭐
COS/COSFS 很慢 无限制 延迟高，不适合 ⭐⭐

应对策略： 1. 节点规模扩展: 通过增加节点数量分散单节点挂载压力 2. 分批启动: 避免短时间内大规模并发创建 Pod 3. 预挂载机制: 对高活跃用户提前创建并保持 Pod 运行 4. 盘缓存策略: 卸载 Pod 时保留云盘一段时间（如 7 天），避免频繁挂载/卸载

3. 计算资源：超卖 + 弹性管理

超卖策略：

  • CPU 超卖比: 4-5:1（request: 0.2C, limit: 1C）
  • 内存超卖比: 2-3:1（request: 800MB, limit: 2GB）
  • 节点规格: 48C192G 标准节点，可运行 200-300 Pod

弹性管理：

状态 资源占用 触发条件 恢复时间
活跃运行 CPU + 内存 + 存储 用户活跃 -
卸载 仅存储（CFS 目录保留） 30 天不活跃 < 5 秒
完全删除 释放所有资源 用户注销 -

优势：

  • ✅ 超卖大幅降低成本
  • ✅ 卸载机制释放闲置资源，实际资源占用约 20-30%

劣势：

  • ⚠️ 超卖比过高可能导致资源争抢（需根据实际负载调优）

4. 安全隔离：三种方案

方案 隔离强度 成本 适用场景
方案 A：普通容器 + 网络策略（基础） ⭐⭐ 基准成本 可接受低风险，同公司用户
方案 B：调度亲和性 + 网络策略（增强） ⭐⭐⭐ 基准成本 同公司用户调度到同节点
方案 C：Kata Containers + 裸金属（强隔离） ⭐⭐⭐⭐⭐ +30-50% 跨公司数据强隔离需求

方案详解：

方案 A：普通容器运行时（containerd/runc） - 原理: 标准 Linux 容器隔离（Namespace + Cgroup） - 风险: 理论上存在容器逃逸风险（但实际攻击成本高） - 适用: 同公司内部用户，风险可控

方案 B：调度亲和性策略 - 原理: 通过 Kubernetes 调度器，将同公司用户的 Pod 固定到同一节点 - 效果: 即使逃逸，也只能访问同公司数据，风险可控 - 成本: 无额外成本，调度灵活性略降低

方案 C：Kata Containers + 裸金属 - 原理: 每个 Pod 运行在独立的轻量级虚拟机中（虚拟化隔离） - 节点: 裸金属服务器（无二次虚拟化损耗） - 隔离强度: 虚拟机级别隔离，安全性接近物理隔离 - 成本: 裸金属价格比虚拟机高 30-50%，超卖后成本可控

推荐： - 初期试点: 方案 A（成本最低，快速验证） - 规模上线: 方案 B（成本不变，风险降低） - 高安全要求: 方案 C（金融/政务等敏感场景）

集群规模设计

单集群规模： - 节点数: 150-200 台（48C192G 标准节点） - Pod 数: 5-8 万（超卖后可达 10 万） - 承载用户: 5-8 万活跃用户

多集群架构（100 万用户）： - 集群数量: 12-20 个 - 负载均衡: 通过上层调度平台（企业微信控制面）分配用户到不同集群 - 跨集群管理: 统一配置下发、监控告警、日志采集

方案优劣总结

✅ 优势

  1. 成本可控: 超卖 + 弹性管理，大幅降低资源成本
  2. 启动速度: CBS 挂载 10-15 秒，可满足大部分场景需求
  3. 灵活度高: 自管集群，可自定义网络策略、安全加固、监控告警
  4. 成熟度高: TKE 集群已被多家企业验证（10 万+ Pod）

⚠️ 劣势

  1. 运维复杂: 需自行管理控制面、节点、网络、存储
  2. 性能待验证:
  3. CBS 大规模挂载性能和单节点限制（需压测）
  4. Ingress 10 万子域名性能（需压测）
  5. NAT 网关限流/熔断能力（待确认）
  6. 启动速度: CBS 挂载 10-15 秒，略慢于 CFS 方案
  7. 隔离性: 标准容器运行时隔离性弱于 TKE Serverless

方案二：TKE Serverless（托管方案）

架构设计

┌──────────────────────────────────────────────────────────────┐
│                        企业微信/飞书/钉钉                           │
│                         用户访问入口                                │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌──────────────────────────────────────────────────────────────┐
│              Ingress (Nginx/Traefik)                          │
│              子域名路由: user-a.openclaw.example.com           │
└────────────────────┬────────────────────────────────────────┘
                     │
        ┌────────────┼────────────┐
        │            │            │
        ▼            ▼            ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ EKS Pod A │ │ EKS Pod B │ │ EKS Pod C │ ... (百万级Pod)
│ (轻量虚拟机)│ │ (轻量虚拟机)│ │ (轻量虚拟机)│
│ 1C2G     │ │ 1C2G     │ │ 1C2G     │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
      │             │             │
      ▼             ▼             ▼
┌──────────────────────────────────────┐
│    CBS 云硬盘（20GB/用户）             │
│    自动挂载/卸载，盘缓存机制           │
└──────────────────────────────────────┘
      │
      ▼
┌──────────────────────────────────────┐
│    腾讯云 TKE Serverless 控制面        │
│    自动超卖、弹性伸缩、安全隔离        │
└──────────────────────────────────────┘

核心特性

1. 强隔离（虚拟机级别）

  • 原理: 每个 Pod 运行在独立的轻量级虚拟机（microVM）中
  • 安全性: 虚拟机级别隔离，逃逸风险极低
  • 适用: 跨企业、跨租户场景

2. 自动管理

  • 超卖: 腾讯云控制超卖比（如 4-5 倍），用户无感知
  • 弹性: 自动缩容/扩容，无需手动管理节点
  • 升降配: 支持 Pod 资源原地升降配（主线研发中，预计 2026 Q2 上线）

3. 存储优化

  • CBS 自动挂载: 控制面管理挂载/卸载，无单节点限制
  • 盘缓存机制: 卸载后保留云盘，重新创建 Pod 时自动挂载（缓存时间可配置，如 7 天）
  • 挂载速度: 5-10 秒（取决于 CBS 性能）

4. 网络方案

  • 当前: 仅支持 VPC IP 模式（消耗 IP 配额）
  • 规划: 支持 Global Root 网段（TKE 团队规划中，时间待定）

方案优劣总结

✅ 优势

  1. 强隔离: 虚拟机级别隔离，安全性最高
  2. 免运维: 无需管理节点、控制面，降低运维复杂度
  3. CBS 无限制: 自动管理挂载，无单节点限制
  4. 弹性能力: 自动缩扩容，适应突发流量

⚠️ 劣势

  1. 网络限制: 当前仅支持 VPC IP，百万级 Pod 需大量 IP（GlobalRouter 支持待排期）
  2. 超卖不可控: 超卖比由腾讯云控制，无法自定义
  3. 成本不确定: 最终成本需根据实际报价和使用情况测算
  4. CRD 扩展: 支持自定义 CRD（卸载/加载策略），但灵活度低于自管集群
  5. 启动速度: CBS 挂载速度 10-15 秒

两种方案对比

维度 自管 TKE 集群 TKE Serverless
隔离强度 ⭐⭐⭐（可选 Kata 达到 ⭐⭐⭐⭐⭐） ⭐⭐⭐⭐⭐（虚拟机隔离）
成本 超卖+弹性后成本可控 成本待测算，预计略高但免运维
启动速度 10-15 秒（CBS） 10-15 秒（CBS）
运维复杂度 高（需自管） 低（托管）
网络方案 ✅ GlobalRouter 成熟 ⚠️ 当前仅 VPC IP
超卖控制 ✅ 自定义（4-5:1） ❌ 腾讯云控制
存储 CBS（推荐） CBS 自动管理
集群规模 5-8 万 Pod/集群 无限制
灵活度 ✅ 高（自定义网络/安全策略） ⚠️ 中（受限于产品功能）
成熟度 ✅ 已验证（10 万+ Pod） ⚠️ 百万级 Pod 待验证

推荐策略

阶段 1：技术验证

目标: 验证核心技术可行性

验证项:

  1. CBS 大规模挂载性能和单节点限制（压测 5000 Pod/节点）
  2. Ingress 10 万子域名性能（压测 Nginx/Traefik）
  3. NAT 网关限流/熔断能力（TKE 团队确认）
  4. Kata Containers 性能和成本对比（裸金属 vs 虚拟机）

输出: 技术可行性报告 + 风险清单

阶段 2：小规模试点

目标: 验证业务场景和用户体验

规模: 5000 用户（1 个 TKE 集群）

方案选择:

  • 推荐: 自管 TKE 集群 + CBS + GlobalRouter + 方案 A（普通容器）
  • 理由: 技术成熟，快速验证，风险可控

验证项:

  1. 用户卸载/加载流程（CBS 挂载时间验证）
  2. 超卖比调优（CPU 4-5:1, 内存 2-3:1）
  3. 企业集成（子域名路由、出口访问）
  4. 成本核算（实际 vs 预估）

阶段 3：规模化部署

目标: 支撑 10-50 万用户

方案选择:

  • 自管 TKE: 2-5 个集群（根据实际负载调整）
  • 安全升级: 方案 B（调度亲和性）或方案 C（Kata Containers）

优化项:

  1. 自动化运维（集群管理、监控告警、日志采集）
  2. 成本优化（弹性策略调优，降低闲置资源）
  3. 多集群调度（上层控制面统一分配用户）

阶段 4：全量上线

目标: 支撑 100 万+ 用户

方案评估:

  • 自管 TKE: 如果阶段 3 验证成功，继续扩展到 12-20 个集群
  • TKE Serverless: 如果网络方案（Global Root）就绪 + 成本可接受，可考虑迁移

决策因素:

  1. 成本: 自管 vs Serverless 的综合成本对比（包含运维成本）
  2. 运维: 是否有足够团队支撑自管集群运维
  3. 安全: 是否需要虚拟机级别隔离（金融/政务客户）

经验总结

  • 启动速度: 15 秒内可接受，10 秒为较好体验
  • 超卖比: CPU 4-5:1 较为稳妥，内存 2-3:1 较保守，需根据实际负载调优
  • 存储: CBS 需要考虑单节点挂载限制和并发挂载性能，通过集群扩展节点数应对
  • 安全: 调度亲和性 + 网络策略可满足大部分场景，Kata 用于高安全要求

相关文档

最后更新: 2026-03-05 作者: TKE Workshop Team