IBM Bob

Operacje i rozwiązywanie problemów

Monitoruj, utrzymuj i rozwiązuj problemy z wdrożeniami bramy modelu, w tym aktualizacje konfiguracji modelu, rotację danych uwierzytelniających, monitorowanie kondycji, zbieranie dzienników i rozwiązywanie typowych problemów z łącznością i uwierzytelnianiem.

Po wdrożeniu bieżące zarządzanie operacyjne bramy modelu pomaga zapewnić niezawodny dostęp do skonfigurowanych modeli AI i minimalizuje zakłócenia usług. Administratorzy mogą przeglądać aktywne konfiguracje modeli, aktualizować dane uwierzytelniające dostawców, rotować sekrety, monitorować kondycję bramy i zbierać informacje diagnostyczne w przypadku wystąpienia problemów.

Przeglądanie skonfigurowanych modeli

Przeglądanie modeli odbywa się na dwóch poziomach — co jest w konfiguracji i co bob-inference faktycznie załadował w czasie uruchamiania.
  • Poziom konfiguracji — pobierz bieżącą konfigurację bramy modelu z ConfigMap wnioskowania: 
    oc get cm bob-inference-config -n <bob-namespace> -o yaml | yq '.data."config.yaml"'
    •
  • Poziom uruchamiania — co bob-inference zarejestrował i aktywnie do czego kieruje: zapytaj bezpośrednio punkt końcowy /v1/models (zobacz Weryfikacja łączności z modelami).
    •
Uwaga:

Punkt końcowy /v1/models w czasie uruchamiania wyświetla tylko modele z exposed: true. Plik konfiguracyjny jest jedynym sposobem na wyświetlenie pełnego zestawu skonfigurowanych modeli.

Aktualizowanie danych uwierzytelniających dostawców

Dane uwierzytelniające są montowane jako zmienne środowiskowe z bob.modelGateway.secrets. Ich aktualizacja to operacja dwuetapowa — zaktualizuj wartość sekretu, a następnie uruchom ponownie usługę wnioskowania, aby pobrać nowe montowanie.

Aktualizacja sekretu

Edytuj CR Bob i zastosuj nową wartość:

oc edit bob <instance-name> -n <bob-namespace>
# Zaktualizuj wartość w sekcji bob.modelGateway.secrets

Ponowne uruchomienie usługi wnioskowania

Uruchom ponownie usługę wnioskowania, aby nowy sekret został zamontowany:

oc rollout restart deploy/inference-service -n <bob-namespace>
oc rollout status deploy/inference-service -n <bob-namespace>
Ostrzeżenie:

Pod usługi wnioskowania musi zostać uruchomiony ponownie po każdej aktualizacji sekretu. Zmiany konfiguracji modelu (dodawanie lub usuwanie modeli, zmiana base_url) i zmiany sekretów mogą być zgrupowane w jednej aktualizacji CR, a następnie po jednym restarcie.

Rotacja sekretów

Rotacja sekretów przebiega według tego samego wzorca co aktualizacja danych uwierzytelniających, z dodatkową dbałością o czas, aby uniknąć przestojów.

Zalecana sekwencja rotacji bez przestojów:
  1. Zaktualizuj bob.modelGateway.secrets nową wartością danych uwierzytelniających.
    2.
  2. Uruchom ponownie usługę wnioskowania: oc rollout restart deploy/inference-service -n <bob-namespace>.
    3.
  3. Potwierdź, że nowe dane uwierzytelniające działają, używając testu wnioskowania z artykułu Weryfikacja po instalacji.
    4.
  4. Unieważnij stare dane uwierzytelniające po stronie dostawcy dopiero po potwierdzeniu kondycji poda.
    5.

Uwagi specyficzne dla dostawców:
  • openai_compatible / klucze API — nowy klucz obowiązuje natychmiast po restarcie. Bezpiecznie jest unieważnić stary klucz po potwierdzeniu kondycji poda.
    •
  • bedrock — upewnij się, że nowy klucz dostępu IAM jest aktywny w AWS przed restartem. Propagacja IAM może potrwać kilka sekund.
    •
  • vertex — wygeneruj i zakoduj w base64 nowy klucz konta usługi, zaktualizuj sekret, uruchom ponownie i zweryfikuj, a następnie usuń stary klucz w GCP.
    •
  • ca_cert_pem — podczas odnawiania certyfikatu sprawdź, czy nowy certyfikat nie wygasł, przed zastosowaniem. Zobacz Weryfikacja certyfikatu TLS.
    •

