基于 Amazon EKS 和 Graviton 构建多租户 AI Agent 平台：OpenClaw on Kubernetes 实践

摘要：随着生成式 AI 的快速普及，越来越多的企业需要为内部团队或外部客户提供 AI Agent 服务。如何在保障安全隔离的前提下，实现高效、低成本的多租户 AI Agent 部署，成为一项关键的技术挑战。本文介绍如何基于 Amazon EKS、AWS Graviton 和 Kubernetes Operator 模式，构建一个支持多租户、多模型的 OpenClaw AI Agent 平台，并通过 CloudFront + Cognito + ALB 的前端架构实现用户自助 Provisioning。

01 一、引言

02 二、OpenClaw 简介与价值

03 三、多租户场景的挑战

04 四、方案设计思路

05 五、Amazon EKS + Graviton 的优势

06 六、架构介绍

07 七、运行时选项：标准容器 vs. Kata Containers microVM

08 八、支持的模型提供商

09 九、弹性扩展与存储方案

10 十、认证与授权方案

11 十一、Demo 演示

12 十二、总结与展望

13 十三、参考资料

一、引言

随着生成式 AI 的快速普及，越来越多的企业需要为内部团队或外部客户提供 AI Agent 服务。如何在保障安全隔离的前提下，实现高效、低成本的多租户 AI Agent 部署，成为一项关键的技术挑战。本文介绍如何基于 Amazon EKS 、 AWS Graviton 和 Kubernetes Operator 模式，构建一个支持多租户、多模型的 OpenClaw AI Agent 平台，并通过 CloudFront + Cognito + ALB 的前端架构实现用户自助 Provisioning 。

二、OpenClaw 简介与价值

OpenClaw 是一个开源的云原生 AI Agent 运行时平台，能够作为用户的个人 AI 助手，跨 Telegram、Discord、WhatsApp、Signal 等多个渠道提供服务。它不仅仅是一个聊天机器人，更是一个具备记忆、技能系统、浏览器自动化和代码执行能力的智能 Agent 。

OpenClaw 的核心能力包括：

多 AI 提供商支持：Amazon Bedrock (Claude)、OpenAI、SiliconFlow 等

可扩展的技能系统：基于 MCP (Model Context Protocol) 的插件化架构

内置安全沙箱：安全的代码执行环境和浏览器自动化

声明式配置：通过 Kubernetes CRD 声明式管理 Agent 实例

持久化存储：支持 Agent 记忆和工作空间的持久化

对于企业用户而言，OpenClaw 提供了一种将 AI Agent 能力作为内部服务（Agent-as-a-Service）的可能性——每位员工或每个团队都可以拥有自己的专属 AI Agent，同时企业能够统一管控模型访问、成本和安全策略。

三、多租户场景的挑战

当我们尝试将 OpenClaw 扩展为一个服务多用户的平台时，面临以下核心挑战：

3.1 用户与模型多样性

不同用户可能需要访问不同的 AI 模型（如 Claude Sonnet、Claude Opus），甚至不同的模型提供商（Amazon Bedrock、SiliconFlow 等）。平台需要灵活支持多模型配置，同时统一管理模型访问凭证。

3.2 安全隔离保障

每个 AI Agent 实例拥有用户的个人数据、对话记录和工作空间文件。在多租户环境中，必须确保：

数据隔离：不同用户的数据完全隔离，无法互相访问

网络隔离： Agent 实例之间的网络流量严格受控

资源隔离：单个用户不能耗尽共享集群资源

运行时隔离：提供 VM 级别的隔离选项，防止容器逃逸

3.3 效率与性能

AI Agent 的交互是实时的，用户期望低延迟的响应。平台需要在保障隔离的同时，最小化性能开销，快速完成实例的创建和启动。

3.4 可扩展性设计

从 10 个用户扩展到 1000 甚至 10000 个用户，架构需要具备弹性伸缩能力，而不是线性增加管理复杂度和基础设施成本。

四、方案设计思路

基于上述挑战，我们设计了以下解决方案，围绕四个核心设计目标：

4.1 设计目标一：多用户、多模型支持

