Kairon

Kairon

Pod のふりをしない VM。

Kubernetes がスケジュールし、KVM 上で直接実行する本物の仮想マシンです。 VM ごとの virt-launcher Pod も、ホットパス上の libvirt も、乱立するオペレーターもありません。Machine は望ましい状態を表し、kairon-controller が配置し、kairon-node が QEMU、Cloud Hypervisor、Firecracker、または FluxVM 独自のハイパーバイザーを使って FluxVM 上で実行します。

VM ごとの Pod はゼロ · 4 種類のハイパーバイザーを 1 つの CRD で · すべての VM エッジで eBPF を使用 · サイレントなスプリットブレインなし · AI エージェントを標準搭載（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シードを使用し、1つのスクリプトで両方を実行しました。準備完了とは、ゲストのsshdが応答する状態を指します。どちらの場合もVMにかかるコストは同じです。削減できるのは、KubeVirtがVMの周囲に用意するすべての要素です。手法、生のJSON、注意事項（VM 10台の実行を含む）については、docs/benchmarksをご覧ください。

Kairon と KubeVirt の比較

取り除くレイヤーが一つ増えるごとに、パッチを適用する対象が一つ減り、読むログが一つ減り、午前2時にクラッシュするプロセスが一つ減ります。

以前のレイヤースタックの図：docs/assets/kairon-vs-kubevirt.jpg。

得られるもの

Pod ではなく Machine

インスタンスタイプ、NUMA と CPU のピンニング、Windows ゲスト、PVC と CSI からのブート、マルチボリューム virtiofs、CPU／メモリのホットプラグ、一時停止と停止、cloud-init、ポートフォワードに対応した Machine と MachineSet。望ましい状態は Kubernetes に保存され、ノードが数秒ごとに調整します。提供機能 →

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

推測で処理しないマイグレーション

コールドマイグレーション、ノード退避、相互 TLS と暗号化されたデータプレーンを使った安全なライブマイグレーションに対応しています。ノードを Cordon すると、コントローラーが MachineDisruptionBudget によるスロットリングを行いながら退避できます。コミット結果が不明な場合、Machine は NeedsRecovery になり、2 つの実行中コピーが生じるリスクを避けて、オペレーターの対応を待ちます。移行 → · NeedsRecovery の運用手順 →

すべての VM に eBPF エッジ

各 VM の tap は FluxVM の eBPF データプレーンを利用します。なりすまし対策、DNS と TLS-SNI の許可リスト、レート制限に対応し、破棄の理由（spoof_ip、dns_deny、sni_deny、rate_limit、…）を特定できます。ポリシーは MachineNetworkPolicy／NetworkSecurityGroup として記述し、CLI とダッシュボードの Network パネルでリアルタイムに確認できます。1 つのコマンドで 1 台の VM のパケットをキャプチャできます。VM エッジ → · ネットワークファブリック →

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

AI エージェントを安全に

kaironctl mcp serve は stdio 経由で Model Context Protocol を使用します。Hermes Agent、Claude、Cursor などの MCP クライアントは、Machine の一覧表示、ポリシーの読み取り、フロー、ドロップ、キャプチャの取得ができます。電源、スナップショット、キャプチャ、封印済みクレーム、ポリシー適用のツールは --allow-write を指定した場合にのみ表示され、すべての書き込みは最初にハッシュチェーン監査ログへ記録されます。kaironctl agent ask は、OpenAI 互換モデルを使って平易な英語のリクエストを検証済みの提案に変換し、kaironctl agent diagnose は Machine や移行が停止している理由を順位付けします。どちらも何も適用せず、調整ループ内でモデルが実行されることもありません。公式 MCP SDK を使って、CI でエンドツーエンドのテストを実施しています。AI エージェント → · エージェントプレーン →

スナップショットと復旧

