mcpField
K
kubernetes-health

kubernetes-health

github.com/nodnarbnitramクラウド・DevOps1684 回インストール27 週間前に更新
リポジトリ

kubernetes-health について

kubernetes-healthは、検出結果に基づいてKubernetesクラスターを診断するスキルです。既存のkubectl設定を使ってAPIや導入済みOperatorを検出し、読み取り専用のチェックを行うエージェントを割り当てます。

主な機能

  1. 01APIグループと導入済みOperatorの検出
  2. 02コアおよびOperatorのヘルスチェック
  3. 03専用エージェントの並列実行
  4. 04ヘルススコアによる結果集約
  5. 05統合JSONレポートの生成

活用シーン

  1. 01デプロイ後のクラスター状態確認
  2. 02Operator構成が異なるクラスターの問題調査
  3. 03リソースを変更せずにクラスター状態を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nodnarbnitram/claude-code-extensions --skill kubernetes-health

インストール後、Claude Code で/kubernetes-healthを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
references/
health-scoring.md
operator-checks.md
scripts/
aggregate_report.py
discover_apis.py
health_orchestrator.py
templates/
health-report.json

詳細

Kubernetes のヘルス診断

あらゆる Kubernetes クラスター構成に対応する、動的な検出ベースのヘルスチェック

始める前に

影響値
トークンの節約手動での kubectl 調査と比べて約 70%
セットアップ時間0 分(既存の kubectl 設定を使用)
対応範囲インストール済みのオペレーターに自動で適応
防止できる既知の問題
問題根本原因このスキルの対処方法
オペレーターのヘルス状態を見落とす静的なチェックリストでは CRD を見落とす動的な API 検出ですべてのインストール済みオペレーターを検出
診断が古くなる手動のチェックが最新でなくなるクラスター API をリアルタイムで照会
対応範囲が不完全クラスター構成が不明関連するサブエージェントを自動的に起動

クイックスタート

  1. クラスターへのアクセスを確認する:kubectl が設定され、クラスターに接続できることを確認します
  2. 検出を実行する:discover_apis.py を実行して、インストール済みのオペレーターを検出します
  3. エージェントをディスパッチする:オーケストレーターを使用して、検出結果に基づくヘルスチェックを実行します
# Step 1: Verify kubectl context
kubectl config current-context
kubectl cluster-info

# Step 2: Run API discovery
uv run .claude/skills/kubernetes-health/scripts/discover_apis.py

# Step 3: Review detected operators and dispatch health agents

重要なルール

必ず行うこと
  • ヘルスチェックの実行前に kubectl コンテキストを確認します
  • 読み取り専用の kubectl コマンド(get、describe、logs)を使用します
  • オペレーター固有のチェックより先に、コアのヘルスチェックを実行します
  • 提供されたスコアリング方法で結果を集約します
絶対に行わないこと
  • ヘルスチェック中にクラスターリソースを変更する
  • ヘルスレポートにシークレットの値を含める(メタデータのみ)
  • 本番クラスターのコンテキスト確認を省略する
  • API 検出を行わずにオペレーターが存在すると想定する
よくある間違い
間違い問題である理由正しい方法
オペレーターのチェックをハードコードするインストール済みのオペレーターを見落とし、存在しないオペレーターをチェックしてしまうAPI 検出を使用して、インストール済みのものを検出します
エージェントを逐次ディスパッチする複数のオペレーターがあるクラスターでは遅くなるオペレーターエージェントを並列で実行します(同じ優先度)
kubectl の生出力を使うトークン効率が悪く、解析しにくいスクリプトで簡潔な JSON 出力を使用します

同梱リソース

スクリプト
スクリプト目的
scripts/discover_apis.pyすべての API グループを検出し、インストール済みのオペレーターを特定します
scripts/health_orchestrator.py検出された API を専用のヘルスエージェントに割り当てます
scripts/aggregate_report.py複数エージェントの結果を統合レポートに集約します
リファレンス
ファイル内容
references/operator-checks.mdサポート対象の各オペレーターに対する詳細なヘルスチェック
references/health-scoring.mdスコアリング方法と重みの割り当て
テンプレート
ファイル目的
templates/health-report.jsonヘルスレポート出力用の JSON スキーマ

依存関係

必須
パッケージバージョン目的
kubectl最新クラスターとのやり取り
Python>= 3.11スクリプトの実行
uv最新Python スクリプトランナー
オプション
パッケージバージョン目的
kubernetes>= 28.1.0Python クライアント(高度な検出用)

サポート対象のオペレーター

このスキルは、次の専用エージェントを自動的に検出してディスパッチします。

オペレーターAPI グループエージェント
Core K8s(常に)k8s-core-health-agent
Crossplanecrossplane.iok8s-crossplane-health-agent
ArgoCDargoproj.iok8s-argocd-health-agent
Cert-Managercert-manager.iok8s-certmanager-health-agent
Prometheusmonitoring.coreos.comk8s-prometheus-health-agent

ヘルススコア

状態スコア範囲判定基準
正常90-100すべてのチェックに合格し、警告なし
劣化60-89一部に警告があるが、重大な問題はない
重大0-59可用性に影響する重大な問題がある

トラブルシューティング

kubectl の接続に関する問題
# Verify context
kubectl config current-context

# Test connectivity
kubectl cluster-info

# Check permissions
kubectl auth can-i get pods --all-namespaces
検出結果が空の場合
  • クラスターに接続できることを確認します
  • API 検出に必要な RBAC 権限を確認します
  • kubectl のバージョンに互換性があることを確認します
エージェントのディスパッチ失敗
  • 検出された API グループがエージェントのトリガーと一致することを確認します
  • エージェントファイルが .claude/agents/specialized/kubernetes/ に存在することを確認します
  • エージェントのツール制限を確認します

セットアップチェックリスト

  • kubectl が設定され、クラスターに接続されている
  • Python 3.11+ がインストールされている
  • スクリプト実行用の uv がインストールされている
  • クラスターリソースへの読み取り権限がある
  • エージェントファイルが .claude/agents/specialized/kubernetes/ に存在する

コメント