通过 Kubernetes Operator 模式，将每个用户的 AI Agent 抽象为一个 OpenClawInstance CRD（Custom Resource Definition）。Operator 监听 CRD 变化，自动创建对应的 StatefulSet、Service、PVC、ConfigMap 等资源。每个实例可以独立配置模型提供商和模型 ID 。

4.2 设计目标二：安全隔离保障

采用 Namespace-per-User 的隔离策略：每个用户的 Agent 运行在独立的 Kubernetes Namespace 中，配合 NetworkPolicy、ResourceQuota 和 RBAC 实现多层隔离。对于更高安全要求的场景，支持 Kata Containers + Firecracker microVM，提供 VM 级别的硬件隔离。

4.3 设计目标三：效率和性能

选择 AWS Graviton (ARM64) 实例作为计算基座，在提供优秀性能的同时降低 20-40% 的成本。Provisioning Service 预置共享 IAM Role，将用户实例创建时间从 3-5 秒优化到 2-3 秒。CloudFront CDN 加速前端访问，静态资源缓存命中率 > 80%。

4.4 设计目标四：可扩展性设计

通过共享 ALB + 路径路由替代 per-user ALB，将基础设施成本从 O(n) 降为 O(1)。Karpenter 自动弹性伸缩节点池，按需调度 Graviton Spot 实例。OpenClaw Operator 的 Reconcile 机制确保最终一致性，支持大规模并发创建。

五、Amazon EKS + Graviton 的优势

本方案选择 Amazon EKS 作为容器编排平台，结合 AWS Graviton 处理器，带来以下优势：

维度	Graviton (ARM64)	x86 同配置实例
性价比	便宜 20-40%	基准
单核性能	优秀（Neoverse V2）	良好
能效比	高（功耗更低）	标准
生态兼容	主流软件均已支持	完全兼容

选择 EKS + Graviton 的关键理由：

EKS 提供托管的 Kubernetes 控制平面，降低运维复杂度

Graviton Metal 实例（c6g.metal）支持 KVM 硬件虚拟化，是运行 Kata Containers 的前提

Karpenter 原生支持 Graviton 实例族，可以按需自动选择最优的 ARM64 实例类型

Spot 实例 + Graviton 组合可进一步节省 60-80% 的计算成本

Amazon ECR 原生支持多架构镜像，简化 ARM64 镜像的构建和分发

六、架构介绍

[图1]

整体架构分为以下几个层次：

6.1 前端接入层

用户通过 Amazon CloudFront CDN 访问平台。CloudFront 提供全球加速和静态资源缓存。用户认证使用 Amazon Cognito User Pool，支持注册、登录和 JWT Token 颁发。认证后的请求通过共享的 Application Load Balancer (ALB) 路由到后端服务。

6.2 Provisioning 服务层

Provisioning Service 是一个运行在 EKS 上的 Flask 应用，负责处理用户的实例创建、查询和删除请求。它从 Cognito 的 JWT Token 中提取用户身份（email），生成唯一的 user_id（SHA256 哈希前 8 位），然后通过 Kubernetes API 创建对应的 Namespace、ResourceQuota、NetworkPolicy 和 OpenClawInstance CRD。

6.3 Operator 控制层

OpenClaw Kubernetes Operator 持续监听 OpenClawInstance CRD 的变化，并自动 Reconcile 出完整的运行时资源栈：StatefulSet、Service、PVC、ConfigMap、Secret、NetworkPolicy 等 9+ 种 Kubernetes 资源。Operator 还支持 RuntimeClassName 配置，可以将 Pod 调度到 Kata Containers 运行时。

6.4 Agent 运行层

每个用户的 OpenClaw 实例以 StatefulSet Pod 的形式运行，包含 OpenClaw 主容器和 Gateway Proxy Sidecar。Pod 通过 Service 暴露 Gateway 端口（18789），并由共享 ALB 统一路由。存储使用 PVC（EBS gp3 或 EFS），数据持久化在独立的卷中。

6.5 架构优势

满足多用户需求：Namespace-per-User + CRD-per-Instance 的模式天然支持多租户

安全隔离到位：Namespace、NetworkPolicy、ResourceQuota、Pod Security Standard 四层隔离

效率和性能：共享 ALB 减少基础设施开销，Graviton + Spot 优化计算成本

