IBM Bob

運用とトラブルシューティング

モデル設定の更新、クレデンシャルのローテーション、ヘルス監視、ログ収集、一般的な接続・認証問題の解決など、モデルゲートウェイデプロイメントの監視、保守、トラブルシューティングを行います。

デプロイメント後、モデルゲートウェイの継続的な運用管理は、設定済み AI モデルへの信頼性の高いアクセスを確保し、サービス中断を最小限に抑えます。管理者はアクティブなモデル設定を確認し、プロバイダークレデンシャルを更新し、シークレットをローテーションし、ゲートウェイのヘルスを監視し、問題が発生した場合に診断情報を収集できます。

設定済みモデルの表示

モデルの表示には 2 つのレベルがあります — 設定にあるものとランタイムで bob-inference が実際に読み込んだものです。
  • 設定レベル — inference ConfigMap から現在のモデルゲートウェイ設定を取得します。 
    oc get cm bob-inference-config -n <bob-namespace> -o yaml | yq '.data."config.yaml"'
    •
  • ランタイムレベル — bob-inference が登録してアクティブにルーティングしているもの: /v1/models エンドポイントに直接クエリします (モデル接続性の検証を参照)。
    •
注意:

ランタイムの /v1/models エンドポイントは exposed: true のモデルのみを一覧表示します。設定ファイルは設定済みモデルの完全なセットを確認する唯一の方法です。

プロバイダークレデンシャルの更新

クレデンシャルは bob.modelGateway.secrets から環境変数としてマウントされます。更新は 2 ステップの操作です — シークレット値を更新し、Inference Service を再起動して新しいマウントを取得します。

シークレットの更新

Bob CR を編集して新しい値を適用します。

oc edit bob <instance-name> -n <bob-namespace>
# bob.modelGateway.secrets 以下の値を更新

Inference Service の再起動

新しいシークレットがマウントされるように Inference Service を再起動します。

oc rollout restart deploy/inference-service -n <bob-namespace>
oc rollout status deploy/inference-service -n <bob-namespace>
警告:

Inference Service Pod はシークレット更新後に再起動する必要があります。モデル設定の変更 (モデルの追加または削除、base_url の変更) とシークレットの変更は、1 回の CR 更新にまとめて 1 回の再起動で適用できます。

シークレットのローテーション

シークレットのローテーションはクレデンシャル更新と同じパターンに従いますが、ダウンタイムを避けるためのタイミングに追加の注意が必要です。

推奨されるゼロダウンタイムローテーション手順:
  1. 新しいクレデンシャル値で bob.modelGateway.secrets を更新します。
    2.
  2. Inference Service を再起動します: oc rollout restart deploy/inference-service -n <bob-namespace>。
    3.
  3. インストール後の確認の推論テストを使用して新しいクレデンシャルが機能していることを確認します。
    4.
  4. Pod が正常であることを確認した後にのみ、プロバイダー側で古いクレデンシャルを失効させます。
    5.

プロバイダー固有の注意事項:
  • openai_compatible / API キー — 新しいキーは再起動後すぐに有効です。Pod が正常であることを確認したら古いキーを失効させても安全です。
    •
  • bedrock — 再起動前に新しい IAM アクセスキーが AWS でアクティブであることを確認してください。IAM の伝播には数秒かかる場合があります。
    •
  • vertex — 新しいサービスアカウントキーを生成して base64 エンコードし、シークレットを更新し、再起動して確認してから GCP で古いキーを削除します。
    •
  • ca_cert_pem — 証明書の更新の場合は、適用前に新しい証明書が期限切れでないことを確認してください。TLS 証明書の検証を参照してください。
    •

ゲートウェイのヘルス監視

Pod 再起動数 — 再起動数の増加は繰り返し起動失敗 (不正なシークレットマウント、設定解析エラー) の早期シグナルです。

 
oc get pods -n <bob-namespace> -l app=bob-inference \
  -o custom-columns='NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount'

