Posted inAI

K8sGPTとローカルOllamaでKubernetesのトラブルシューティングを自動化する

AI tutorial - IT technology blog
AI tutorial - IT technology blog

クイックスタート（5分）

Kubernetesワークロードのデバッグでは、膨大なログストリーム、難解なイベント、意味不明な終了コードの調査に追われがちです。午前2時にそのような対応をするのは誰にとっても過酷です。K8sGPTとOllamaを組み合わせれば、マシン上で高速かつ自動化されたトリアージを実行できます。クラスターのシークレット、マニフェスト、内部IPを外部のクラウドAPIに送信することなく、明確な診断サマリーを取得可能です。

ここでは、管理用ワークステーション上に5分でオフライン診断パイプラインを構築する手順を説明します。

1. Ollamaのインストールと軽量モデルのプル

まず、Ollamaを入手し、軽量なモデルをダウンロードします。クラスター診断には、メモリ消費を抑えつつYAML構造やエラートレースを的確に処理できるmistral（7B）またはllama3.2（3B）が適しています:

# LinuxにOllamaをインストール
curl -fsSL https://ollama.com/install.sh | sh

# Ollamaのバックグラウンドデーモンを起動
ollama serve &

# Mistral 7Bの重みをプル（約4.1 GB）
ollama pull mistral

Ollamaがポート11434で応答することを確認します:

curl http://localhost:11434/api/version
# 期待される出力: {"version":"0.5.4"}

2. K8sGPT CLIのインストール

お使いのアーキテクチャに応じたK8sGPTバイナリをダウンロードします:

# AMD64用Debianパッケージの取得とインストール
curl -LO https://github.com/k8sgpt-ai/k8sgpt/releases/download/v0.3.40/k8sgpt_amd64.deb
sudo dpkg -i k8sgpt_amd64.deb

# インストールされたバージョンを確認
k8sgpt version

3. K8sGPTをローカルのOllamaエンジンに接続

OllamaはOpenAI互換の/v1エンドポイントを提供しています。ローカルデーモンにクエリを送信するため、K8sGPTで本物のAPIキーを用意する必要はありません。CLIパーサーの要件を満たすダミーの文字列を渡します:

k8sgpt auth add --backend localai --model mistral --baseurl http://localhost:11434/v1 --password dummy

# LocalAIをアクティブなバックエンドとして設定
k8sgpt auth default -b localai

4. 最初の診断スキャンを実行

kubectlのコンテキストをテスト用クラスターに向け、分析を実行します:

k8sgpt analyze --explain --backend localai

K8sGPTはアクティブな名前空間を検査し、問題のあるオブジェクトを特定して、サニタイズされたエラーのスニペットをOllamaに渡します。2〜4秒以内に、根本原因の分かりやすい説明と、具体的なkubectlの修正コマンドが返されます。

アーキテクチャ: K8sGPTがローカルでクラスターを分析する仕組み

分析実行時に内部で何が起きているかを把握しておくことで、システムの信頼性を維持し、データ漏洩を防ぐことができます。

フィルター付きアナライザーパイプライン

K8sGPTは未加工のクラスターマニフェストをそのままLLMプロンプトに投入することはありません。オブジェクトツリー全体を送信すると、すぐにトークン上限に達し、レイテンシが増大するためです。代わりに、専用のGoアナライザーがKubernetes APIに直接問い合わせて異常を検知します:

  • PodAnalyzer: CrashLoopBackOff状態、イメージプルのバックオフ、liveness probeの失敗、終了コード137（OOMKilled）のイベントなどを検出します。
  • ServiceAnalyzer: ラベルが実行中のPodと一致していない不正なエンドポイント構成を検出します。
  • IngressAnalyzer: 不足しているTLSシークレット、ルーティングの競合、無効なバックエンドサービス参照を捕捉します。
  • PV/PVC Analyzers: 未バインドのPVC、存在しないストレージクラス、プロビジョナーのタイムアウトエラーなどを検知します。

これらのアナライザーはクラスターオブジェクトに対して絞り込んだヘルスチェックを実行します。リソースに障害が発生した場合、アナライザーはノイズを除去し、関連するエラーメッセージ、コンテナの終了コード、直近のイベントのみを保持します。そして、最適化されたプロンプトテンプレートを用いて、その要約されたペイロードをOllamaに渡します。

クラスターセキュリティにおいてオフラインLLM推論が重要な理由

金融、防衛、医療などの業界では、厳格なデータ境界の遵守が求められます。稼働中のマニフェストやコンテナログを外部のSaaS型モデルに送信することは、重大なセキュリティリスクを招きます。プロンプト経由で、プライベートエンドポイント、内部CIDRブロック、あるいは環境変数に保存されたマスクされていないデータベース認証情報が偶発的に流出する恐れがあるためです。

Ollamaをローカルで実行すれば、外部へのデータ転送は発生しません。すべてのプロンプトトークンはお使いのVPCやワークステーションの境界内に留まります。1件の障害につき3秒未満でトリアージが完了し、セキュリティチームもコンプライアンス違反を心配する必要がありません。

