Model-Gateway-Deployments überwachen, warten und Fehler beheben, einschließlich Modellkonfigurationsaktualisierungen, Credential-Rotation, Gesundheitsmonitoring, Log-Sammlung und Behebung häufiger Konnektivitäts- und Authentifizierungsprobleme.

Nach dem Deployment hilft ein laufendes Betriebsmanagement des Model Gateways dabei, zuverlässigen Zugang zu konfigurierten KI-Modellen sicherzustellen und Serviceunterbrechungen zu minimieren. Administratoren können aktive Modellkonfigurationen überprüfen, Provider-Anmeldeinformationen aktualisieren, Secrets rotieren, die Gateway-Gesundheit überwachen und Diagnoseinformationen sammeln, wenn Probleme auftreten.

Konfigurierte Modelle anzeigen

Es gibt zwei Ebenen für die Anzeige von Modellen — was in der Konfiguration steht und was bob-inference tatsächlich zur Laufzeit geladen hat.

Konfigurationsebene — aktuelle Model-Gateway-Konfiguration aus der Inferenz-ConfigMap abrufen:

oc get cm bob-inference-config -n <bob-namespace> -o yaml | yq '.data."config.yaml"'

Laufzeitebene — was bob-inference registriert hat und aktiv routed: Den /v1/models-Endpoint direkt abfragen (siehe Modellkonnektivität validieren).

Hinweis:

Der Laufzeit-Endpoint /v1/models listet nur Modelle auf, bei denen exposed: true gesetzt ist. Die Konfigurationsdatei ist der einzige Weg, den vollständigen Satz konfigurierter Modelle zu sehen.

Provider-Anmeldeinformationen aktualisieren

Anmeldeinformationen werden als Umgebungsvariablen aus bob.modelGateway.secrets eingehängt. Ihre Aktualisierung ist ein zweistufiger Vorgang — den Secret-Wert aktualisieren, dann den Inferenz-Service neu starten, damit das neue Einhängen wirksam wird.

Secret aktualisieren

Die Bob-CR bearbeiten und den neuen Wert anwenden:

oc edit bob <instance-name> -n <bob-namespace>
# Update the value under bob.modelGateway.secrets

Inferenz-Service neu starten

Den Inferenz-Service neu starten, damit das neue Secret eingehängt wird:

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

Warnung:

Der Inferenz-Service-Pod muss nach jeder Secret-Aktualisierung neu gestartet werden. Modellkonfigurationsänderungen (Hinzufügen oder Entfernen von Modellen, Ändern der base_url) und Secret-Änderungen können in einer einzigen CR-Aktualisierung gesammelt und mit einem einzelnen Neustart angewendet werden.

Secrets rotieren

Die Secret-Rotation folgt demselben Muster wie eine Anmeldeinformationsaktualisierung, mit zusätzlicher Sorgfalt beim Timing, um Ausfallzeiten zu vermeiden.

Empfohlene Zero-Downtime-Rotationssequenz:

bob.modelGateway.secrets mit dem neuen Anmeldeinformationswert aktualisieren.

Den Inferenz-Service neu starten: oc rollout restart deploy/inference-service -n <bob-namespace>.

Bestätige, dass die neue Anmeldeinformation funktioniert, indem du den Inferenztest aus Verifizierung nach der Installation verwendest.

Die alte Anmeldeinformation beim Provider erst widerrufen, nachdem der Pod als gesund bestätigt wurde.

Provider-spezifische Hinweise:

openai_compatible / API-Schlüssel — neuer Schlüssel ist sofort nach dem Neustart wirksam. Sicher, den alten Schlüssel zu widerrufen, sobald der Pod gesund ist.

bedrock — stelle sicher, dass der neue IAM-Zugriffsschlüssel in AWS aktiv ist, bevor du neu startest. IAM-Propagierung kann einige Sekunden dauern.

vertex — den neuen Service-Account-Schlüssel generieren und base64-kodieren, Secret aktualisieren, neu starten und verifizieren, dann den alten Schlüssel in GCP löschen.

