# 利用 Amazon EKS , Kata Container 构建通用 AI Agents 平台

> **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。
> 
> **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/
> 
> **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。

## 一、基础信息

- **会议类型**：专题演讲
- **Persona**：AI 基础架构师
- **时间信息**：6月23日 | 14:00 - 14:30
- **标题**：利用 Amazon EKS , Kata Container 构建通用 AI Agents 平台
- **PDF 资料**：有
- **视频回放**：有

## 演讲人信息

### 会议信息
- **地点**：上海世博中心（2026 亚马逊云科技中国峰会）
- **日期**：2026年6月23日（Day 1）
- **时间**：14:00 - 14:30
- **会议类型**：专题演讲
- **面向 Persona**：AI 基础架构师

### 亚马逊云科技演讲人
- **粟伟**：资深解决方案架构师

## 二、会议资料 PDF 转录内容

--- Page 1 ---
2026年6月23日-24日 上海·世博中心

--- Page 2 ---
3 0 1
利用 构建
Amazon EKS, Kata Container
通用 平台
AI Agents
粟伟
游戏行业资深解决方案架构师
亚马逊云科技

--- Page 3 ---
议程
• 挑战与选型
• 方案概览
• 实战经验
• 方案演示
• 总结与展望

--- Page 4 ---
为什么选择
Amazon EKS, Kata Container

--- Page 5 ---
多租户 AI Agents 部署面临的挑战
AI AGENT 现有需求： 传统容器隔离不足：
共享内核 = 共享攻击面
执行 shell 命令与 pip install
文件系统读写（I/O 密集） 容器逃逸 CVE 每季度发布（runc, OverlayFS)
多租户并行，互不干扰 namespace + cgroups 无法阻止内核级攻击

--- Page 6 ---
AI Agents 集成挑战
WebSocket vs Webhook
ASPECT WEBHOOK (HTTP CALLBACK) WEBSOCKET (PERSISTENT)
方向 Platform → Agent（入站 HTTP） Agent → Platform（出站 WS）
基础设施 需公网 Ingress / ALB + TLS 无需公网端点
NAT / 防火墙 需开入站端口 仅出站，防火墙友好
延迟 每消息一次 RTT 持久连接 <100 ms
可靠性 需处理重试 / 去重 内建自动重连
扩展性 无状态，易负载均衡 粘性会话 per connection
WebSocket-First 对 Kata 沙箱最理想—无需入站路由，简化 NetworkPolicy:deny all ingress, allow selective egress

--- Page 7 ---
AI Agents 集成挑战（续）
HERMES AGENT OPENCLAW AGENT
Hermes OpenClaw
CONNECTION CONNECTION
WebSocket → 飞书/Lark;长轮询 → Slack/Telegram WebSocket + Webhook 混合模式
INFRA PLATFORMS
无需 Ingress/ALB — 纯出站连接 20+ 平台 — Feishu, Slack, Telegram, Discord, Line, Matrix, Teams
PORTS COMPLEXITY
8642 (API) + 9119 (Dashboard) 内部访问 Webhook 模式需 Ingress + TLS — 增加网络复杂度
RUNTIME RUNTIME
Go 二进制 · gosu 降权 UID 100 · config.yaml + .env Node.js · UID 1000 · Port 19001 · OpenClaw.json 配置
OpenClaw (MIT License) · github.com/OpenClaw/OpenClaw
Hermes Agent (MIT License) · github.com/NousResearch/Hermes-agent · © Nous Research

--- Page 8 ---
Amazon EKS、Kata Container 的优势
传统 VM 方案的痛点 Amazon EKS + Kata Container 方案的优势
✓ 声明式管理 — YAML 驱动，版本控制，GitOps 友好
运维复杂 — AMI 打包、版本管理、滚动更新
✓ 成本低 — 20 MB/VM;64 GB 节点可运行~3000个
成本高 — 最小单位是整个 VM（~2 GB 内存/VM）
microVM 理论值
冷启动慢 — 2-5分钟；agent 超时
✓ 冷启动快 — 200 ms (CLH) vs 2-5分钟传统 VM
多租户隔离差 — 共享底层 hypervisor
✓ 多租户隔离 — 每 Pod 独立 microVM + 五层隔离
扩展瓶颈 — 手动管理容量规划
✓ 弹性扩展 — 按需创建销毁，无预热
关键差异：
Amazon EKS 是云原生 Kubernetes, 设计来管理大规模 Pod; Kata Container 把 microVM 引入了 Kubernetes 生态

