Kairon

Kairon

VM 不会伪装成 Pod。

由 Kubernetes 调度、直接运行在 KVM 上的真实虚拟机。 每台 VM 不需要单独的 virt-launcher Pod，热路径中没有 libvirt，也不需要一大堆 Operator。Machine 表示期望状态，kairon-controller 负责调度，kairon-node 则通过 FluxVM 使用 QEMU、Cloud Hypervisor、Firecracker 或 FluxVM 自有的 Hypervisor 运行它。

每台 VM 零 Pod · 四种 Hypervisor，一个 CRD · 每台 VM 的边缘节点都运行 eBPF · 不会悄然发生脑裂 · 内置 AI Agent（MCP）

_{此仪表板演示使用本地示例数据栈录制（查看方法），并非生产集群。}

最新动态

实验性运维： Kairon Rehearsal 在隔离的 CSI 副本上测试升级。高级运维新增健康检查门控的配置变更计划、应用恢复验证、基于流量/RTT 的放置建议，以及带修复验证的事件复现。包含可运行的场景和故障路径测试。VM/CSI 和主机隔离的硬件资格验证仍在等待中。

自 v0.6.0 以来的新增内容（最新标签：v0.10.2；截至事件包的各行内容均为 v0.10.0 新增）：

为什么选择 Kairon

数据一览

使用相同的 k3s 节点、相同的 Ubuntu 24.04 镜像、相同的 1 vCPU / 512 MiB 客户机和 cloud-init 种子，由同一个脚本驱动两者；就绪的定义是客户机的 sshd 开始响应。无论采用哪种方式，VM 本身的成本都相同；你省下的是 KubeVirt 围绕 VM 添加的一切。测试方法、原始 JSON 和注意事项（包括 10 台 VM 的测试）：docs/benchmarks。

Kairon 与 KubeVirt

移除每一层，就少一件需要打补丁的东西，少一份需要阅读的日志，也少一个可能在凌晨 2 点崩溃的进程。

之前的技术栈插图：docs/assets/kairon-vs-kubevirt.jpg。

你将获得什么

Machine，而非 Pod

Machine 和 MachineSet 支持实例类型、NUMA 和 CPU 绑定、Windows 来宾、PVC 和 CSI 启动、多卷 virtiofs、CPU/内存热插拔、暂停和停止、cloud-init 以及端口转发。期望状态保存在 Kubernetes 中；节点每隔几秒就会协调一次。已交付功能 →

kaironctl create demo --image /var/lib/fluxvm/images/ubuntu.qcow2 --cpu 2 --memory 2Gi --backend qemu
kaironctl get machines

拒绝猜测的迁移

冷迁移、节点疏散，以及通过相互 TLS 和加密数据平面进行的安全实时迁移。封锁节点后，控制器可以为你疏散该节点上的 Machine，并由 MachineDisruptionBudget 控制速率。提交状态不明确时，Machine 会进入 NeedsRecovery 并等待操作员处理，而不是冒险同时运行两个副本。迁移 → · NeedsRecovery 操作手册 →

每台 VM 上的 eBPF 边缘层

每个 VM tap 都使用 FluxVM 的 eBPF 数据平面：反欺骗、DNS 和 TLS-SNI 允许列表、速率限制，以及附带原因标记的丢弃（spoof_ip、dns_deny、sni_deny、rate_limit，等等）。使用 MachineNetworkPolicy / NetworkSecurityGroup 编写策略；在 CLI 和仪表板的 Network 面板中实时查看；只需一条命令即可捕获单台 VM 的数据包。VM 边缘层 → · 网络结构 →

kaironctl network flows demo --limit 20
kaironctl network drops demo
kaironctl network capture demo --seconds 15 --output demo.pcap

AI Agent，安全可控

kaironctl mcp serve 通过 stdio 使用 Model Context Protocol。Hermes Agent、Claude、Cursor 或任何 MCP 客户端都可以列出 Machine、读取策略并拉取流、丢弃和捕获数据。Power、snapshot、capture、sealed-claim 和 policy-apply 工具仅在使用 --allow-write 时才会显示，并且每次写入都会先记录到哈希链审计日志中。kaironctl agent ask 使用任意兼容 OpenAI 的模型，将自然语言请求转换为经过验证的提案；kaironctl agent diagnose 则会对 Machine 或迁移停滞的原因进行排序；二者都不会应用任何内容，也没有模型在协调循环中运行。通过官方 MCP SDK 在 CI 中进行端到端覆盖。AI Agent → · Agent 平面 →

快照与恢复

基于 CSI VolumeSnapshots 的 MachineSnapshot、MachineSnapshotRestore 和 MachineSnapshotSchedule，并使用来宾代理冻结文件系统，以创建应用一致性快照。通过 FluxVM 创建 VM 内存快照，并提供用于灾难恢复的 CRD 备份/恢复脚本。快照 →

集群防护与运维

MachineQuota、MachineDisruptionBudget、MigrationPolicy 和可选择启用的准入 Webhook。kairon-ui 仪表板支持 SSO、按操作员划分的账户以及浏览器内 VNC 控制台。Prometheus 指标和告警、控制器 HA 租约，以及可选择启用的 OpenTelemetry spans。可观测性 → · 安全 →

仪表板

概览：集群运行状况和节点使用情况

迁移页面，突出显示 NeedsRecovery

所有命名空间，批量 Start/Stop

更多页面：图库。截图和片段由 docs/ux 中的示例数据栈生成，因此展示的是实际仪表板构建，而不是实验室集群。

工作原理

v0.10.0 新增，动画演示：Agent 会话、空闲沙箱、跨集群灾难恢复、维护与 DRS、弹性内存、增量备份、Mac Fabric

flowchart TB
  subgraph clients["Clients"]
    cli["kaironctl / kubectl kairon"]
    dash["Dashboard (HTTPS)"]
    agent["AI agents via MCP"]
  end
  clients --> api["Kubernetes API<br/>Machine, MachineMigration, VirtualNetwork, ..."]
  api <--> ctl["kairon-controller<br/>placement, migration state machine,<br/>quota, IPAM, backup policy"]
  api <--> ui["kairon-ui"]
  api <--> node["kairon-node<br/>one per VM host"]
  node -->|"REST on 127.0.0.1"| flux["FluxVM<br/>QEMU, Cloud Hypervisor,<br/>Firecracker, FluxVM"]
  flux --> kvm["KVM + eBPF edge"]
  node <-->|"mTLS peer"| node2["kairon-node on another host"]
  flux --> s3[("S3 backups")]

完整说明：ARCHITECTURE.md · docs/architecture.md · 架构示意图：docs/assets/readme-architecture.jpg

快速开始

在 VM 主机运行 FluxVM 的 Kubernetes 集群上：

kubectl label node worker-1 kairon.zyvor.dev/capable=true

helm upgrade --install kairon oci://ghcr.io/zyvorai/charts/kairon \
  --version 0.10.2 -n kairon-system --create-namespace \
  -f https://raw.githubusercontent.com/zyvorai/kairon/v0.10.2/charts/kairon/values-production.yaml

curl -fsSL -o kaironctl https://github.com/zyvorai/kairon/releases/download/v0.10.2/kaironctl-linux-amd64
chmod +x kaironctl && sudo mv kaironctl /usr/local/bin/      # or: kubectl krew install kairon

kaironctl create demo --image /var/lib/fluxvm/images/ubuntu.qcow2 --cpu 2 --memory 2Gi

生产配置会将镜像标签固定为 Chart.AppVersion，并启用 webhook、命名空间隔离、网络默认拒绝和迁移数据平面 TLS。镜像：ghcr.io/zyvorai/kairon-{controller,node,ui}，带有签名、校验和及 SBOM。

从笔记本电脑部署到裸机主机，由主机负责构建，因此笔记本电脑无需安装 Go 或 Node，最后还会运行冒烟测试：

./scripts/deploy-remote.sh user@host --remote-build --with-controller --with-ui --with-console --self-test=quick

不使用 --remote-build 时，二进制文件会在本地交叉编译，然后作为静态文件发送。无论采用哪种方式，仪表板和控制台中继均使用 HTTPS。所有标志和部署流程 →

之后，在任何安装环境中：kaironctl doctor 会检查控制平面，kaironctl selftest 会启动一台 CirrOS VM，以端到端验证整个流程。

git clone https://github.com/zyvorai/zyvor-kairon.git && cd zyvor-kairon
make docker-build
helm upgrade --install kairon ./charts/kairon -n kairon-system --create-namespace
# or: kaironctl install   (embedded Helm SDK, no helm binary needed)

要求

• Kubernetes 集群中的 VM 主机必须运行 Linux，并提供 /dev/kvm。
• 每台 VM 主机上都要运行 FluxVM（默认地址为 127.0.0.1:7788）。
• 使用 eBPF 边缘功能时：内核必须支持 BTF 和 cgroup v2，并且 dataplaneMode: ebpf。

