ローカルGPUでKubernetes障害の原因と根拠を調べる
TriFleetRCA: On-Premise LLM Root Cause Analysis for Kubernetes
この論文をやさしく読む
ひとことで言うと
本番ログを外部へ出さずに、1台のGPUで障害原因と根拠を提示する方法を、障害を注入したクラスタで評価しています。
何に役立つ？
考えられる用途は、外部モデルにログを送れない環境での運用調査の支援です。検索範囲とトークン費用の選択にも手掛かりを与えます。
この研究の面白いところ
原因の正解と根拠の正しさを分けて調べ、正しく診断しても引用を誤る事例を見つけています。
どこまで分かった？
評価した障害は4種類です。範囲による正解率の区間は重なり、ガードなしでも試した悪意ある指示は拒否されました。この結果だけでガードの一般的な防御効果や全障害への性能は確定しません。
v1のアブストラクトに基づくAI解説。日本語訳とは別に、用途の解釈を含みます。
アブストラクトの日本語訳
遠隔拠点での根本原因分析には時間がかかる。証拠はPodのログ、Kubernetesのイベント、クラスタ単位のオブジェクトに分散し、多くの運用者は本番ログを外部のホスト型モデルへ送信すること自体ができない。オンプレミス推論は後者の制約を取り除くが、実際のクラスタを使うベンチマークでは未検討の問題を生む。1台のワークステーションGPUによってモデルとコンテキストの予算がともに固定されるとき、証拠をどう検索すべきか。また、モデルが参照する運用手順書が改ざんされたら何が起きるのか。 本研究では、オンプレミスの1台のGPUだけで動くTriFleetRCAを提示する。この処理系は、Pod、名前空間、クラスタの3つの範囲のいずれかで証拠を集め、テンプレートによる重複除去を行ってからBM25で順位づけし、取り込み時のガードで運用手順書を選別し、根本原因とそれを支える証拠行を返す。実際のKubernetesクラスタに4種類の障害を注入し、正解が構成上分かっている状態で評価した。Qwen2.5-14B-Instructを温度0で使い、100回の分析を行った。 正解率はPod、名前空間、クラスタの範囲でそれぞれ0.85、0.90、0.95だった。区間は重なっており、範囲による効果の全体は、原因がクラスタ単位のオブジェクトである1種類の障害から生じていた。また、クラスタ範囲ではトークンが55%多く必要だった。順位づけ前の重複除去は、同じトークン費用で正解率を0.75から0.90へ改善した。名前空間を削除するようモデルに指示する汚染済みの運用手順書は、すべての実行でガードに拒否された。ガードを無効にした場合でも、モデルは20回すべての分析で指示への追従を拒否したため、ガードは唯一の障壁ではなく多層防御となっている。 引用の品質を正解率と分けて評価することも有益だった。ある障害はすべての試行で正しく診断されたが、引用はすべて誤っており、正解率だけではこの失敗が隠れていた。プロンプト2,200トークンで遅延の中央値は1.6秒だった。処理系、障害注入器、全記録を公開する。
v1の要旨から自動生成。本文の精読・人による確認は未実施。
- 初稿
- 2026-09-20（UTC）
- 最新改訂
- 2026-09-20 · v1
- 査読・掲載
- 査読状況未確認
更新履歴
- v1 2026-09-20 この版を読む
取得できた版を表示。版の更新は査読済みを意味しません。過去版の本文差分は未解析です。
原文の要旨
Root cause analysis at a remote site is slow: evidence is scattered across pod logs, Kubernetes events and cluster-level objects, and many operators cannot send production logs to a hosted model at all. On-premise inference removes the second constraint but raises a question live-cluster benchmarks have not addressed: when one workstation GPU fixes both the model and the context budget, how should evidence be retrieved, and what happens when the runbooks the model consults have been tampered with? We present TriFleetRCA, a pipeline running entirely on one on-premise GPU that collects evidence at one of three scopes (pod, namespace, cluster), ranks it by template de-duplication then BM25, filters runbooks through an ingest guard, and returns a root cause with the evidence lines supporting it. We evaluate on a live Kubernetes cluster into which we inject four faults, so ground truth is known by construction, across 100 analyses with Qwen2.5-14B-Instruct at temperature 0. The hit rate was 0.85, 0.90 and 0.95 at pod, namespace and cluster scope; intervals overlap, but the whole scope effect comes from the one fault whose cause is a cluster-level object, and cluster scope costs 55% more tokens. De-duplication before ranking raised the hit rate from 0.75 to 0.90 at equal token cost. A poisoned runbook telling the model to delete the namespace was rejected by the guard every run; with the guard disabled the model declined to follow it in all 20 analyses, making the guard defence in depth rather than the sole barrier. Separating citation quality from accuracy proved informative: one fault was diagnosed correctly and cited incorrectly every trial, a failure mode accuracy conceals. Median latency was 1.6 s at 2,200 prompt tokens. We release the pipeline, the fault injector and all records.
arXiv ID: 2609.23766 ／ 要約の誤りについて