Einführung

Der Navique AI Core Operator ist ein Kubernetes-Operator, der eine vollständige, governance-fähige, selbst gehostete KI-Plattform durchgängig bereitstellt und verwaltet. Das Anwenden seiner Custom Resources richtet das LiteLLM-Gateway, die LibreChat-Chat-UI, die Langfuse-LLM-Observability, ihre Datenspeicher und die Secrets-Verkabelung ein — und installiert dabei alle benötigten Upstream-Capability-Operatoren.

Er ist mit dem Operator SDK (Go / Kubebuilder) gebaut. Upstream-Operatoren werden installiert, indem ihre offiziellen Helm-Charts angesteuert werden, die im Operator-Binary gebündelt sind und mit dem Helm v4 Go SDK aus den Reconcilern heraus angewendet werden.

Das Problem, das er löst

Die Plattform wurde zuvor als Baum von Helm-Charts ausgeliefert, der von ArgoCD orchestriert wurde. Das funktioniert, koppelt jedoch Belange, die getrennt sein sollten:

• Capability-Operatoren (CloudNativePG, External Secrets, cert-manager…) und die davon abhängigen Workloads verheddern sich im selben Chart-Graphen.
• Ein Singleton-Operator, der als Subchart zweier verschiedener Releases eingebunden wird, führt zu zwei Releases, die um dieselben CRDs streiten (Helm verweigert geteilte CRD-Eigentümerschaft).
• Die Bereitstellungsreihenfolge wird als globale Sync-Wellen ausgedrückt statt als die tatsächliche Readiness jeder Abhängigkeit.
• Anmeldedaten landen schließlich in git eingecheckt in Chart-Werten.

Der Operator entwirrt all dies. Sie deklarieren die Plattform als Kubernetes-Objekte; der Operator konvergiert den Cluster passend dazu — er installiert Capability-Operatoren bedarfsgesteuert, stellt Datenspeicher bereit, verkabelt Anmeldedaten zwischen Komponenten und liefert in jedem Schritt präzise Status-Conditions.

Was er tut, in zwei Schichten

Der Operator trennt bewusst die beiden Schichten, die die Helm-Charts vermischt haben:

1. Er installiert Upstream-Capability-Operatoren — LiteLLM, Langfuse, External Secrets, Sealed Secrets, CloudNativePG, cert-manager, den Redis-Operator, den ClickHouse-Operator und die MongoDB-Controller — indem er ihre offiziellen Helm-Charts ansteuert. Jedes Chart ist ein eigenständiges Helm-Release (niemals eine Subchart-Abhängigkeit), installiert provenance-bewusst: Es wird übersprungen und adoptiert, falls Sie es bereits installiert haben, und nur deinstalliert, wenn der Operator es besitzt und nichts es mehr benötigt.

2. Er verwaltet die Plattform-Workloads über seine eigenen CRDs, indem er die Upstream-Custom-Resources (LiteLLMInstance, LangfuseInstance, CNPG Cluster/Database, ESO SecretStore/ExternalSecret, …) emittiert und das LibreChat-Workload-Chart installiert.

Siehe Funktionsweise für die Architektur und Kernkonzepte für das Vokabular.

Was Sie erhalten

Custom Resource	Richtet ein
License	Clusterweite Lizenz; gated Enterprise-Funktionen und Instanz-Caps
SecretsManagement	External Secrets oder Sealed Secrets als Anmeldedaten-Backend
PostgresCluster	PostgreSQL via CloudNativePG (managed) oder adopt/external
ClickHouseCluster	ClickHouse (managed) oder adopt/external
RedisInstance	Redis via OT-Container-Kit-Operator oder adopt/external
MongoCluster	MongoDB via MCK-Operator oder adopt/external
MeilisearchInstance	Meilisearch-Such-Backend (operator-nativ)
Gateway	LiteLLM-KI-Gateway + Models / Teams / Orgs
Observability	LLM-Observability (Langfuse v3)
ChatUI	LibreChat-Web-UI, verkabelt mit einem Gateway
ManagementPlane	Konfiguriert die Admin-Konsole (standardmäßig bereitgestellt)

Designprinzipien

• Komponentenspezifische CRDs, keine Klammer. Jede Capability ist ihre eigene Ressource. Ein optionaler Stack sitzt darüber für One-Shot-Bündel, doch die granularen Ressourcen bleiben eine erstklassige Möglichkeit, von Hand zu komponieren.
• Eigenständige gebündelte Charts. Jeder Capability-Operator ist sein eigenes Helm-Release, einmal installiert und gemeinsam genutzt — niemals eine Subchart-Abhängigkeit.
• Provenance-bewusst. Der Operator installiert oder löscht niemals einen Operator erneut, den Sie selbst installiert haben; er bereinigt nur, was er besitzt. Siehe Provenance & Lebenszyklus.
• External-First-Datenspeicher. Jeder Datenspeicher kann operator-verwaltet, aus einer bestehenden In-Cluster-Ressource adoptiert oder auf einen externen Host verwiesen werden.
• Secrets sind niemals inline. Anmeldedaten kommen aus Key Vault (via External Secrets) oder Sealed Secrets. Siehe Secrets-Verwaltung.
• Idempotent und readiness-gesteuert. Reconciler reihen sich erneut ein, während sie auf Readiness warten, anstatt zu fehlern; jedes Apply ist ein sicheres Install-or-Upgrade.

Für wen er gedacht ist

• Plattform-Teams, die ein governance-fähiges, mandantenfähiges KI-Gateway und eine Chat-UI auf Kubernetes einrichten — auf AKS, EKS, GKE, OpenShift oder on-prem (einschließlich Air-Gapped).
• Regulierte Organisationen, die Self-Hosting, Observability, SSO und eine Datenpfad-Guardrail für PII benötigen.
• Alle, die den Open-Source-Kern evaluieren: Die kostenlose Edition stellt eine vollständige Single-Instance-Plattform ganz ohne Lizenz bereit.

Lizenzierung in einem Absatz

Der Operator-Kern ist Open Source unter AGPL-3.0 und läuft vollständig ohne Lizenz (die Community-Edition). Enterprise-Erweiterungen — zusätzliche Instanzen, Mandantenfähigkeit, komponentenübergreifendes Auto-Wiring, SSO/SCIM, die PII-Guardrail — werden mit einer signierten, offline geprüften Lizenz freigeschaltet, die gegen einen in das Binary kompilierten Public Key verifiziert wird. Es gibt keinen Lizenzserver und kein Phone-Home, daher funktioniert sie air-gapped. Bei Ablauf stuft sich die Plattform anmutig auf Community herunter, anstatt auszufallen. Siehe Editionen & Lizenzierung.

Nächste Schritte

• Funktionsweise — die Architektur und das Reconcile-Modell.
• Kernkonzepte — Provenance, Modi, Auto-Wiring und die in dieser Dokumentation verwendeten Begriffe.
• Schnellstart — eine vollständige Plattform auf einem Cluster einrichten.