Vue d'ensemble des Custom Resources

Toutes les ressources appartiennent au groupe d'API core.navique.com, version v1alpha1. Cette page est la carte de référence ; chaque ressource dispose de sa propre page de référence avec l'ensemble des champs, des valeurs par défaut, du statut et des exemples.

La carte des ressources

Ressource	Portée	Rôle
License	Cluster	License hors ligne signée en singleton ; gouverne les fonctionnalités et les plafonds d'instances
SecretsManagement	Namespaced	Requis. Backend d'identifiants — ESO ou Sealed Secrets
PostgresCluster	Namespaced	PostgreSQL partagé, multi-base de données
ClickHouseCluster	Namespaced	ClickHouse
RedisInstance	Namespaced	Redis
MongoCluster	Namespaced	MongoDB partagé, multi-base de données
MeilisearchInstance	Namespaced	Backend de recherche Meilisearch
Gateway	Namespaced	Passerelle IA (LiteLLM ou Wäg, via spec.type) + modèles / équipes / organisations
Observability	Namespaced	Observabilité LLM (Langfuse v3)
ChatUI	Namespaced	Interface LibreChat, câblée à un Gateway
ManagementPlane	Namespaced	Configure la console d'administration (déployée par défaut)
Stack	Namespaced	Umbrella optionnel — bundle organisé et auto-câblé (sous licence)
User	Namespaced	Une personne / un siège sous licence, compté dans le quota users
Identity / Organization / Team	Namespaced	Comptes par backend et tenance gérés (sous licence)
Lock	Namespaced	Protège une resource contre une suppression accidentelle (verrou façon Azure)
ServiceMesh	Cluster	Installe/adopte Istio (Sail) pour le mTLS + l'isolation des locataires (sous licence)

Conventions communes à toutes les ressources

Ces conventions s'appliquent à chaque ressource, sauf mention contraire sur une page.

secretsRef (optionnel sur les workloads)

Chaque workload (Gateway, Observability, ChatUI) référence directement chaque identifiant dont il a besoin — un Secret de compte admin, un Secret de clés, un Secret de connexion. secretsRef nomme optionnellement un SecretsManagement du même namespace qui produit ces Secrets (ESO depuis un coffre, ou SealedSecrets) ; le workload attend alors qu'il soit Ready.

Omettez secretsRef pour faire tourner un workload sur de simples Secrets Kubernetes que vous créez vous-même — ni ESO ni SealedSecrets ne sont alors nécessaires. Un Stack ne le renseigne que s'il dispose d'un backend spec.secrets.

Bases de données pour les workloads qui référencent un datastore

Un workload qui référence un datastore managé partagé y a besoin de sa propre base : une Observability sur un PostgresCluster (langfuse.postgres.databaseName) et un ClickHouseCluster (langfuse.clickhouse.databaseName), un Gateway sur un PostgresCluster (database.databaseName, par défaut litellm) et — pour Wäg en stockage split — un ClickHouseCluster (waeg.clickhouseDatabase, par défaut waeg), un ChatUI sur un MongoCluster (mongo.databaseName, par défaut LibreChat).

• Avec la licence auto-wiring, le datastore trouve ces références et crée lui-même les bases, à côté de celles que déclare son spec.databases. Sa spec n'est jamais modifiée (un outil GitOps n'a rien à annuler) ; chaque base de status.databases liste dans claimedBy les workloads qui l'utilisent. Le Secret de connexion du workload est créé et monté comme d'habitude.
• Sans elle, déclarez la base dans le spec.databases du datastore. Tant que ce n'est pas fait, la condition DatastoreReady du workload nomme l'entrée exacte à ajouter.

Une base n'est jamais supprimée lorsque son workload disparaît : les données survivent à une suppression malencontreuse. Un Stack déclare ses propres bases, il fonctionne donc dans les deux cas.

Formes de référence

Type	Forme	Notes
ObjectRef	{ name, namespace? }	Le namespace prend par défaut celui de la ressource ; les références inter-namespaces sont autorisées pour les datastores / gateways / observability
LocalRef	{ name }	Même namespace uniquement (secretsRef)
SecretKeyRef	{ name, key?, namespace? }	Les références de Secret restent dans le namespace

Statut et conditions

Chaque ressource expose status.conditions []metav1.Condition avec au minimum une condition Ready, complétée par des conditions propres à chaque phase, ainsi qu'un observedGeneration. Les colonnes d'impression kubectl get recommandées font apparaître la phase/Ready, le mode/type, ainsi qu'un endpoint ou un décompte significatif par ressource.

Datastore type × mode

Les cinq ressources de type datastore partagent la même forme : un type (implémentation du backend) et un mode (Provenance — managed / adopt / external). Voir Concepts fondamentaux.

Comment elles se composent

Les ressources se référencent mutuellement pour former la plateforme :

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

Les références peuvent traverser les namespaces (à l'exception des références de Secret, qui restent dans le namespace), et plusieurs workloads peuvent partager un même datastore ou un même Observability.