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 が登録してアクティブにルーティングしているもの: 
    oc exec -n <bob-namespace> deploy/bob-gateway -- \
  curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/model/info | jq .
    •
注意:

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

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

クレデンシャルは config.yaml の bob.modelGateway.secrets の下に保管されます。bobctl update-model-config --update-secrets を使用して、更新されたクレデンシャルをクラスターにプッシュします。

クレデンシャルの更新

config.yaml の bob.modelGateway.secrets の下にあるクレデンシャルを更新します。

更新されたシークレットをクラスターにプッシュ

bobctl update-model-config --update-secrets

ibm-bob-operator が bob-inference デプロイメントを調整 (reconcile) し、新しいシークレットを自動的にマウントします。

ヒント:

モデル設定ファイルとクレデンシャルの両方を同時に更新する場合は、単一のコマンドで両方をプッシュできます：

bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets

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

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

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

プロバイダー固有の注意事項:
  • openai_compatible / API キー — 新しいキーはシークレットの更新後すぐに有効になります。デプロイメントが正常であることを確認したら古いキーを失効させても安全です。
    •
  • bedrock — update-model-config を実行する前に、新しい IAM アクセスキーが AWS でアクティブであることを確認してください。IAM の伝播には数秒かかる場合があります。
    •
  • vertex — 新しいサービスアカウントキーを生成して base64 エンコードし、config.yaml を更新し、bobctl update-model-config --update-secrets を実行して確認してから 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/model/info エンドポイントはシンプルな 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/model/info にモデルが表示されない
  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.
このトピックはいかがですか？

このページ

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