可扩展性强：Operator 自动 Reconcile + Karpenter 自动扩缩节点，支持大规模部署

七、运行时选项：标准容器 vs. Kata Containers microVM

本方案提供两种运行时选项，适用于不同的安全和性能需求：

维度	标准容器 (runc)	Kata Containers + Firecracker
隔离级别	Linux Namespace + cgroups	VM（独立 Guest Kernel）
启动时间	~10 秒	~15 秒（含 VM 启动 <150ms ）
内存开销	~1MB 运行时开销	~5MB（Firecracker VM 开销）
CPU 额外开销	无	+100m requests
内存额外开销	无	+200Mi requests
容器逃逸风险	较高（共享内核）	极低（ VM 边界隔离）
合规场景	一般场景	金融、医疗等高合规要求
部署密度	高	中（需要 Metal 实例）
节点要求	任意实例类型	Graviton Metal (c6g.metal)

推荐策略：

默认使用标准容器 (runc) ：适用于内部团队、开发测试、一般生产场景

高安全场景使用 Kata Containers：适用于处理敏感数据、外部客户隔离、合规审计要求

在 OpenClawInstance CRD 中，只需要一行配置即可切换运行时：

spec:
  availability:
    runtimeClassName: kata-fc  # 使用 Kata Firecracker 运行时
    # runtimeClassName: null   # 使用标准容器运行时 (默认)

八、支持的模型提供商

本平台支持多种 AI 模型提供商，用户可以根据需求灵活选择：

8.1 Amazon Bedrock

支持模型：Claude Sonnet 4, Claude Opus 4, Claude Haiku 等 Anthropic 系列

认证方式：EKS Pod Identity（无需手动管理 AWS 凭证）

优势：与 AWS 生态深度集成，数据不离开 AWS 网络，满足数据驻留要求

8.2 SiliconFlow

支持模型：DeepSeek、Qwen 等国产大模型

认证方式：API Key（存储在 Kubernetes Secret 中）

优势：丰富的国产模型选择，按量计费成本可控

8.3 其他提供商

OpenClaw 基于 LiteLLM 的统一模型接口，理论上支持 100+ 模型提供商，包括 OpenAI、Google AI、Azure OpenAI 等。用户可以通过环境变量或 ConfigMap 灵活配置。

九、弹性扩展与存储方案

9.1 Karpenter 自动弹性伸缩

我们使用 Karpenter 作为节点自动伸缩器，替代传统的 Cluster Autoscaler，享受以下优势：

快速调度：直接调用 EC2 Fleet API ，节点启动时间 < 2 分钟

智能选型：自动选择最优的 Graviton 实例类型（t4g, c 7 g, m 8 g 等系列）

成本优化：优先使用 Spot 实例，自动回退到 On-Demand

自动整合：空闲节点 30 分钟后自动回收（consolidateAfter: 30m）

Karpenter NodePool 配置示例：

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: provisioning-graviton
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["t", "c", "m"]
  limits:
    cpu: 100
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30m

9.2 存储方案

每个 OpenClaw 实例需要持久化存储来保存用户的工作空间、对话记录和 Agent 记忆。我们提供两种存储选项：

Amazon EBS (gp3)：

适用场景：单实例独占存储，高 IOPS 需求

配置：每用户 10Gi PVC ， gp3 类型，支持加密

优势：性能稳定，成本低（ $0.08/GB/ 月）

Amazon EFS：

适用场景：需要跨可用区访问，或多 Pod 共享的场景

配置：EFS CSI Driver + StorageClass，自动创建 Access Point

优势：弹性容量，按使用量计费，跨 AZ 高可用

# EFS StorageClass 配置
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: "${EFS_FILE_SYSTEM_ID}"
  directoryPerms: "700"
  basePath: "/openclaw"

十、认证与授权方案

多租户平台的认证授权需要覆盖两个层面：用户认证和 AWS 服务访问授权。

10.1 用户认证： Amazon Cognito

用户通过 Amazon Cognito User Pool 进行注册和登录，获取 JWT Token。Token 通过 CloudFront → ALB 传递到 Provisioning Service，Service 从 Token 中提取用户身份信息（email, sub）创建对应的 OpenClaw 实例。

10.2 Provisioning Service 授权： EKS Pod Identity