--- Page 9 ---
Amazon EKS、Kata Container 的优势（续）
E2B on Amazon Kata + Kubernetes
基于 Nomad 调度 Firecracker microVM,VM 启动停止提供 API 接口 借用 Kubernetes 完整生态,Kata Containers 无缝对接 CRI 标准接口
01 01
MicroVM 隔离 K8s 生态全覆盖
同样利用 Firecracker 轻量虚拟化 CNI / CSI / CRI 标准网络存储方案
02 02
Nomad 生态 Kata 标准化集成
网络、存储插件远不如 Kubernetes 丰富 RuntimeClass 切换，无需自研生命周期代码
03 03
自研生命周期管理 运维可观测性
VM 启停靠项目代码实现，非标准化方案 复用 K8s 监控、日志、弹性伸缩体系

--- Page 10 ---
方案概览

--- Page 11 ---
架构图

--- Page 12 ---
方案架构介绍
单集群 · 双节点组 关键设计原则
M5/M8i.xlarge Pod 生命周期 = VM 生命周期
LiteLLM · Prometheus · Grafana · CoreDNS 无需管理 AMI,无长期运行 VM
平台控制面与可观测性组件
RuntimeClass 一行切换
kata-CLH / kata-qemu,单字段 YAML 配置
KATA NODES · M8i/C8i
AI Agent 沙箱 — 每个 Pod = 一个 microVM 多 Agent 运行时统一调度
VM 级隔离，独立内核，任意代码执行 Hermes · OpenClaw — 同一基础设施
流量路径： NLB → Kata Pods → Bedrock

--- Page 13 ---
实战经验

--- Page 14 ---
启用 KVM 的嵌套虚拟化
核心挑战
• Kata 需要/dev/kvm
• 第8代 Intel (c8i/m8i)支持 CpuOptions. NestedVirtualization
• Terraform v5.x 不支持（v6.33+ 已支持，但升级有成本）
• Karpenter 社区 PR 已经合并到主分支
解决方案
• 使用 EC2 API 创建启动模板（支持 NestedVirtualization）
• Terraform 引用预创建的启动模板 ID
• Amazon EKS 托管节点组使用自定义启动模板

--- Page 15 ---
Kata Hypervisor · 深度对比
CLH vs QEMU vs Firecracker
推荐（默认选择） 全功能 极致密度
Cloud Hypervisor QEMU Firecracker
启动时间 ~200 ms 启动时间 ~500 ms 启动时间 ~125 ms
内存开销 10-20 MB 内存开销 30-130 MB 内存开销 ~5 MB
virtio-fs：支持 virtio-fs：支持 virtio-fs No
热插拔 Yes initContainers Yes 热插拔 No
initContainers No GPU 透传 Yes 镜像分发 devmapper
标准镜像分发，平衡速度与资源 完整 PCI/USB 设备模型，复杂初始化 需静态资源分配，适合预创建沙箱池
决策 通用沙箱 →CLH 极致密度 →Firecracker 复杂场景 / GPU →QEMU

--- Page 16 ---
Hypervisor · 镜像交付
01 02
virtio-fs (CLH / QEMU) devmapper + virtio-blk (FC)
containerd (host) containerd (host)
→ overlayfs snapshotter → rootfs → devmapper snapshotter
→ kata-shim → virtiofsd (host) → layer = LVM thin volume
→ vhost-user socket → VM kernel → CoW thin-snapshot → /dev/dm-X
→ guest mount virtiofs → rootfs → virtio-blk → Firecracker VM
→ guest mount ext4 → rootfs
标准 overlayfs snapshotter，与普通容器一致 FC 不实现 virtio-fs（最小攻击面）
DAX 映射零拷贝，多 pod 共享底层 layer 镜像以块设备形式交付给 VM
无需 AMI 定制,AL2023 即可 需预配置 LVM thin-pool + devmapper

--- Page 17 ---
Kata Hypervisor · 存储
PATH A · CLH / QEMU PATH B · FIRECRACKER
virtio-fs + overlayfs devmapper + virtio-blk
01 DAX 映射零拷贝，Host/Guest 共享文件 01 LVM thin-pool 块设备交付镜像 layer
02 EFS / S3 / hostPath / ConfigMap 透明传入 02 需专用 EBS 卷 + thin-pool 初始化
03 EFS/S3 需 guest 内变通 — PVC 抽象失效
03 需要 virtiofsd 支持，
PV/PVC 抽象完整保留， virtiofsd 依赖 AMI 定制 + 空间规划必须， 隔离性更高
结论 CLH 是默认选择 —— 80% 的密度收益，20% 的复杂度。virtio-fs 是分水岭。

