Auto-wiring entre composants
L'auto-wiring est la capacité par laquelle l'opérateur provisionne et injecte les identifiants entre composants, de sorte que vous ne configurez aucun secret inter-composants à la main. C'est une fonctionnalité sous licence (auto-wiring) ; sans elle, chaque référence dispose d'un repli manuel qui maintient la plateforme pleinement opérationnelle.
Ce qui est câblé
| Référence | Sous licence (auto-wiring) | Community (manuel) |
|---|---|---|
| Gateway → Postgres | database.mode: postgresCluster résout le cluster, provisionne la BDD litellm + rôle + mot de passe, injecte litellm-db-credentials | database.mode: external + connectionSecretRef (user/password) |
| Observability → Postgres / ClickHouse / Redis | chaque mode: ref résout le datastore et câble ses identifiants générés | chaque mode: external + connectionSecretRef |
| ChatUI → Gateway | gatewayRef crée une LiteLLMVirtualKey, injecte l'URL in-cluster + la clé | gateway.{ url, apiKeySecretRef } |
| Gateway → Observability (traces) | observabilityRef émet une LangfuseOrganization + un LangfuseProject ; le langfuse-operator crée une clé d'API de projet que le callback LiteLLM consomme | observability.{ host, callbackSecretRef } (clés publicKey / secretKey) |
Les identifiants générés (clés virtuelles, clés de callback, mots de passe de datastore) sont stockés comme Kubernetes Secrets possédés (owned) en clair.
Comment une référence se résout
Pour chaque *Ref, le contrôleur :
- Résout et conditionne — récupère la cible ; si elle est absente ou non prête, il remet en file d'attente (requeue) avec une condition claire plutôt que d'échouer.
- Câble automatiquement si sous licence — quand
auto-wiringest activé, il effectue le provisionnement + l'injection du tableau ci-dessus. - Se replie sur le manuel — quand la fonctionnalité n'est pas sous licence, il ignore le remplissage automatique, utilise les champs explicites que vous avez fournis, et émet une condition
AutoWiringUnlicensed+ un Event nommant exactement ce qu'il faut définir.
Parce que les références de propriétaire inter-namespaces ne sont pas autorisées dans Kubernetes, l'opérateur utilise des watches basées sur des labels (et non des owner refs) afin que les modifications d'une ressource référencée dans un autre namespace re-déclenchent quand même la réconciliation.
Une note sur Gateway → Observability
Deux conditions s'appliquent au provisionnement automatique des clés Langfuse
La création de l'organisation/du projet Langfuse et la création d'une clé d'API utilisent l'Admin API de Langfuse, qui est une fonctionnalité Langfuse Enterprise — indépendante de la licence Navique. Ainsi, le provisionnement entièrement automatique des clés nécessite à la fois la fonctionnalité Navique auto-wiring et un déploiement Langfuse EE.
Sur une instance Langfuse community, le LangfuseProject ne peut pas créer de clé : créez le projet et la clé dans l'UI Langfuse et définissez Gateway.spec.observability.{ host, callbackSecretRef }. L'opérateur le détecte et expose une condition exploitable. Le tracing Langfuse est optionnel — le Gateway fonctionne sans lui.
Le chemin manuel maintient tout en fonctionnement
C'est la promesse centrale : la plateforme de base ne se bloque jamais sur la licence. Même sans aucune licence, vous pouvez monter toute la plateforme en fournissant vous-même les secrets de connexion, l'URL/la clé du gateway et le callback Langfuse. L'auto-wiring est un incrément de confort, pas une condition préalable au fonctionnement de la plateforme.
Consultez Éditions et licences pour savoir quelle édition inclut l'auto-wiring.