Komponentenübergreifendes Auto-Wiring
Auto-Wiring ist die Fähigkeit, mit der der Operator Anmeldedaten über Komponenten hinweg bereitstellt und injiziert, sodass Sie keine komponentenübergreifenden Secrets von Hand konfigurieren. Es ist ein lizenziertes Feature (auto-wiring); ohne es hat jede Referenz einen manuellen Fallback, der die Plattform vollständig am Laufen hält.
Was verdrahtet wird
| Referenz | Lizenziert (auto-wiring) | Community (manuell) |
|---|---|---|
| Gateway → Postgres | database.mode: postgresCluster löst den Cluster auf, stellt die litellm-DB + -Rolle + -Passwort bereit, injiziert litellm-db-credentials | database.mode: external + connectionSecretRef (user/password) |
| Observability → Postgres / ClickHouse / Redis | jeder mode: ref löst den Datenspeicher auf und verdrahtet seine generierten Anmeldedaten | jeder mode: external + connectionSecretRef |
| ChatUI → Gateway | gatewayRef erzeugt einen LiteLLMVirtualKey, injiziert die clusterinterne URL + den Key | gateway.{ url, apiKeySecretRef } |
| Gateway → Observability (Traces) | observabilityRef emittiert eine LangfuseOrganization + ein LangfuseProject; der langfuse-operator erzeugt einen Projekt-API-Key, den der LiteLLM-Callback konsumiert | observability.{ host, callbackSecretRef } (Keys publicKey / secretKey) |
Generierte Anmeldedaten (Virtual Keys, Callback Keys, Datenspeicher-Passwörter) werden als einfache owned Kubernetes Secrets gespeichert.
Wie eine Referenz aufgelöst wird
Für jeden *Ref tut der Controller:
- Auflösen und gaten — ruft das Ziel ab; falls es fehlt oder nicht ready ist, wird mit einer klaren Bedingung requeued, anstatt zu scheitern.
- Auto-Wiring bei vorhandener Lizenz — wenn
auto-wiringaktiviert ist, führt er die Bereitstellung + Injektion aus der obigen Tabelle durch. - Fallback auf manuell — wenn das Feature nicht lizenziert ist, überspringt er das automatische Befüllen, verwendet die expliziten Felder, die Sie angegeben haben, und emittiert eine
AutoWiringUnlicensed-Bedingung + ein Event, das genau benennt, was zu setzen ist.
Da namespaceübergreifende Owner References in Kubernetes nicht erlaubt sind, verwendet der Operator labelbasierte Watches (keine Owner Refs), sodass Änderungen an einer referenzierten Resource in einem anderen Namespace die Reconciliation dennoch erneut auslösen.
Ein Hinweis zu Gateway → Observability
Zwei Gates gelten für das automatische Bereitstellen von Langfuse-Keys
Das Erstellen der Langfuse-Organisation/des -Projekts und das Erzeugen eines API-Keys verwendet die Admin API von Langfuse, was ein Langfuse-Enterprise-Feature ist — unabhängig von der Navique-Lizenz. Vollständig automatisches Key-Provisioning benötigt daher sowohl das Navique-auto-wiring-Feature als auch ein Langfuse-EE-Deployment.
Auf einem Community-Langfuse kann das LangfuseProject keinen Key erzeugen: Erstellen Sie Projekt und Key in der Langfuse-UI und setzen Sie Gateway.spec.observability.{ host, callbackSecretRef }. Der Operator erkennt dies und legt eine umsetzbare Bedingung offen. Langfuse-Tracing ist optional — das Gateway funktioniert auch ohne es.
Der manuelle Pfad hält alles am Laufen
Dies ist das Kernversprechen: Die Kernplattform blockiert niemals aufgrund der Lizenz. Selbst ganz ohne Lizenz können Sie die gesamte Plattform aufbauen, indem Sie die Connection Secrets, die Gateway-URL/den -Key und den Langfuse-Callback selbst angeben. Auto-Wiring ist ein Komfortzuwachs, kein Gate dafür, ob die Plattform funktioniert.
Siehe Editionen & Lizenzierung für die Frage, welche Edition Auto-Wiring enthält.