运维

# Relocate
kaironctl migrate demo --strategy cold --target-node worker-2
kaironctl migrate demo --strategy live --target-node worker-2 --mode pre-copy
kaironctl evacuate worker-1 --wait

# See the network from the VM's point of view
kaironctl network status demo
kaironctl network drop-reasons demo
kaironctl network identity demo

# Hand the fleet to an AI agent
kaironctl mcp serve                  # add --allow-write for power, snapshot, capture and claims (audited)
kaironctl agent diagnose machine/demo   # ranked causes; adds a model summary when KAIRON_LLM_URL is set

# Dashboard (HTTPS; self-signed unless ui.tls.secretName is set)
kubectl -n kairon-system port-forward svc/kairon-ui 18082:18082   # then https://localhost:18082
kaironctl ui                         # or through the API server, no port-forward

成熟度

v0.10.2 是最新版本（基于 v0.10.1 的补丁版本，修复了发布流水线；v0.10.1 添加了 MCP 服务镜像和 MCP Registry 列表）。2026-10-14 在真实实验环境中进行了双主机实时迁移（冷迁移、源端故障、控制器故障切换、所有 3 种自适应用例以及 post-copy 源端故障，均在匹配的 QEMU 10.2.1 上双向通过；高写入负载下的普通 pre-copy 未能收敛；NeedsRecovery 演练 6 次中通过 5 次，另有 1 次原因不明的失败，导致迁移停留在 Adopting）。目前尚未进行实时迁移与 eBPF 组合测试，也尚无 nightly CI，因此仍处于预览阶段。自适应实时迁移在其矩阵用例通过 nightly 实验室工作流之前，仍处于实验阶段。尚未解决的问题详见 docs/STATUS.md；后续计划见 ROADMAP.md。

文档

开发

make test-race && make cover-check      # Go tests with the race detector, coverage gate
make build smoke                        # binaries and smoke test
cd web && npm install && npm run dev    # dashboard UI

请从 CONTRIBUTING.md 开始；依赖规则见 docs/DEPENDENCIES.md。

Zyvor 技术栈的一部分

→ zyvor.dev

支持

在 Apache-2.0 许可下免费提供。如果它对你有帮助，你可以捐赠任意金额：https://rzp.io/rzp/utwdYh3。捐赠完全自愿，用于支持开发和维护。捐赠不是购买：不会因此获得支持、SLA、功能、优先权或许可证，也不能抵税（Zyvor AI Labs Private Limited 是一家公司，不是慈善机构）。Zyvor Enterprise（受支持的版本、SLA、指定联系人和企业功能）为独立服务：[email protected]。

许可证

Kairon 基于 Apache License 2.0 免费开源（见 NOTICE），可免费使用、修改并用于生产环境。这一点不会改变。

Zyvor Enterprise 提供生产团队所需的服务：受支持的版本、部署和升级指导、优先事件分诊、指定技术联系人以及全天候关键问题受理。方案和条款：docs/SUBSCRIPTION-MODEL.md · 定价 · [email protected]。

Bug 和功能请求 → GitHub Issues。请通过 [email protected] 或 GitHub 私密漏洞报告 私下报告漏洞；详见 SECURITY.md。参与贡献：CONTRIBUTING.md。

原生 macOS

Kairon 可在 Apple silicon 上原生构建和运行，并可通过 FluxVM 的 vz 后端将 Machines 调度到 Mac 上。有关已验证的内容和限制，请参阅 docs/macos.md。

每台 Mac 都会成为 Kubernetes Node：可以是家中的 Mac mini、供团队使用的 Mac Studio，也可以是来去不定的 MacBook Pro。Kairon 根据可分配的统一内存放置 Machines，FluxVM 负责运行它们，而 Velora 则在同一硬件上提供私有的 OpenAI 兼容 LLM 端点。几台 Mac Studio 就能组成安静、低功耗的本地推理集群。

已验证：在 Apple M4、macOS 27.2 上，Mac 注册为 Ready Node，vz Machine 已完成调度、启动、SSH 和删除。**尚未验证：**多 Mac 集群、Thunderbolt RDMA。集群指南包含多 Mac 示例（examples/macos-fleet.yaml）、容量规划和路线图，案例参考 GK Servis 的 Mac Studio 案例研究：docs/macos-cluster.md。