Überblick über die Custom Resources

Alle Ressourcen gehören zur API-Gruppe core.navique.com, Version v1alpha1. Diese Seite ist die Übersicht; jede Ressource verfügt über eine eigene Referenzseite mit vollständigen Feldern, Standardwerten, Status und Beispielen.

Die Ressourcenübersicht

Ressource	Geltungsbereich	Rolle
License	Cluster	Singleton, signierte Offline-Lizenz; gibt Features und Instanz-Obergrenzen frei
SecretsManagement	Namespaced	Erforderlich. Anmeldedaten-Backend — ESO oder Sealed Secrets
PostgresCluster	Namespaced	Gemeinsam genutztes PostgreSQL, mehrere Datenbanken
ClickHouseCluster	Namespaced	ClickHouse
RedisInstance	Namespaced	Redis
MongoCluster	Namespaced	Gemeinsam genutztes MongoDB, mehrere Datenbanken
MeilisearchInstance	Namespaced	Meilisearch-Such-Backend
Gateway	Namespaced	KI-Gateway (LiteLLM oder Wäg, über spec.type) + Modelle / Teams / Organisationen
Observability	Namespaced	LLM-Observability (Langfuse v3)
ChatUI	Namespaced	LibreChat-UI, an ein Gateway angebunden
ManagementPlane	Namespaced	Konfiguriert die Admin-Konsole (standardmäßig bereitgestellt)
Stack	Namespaced	Optionale Klammer — kuratiertes, automatisch verdrahtetes Bundle (lizenziert)
User	Namespaced	Person / lizenzierter Sitzplatz, zählt gegen das users-Limit
Identity / Organization / Team	Namespaced	Verwaltete Konten pro Backend und Mandantenzuordnung (lizenziert)
Lock	Namespaced	Schützt eine Ressource vor versehentlichem Löschen (Sperre im Azure-Stil)
ServiceMesh	Cluster	Installiert/übernimmt Istio (Sail) für mTLS + Mandantenisolation (lizenziert)

Konventionen, die für alle Ressourcen gelten

Diese gelten für jede Ressource, sofern eine Seite nichts anderes angibt.

secretsRef (optional bei Workloads)

Jeder Workload (Gateway, Observability, ChatUI) referenziert jede benötigte Anmeldeinformation direkt — ein Admin-Konto-Secret, ein Schlüssel-Secret, ein Verbindungs-Secret. secretsRef benennt optional eine SecretsManagement im selben Namespace, die diese Secrets erzeugt (ESO aus einem Vault oder SealedSecrets); der Workload wartet dann, bis sie Ready ist.

Lassen Sie secretsRef weg, um einen Workload mit gewöhnlichen Kubernetes-Secrets zu betreiben, die Sie selbst anlegen — ESO oder SealedSecrets sind dann nicht nötig. Ein Stack setzt es nur, wenn er ein spec.secrets-Backend hat.

Datenbanken für Workloads, die einen Datenspeicher referenzieren

Ein Workload, der einen gemeinsam genutzten verwalteten Datenspeicher referenziert, benötigt dort eine eigene Datenbank: eine Observability auf einem PostgresCluster (langfuse.postgres.databaseName) und einem ClickHouseCluster (langfuse.clickhouse.databaseName), ein Gateway auf einem PostgresCluster (database.databaseName, Standard litellm) und — für Wäg im Speichermodus split — einem ClickHouseCluster (waeg.clickhouseDatabase, Standard waeg), ein ChatUI auf einem MongoCluster (mongo.databaseName, Standard LibreChat).

• Mit der auto-wiring-Lizenz findet der Datenspeicher diese Referenzen und legt die Datenbanken selbst an, neben denen, die sein spec.databases deklariert. Seine Spec wird nie bearbeitet (ein GitOps-Werkzeug hat nichts zurückzusetzen); jede Datenbank in status.databases listet in claimedBy die Workloads auf, die sie nutzen. Das Verbindungs-Secret des Workloads wird wie gewohnt erzeugt und eingebunden.
• Ohne sie deklarieren Sie die Datenbank im spec.databases des Datenspeichers. Bis dahin nennt die Condition DatastoreReady des Workloads genau den Eintrag, der hinzuzufügen ist.

Eine Datenbank wird nie gelöscht, wenn ihr Workload verschwindet: Die Daten überdauern ein versehentliches Löschen. Ein Stack deklariert seine eigenen Datenbanken und funktioniert daher so oder so.

Referenzformen

Typ	Form	Hinweise
ObjectRef	{ name, namespace? }	Der Namespace ist standardmäßig der eigene der Ressource; namespace-übergreifend zulässig für Datenspeicher / Gateways / Observability
LocalRef	{ name }	Nur im selben Namespace (secretsRef)
SecretKeyRef	{ name, key?, namespace? }	Secret-Referenzen bleiben im selben Namespace

Status und Conditions

Jede Ressource stellt status.conditions []metav1.Condition bereit, mit mindestens einer Ready-Condition zuzüglich phasenspezifischer Conditions sowie einem observedGeneration. Empfohlene kubectl get-Druckspalten zeigen Phase/Ready, mode/type sowie einen aussagekräftigen Endpunkt oder Zählwert je Ressource.

Datenspeicher type × mode

Die fünf Datenspeicher-Ressourcen teilen sich dieselbe Form: einen type (Backend-Implementierung) und einen mode (Provenance — managed / adopt / external). Siehe Grundlegende Konzepte.

Wie sie zusammenwirken

Ressourcen referenzieren sich gegenseitig, um die Plattform zu bilden:

ChatUI ──gatewayRef──▶ Gateway ──observabilityRef──▶ Observability
  │                       │                              │
  ├─mongo──▶ MongoCluster │                              ├─postgres──▶ PostgresCluster
  └─meili──▶ Meilisearch  └─database──▶ PostgresCluster  ├─clickhouse▶ ClickHouseCluster
                                                         └─redis─────▶ RedisInstance

All workloads ──secretsRef (optional)──▶ SecretsManagement (same namespace)
License (cluster) ──gates──▶ every controller's feature flags + instance caps

Referenzen können namespace-übergreifend sein (mit Ausnahme von Secret-Referenzen, die im selben Namespace bleiben), und mehrere Workloads können sich einen Datenspeicher oder eine Observability-Instanz teilen.