チームに新しく入った人が、Kubernetesクラスタの様子を見ようとしてターミナルの前で固まる。隣では別のメンバーが:deployや/を叩いて目的の画面をさっと開いている。そんな場面に覚えがあるなら、2026年10月8日に最新版が公開された「k10s」が候補になる。マウスでクリックして操作できるターミナルツールだ。組み込みのAI機能もあるが、見るクラスタの情報は4項目に絞られ、送信前にはEnterキーでの確認を挟む設計になっている。
コマンドを覚えずに操作できる仕組み
Kubernetesクラスタの操作には、「k9s」という定番ツールが長年使われてきた。キーボードだけでPodやServiceを素早く操作できる速さで支持されてきたが、その速さはコマンドを覚えている前提の上に立っている。
k10sは、同じ領域のターミナルUI(TUI)にあたる。TUIとは、ターミナルの中でマウスやキー操作に反応する画面を持つツールを指す。
k10s公式GitHubリポジトリのREADMEは、k9sとの違いを比較表で示している。
| 観点 | k9s | k10s |
|---|---|---|
| 主な入力 | キーボード中心、コマンド駆動 | マウスとキーボードを同等に扱う |
| 発見のしやすさ | コマンドを覚える必要がある | 選択中のオブジェクトに使えるアクションを画面へ列挙 |
| 検索 | ビューごとのフィルタと:でのビュー移動 | ctrl+pでリソース種別とオブジェクトを横断検索 |
| AI | プラグインで実現する領域 | 組み込みで、クラスタの文脈を注入 |
| 規模 | 大規模でプラグイン生態系が豊富 | 意図的に小さく絞った構成(k9s形式のプラグインには対応) |
| アップグレード | パッケージマネージャ経由 | k10s updateでの自己置換 |
(k10s公式READMEより作成)
差が大きいのは「発見のしやすさ」だ。k9sはPodを再起動したければr、ログを見たければlと、キーを覚えて打つ。k10sでは、画面に表示されているPodを選ぶと、そのPodに対してできる操作(ログ・exec・ポートフォワード・再起動・削除など)が画面上に並ぶ。新しく入った人がまず戸惑う「何を打てばいいか分からない」状態を、クリックで選べる一覧に置き換えている。
この一覧を支えているのは、Kubernetes APIから状態を取得する「informer」という仕組みの遅延起動だ。informerはAPIサーバーに継続的に問い合わせてリソースの変化を受け取る部品で、k9sも使っている技術になる。READMEによると、k10sは開いた画面の分だけinformerを起動する。全リソースを先回りして監視しないので、起動直後の負荷を抑えられるという。
対応するリソースの種類はWorkloads・Network・Config・Storage・RBAC・Clusterなど30種類を超える。CRD(ユーザーが追加した独自のリソース種別)も自動で見つけて一覧に加える。
クリックで操作の幅は広がった。では、もう一つの新機能であるAIは、クラスタの何を見ているのか。
AIモードは何を見ているのか
k10sにはctrl+aで切り替えるAIモードがある。自分のAPIキーを使い、OpenAI互換API(Groq・Ollama・vLLMなど)かAnthropicのモデルに質問できる。
たとえば、あるPodがCrashLoopBackOff(起動と終了を繰り返している状態)になっているとする。そのPodを選んでctrl+aを押し、「このPodが落ちている理由を教えて」とAIに尋ねる場面を考えてみる。
AIに聞けると分かると、真っ先に浮かぶ心配は、クラスタの情報がどこまで外部に渡るのかだろう。自分は、k10sのAI機能を見たとき、裏で開いている画面の情報をまるごと渡しているのではと身構えた。ところが公式READMEを読むと、注入される情報は次の4項目に絞られていた。
- 現在のkubeconfigのコンテキスト
- 選んでいるnamespace
- 見ているリソースの種類(PodやDeploymentなど)
- 選択中のオブジェクトの名前
しかもEnterキーを押すまでは、この4項目すら送信されないと明記されている。つまりAIに渡るのは、今どのクラスタの、どのnamespaceの、どんな種類のリソースを、どのオブジェクトを選んで質問しているか、という座標の情報にとどまる。Podの中のログの中身やSecretの値そのものとは別になる。
質問に答えるAIに渡るのは、クラスタの中身ではなく座標だ。この絞り方を知ったうえで次に気になるのは、使い慣れたk9sの環境や、普段の運用ルールをそのまま持ち込めるかどうかだ。
既存の環境を引き継げるか
k10sはk9s形式のプラグイン(~/.k10s/plugins.yaml)に対応している。普段使っているプラグインの書式を、そのまま流用できる余地がある形だ。
運用面では、2026年10月8日公開のv0.1.7リリースノートによると、読み取り専用モードが加わった。k10s --readonly(または--read-only)で起動すると、次の操作がすべて使えなくなる。
- Edit・Scale・Rollout Restart・Cordon・Drain・Delete
- Shell(Podへのログイン)・Port Forward
これは画面上でボタンを隠すだけの制限ではない。通信層でもGET・HEAD・OPTIONS以外のリクエストを拒否する作りで、dangerous: trueと印のついたプラグインも非表示になるという。見るだけの権限を新しいメンバーに渡す、といった使い方を想定しているとみられる。
ただし、k10s自身のREADMEは現状を「live」としながらも、本番クラスタでの十分なスモークテストは済んでいないと明記している。まずはkind(ローカルで動かす検証用クラスタ)での試用を勧めている。k10s demoというコマンドも用意されている。こちらはオフラインのサンプルクラスタが起動するので、実際のクラスタを用意しなくても画面の動きだけ先に確かめられる。
開発元p10nodeの公式GitHub組織プロフィールによると、2025年からDevOpsを専業とする会社で、ホーチミン拠点のシニアエンジニア32名を抱えるという。Releasesの履歴を見ると、v0.1.0の初回リリースは2026年8月26日で、そこからv0.1.7まで6週間ほどで8回のリリースを重ねた。動きの速いプロジェクトだと分かったうえで、本番ではなくまず手元の検証クラスタか読み取り専用モードで試すのが無難だ。
まとめ
k10sは、k9sのキーボード操作をクリックに置き換えたKubernetes向けTUIだ。選んだオブジェクトに使える操作を画面に並べることで、コマンドを覚える手間を減らす。組み込みのAIモードは、クラスタの文脈を現在のコンテキスト・namespace・リソース種別・選択中のオブジェクトの4項目に絞り、送信前にEnterキーでの確認を挟む。
k9s形式のプラグインにも対応しつつ、読み取り専用モードで操作を通信層ごと制限できる。公開から2か月足らずの新しいプロジェクトで、README自身が本番での十分な検証はまだだと明言している。チームに入れる前には、まずkindか読み取り専用モードで試すのが確実だ。
コメント
気づきや感想をどうぞ記事への補足や、読んで考えたことをお寄せください。個人情報や、他の人を傷つける内容の投稿はお控えください。
投稿にはGoogleログインが必要です。
Googleでログイン投稿にはGoogleアカウントの表示名が公開されます。メールアドレスは取得・公開しません。
コメントを読み込んでいます…