CSI VolumeSnapshots 上の MachineSnapshot、MachineSnapshotRestore、MachineSnapshotSchedule に対応し、アプリケーション整合性のあるスナップショットを取得するためにゲストエージェントによるファイルシステムのフリーズを行います。FluxVM を通じた VM メモリのスナップショット、および災害復旧用の CRD バックアップ／復元スクリプトも利用できます。スナップショット →

フリートのガードと運用

MachineQuota、MachineDisruptionBudget、MigrationPolicy、オプトイン方式のアドミッション Webhook に対応しています。kairon-ui ダッシュボードでは、SSO、オペレーターごとのアカウント、ブラウザー内 VNC コンソールを利用できます。Prometheus メトリクスとアラート、コントローラー HA リース、オプトイン方式の OpenTelemetry スパンも備えています。可観測性 → · セキュリティ →

ダッシュボード

概要：フリートの健全性とノードの使用状況

NeedsRecovery が表示された移行

全ネームスペース、一括 Start/Stop

その他のページ：ギャラリー。スクリーンショットとクリップは docs/ux のサンプルデータスタックから生成されるため、ラボクラスターではなく、実際のダッシュボードのビルドを示しています。

全体の仕組み

v0.10.0 の新機能、アニメーション：エージェントセッション、アイドル状態のサンドボックス、クラスター間 DR、メンテナンスと 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 で署名されています。

ノート PC からベアメタルホストにデプロイする場合は、ホスト上でビルドするため、ノート PC に 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)

要件

• VM ホストで /dev/kvm が利用できる Linux の Kubernetes クラスター。
• 各 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 に実際のラボ環境で 2 ホスト間のライブマイグレーションを実施しました（コールドマイグレーション、ソース障害、コントローラーのフェイルオーバー、3 つすべての適応型ケース、ポストコピー中のソース障害は、QEMU 10.2.1 のバージョンを一致させた環境で両方向とも成功しました。一方、負荷の高い書き込み中の通常のプリコピーは収束せず、NeedsRecovery のドリルは 6 回中 5 回成功しました。原因不明の失敗が 1 回あり、移行が Adopting 状態のままになりました）。ライブマイグレーションと eBPF を組み合わせた実行はまだなく、ナイトリー CI もまだないため、引き続きプレビューです。適応型ライブマイグレーションは、ナイトリーのラボワークフローでマトリックスのケースに合格するまで、実験的な扱いが続きます。未解決の課題については 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では、本番環境のチームが求めるサポート対象リリース、デプロイとアップグレードのガイダンス、インシデントの優先トリアージ、専任技術窓口、重大な問題に対する24時間365日の受付を提供します。プランと利用条件：docs/SUBSCRIPTION-MODEL.md · 料金 · [email protected]。

バグと機能リクエスト → GitHub Issues。脆弱性は[email protected]またはGitHub の非公開脆弱性報告から非公開で報告してください。SECURITY.mdを参照してください。コントリビューション：CONTRIBUTING.md。

macOSネイティブ

KaironはAppleシリコン上でネイティブにビルド、実行でき、FluxVMのvzバックエンドを通じてMacにマシンをスケジュールできます。検証済みの内容と制限については、docs/macos.mdをご覧ください。

すべてのMacがKubernetesノードになります。自宅のMac mini、チーム用のMac Studio、必要に応じて持ち運ぶMacBook Proです。Kaironは割り当て可能なユニファイドメモリに基づいてマシンを配置し、FluxVMがそれらを実行します。また、同じハードウェア上でVeloraが、プライベートなOpenAI互換LLMエンドポイントを提供します。数台のMac Studioで、静かで低消費電力のオンプレミス推論クラスターを構築できます。

Apple M4、macOS 27.2で検証済み：MacがReadyノードとして登録され、vzマシンがスケジュールされ、起動し、SSH接続され、削除されること。未検証：複数Macのクラスター、Thunderbolt RDMA。GK ServisのMac Studio導入事例を参考にした、複数Macのサンプル（examples/macos-fleet.yaml、サイジング、ロードマップを含むクラスターガイド：docs/macos-cluster.md。