Modellkonnektivität, Anmeldeinformationen, Zertifikate und Konfigurationseinstellungen vor der Installation validieren, um Model-Gateway-Probleme zu identifizieren und zu beheben, bevor Bob On-Premises deployed wird.

Überprüfe vor der Installation von Bob On-Premises, ob deine Modell-Endpoints, Authentifizierungsnachweise, TLS-Zertifikate und die Model-Gateway-Konfiguration korrekt konfiguriert und vom Ziel-OpenShift-Cluster aus zugänglich sind. Diese Validierungsprüfungen helfen, Konnektivitätsprobleme, ungültige Anmeldeinformationen, Zertifikats-Trust-Probleme und Konfigurationsfehler vor dem Deployment zu identifizieren, was Installationsfehler und Fehlerbehebungsaufwand reduziert.

Gehe diese Checkliste durch, bevor du bobctl install ausführst, um fehlende Konfigurationen frühzeitig zu erkennen.

Konnektivitätstest zu Modell-Endpoints

Bestätige, dass der OpenShift-Cluster jeden Modell-Endpoint erreichen kann, bevor eine Bob-Komponente deployed wird. Starte einen temporären Debug-Pod im Ziel-Namespace und teste die HTTPS-Erreichbarkeit direkt:

# openai_compatible
oc run curl-test --image=curlimages/curl --restart=Never --rm -it -- \
  curl -v https://<model-endpoint>/v1/models

# bedrock
oc run curl-test --image=curlimages/curl --restart=Never --rm -it -- \
  curl -k https://bedrock.<AWS_REGION>.amazonaws.com/foundation-models \
  --aws-sigv4 "aws:amz:${REGION}:bedrock" \
  --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY"

Für openai_compatible-Endpoints teste gegen den base_url-Wert aus deiner Model-Gateway-Konfiguration. Für Air-Gapped- oder private Infrastruktur ist dies der einzige Weg, die Konnektivität zu validieren, da per Design keine externe Erreichbarkeit vorhanden ist.

Authentifizierungsvalidierung

Validiere Anmeldeinformationen bevor du sie als Secrets in config.yaml kodierst. Eine fehlerhafte Anmeldeinformation führt zu einem fehlgeschlagenen Start des Inferenz-Services, oft mit einer kryptischen Log-Meldung.

openai_compatible — teste den API-Schlüssel direkt aus einem Debug-Pod:

curl -s https://<base_url>/v1/models \
  -H "Authorization: Bearer <api_key>" | jq '.data[].id'

bedrock — überprüfe die Werte AWS_ACCESS_KEY und AWS_SECRET_ACCESS_KEY mit der AWS-CLI, bevor du sie zu config.yaml hinzufügst:
```
aws bedrock list-foundation-models --region us-east-1
```
vertex — dekodiere den base64-Wert von GEMINI_CREDENTIALS und bestätige, dass es ein gültiges Service-Account-JSON ist, bevor du es bereitstellst:
```
base64 -d <<< "$GEMINI_CREDENTIALS" | jq '.type'
# Expected output: "service_account"
```

TLS-Zertifikatsvalidierung

Wenn du ca_cert_pem mit einem openai_compatible-Endpoint verwendest, validiere das Zertifikat, bevor du es als Secret bereitstellst.

Stelle sicher, dass das Zertifikat PEM-kodiert und nicht abgelaufen ist:

echo "<cert content>" | openssl x509 -noout -dates

Bestätige, dass das Zertifikat zur CA-Kette des Endpoints passt:

openssl s_client -connect <host>:<port> -CAfile ca.pem

Warnung:

insecure_skip_verify: true darf nur vorübergehend während des initialen Konnektivitäts-Debuggings verwendet werden. Entferne es vor dem Produktiveinsatz. Wenn ca_cert_pem eine Umgebungsvariable referenziert, die nicht in bob.modelGateway.secrets vorhanden ist, startet der Inferenz-Service erfolgreich, aber TLS schlägt zur Inferenzzeit fehl.

Modellentdeckungs-Validierung

Bestätige, dass die model-ID in deinem Provider-Block genau dem entspricht, was der Provider bereitstellt. Eine Nichtübereinstimmung führt zu einem 404- oder Model-not-found-Fehler zur Inferenzzeit, nicht beim Start.

Für openai_compatible-Endpoints überprüfe verfügbare Modell-IDs vor der Installation:

curl -s https://<base_url>/v1/models \
  -H "Authorization: Bearer <api_key>" | jq '.data[].id'

Häufige Fehlkonfigurationsprüfungen

Fehlkonfiguration	Symptom	Prüfung
Secret-Name in der Modellkonfiguration stimmt nicht mit dem Schlüssel im `secrets`-Block von `config.yaml` überein	Authentifizierung schlägt zur Anfragenzeit fehl, nicht beim Start	Jede `env.*`-Referenz in der Modellkonfiguration mit den Schlüsseln in `bob.modelGateway.secrets` abgleichen
`GEMINI_CREDENTIALS` nicht base64-kodiert	Vertex-Provider schlägt beim Start mit Parsefehler für Anmeldeinformationen fehl	`base64 -d <<< "$VALUE"` ausführen und bestätigen, dass es gültiges JSON mit `"type": "service_account"` ist
`base_url` enthält einen abschließenden `/` oder Pfad-Suffix	Provider gibt 404 zurück	Abschließende Schrägstriche entfernen — der Gateway hängt Pfade wie `/v1/chat/completions` selbst an
Doppelte `model_name`-Werte in der `models`-Liste	Undefiniertes Routing-Verhalten	Sicherstellen, dass alle `model_name`-Werte in der gesamten Konfiguration eindeutig sind
`bobctl install` ohne `--model-config` ausgeführt	Leerer Gateway, keine Inferenz	Bestätigen, dass `--model-config` übergeben wird und die Datei unter dem angegebenen Pfad lesbar ist
`ca_cert_pem`-Umgebungsvariable in der Modellkonfiguration definiert, aber in `secrets` fehlend	TLS-Fehler zur Inferenzzeit	Jede `env.*`-Referenz in der Modellkonfiguration mit dem `secrets`-Block abgleichen

Validierung vor der Installation

Konnektivitätstest zu Modell-Endpoints

Authentifizierungsvalidierung

TLS-Zertifikatsvalidierung

Modellentdeckungs-Validierung

Häufige Fehlkonfigurationsprüfungen

Auf dieser Seite