--- Page 18 ---
Kata Container · 网络
runc 容器路径(kube-proxy 生效） Kata VM 路径（tc-redirect-tap 绕过 iptables）
• VM 内进程 （独立 guest kernel）
• 容器进程 （共享 host kernel）
→ guest eth0 (virtio-net)
→ veth pair
→ tap0 设备 (pod netns)
→ host netns iptables PREROUTING
→ TC mirred redirect （L2 层） ★
DNAT: ClusterIP → Pod IP ✓
→ veth → host netns
→ routing → FORWARD → POSTROUTING
→ VPC CNI 策略路由 → ENI
→ ENI → VPC 路由
iptables DNAT 被绕过 ✗
tc-redirect-tap
# VPC CNI 策略路由(ip rule)
# VM→Host: tap ingress → veth egress
from 10.1.12.45 lookup 2 # Pod IP
tc filter add dev tap0 ingress \
route table 2:
action mirred egress redirect dev eth0
default via 10.1.12.1 dev eth1
# 结果：L2 帧直接转发，不触发 netfilter
# ClusterIP 172.20.x.x 无匹配 → 丢包
结论：凡需要 kube-proxy 参与的路径均不可达；凡走 VPC 原生路由的路径均可达

--- Page 19 ---
Kata Container · NLB + VPC DNS
DNS 修复:dnsPolicy: None + VPC DNS
可达性矩阵
spec:
目标类型 可达？ 原因
dnsPolicy: None
dnsConfig:
ClusterIP ✗ iptables DNAT 被绕过
nameservers:
NodePort ✗ 同上
- # VPC CIDR base + 2
CoreDNS (ClusterIP) ✗ DNS 10.96.0.10 不可达
searches:
Pod IP（同节点） ✓ L2 直达 - "svc.cluster.local"
Pod IP（跨节点） ✓ VPC 路由（真实 IP)
NLB 解决方案 & 跨 AZ 必要配置
Node IP + hostPort ✓ 目标节点 iptables 处理
annotations:
Internal NLB ✓✓✓ 真实 VPC ENI ← 推荐
aws-load-balancer-type: external
NAT Gateway（外网） ✓ VPC 路由
aws-load-balancer-scheme: internal
aws-load-balancer-nlb-target-type: ip
三种方案对比
load_balancing.cross_zone.enabled=true
# cross-zone 必须开启！
Internal NLB hostPort Pod IP 直连
生产推荐 开发/测试 高复杂度
# 否则跨 AZ 目标静默失败

--- Page 20 ---
经验教训
• IaC 工具链选择
• Kata + VPC CNI：部署前完整测试网络路径
• 容器镜像兼容性 — CLH 不支持 initContainer | EFS/NFS 不支持 Firecracker
• 网络隔离的#1 惊喜：ClusterIP 不工作 → 必须使用内部 NLB
• 启动延迟可驱动 — Hermes Pod 20秒快速部署
• per-Kata 节点监控 — Firecracker devmapper pool 利用率

--- Page 21 ---
关键技术点#1 cpuOption 支持
Karpenter PR #9043: aws/karpenter-provider-aws
cpuOptions 已经支持（NestedVirtualization 参数）
影响与解决方案
• Amazon EKS Managed Node Group + 预创建启动模板（混合 IaC）
• 亚马逊云科技 CLI 创建启动模板（支持 Nested Virtualization）
• Terraform 使用 data source 引用模板 ID
• Karpenter 已经支持提供成熟的弹性伸缩方案

--- Page 22 ---
关键技术点#2: Webhook 实践
问题场景:WhatsApp/iMessage 等仅支持 Webhook
• Webhook 必需:ALB Ingress + TLS 证书 + 公共 IP
• Kata 中的 Webhook 架构：
1. ALB Ingress 在 Core Nodes (m5.xlarge)
2. Core Node → Pod IP (Kata VM)代理层
3. 代理使用内部 NLB 或 Pod IP 直连
• Webhook 最佳实践：
✓ 签名验证（HMAC-SHA256）— 防止伪造请求
✓ 幂等性处理 — 去重（消息 ID + 时间窗口）
✓ 超时 + 重试策略 — 平台会重试失败请求
✓ 速率限制 — 防止代理过载（bucket algorithm）

--- Page 23 ---
关键技术点#2： Webhook 实践（续）
#1: Webhook 回调来源 IP 隔离失效
• 问题:ALB Ingress 代理 → 所有 Kata Pod 看到同一源 IP (ALB IP)
• 风险：无法用 sourceIP 做 tenant 隔离
• 原因：ALB 代理层，真实租户信息在 HTTP Header 中（X-Forwarded-For）
• 解决方案：必须解析 X-Forwarded-For + 签名的 webhook payload 中的 tenant 标识
#2: Webhook Request Timeout 与重试风暴
• 多租户高并发场景：单个 Kata Pod 接收 N 个租户的 webhook
• 平台(WhatsApp/iMessage)的默认 timeout = 3-5秒
• 如果 Pod 处理缓慢 → 超时 → 平台重试（指数退避）→ 请求风暴
最佳实践：
• 快速返回 202 Accepted，异步处理消息到队列（SQS/Kafka）
• 实现 Circuit Breaker 防止重试雪崩