本番環境での自動化: クラスター内オペレーターのセットアップ

アドホックなCLIコマンドは緊急トリアージ時に便利ですが、複数のクラスターを管理するプラットフォームエンジニアリングチームにとっては、バックグラウンドでの継続的な分析の方が高い価値を生み出します。

永続ストレージを使用したOllamaのデプロイ

Podが再起動するたびに数ギガバイトのモデルを再ダウンロードする手間を省くため、Ollamaの/root/.ollamaにPersistentVolumeをマウントします:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama
  namespace: k8sgpt-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama
  template:
    metadata:
      labels:
        app: ollama
    spec:
      containers:
      - name: ollama
        image: ollama/ollama:latest
        ports:
        - containerPort: 11434
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
          limits:
            memory: "8Gi"
            cpu: "4"
        volumeMounts:
        - name: model-cache
          mountPath: /root/.ollama
      volumes:
      - name: model-cache
        persistentVolumeClaim:
          claimName: ollama-models-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: ollama-service
  namespace: k8sgpt-system
spec:
  type: ClusterIP
  ports:
  - port: 11434
    targetPort: 11434
  selector:
    app: ollama

Podの起動後、選択したモデルをボリュームに直接プルします:

kubectl exec -it -n k8sgpt-system deploy/ollama -- ollama pull mistral

K8sGPT Operatorのデプロイ

監視用の名前空間にHelmを使って公式オペレーターをインストールします:

helm repo add k8sgpt https://charts.k8sgpt.ai/
helm repo update

helm install k8sgpt-operator k8sgpt/k8sgpt-operator \
  --namespace k8sgpt-system \
  --create-namespace

クラスター内カスタムリソースの設定

ダミーのパスワードを含むSecretを作成し、クラスター内のOllamaサービスを指すK8sGPTリソースを定義します:

kubectl create secret generic k8sgpt-ollama-secret \
  --namespace k8sgpt-system \
  --from-literal=password=dummy

apiVersion: core.k8sgpt.ai/v1alpha1
kind: K8sGPT
metadata:
  name: k8sgpt-ollama
  namespace: k8sgpt-system
spec:
  ai:
    enabled: true
    model: mistral
    backend: localai
    baseUrl: http://ollama-service.k8sgpt-system.svc.cluster.local:11434/v1
    secret:
      name: k8sgpt-ollama-secret
      key: password
  noCache: false
  repository: ghcr.io/k8sgpt-ai/k8sgpt
  version: v0.3.40

カスタムリソース経由での結果確認

オペレーターは定期的なリコンサイルループでリソースをスキャンし、検出結果をResultカスタムリソースとして出力します:

kubectl get results -n k8sgpt-system -o wide

Podが失敗した理由を詳しく調べるには、対応するResultリソースの情報を確認します:

kubectl describe result default-payment-service-crashloop -n k8sgpt-system

出力にはBack-off restarting failed container payment-apiのような詳細なエラーメッセージが表示され、それに続いてシークレットキーの不足がクラッシュの原因であることを明快に解説したアドバイスが提示されます。

本番運用のサイジングと推奨ガイドライン

1. コンピューティングリソースに応じたモデルパラメータの選定

共有CPUノード上で70Bパラメータのモデルを実行するのは避けてください。障害発生時には、回りくどい解説よりも迅速な回答が求められます:

  • Llama-3.2（3B）またはPhi-3 Mini（3.8B）: 約2.2 GBのRAMを消費します。GPUパススルーのない標準的な4コアCPUワーカーノードでも、1〜3秒で応答を返します。
  • Mistral（7B）またはLlama-3.1（8B）: 約5.5 GBのVRAMが必要です。Nvidia T4（16 GB）またはA10Gを使用することで800ミリ秒未満の推論時間を実現し、ネットワークポリシーやマルチコンテナ仕様の解析精度も向上します。

2. スキャン範囲の限定によるクラスター負荷の軽減

50以上の名前空間全体でフルスキャンを実行すると、APIサーバーと推論エンジンの両方に高い負荷がかかります。重要な名前空間や問題の発生しているリソースに対象を絞り込みましょう:

# 本番環境のpayments名前空間のみをスキャン
k8sgpt analyze --namespace payments --explain

# 失敗しているPodとServiceのみに絞り込んで分析
k8sgpt analyze --filter Pod,Service --explain

3. クライアント側の匿名化機能の有効化

社内専用の推論エンジンを使用する場合であっても、識別子のマスキングは推奨されるベストプラクティスです。K8sGPTはプロンプトを構築する前に、Pod名、名前空間ラベル、数値IDをサニタイズできます:

k8sgpt analyze --explain --anonymize

4. Prometheus経由のアラートルート設定

K8sGPTオペレーターはk8sgpt_number_of_failuresというPrometheusメトリクスをエクスポートします。Tier-1ワークロードにおいてこのカウントが5分以上ゼロを超えた場合にトリガーされるアラートルールを追加しましょう。オンコールエンジニアは、生コンテナログを手作業で漁る代わりに、事前生成されたResult CRDを即座に確認できます。

Share:
Tags: