架构

Kibotos 在两处处理你的请求：ctrlKibotos 集群的控制面服务。它接收控制面请求，决定每个 Workspace 运行在哪台宿主机上，并签发访问数据面用的会话凭证。 管理 Workspace，运行 Workspace 的 node运行在每台宿主机上的服务。它启动、停止 Workspace 的 MicroVM，并提供数据面服务。 提供 Workspace 里的文件、进程与终端。本页介绍每个请求经过哪些组件，以及这对调用方式有什么影响。部署和运维 Kibotos 见安装。

组件复制标题链接

flowchart LR
  K["你的程序<br/>kibo / 原生 API"]
  C["ctrl<br/>控制面"]
  N["node<br/>数据面"]
  G["guest agent<br/>MicroVM 内"]

  K -->|管理 Workspace<br/>申请凭证| C
  K -->|文件、进程、终端| N
  C -->|调度、启停| N
  N -->|vsock| G

用 kibo 或原生 API 时不经过任何网关。用 E2B SDK 时，E2B 网关代替图中「你的程序」一侧：它替你调用 ctrl、申请凭证、连接 node。公开 URL 的访问经 Exposure 网关转到 node，网关每次向 ctrl 取一个只对这次请求有效的凭证。

一次请求怎样走复制标题链接

创建 Workspace：

1. 你向 ctrl 发出创建请求。ctrl 接受后立即返回，Workspace 处于 CREATING。
2. ctrl 选一台有足够资源、能访问所需存储池的宿主，必要时先在那台宿主上准备 Template。
3. 宿主上的 node 启动 MicroVM，guest agent 就绪后 Workspace 变为 AVAILABLE。

kibo workspace create 默认等到这一步；用原生 API 时，轮询 Workspace 状态或查询创建命令的结果。

在 Workspace 里执行一条命令：

1. 你向 ctrl 申请一个数据面凭证，响应里带着运行这个 Workspace 的 node 地址。
2. 你带着凭证直接连到这个 node，请求启动进程。
3. node 经宿主与 MicroVM 之间的 vsock 通道交给 guest agent 执行，输出沿原路返回。

ctrl 不在第二、三步的路径上。

对调用方的影响复制标题链接

• 先申请凭证，再访问数据面。 凭证有效期短，过期后重新申请即可。kibo 和 E2B 网关会自动申请和续期。
• 重新启动后旧连接失效。 每次启动都是新的执行代，上一代的凭证、进程和连接全部作废，需要重新申请凭证、重新启动进程。这也是停止再启动后不保留进程和内存的原因。
• 宿主故障时连接中断。 正在进行的文件传输和进程连接会断开。部署方确认这台宿主已经失效后，上面的 Workspace 变为 FAILED；之后可以直接再启动，Kibotos 会把它们放到另一台能访问其存储的宿主上。数据保留规则见保证与边界。
• 数据面地址可能变化。 每次启动可能落在不同的宿主上，不要缓存 node 地址，每次以凭证响应里的为准。

两种 MicroVM 后端复制标题链接

部署方可以用 Firecracker 或 KiboVM 运行 MicroVM。两者提供同样的 API，对调用方基本透明，差别只在 guest 里自己重启或关机时：

要停止或重启 Workspace，使用 Kibotos 的停止与启动接口，不要在 guest 里关机或重启。细节见服务端自行处理的停止与重启。

下一步复制标题链接

• 保证与边界：哪些数据在什么情况下保留，网络与隔离的边界，出了问题会看到什么。
• API 概览：两个入口的地址、认证与协议细节。