Skip to content

Auto-wiring tra componenti ​

L'auto-wiring è la capacità con cui l'operatore effettua il provisioning e inietta le credenziali tra i componenti, così non devi configurare a mano alcun secret tra componenti. È una funzionalità soggetta a licenza (auto-wiring); senza di essa, ogni riferimento dispone di un fallback manuale che mantiene la piattaforma pienamente funzionante.

Che cosa viene collegato ​

RiferimentoCon licenza (auto-wiring)Community (manuale)
Gateway → Postgresdatabase.mode: postgresCluster risolve il cluster, effettua il provisioning del DB litellm + ruolo + password, inietta litellm-db-credentialsdatabase.mode: external + connectionSecretRef (utente/password)
Observability → Postgres / ClickHouse / Redisogni mode: ref risolve il datastore e collega le credenziali da esso generateogni mode: external + connectionSecretRef
ChatUI → GatewaygatewayRef genera una LiteLLMVirtualKey, inietta l'URL interno al cluster + la chiavegateway.{ url, apiKeySecretRef }
Gateway → Observability (tracce)observabilityRef emette una LangfuseOrganization + un LangfuseProject; il langfuse-operator genera una chiave API di progetto utilizzata dalla callback di LiteLLMobservability.{ host, callbackSecretRef } (chiavi publicKey / secretKey)

Le credenziali generate (virtual key, chiavi di callback, password dei datastore) sono memorizzate come semplici Secret Kubernetes posseduti dall'operatore.

Come si risolve un riferimento ​

Per ogni *Ref, il controller:

  1. Risolve e verifica — recupera la risorsa di destinazione; se è mancante o non pronta, rimette in coda il reconcile con una condition chiara invece di fallire.
  2. Esegue l'auto-wiring se la licenza lo consente — quando auto-wiring è abilitato, esegue il provisioning + l'iniezione indicati nella tabella sopra.
  3. Ripiega sulla modalità manuale — quando la funzionalità non è in licenza, salta il completamento automatico, usa i campi espliciti che hai fornito ed emette una condition AutoWiringUnlicensed + un Event che indicano esattamente cosa impostare.

Poiché in Kubernetes gli owner reference tra namespace diversi non sono consentiti, l'operatore usa watch basati su label (non owner reference), così che le modifiche a una risorsa referenziata in un altro namespace attivino comunque un nuovo reconcile.

Una nota su Gateway → Observability ​

Al provisioning automatico delle chiavi Langfuse si applicano due gate

La creazione dell'organizzazione/del progetto Langfuse e la generazione di una chiave API usano l'Admin API di Langfuse, che è una funzionalità di Langfuse Enterprise — indipendente dalla licenza Navique. Il provisioning completamente automatico delle chiavi richiede quindi sia la funzionalità Navique auto-wiring sia un deployment Langfuse EE.

Su un Langfuse community, il LangfuseProject non può generare una chiave: crea il progetto e la chiave nella UI di Langfuse e imposta Gateway.spec.observability.{ host, callbackSecretRef }. L'operatore lo rileva e segnala una condition con le azioni da intraprendere. Il tracing Langfuse è opzionale — il Gateway funziona anche senza.

Il percorso manuale mantiene tutto in funzione ​

Questa è la promessa fondamentale: la piattaforma di base non si blocca mai a causa della licenza. Anche senza alcuna licenza puoi avviare l'intera piattaforma fornendo tu stesso i secret di connessione, l'URL/la chiave del gateway e la callback Langfuse. L'auto-wiring è un vantaggio aggiuntivo, non una condizione per il funzionamento della piattaforma.

Vedi Edizioni e licenze per sapere quale edizione include l'auto-wiring.

Nucleo open source sotto AGPL-3.0. I componenti Enterprise sono proprietari e soggetti a licenza.