ca_cert_pem — für die Zertifikatserneuerung vor dem Anwenden sicherstellen, dass das neue Zertifikat nicht abgelaufen ist. Siehe TLS-Zertifikatsvalidierung.

Gateway-Gesundheit überwachen

Pod-Neustartanzahl — eine steigende Neustartanzahl ist ein frühes Signal für einen wiederkehrenden Startfehler (fehlerhaftes Secret-Einhängen, Konfigurationsparsefehler):

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

Liveness- und Readiness-Probes — aktuelle Probe-Konfiguration und -Status prüfen:

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

Periodische Gesundheitsprüfung — der /v1/models-Endpoint dient als einfache Liveness-Prüfung. Wenn er eine gültige Modellliste zurückgibt, ist der Gateway aktiv. Dies kann von einem Monitoring-Tool oder einem Cron-Job innerhalb des Clusters abgefragt werden.

Logs und Diagnostik sammeln

Logs für ein bestimmtes Zeitfenster (am nützlichsten bei der Untersuchung eines gemeldeten Vorfalls):

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

Logs von einer vorherigen Pod-Instanz (wenn der Pod neu gestartet wurde und die Fehlerlogs nicht mehr vorhanden sind):

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

Vollständiges Diagnosepaket für den Support:

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

Hinweis:

Das Diagnosepaket enthält Pod-Umgebungsvariablennamen, aber keine Secret-Werte (Secrets werden eingehängt, nicht in Logs ausgegeben). Überprüfe Logs auf versehentliche Ausgabe von Anmeldeinformationen, bevor du sie an den Support sendest.

Fehlerbehebung bei Konnektivitäts- und Authentifizierungsproblemen

Modell erscheint nicht in /v1/models

Prüfe, ob exposed: false gesetzt ist — wenn ja, ist dies das erwartete Verhalten.

Überprüfe die Startlogs auf einen Registrierungsfehler für diesen model_name.

Verifiziere den Provider-Block — korrekte base_url, Modell-ID und Anmeldeinformationen.

401 Unauthorized bei Inferenzanfragen

Bestätige, dass der Secret-Wert in bob.modelGateway.secrets korrekt und aktuell ist.

Bestätige, dass die env.<VAR>-Referenz in der Modellkonfiguration genau mit dem Secret-Schlüsselnamen übereinstimmt (Groß-/Kleinschreibung beachten).

Inferenz-Service neu starten und erneut versuchen — das Secret wurde möglicherweise ohne Neustart aktualisiert.

Anmeldeinformationen extern testen. Siehe Authentifizierungsvalidierung.

502 Bad Gateway oder connection refused

Bestätige, dass der Modell-Endpoint aktiv und vom Cluster aus erreichbar ist. Siehe Konnektivitätstest.

Auf base_url-Probleme prüfen — abschließende Schrägstriche, falsches Schema (http vs. https), falscher Port.

Auf Netzwerkrichtlinienänderungen prüfen, die seit der Installation ausgehenden Traffic blockiert haben könnten.

certificate signed by unknown authority

Bestätige, dass ca_cert_pem gesetzt ist und eine gültige Umgebungsvariable referenziert.

Bestätige, dass die Umgebungsvariable in bob.modelGateway.secrets vorhanden ist.

Stelle sicher, dass das Zertifikat nicht abgelaufen ist: openssl x509 -noout -dates.

Bestätige, dass das Zertifikat den Hostnamen des Endpoints durch Prüfen der Subject Alternative Names abdeckt.

Inferenz-Service-Pod in CrashLoopBackOff

Logs der vorherigen Instanz prüfen: oc logs --previous.

Nach Konfigurationsparsefehler suchen — fehlerhaftes YAML in der Model-Gateway-Konfiguration.

Nach fehlenden Secret-Einhängungen im Events-Abschnitt suchen: oc describe pod.

Sicherstellen, dass das YAML der Model-Gateway-Konfiguration gültig ist, bevor es erneut angewendet wird.

Betrieb und Fehlerbehebung