OpenClaw on TKE 架构方案

文档元信息

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

功能概述

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

业务场景

核心特点：

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

核心挑战

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

方案一：自管 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	很慢	无限制	延迟高，不适合	⭐⭐

应对策略：

节点规模扩展: 通过增加节点数量分散单节点挂载压力
分批启动: 避免短时间内大规模并发创建 Pod
预挂载机制: 对高活跃用户提前创建并保持 Pod 运行
盘缓存策略: 卸载 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%，超卖后成本可控

集群规模设计

单集群规模：

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

多集群架构（100 万用户）：

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

方案优劣总结

✅ 优势

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

⚠️ 劣势

运维复杂: 需自行管理控制面、节点、网络、存储
性能待验证:
- CBS 大规模挂载性能和单节点限制（需压测）
- Ingress 10 万子域名性能（需压测）
- NAT 网关限流/熔断能力（待确认）
启动速度: CBS 挂载 10-15 秒，略慢于 CFS 方案
隔离性: 标准容器运行时隔离性弱于 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 团队规划中，时间待定）

方案优劣总结

✅ 优势

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

⚠️ 劣势

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

经验总结

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

OpenClaw on TKE 架构方案

OpenClaw on TKE 架构方案

文档元信息

功能概述

业务场景

核心挑战

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

架构设计

核心技术组件

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

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

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

4. 安全隔离：三种方案

集群规模设计

方案优劣总结

✅ 优势

⚠️ 劣势

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

架构设计

核心特性

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

2. 自动管理

3. 存储优化

4. 网络方案

方案优劣总结

✅ 优势

⚠️ 劣势

两种方案对比

推荐策略

阶段 1：技术验证

阶段 2：小规模试点

阶段 3：规模化部署

阶段 4：全量上线

经验总结

相关文档