--- Page 24 ---
迁移路径：从现有容器 → Kata 容器
Phase 2: PoC(1-2周） Phase 3: 生产(1-2周）
Phase 1: 评估（1周）
• ✓ 配置 ALB Ingress + WebSocket
• ✓ 审计现有容器镜像： • ✓ 部署 EKS + Kata Nodes
/ NLB
initContainer 依赖 (m8i.4xlarge)
• ✓ 多租户隔离:NetworkPolicy +
• ✓ 检查应用 syscall 兼容性（• ✓ 修改 Dockerfile 移除
RBAC
strace -f -e trace=all) initContainers
• ✓ 监控:Prometheus + Grafana
• ✓ 识别 EBS/持久存储需求 • ✓ 创建 K8s RuntimeClass: kata-CLH
on Core Nodes
• ✓ 容量规划：估算内存、CPU、 • ✓ 部署5-10个 sample Pod 测试
• ✓ 灰度部署：10% → 50% →
IOPS
100%
关键迁移
• initContainer 兼容性 — CLH 不支持，需改到 entrypoint
• ClusterIP 不可达 — 必须改用 NLB 或 Pod IP 访问
• 镜像首次拉取慢 — 30-60s,需调整 readiness probe timeout
• Firecracker devmapper pool — 需要定制 AMI + systemd Service

--- Page 25 ---
方案演示

--- Page 26 ---
演示

--- Page 27 ---
总结 答疑
&

--- Page 28 ---
总结
• Amazon EKS 托管控制面，大幅降低运维复杂度
• Nested KVM + Kata VM 边界，硬件级隔离防止容器逃逸
• CLH 微虚拟机200 ms 启动、10-20 MB 开销，单节点可运行数十个隔离沙箱
• 标准 K8s API + RuntimeClass 一行切换，应用层改造极小
• AI Agent 安全执行代码，WebSocket 网关零入站暴露面

--- Page 29 ---
参考资料
• OpenClaw MIT github.com/OpenClaw/OpenClaw
• Hermes Agent MIT github.com/NousResearch/Hermes-agent
• Kata Containers Apache 2.0 github.com/kata-containers/kata-containers
• Firecracker Apache 2.0 github.com/firecracker-microvm/firecracker

--- Page 30 ---
Thank you

--- Page 31 ---
Thank you

## 三、会议回放视频转录内容

谢谢大家，我叫粟伟，我是亚马逊游戏行业资深解决方案架构师。
今天我带来的主题是利用 Amazon EKS 以及 Kata Container 来构建通用的 AI Agent.
首先的话就是我这块的话就是我们会去快速的去看一下，就是我们现在构建一个 AI Agent 的这个平台，我们遇到的一些挑战和选型。
然后我会在今天的话我会去讲解一个基于我们的 EKS，也就是前面一个 topic 的嘉宾提到的 Kubernetes 的平台，以及开源的 Kata Container 的一个方案。
我们会详细的去讲一下我们在这个构建这个方案中间的话遇到一些挑战吧，就是方案的经验，然后最后有个方案的演示。
那为什么要选择 Amazon EKS 和 Kata Container?
那首先来说的话就是因为从2026年1月份开始就是 OpenClaw 发布之后，就是市面上的 micro-agents 都卖断了。
那同时其实很多企业，因为我们有很多2B 的客户，他们就找到我们，他就说就是我如何运用 Amazon EKS 的这种 AI infra 就是底座来构建我一个企业，比如说我一个部门可能有一百个人，那我需要安装 OpenClaw 以及这样的需求。
那其实我们稍微分析一下的话，其实无外乎是说他的挑战有以下几个第一，你的权限怎么样分配，每一个 Agent 他都需要调用大模型对吧，那你的权限怎么分配。
第二，你 Agent 和 Agent 之间的沙箱怎么定义？那通常情况下企业实际上是不太允许把 OpenClaw 这种东西安装在自己企业配置的比如说笔记本上面，因为它可能有些安全的问题。
那所谓沙箱的隔离，然后它的资源的调用，那这些的话，很多企业当然也在用类似于像 Docker 这种技术，但是在传统的 Docker 技术下面的话，仍然会有些容器逃逸的这种问题，就是安全问题。
那我们基于这一招的话，另外还有两个也是挑战方向。就 OpenClaw 它擅长的其实是和 Channel，就是如果你了解 OpenClaw 的话，以及 Hermes 的话你就知道它会有一个 Channel，什么叫 Channel，比如说飞书企业微信，还有国外的 Slack, WhatsApp 等等。
那这些 Channel 往往是需要两种连接方式，一种叫 Webhook，一种叫 WebSocket，比如说飞书，那我们自己也有这个亚马逊配置的飞书，或者你用个人飞书的时候，你可以尝试着用 WebSocket 去连，然后你去配置 Slack 的时候，你也可以选 WebSocket 和 Webhook.
那这为什么是一个挑战呢？Webhook 一定需要对方，就是你的服务方，比如说 Slack，它去处理，就是你会需要一个对外暴露的 endpoint，就是一个对外暴露的 HTTP 端点。
那这个问题是这样的，你一个人可能比较好解决，那一个企业比如说100 多员工，甚至200 多员工，500 多员工，那你怎么样去管理这些 Webhook，对吧？
这其实也是一个面临的挑战，因为它会有潜在的安全性。在我们的这个方案里边，主要是针对两种 agent 进行的支持，一种就是 OpenClaw，一种就是 Hermes.
那这两种之间的话，它其实有一些区别，先出来的是 OpenClaw，那它提出了它有一个核心的 agent core，它有一个叫 Gateway，那 Hermes 后面的话，它也会参考这种架构。
那这两个看来的话，因为这两个都算比较，就是为什么我那个演讲的主题叫通用 Agent 呢？就是说我们认为这两个是比较主流的，所以说我们后面的方案的话也是围绕着这两个来做。
他们的语言在 Kubernetes 上面不是什么问题，一个是 Node.js，一个是 Go lang，那这个都是天然支持的。
那么我们来回到我们刚才谈的底座，前面讲了，对于亚马逊云科技来说的话，我们的容器服务有 EKS，有 ECS，那 EKS 的好处是说它兼容现在 Kubernetes, Kubernetes 的体系，不管你的镜像的打包，
还是你的部署甚至 Pod 的调度，它有一整套体系，目前应该是企业在进行一些弹性伸缩中间是一种典型的，比如说前面讲的 GPU，对吧，你是 EKS，那我们这里的 Agent 的平台其实选择的也是 EKS，而且它天然支持 Intel CPU 和我们自己的 Arm 的 Graviton 的自研芯片的这个 CPU.
那为什么选择 Kata Container 呢，就这里要稍微多讲一下，因为前面提到的话，其实 Docker 的话，它其实是基于 Namespace 和 cgroups 的这种技术吧，就是它其实不是物理的隔离，其实除了 Docker 之外，就是市面上还有一种叫 MicroVM 的技术，比如说，
亚马逊自己的开源项目 Firecracker，他就是用一个 Rust 写的这个 MicroVM 的这个框架，包括我们自己的 Lambda 其实都是基于 MicroVM 的，就是 Firecracker 的。
他的好处是说，他会利用到 KVM，在 KVM 上面使用一种叫嵌套虚拟化的技术，或者叫 Nested VM 的技术，那在这个上面他得到的是一个真正的虚拟机的，就是它虽然是个进程，但是它用了内核里边 KVM 直接使用到虚拟机的能力，它是完全独立的，就是它每个容器之间。
所以说，基于这个的话，我们的方案就选择了 EKS 加 Kata Container 的结合。
其实如果对亚马逊比较熟悉的话，而且你也在做 Agent 的话，因为之前我记得在上一次的时候，其实我们有同事去讲了另外一种方案叫 E2B on Amazon.
它其实是说用 Nomad 去调度我们的 Firecracker，去启动了很多沙箱。那这些沙箱用来干嘛？就是给 Agent 使用。
那不论是 Agent 自己还是说，我 Agent 在执行程序的时候我去调它，那也是我们现在的一个公开的开源方案。
那今天的这个方案和这个方案有一点点不同，那个方案它用的不是 K8S 的那个生态，那今天我们的这个方案的话就是完全兼容 K8S 的，就是 K8S 用的部署的，比如说你的运维团队已经很熟悉 K8S 的，那你都可以使用这一套。
我们来看一下价值。那首先的话就是说在设计这个方案的时候，我们分成两个组节点，一个的话是我们的控制平面，就是 Core Node Group，它主要是有这么几个功能。
因为在 Agent 里面现在大部分的 Agent 其实是支持的可观测性是支持的比较好的，而可观测性里面有几个我们是通常会选用的，比如 Prometheus, Grafana，然后使用的协议是 OpenTelemetry，那这些的话我们都放在这个 Core Node Group 里面。
同时的话我们还引入了另外的开源项目，就是 LiteLLM，为什么要引入它呢？因为如果你使用过亚马逊的 Bedrock 的话，就是你可能会了解，我们的 Bedrock 其实是走的是 IAM，就是亚马逊你会在 IAM 里面去配，对吧？
那这是很多企业，它其实有更小的颗粒度的配置的方式，它比如说每个月我给你的 quota 就给10 刀或者20 刀，那这些 quota 的配置其实现在的 LiteLLM 以及一些第三方的这种，你可以理解为 Proxy，它其实是可以做到这样细粒度的分发。
所以说这里的话其实我们放了一个 LiteLLM，主要是解决你员工在使用具体的 agent 的时候，我可以细粒度的对它的使用的资源进行一部分分发。然后总结一点的核心的目的话就是我来控制，我来控制。
就是在企业里面其实通常员工的话，这肯定是个多租户的系统，那每一个员工打着比方叫 A 员工，他要使用 Hermes 的 agent，那在这里他就可以启动起来，你通过一个 YAML 文件或者是 UI，你向控制平面发出指令，他就启动起来。
那同样的 OpenClaw 以及很多类似 OpenClaw 的这样的 agent 我们都可以在这个 Node Group 里面去启动，那这个 Node Group 里面的话，因为它用到 KVM 虚拟化，在我们的8 系的机器，比如说8i的这种机器里面，我们都天然支持了。
最早的时候其实是需要裸金属的，现在不需要了，你要去启动8i的机器，比如说8i就是 c8i.xlarge，就这样的机器，你就可以启动去进行部署。
那它外围的话还一些其他的，比如说我们会放一张 ALB 去解决 Webhook 的问题，因为 Webhook 的其实它是内部连，它不需要。那 Webhook 的话就是用 ALB 来解决，这就是整体的这个架构图。
那就这就已经讲了，那核心的一点就是说我们把它优化成了一个标准的 K8s 的方案之后，你可以通过这种 yaml 文件去切换，这个后面我也会去讲，其实它其实是有不同的 hypervisor，它既会 Kata 的话，它既会支持它自己的也会支持 firecracker，这个后面也有实战经验。
那坦白的说，就是因为这个是偏 infra 的，就是这个方案的核心的话，其实就是利用了 Kata container 的嵌套虚拟化，就是以及亚马逊的这个第八代的 Intel 的机器。
它就是你在启动的时候，你其实要启用这个 KVM 的开关，它才能得到就是 KVM 级别的这种隔离。
那同时的话，我们也遇到几个小坑，比如说我们最早设计的这个方案的时候，当时的 Terraform 的模块，就是 v5 的这个版本，它其实不支持，不支持这个 nested virtualization 的这个配置，
那就导致了启动起来，你启动的其实是普通的 EC2 的这个节点，而不是这个嵌套虚拟化的。
然后另外的话，这段片子其实是上周才改的，Karpenter, Karpenter 是什么呢？
它是一个支持 Kubernetes 的虚机水平扩展管理的一个组件或者叫一个服务。
你可以通过 Karpenter 快速的拉起机器，打个比方，比如说你要拉一千台机器，对吧？
那你这个时候你传统的话是走的 ASG，弹性伸缩组，那这个时候其实你有一条 Karpenter，它其实就像一个 operator 一样，你给它一个 yaml 文件，你配置，你说我需要一百台机器，那它就可以很快的。
而 Karpenter 到上周为止，它有一个重要的 PR 已经被合并进去了，就是这个嵌套虚拟化。
那有了上面的这些挑战的话，其实我们给了很明确的方案。
在这个方案里边，你可以以多种方式去创建、支持嵌套虚拟化的 Kubernetes 机器。
那我们下面再来看一下，就是 Kata Container 的 hypervisor，你可以理解成他们对的就是 Docker，他们就是对的 Docker.
那这里的话其实有三种，CLH 是它的一个缩写叫 Cloud Hypervisor，就是 Kata 自己也是开源的，这里面这些都是开源的。
然后第二个是 QEMU, QEMU 是个老牌的，老牌的这种相当于虚机管理的。
然后另外就是 Firecracker，其实我们当时在做这个方案的时候也比较纠结，因为上一个 E2B 它其实是用的 Firecracker,
那我们也尝试着，就是这个方案是支持 Firecracker 的，但是有着很大的问题，有着区别不一样，就是大家看一下这种 Virtual IO FS，前面两个都是 yes, Firecracker 是 no.
这个不是场景问题，这是设计，因为 Firecracker 它强调的就是安全，它不能直接对一个文件系统进行读取，它必须读取什么呢？
Block 设备，就是让它挂载，行，你要先把它变成一个文件或者叫一个 block，一个 block 的设备，它才能在虚机启动的时候加载。
那这个就还是带来一些小小的不便，就是我们在做整个方案的时候，因为如果咱们在座的这个嘉宾都用了 Docker 的话，
就你可能会知道 Docker 它可以直接访问宿主文件，但是如果你没有 Virtual IO 的话 Firecracker，哪怕你在宿主上面启动了 KVM,
microVM 它也不能访问宿主文件，因为它没有这个驱动，那两者有，但是这就有一点隐形的问题，它其实也是通过一个组件去实现的。
就是如果这个组件挂掉了之后它的设备也会挂住，那这里做这个比较的话，其实我们方案就先测的是 QEMU, QEMU 是最完整的，
但是如果你要安全性非常高的话，建议是用 Firecracker，你要折中的话你就选 CLH，这就是那个 Hypervisor，就这里稍微多讲一下。
然后另外的话 QEMU 的话，它的 Docker File 里面打包的文件它不一样，它没办法去启动一个叫 initContainer 的，
就是 initContainer 是做什么呢？是它的 Container 不是具体执行服务的，它是启起来就在 Pod 里面，它是启起来去启动其他 Container 的，去检查一些准备中做的，那在 QEMU 里面它的 VM 其实不支持的。
对，这个就是一些具体的，就是我刚才讲的它那个设备，你会看到的话，因为 Firecracker 它不支持嘛，它的受攻击面程度是最小的，
你所有的文件它都要打成 Block，它是一个文件，但是实际上是一个 Block 进行 VM 的加载，而其他那些的好处是说我可以把容器化的利用起来，就宿主的，不好意思。
然后它们就关系到存储，那首先来说的话，从因为 Kubernetes 里面它自己会有自己的卷管理方式，就是 PV 和 PVC,
那前面两个 Hypervisor 的话，天然就支持了，就是你通过 Virtual IO FS 的这个组件，那你可以使用到 PV 和 PVC，你在 Kubernetes 里面定义的 EBS 也好，S3, FileMount，就是 S3 这个端点也好，它都可以直接的使用，然后 Firecracker 的话它本身要在 VM, MicroVM 启动之后，
在内部通过网络去进行挂载，而不能使用 PVC 的这一层抽象，然后接下来的话就是说 Kata 和 Docker 有一个区别，就是在 Kubernetes 里面，runc 是标准的 Container 的实现，那 Kata 因为它用的是 MicroVM,
所以说它的区别是说路由，就是 ClusterIP 它都不支持，后面也单独的去讲，就是网络大家记住一点，就是你用 Kata 你就不要用 ClusterIP，这是一条定律，你用的话什么都不通，就是这里，那 Kata 之间的服务这里其实亚马逊云科技的网络非常好，
我们提供一个叫 VPC CNI，这是很多年前就支持的，它的好处是把整个 POD 全部使用上 VPC 的 IP，你可以理解成是个物理 IP，它是绑在 ENI 上的，那由于有这层支持，你所有的东西都可以跳过那个 ClusterIP，所以说它是贴合支持的，
然后再加上通过内部的 NLB 去做你的 Service，那这个就是教训，就是经验教训的话就是我们选择 IaC 工具链的时候要注意一下版本，要注意一下版本，然后网络目前这个方案，它仅支持 VPC CNI，因为我知道其他还有其他的网络组件跑在 ENI 上面，但是在这个方案里边的话，我们只支持这个 VPC CNI,
然后容器的这个兼容性，那容器兼容性的话，其实在 POD 的组装的时候有一些小的区别，因为 CLH 和 QEMU，天然支持这种 Docker 打包的，它打包命令和 Docker 一样，
然后另外的话网络隔离，隔离的话就是它肯定是 ClusterIP 不工作嘛，你必须使用 NLB，然后启动延迟的话，因为它是 micro VM，那目前来说的启动都非常快，
然后这个其实不用讲了，就是它已经支持了，因为最早写这个片子的时候它也不支持，它的那个 PR 号叫9043，如果对看源码感兴趣的话，你可以看一下它究竟实现什么，那因为这个实现了之后它的调度可以由 Karpenter 完全的接管，
然后 webhook 的话，就是要注意一点，就是因为亚马逊云科技一直我们一直的强调安全，那默认情况下的话，ALB 的话就是强烈建议你要启用 TLS 证书，不管是你自己导入证书还是使用 ACM 证书，那你一定要启用这个证书，那因为我们也有自己的 ALBIngress,
所以说它天然的就支持像一些海外常见的 IM，什么 slack, iMessage 这种，它只支持 webhook 的，你把这个 ALB 的那个 controller 配置进去就 ok 了，然后 webhook 就是回调，就是在这个里面的话，因为我前面讲了，Kata 它其实用的就是那个 VPC 原生的路由的，
所以说你在 ALB 里面你只要开启就是保持那个 header，就是你去打开一个 X-Forwarded-For 的那个 header，它最开始是外部的哪个投递端，掉进来就行了，那迁移如果我们比如说在座的咱们的那个嘉宾觉得这个方案 ok，那迁移大家要花多少时间，那首先是这样的，
首先的话建议大家要评估一下现有容器镜像的 Dockerfile，看一下他们对 initContainer 的依赖，就这个你要去 check 一下，然后还有一点你要去检查一下你应用在 SysCall 这个兼容性上面，它的一些区别，
还有一点就是对 PVC 有没有依赖，因为如果你 PVC 有依赖的话你就不好选 Firecracker 就做起来比较麻烦，你就直接选 hypervisor 的时候就选 CLH 以及 QEMU，这是评估，然后第二部分就是 PoC，那可以联系我们亚马逊对吧，相关的这个同事，那我们因为这个方案已经发布在网上，所以说的话就是说直接可以下下来，
然后我们就去启动相应的机器，把你的 Dockerfile 迁移过来，如果没有 initContainer 的有的话就让大模型重新写一个也写得很快，然后去配一个这个 RuntimeClass，就是 Kata hypervisor，那如果你开始觉得不放心的话不知道怎么选的话，你就选那个 QEMU 就行了，
然后接下来的话就是 PoC，我们再看结果，如果 ok 的话我们就迁移，因为它整个一套是基于 K8s 的，所以说在 K8s 上面部署 OpenClaw 和 Hermes 的话这个可以非常非常迅速，
好，刚好还有几分钟就把方案演示一下，这是我录的一个动画，我播放一下，
对，其实这个动画没有声音，我就带来讲一下，它其实就是我们在项目里面就设置了一个一键安装，那一键安装的话这个过程是 Terraform 写的，它就会去拉一个集群，中间我有简剪，就是说它会拉一个集群，那拉完之后的话就是它比较长的时间，就整个拉集群的时间，要稍微长一点，它会拉一个 EKS 集群，
拉了之后的话你会看到的话就是说它这里就要求你去配 LiteLLM 的 master key，就 admin key，以及我这里用的飞书，你也可以不用飞书，用其他的，以及你去配这飞书的 webhook URL，就是 channel 的 WebSocket 的，它就会去配，
那它也给了你一些这个提示的信息，这样的 webhook URL 的话就会在对应的这个 channel 的控制台里边去做，
然后，
这个应该是，不好意思，还在放，对，这个就是几个 webhook URL，这个 webhook URL 很重要，如果你这个 LiteLLM，你没有 master key 的话，你就没办法为你的员工分发后面的 key 了，那这个的话就是典型的一个 YAML 文件，
这有点小，这个其实就是 Hermes 的那个 agent，那我要把这些东西配给它的 agent，配了之后你会看到它就创建了一个沙箱，
那同样的如果你是100 的用户怎么办，其实只需要那个 webhook URL 不一样，你就可以，就是一个 YAML 文件加一个小程序之类的，
它每一个 Pod 起起来的话，其实就是一个完整的 agent 这个工作的一个环境，你会看到它已经起起来了，
对，这就是内容它已经接上了，因为我测试的话就是联系了我们的飞书，那这里的话你会看到其实它的方案后面可能大家都用着，其实就是很典型的 Hermes 的这个聊天方案，
那对，就大概就是这样，它中了没什么区别，只是说这个环境它部署在那个 EKS 和 Kata 上面了，就是它完整的都支持，包括 sql 和其他的，就我人家写了什么小程序这些，对，它先回答了就是 received 一个 l，我已经收到了，然后它就开始写小程序，写那个 writer 文件，
因为它可以用到那个 PVC 和其他的，所以说它的文件也可以落盘，然后就是我稍微总结一下，就是我们是就是在这个方案里边，我们充分利用了亚马逊的 AI infra 的底座，那也就是 Amazon EKS 以及开源项目 kata container，我们来构建了这个方案，那这个方案主要是针对，就是现在企业内部需要，
也不是叫大规模吗，需要部门级部署 OpenClaw 以及 Hermes agent 的这种企业的需求，这一点，然后第二点的话，我们充分的利用了我们八代以后的机器，就是八代 Intel 以后的机器，就是8i的这个机器的，
嵌套虚拟化的这个功能，然后再加上 kata 的这个 hypervisor 以及我们自己的 firecracker，那这样的话，其实我们在我们是内核就是 KVM 级别的隔离，然后第三个的话，就是说我们可以在 kata container 里边选择不同的 hypervisor 来适合我们的这个需求，那第四点的话，就是说整套方案都是基于 K8s API 的，所以说你要做改造这些都是比较好，
比较方便的，那我们也是在这个方案里面进行的最小化暴露，所有的 webhook 都会走到我们的 ALB Ingress，那同样的，因为 ALB Ingress 也可以通过我们的 WAF 就防火墙进行保护，就是基本上是最小化暴露，这就是一些，
引用到参考资料，好，谢谢大家。