Monitorowanie kondycji bramy

Liczba restartów podów — rosnąca liczba restartów to wczesny sygnał powtarzającej się awarii uruchamiania (zły montaż sekretu, błąd parsowania konfiguracji):

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

Sondy liveness i readiness — sprawdź bieżącą konfigurację i status sond:

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

Okresowe sprawdzanie kondycji — punkt końcowy /v1/models służy jako prosta kontrola liveness. Jeśli zwraca prawidłową listę modeli, brama działa. Można go odpytywać z narzędzia monitorującego lub zadania cron wewnątrz klastra.

Zbieranie dzienników i diagnostyki

Dzienniki dla określonego okna czasowego (najbardziej przydatne podczas badania zgłoszonego incydentu):

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

Dzienniki z poprzedniej instancji poda (jeśli pod był restartowany i dzienniki awarii zniknęły):

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

Pełny pakiet diagnostyczny dla wsparcia:

 
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
Uwaga:

Pakiet diagnostyczny zawiera nazwy zmiennych środowiskowych podów, ale nie wartości sekretów (sekrety są montowane, a nie drukowane w dziennikach). Przejrzyj dzienniki pod kątem przypadkowego wyjścia danych uwierzytelniających przed wysłaniem do wsparcia.

Rozwiązywanie problemów z łącznością i uwierzytelnianiem

Model nie pojawia się w /v1/models
  1. Sprawdź, czy ustawiono exposed: false — jeśli tak, to oczekiwane zachowanie.
    2.
  2. Sprawdź dzienniki startowe pod kątem błędu rejestracji dla tej wartości model_name.
    3.
  3. Zweryfikuj blok dostawcy — prawidłowy base_url, ID model i dane uwierzytelniające.
    4.

401 Unauthorized przy żądaniach wnioskowania
  1. Potwierdź, że wartość sekretu w bob.modelGateway.secrets jest prawidłowa i aktualna.
    2.
  2. Potwierdź, że odwołanie env.<VAR> w konfiguracji modelu dokładnie odpowiada nazwie klucza sekretu (rozróżniana jest wielkość liter).
    3.
  3. Uruchom ponownie usługę wnioskowania i spróbuj ponownie — sekret mógł zostać zaktualizowany bez restartu.
    4.
  4. Przetestuj dane uwierzytelniające poza pasmem. Zobacz Weryfikacja uwierzytelniania.
    5.

502 Bad Gateway lub connection refused
  1. Potwierdź, że punkt końcowy modelu jest dostępny z klastra. Zobacz Testowanie łączności.
    2.
  2. Sprawdź problemy z base_url — końcowe ukośniki, nieprawidłowy schemat (http vs https), nieprawidłowy port.
    3.
  3. Sprawdź zmiany zasad sieciowych, które mogły zablokować ruch wychodzący od czasu instalacji.
    4.

certificate signed by unknown authority
  1. Potwierdź, że ca_cert_pem jest ustawiony i odwołuje się do prawidłowej zmiennej środowiskowej.
    2.
  2. Potwierdź, że zmienna środowiskowa jest obecna w bob.modelGateway.secrets.
    3.
  3. Sprawdź, czy certyfikat nie wygasł: openssl x509 -noout -dates.
    4.
  4. Potwierdź, że certyfikat obejmuje nazwę hosta punktu końcowego, sprawdzając Subject Alternative Names.
    5.

Pod usługi wnioskowania w stanie CrashLoopBackOff
  1. Sprawdź dzienniki z poprzedniej instancji: oc logs --previous.
    2.
  2. Szukaj błędów parsowania konfiguracji — nieprawidłowy YAML w konfiguracji bramy modelu.
    3.
  3. Szukaj brakujących montowań sekretów w sekcji Events: oc describe pod.
    4.
  4. Sprawdź, czy YAML konfiguracji bramy modelu jest prawidłowy przed ponownym zastosowaniem.
    5.
Jak oceniasz ten temat?

Na tej stronie

Przeglądanie skonfigurowanych modeliAktualizowanie danych uwierzytelniających dostawcówAktualizacja sekretuPonowne uruchomienie usługi wnioskowaniaRotacja sekretówMonitorowanie kondycji bramyZbieranie dzienników i diagnostykiRozwiązywanie problemów z łącznością i uwierzytelnianiem