liveness と readiness プローブ — 現在のプローブ設定とステータスを確認します。

 
oc describe deploy/bob-inference -n <bob-namespace> | grep -A 10 "Liveness\|Readiness"

定期的なヘルスチェック — /v1/models エンドポイントはシンプルな liveness チェックとして機能します。有効なモデルリストを返せば、ゲートウェイは起動しています。これはクラスター内の監視ツールや cron ジョブからポーリングできます。

ログと診断の収集

特定の時間枠のログ (報告されたインシデントを調査する際に最も有用):

 
oc logs -n <bob-namespace> deploy/bob-inference \
  --since-time="2025-01-01T12:00:00Z" > bob-inference.log

前の Pod インスタンスのログ (Pod が再起動して障害ログが消えた場合):

 
oc logs -n <bob-namespace> deploy/bob-inference --previous

サポート用の完全な診断バンドル:

 
oc describe pod -n <bob-namespace> -l app=bob-inference >> diagnostics.txt
oc get events -n <bob-namespace> --sort-by='.lastTimestamp' >> diagnostics.txt
oc logs -n <bob-namespace> deploy/bob-inference --since=1h >> diagnostics.txt
注意:

診断バンドルには Pod 環境変数名が含まれますが、シークレット値は含まれません (シークレットはマウントされ、ログに出力されません)。サポートに送信する前に、誤ってクレデンシャルが出力されていないかログを確認してください。

接続と認証の問題のトラブルシューティング

/v1/models にモデルが表示されない
  1. exposed: false が設定されているか確認します — 設定されている場合は期待される動作です。
    2.
  2. その model_name の登録エラーがないか起動ログを確認します。
    3.
  3. プロバイダーブロックを確認します — 正しい base_url、model ID、クレデンシャル。
    4.

推論リクエストで 401 Unauthorized
  1. bob.modelGateway.secrets のシークレット値が正しく最新であることを確認します。
    2.
  2. モデル設定の env.<VAR> 参照がシークレットキー名と完全に一致することを確認します (大文字小文字が区別されます)。
    3.
  3. Inference Service を再起動して再試行します — 再起動なしにシークレットが更新された可能性があります。
    4.
  4. クレデンシャルをアウトオブバンドでテストします。認証の検証を参照してください。
    5.

502 Bad Gateway または connection refused
  1. モデルエンドポイントが起動しておりクラスターから到達可能であることを確認します。接続テストを参照してください。
    2.
  2. base_url の問題を確認します — 末尾のスラッシュ、誤ったスキーム (http vs https)、誤ったポート。
    3.
  3. インストール後にアウトバウンドトラフィックをブロックした可能性があるネットワークポリシーの変更を確認します。
    4.

certificate signed by unknown authority
  1. ca_cert_pem が設定されており、有効な環境変数を参照していることを確認します。
    2.
  2. 環境変数が bob.modelGateway.secrets に存在することを確認します。
    3.
  3. 証明書が期限切れでないことを確認します: openssl x509 -noout -dates。
    4.
  4. サブジェクト代替名を確認して、証明書がエンドポイントのホスト名をカバーしていることを確認します。
    5.

Inference Service Pod が CrashLoopBackOff
  1. 前のインスタンスのログを確認します: oc logs --previous。
    2.
  2. 設定解析エラーを探します — モデルゲートウェイ設定の不正な YAML。
    3.
  3. Events セクションでシークレットマウントの欠落を探します: oc describe pod。
    4.
  4. 再適用する前にモデルゲートウェイ設定の YAML が有効であることを確認します。
    5.
このトピックはいかがですか？

このページ

設定済みモデルの表示プロバイダークレデンシャルの更新シークレットの更新Inference Service の再起動シークレットのローテーションゲートウェイのヘルス監視ログと診断の収集接続と認証の問題のトラブルシューティング