Provisioning Service 使用 EKS Pod Identity 获取 AWS 凭证。通过 ServiceAccount 与 IAM Role 绑定，Service Pod 无需硬编码任何 AWS 凭证即可调用 EKS API 管理 Pod Identity Associations。

ServiceAccount: openclaw-provisioner
  ↓ Pod Identity Association
IAM Role: openclaw-provisioning-service
  Permissions: eks:*PodIdentityAssociation

10.3 OpenClaw 实例授权：共享 IAM Role + Pod Identity

所有 OpenClaw 实例共享同一个 IAM Role（openclaw-bedrock-shared），通过各自的 ServiceAccount 与该 Role 建立 Pod Identity Association。这种设计将 AWS API 调用从 per-user 2 次降低为 1 次，IAM Role 数量从 O(n) 降低为 O(1)。

# 共享 Role 架构
Pre-created (one-time):
  └─ IAM Role: openclaw-bedrock-shared
       Permissions: bedrock:InvokeModel*

Dynamic (per-user):
  User 1 → SA (openclaw-user1) → Pod Identity → Shared Role
  User 2 → SA (openclaw-user2) → Pod Identity → Shared Role
  User N → SA (openclaw-userN) → Pod Identity → Shared Role

100 users = 1 IAM Role + 100 Pod Identity Associations

10.4 SiliconFlow 等第三方模型： API Key

对于非 AWS 的模型提供商（如 SiliconFlow），使用 API Key 进行认证。API Key 存储在 Kubernetes Secret 中，通过 envFrom 注入到 OpenClaw Pod。建议结合 AWS Secrets Manager + External Secrets Operator 进行统一管理。

十一、Demo 演示

[图2]

以下展示完整的用户自助流程：

步骤 1：用户通过 CloudFront 域名访问 Dashboard，使用 Cognito 登录

步骤 2：点击 “Provision Instance”，选择模型提供商（Bedrock / SiliconFlow）

步骤 3：Provisioning Service 自动创建独立 Namespace、Pod Identity 和 OpenClaw 实例

步骤 4 ：等待约 30 秒，实例状态变为 Running

步骤 5：通过 OpenClaw Gateway Endpoint 连接到自己的 OpenClaw Agent，开始使用

步骤 6：用户可以配对手机等设备，通过 Telegram/Discord 等渠道与 Agent 交互

十二、总结与展望

本文介绍了基于 Amazon EKS 和 Graviton 构建多租户 OpenClaw AI Agent 平台的完整实践。核心方案特点包括：

Kubernetes Operator 模式：声明式管理 AI Agent 生命周期，自动 Reconcile 9+ 种资源

Namespace-per-User 隔离：四层安全隔离（Namespace、NetworkPolicy、ResourceQuota、Pod Security）

Graviton + Karpenter：20-40% 成本优化，自动弹性伸缩

Kata Containers 可选：VM 级别隔离，满足高合规场景

共享 IAM Role：简化 Pod Identity 管理，减少 50% AWS API 调用

CloudFront + Cognito + 共享 ALB：统一前端架构，95% 基础设施成本优化

未来，我们计划继续探索以下方向：

Agent 自适配能力：利用 Operator 的 SelfConfigure 功能，让 Agent 自主安装技能和调整配置

可观测性增强：Prometheus + Grafana 监控 Agent 性能和模型调用指标

多集群 / 多区域：跨区域部署以满足全球用户的低延迟需求

➡️ 下一步行动：

立即咨询 → 对 OpenClaw 有疑问？联系我们的 AI 专家，获取一对一专业解答。

相关产品：

Amazon EKS — 用于运行容器化应用程序的托管式 Kubernetes 服务
Amazon Cognito — 可在几分钟内实现安全、可扩展和自定义的注册和登录
Amazon IAM — 身份管理以及对 AWS 服务和资源的访问权限
Amazon CloudFront — 可加速 Web 和 API 性能的全球内容分发网络
Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台

相关文章：

十三、参考资料

OpenClaw 项目

OpenClaw Kubernetes Operator

Kata Containers

AWS Graviton Getting Started

Amazon EKS Pod Identity

Karpenter

Enhancing Kubernetes Workload Isolation and Security using Kata Containers (AWS Blog)

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客