Surveillez, maintenez et dépannez les déploiements du Model Gateway, y compris les mises à jour de configuration des modèles, la rotation des identifiants, la surveillance de la santé, la collecte de journaux et la résolution des problèmes courants de connectivité et d'authentification.

Après le déploiement, la gestion opérationnelle continue du Model Gateway permet de garantir un accès fiable aux modèles d'IA configurés et de minimiser les interruptions de service. Les administrateurs peuvent vérifier les configurations de modèles actives, mettre à jour les identifiants des fournisseurs, effectuer la rotation des secrets, surveiller la santé de la passerelle et collecter des informations de diagnostic en cas de problème.

Afficher les modèles configurés

L'affichage des modèles comporte deux niveaux — ce qui se trouve dans la configuration et ce que bob-inference a réellement chargé au moment de l'exécution.

Niveau configuration — récupérez la configuration actuelle du model gateway depuis la ConfigMap d'inférence :

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

Niveau runtime — ce que bob-inference a enregistré et vers quoi il route activement : interrogez directement l'endpoint /v1/models (voir Valider la connectivité des modèles).

Remarque :

L'endpoint de runtime /v1/models liste uniquement les modèles pour lesquels exposed: true. Le fichier de configuration est le seul moyen de visualiser l'ensemble complet des modèles configurés.

Mettre à jour les identifiants des fournisseurs

Les identifiants sont montés sous forme de variables d'environnement depuis bob.modelGateway.secrets. Leur mise à jour s'effectue en deux étapes — mettre à jour la valeur du secret, puis redémarrer le service d'inférence (Inference Service) pour appliquer le nouveau montage.

Mettre à jour le secret

Modifiez la ressource personnalisée Bob et appliquez la nouvelle valeur :

oc edit bob <instance-name> -n <bob-namespace>
# Mettre à jour la valeur sous bob.modelGateway.secrets

Redémarrer le service d'inférence

Redémarrez le service d'inférence pour que le nouveau secret soit monté :

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

Avertissement :

Le pod du service d'inférence doit être redémarré après toute mise à jour de secret. Les modifications de configuration du modèle (ajout ou suppression de modèles, modification de base_url) et les modifications de secret peuvent être regroupées dans une seule mise à jour de la CR suivie d'un unique redémarrage.

Rotation des secrets

La rotation des secrets suit le même modèle qu'une mise à jour d'identifiant, avec une attention particulière portée au calendrier pour éviter toute indisponibilité.

Séquence de rotation sans interruption de service recommandée :

Mettez à jour bob.modelGateway.secrets avec la nouvelle valeur d'identifiant.

Redémarrez le service d'inférence : oc rollout restart deploy/inference-service -n <bob-namespace>.

Confirmez que le nouvel identifiant fonctionne à l'aide du test d'inférence décrit dans Vérification post-installation.

Révoquez l'ancien identifiant côté fournisseur uniquement après avoir confirmé la bonne santé du pod.

Remarques spécifiques aux fournisseurs :

openai_compatible / clés d'API — la nouvelle clé est effective immédiatement au redémarrage. Il est possible de révoquer l'ancienne clé en toute sécurité une fois le pod opérationnel.

bedrock — assurez-vous que la nouvelle clé d'accès IAM est active dans AWS avant le redémarrage. La propagation IAM peut prendre quelques secondes.

vertex — générez et encodez en base64 la nouvelle clé de compte de service, mettez à jour le secret, redémarrez et vérifiez, puis supprimez l'ancienne clé dans GCP.

ca_cert_pem — pour le renouvellement de certificat, vérifiez que le nouveau certificat n'est pas expiré avant de l'appliquer. Voir Validation du certificat TLS.

Surveillance de la santé de la passerelle

Nombre de redémarrages de pods — une hausse du nombre de redémarrages est un signal d'alerte précoce d'un échec de démarrage récurrent (mauvais montage de secret, erreur d'analyse de configuration) :

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

Sondes de vivacité et d'état de préparation (Liveness et Readiness) — vérifiez la configuration et le statut actuels des sondes :

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

Contrôle de santé périodique — l'endpoint /v1/models fait office de simple contrôle de vivacité. S'il renvoie une liste de modèles valide, la passerelle est opérationnelle. Cela peut être interrogé par un outil de surveillance ou une tâche cron à l'intérieur du cluster.

Collecte des journaux et diagnostics

Journaux pour une plage horaire spécifique (particulièrement utile lors de l'investigation d'un incident signalé) :

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

Journaux d'une instance de pod précédente (si le pod a redémarré et que les journaux de défaillance ne sont plus là) :

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

Ensemble complet de diagnostics pour le 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

Remarque :

L'ensemble de diagnostics contient les noms des variables d'environnement des pods mais pas les valeurs des secrets (les secrets sont montés et non affichés dans les journaux). Examinez les journaux pour détecter toute sortie accidentelle d'identifiants avant de les transmettre au support.

Résolution des problèmes de connectivité et d'authentification

Modèle n'apparaissant pas dans /v1/models

Vérifiez si exposed: false est défini — si c'est le cas, il s'agit du comportement attendu.

Consultez les journaux de démarrage à la recherche d'une erreur d'enregistrement pour ce model_name.

Vérifiez le bloc fournisseur — exactitude de base_url, de l'ID model et des identifiants.

401 Unauthorized sur les requêtes d'inférence

Confirmez que la valeur du secret dans bob.modelGateway.secrets est correcte et à jour.

Confirmez que la référence env.<VAR> dans la config du modèle correspond exactement au nom de la clé de secret (sensible à la casse).

Redémarrez le service d'inférence et réessayez — le secret a peut-être été mis à jour sans redémarrage.

Testez l'identifiant hors bande. Voir Validation de l'authentification.

502 Bad Gateway ou connection refused

Confirmez que l'endpoint du modèle est actif et accessible depuis le cluster. Voir Test de connectivité.

Vérifiez les problèmes de base_url — barres obliques finales, mauvais protocole (http vs https), mauvais port.

Vérifiez s'il y a eu des modifications de politiques réseau ayant pu bloquer le trafic sortant depuis l'installation.

certificate signed by unknown authority

Confirmez que ca_cert_pem est défini et fait référence à une variable d'environnement valide.

Confirmez que la variable d'environnement est présente dans bob.modelGateway.secrets.

Vérifiez que le certificat n'est pas expiré : openssl x509 -noout -dates.

Confirmez que le certificat couvre le nom d'hôte de l'endpoint en vérifiant les Subject Alternative Names.

Pod du service d'inférence en CrashLoopBackOff

Vérifiez les journaux de l'instance précédente : oc logs --previous.

Recherchez des erreurs d'analyse de configuration — YAML mal formé dans la configuration du model gateway.

Recherchez des montages de secrets manquants dans la section Events : oc describe pod.

Confirmez que le YAML de configuration du model gateway est valide avant de le réappliquer.

Exploitation et dépannage