Skip to content

Introduction ​

Le Navique AI Core Operator est un opérateur Kubernetes qui déploie et gère de bout en bout une plateforme d'IA complète, gouvernée et auto-hébergée. L'application de ses ressources personnalisées met en place la gateway LiteLLM, l'interface de chat LibreChat, l'observabilité LLM Langfuse, leurs datastores et la tuyauterie des secrets — et installe au passage tous les opérateurs de capacités en amont dont il a besoin.

Il est construit avec l'Operator SDK (Go / Kubebuilder). Les opérateurs en amont sont installés en pilotant leurs Helm charts officiels, embarqués à l'intérieur du binaire de l'opérateur et appliqués avec le Helm v4 Go SDK depuis l'intérieur des reconcilers.

Le problème qu'il résout ​

La plateforme était auparavant livrée sous forme d'une arborescence de Helm charts orchestrée par ArgoCD. Cela fonctionne, mais couple des préoccupations qui devraient rester distinctes :

  • Les opérateurs de capacités (CloudNativePG, External Secrets, cert-manager…) et les workloads qui en dépendent se retrouvent enchevêtrés dans le même graphe de charts.
  • Un opérateur singleton tiré comme subchart de deux releases différentes finit avec deux releases se disputant les mêmes CRD (Helm refuse la propriété partagée des CRD).
  • L'ordre de provisionnement est exprimé sous forme de sync waves globales plutôt que par la disponibilité réelle de chaque dépendance.
  • Les identifiants finissent committés dans git dans les valeurs de chart.

L'opérateur démêle tout cela. Vous déclarez la plateforme sous forme d'objets Kubernetes ; l'opérateur fait converger le cluster pour qu'il corresponde — en installant paresseusement les opérateurs de capacités, en provisionnant les datastores, en câblant les identifiants entre composants et en faisant remonter des status conditions précises à chaque étape.

Ce qu'il fait, en deux couches ​

L'opérateur sépare délibérément les deux couches que les Helm charts mélangeaient :

  1. Il installe les opérateurs de capacités en amont — LiteLLM, Langfuse, External Secrets, Sealed Secrets, CloudNativePG, cert-manager, l'opérateur Redis, l'opérateur ClickHouse et les contrôleurs MongoDB — en pilotant leurs Helm charts officiels. Chaque chart est une release Helm autonome (jamais une dépendance subchart), installée de manière consciente de la Provenance : elle est ignorée et adoptée si vous l'avez déjà installée, et désinstallée uniquement lorsque l'opérateur la détient et que plus rien n'en a besoin.

  2. Il gère les workloads de la plateforme via ses propres CRD, en émettant les ressources personnalisées en amont (LiteLLMInstance, LangfuseInstance, CNPG Cluster/Database, ESO SecretStore/ExternalSecret, …) et en installant le chart de workload LibreChat.

Consultez Comment ça fonctionne pour l'architecture, et Concepts fondamentaux pour le vocabulaire.

Ce que vous obtenez ​

Ressource personnaliséeMet en place
LicenseLicence à l'échelle du cluster ; verrouille les fonctionnalités entreprise et les plafonds d'instances
SecretsManagementBackend d'identifiants External Secrets ou Sealed Secrets
PostgresClusterPostgreSQL via CloudNativePG (managed), ou adopt/external
ClickHouseClusterClickHouse (managed), ou adopt/external
RedisInstanceRedis via l'opérateur OT-Container-Kit, ou adopt/external
MongoClusterMongoDB via l'opérateur MCK, ou adopt/external
MeilisearchInstanceBackend de recherche Meilisearch (natif à l'opérateur)
GatewayGateway d'IA LiteLLM + modèles / équipes / organisations
ObservabilityObservabilité LLM (Langfuse v3)
ChatUIInterface web LibreChat, câblée à une Gateway
ManagementPlaneConfigure la console d'administration (déployée par défaut)

Principes de conception ​

  • Des CRD par composant, pas d'umbrella. Chaque capacité est sa propre ressource. Un Stack optionnel se place au-dessus pour des bundles en une seule passe, mais les ressources granulaires restent un moyen de premier ordre de composer à la main.
  • Charts embarqués autonomes. Chaque opérateur de capacité est sa propre release Helm, installée une seule fois et partagée — jamais une dépendance subchart.
  • Conscient de la Provenance. L'opérateur ne réinstalle ni ne supprime jamais un opérateur que vous avez installé vous-même ; il ne nettoie que ce qu'il détient. Voir Provenance et cycle de vie.
  • Datastores externes en priorité. Tout datastore peut être détenu par l'opérateur, adopté depuis une ressource existante dans le cluster, ou pointé vers un hôte externe.
  • Les secrets ne sont jamais inline. Les identifiants proviennent de Key Vault (via External Secrets) ou de Sealed Secrets. Voir Gestion des secrets.
  • Idempotent et piloté par la disponibilité. Les reconcilers re-mettent en file d'attente pendant qu'ils attendent la disponibilité plutôt que de renvoyer une erreur ; chaque application est un install-or-upgrade sûr.

À qui il s'adresse ​

  • Aux équipes plateforme qui montent une gateway d'IA gouvernée et multi-tenant ainsi qu'une interface de chat sur Kubernetes — sur AKS, EKS, GKE, OpenShift, ou on-prem (y compris en environnement isolé).
  • Aux organisations réglementées qui ont besoin d'auto-hébergement, d'observabilité, de SSO et d'un garde-fou de chemin de données pour les PII.
  • À toute personne évaluant le cœur open source : l'édition gratuite déploie une plateforme mono-instance complète, sans aucune licence.

La licence en un paragraphe ​

Le cœur de l'opérateur est open source sous AGPL-3.0 et fonctionne intégralement sans licence (l'édition Community). Les incréments entreprise — instances supplémentaires, multi-tenance, câblage automatique entre composants, SSO/SCIM, garde-fou PII — se débloquent avec une licence signée et hors ligne vérifiée par rapport à une clé publique compilée dans le binaire. Il n'y a pas de serveur de licence ni de phone-home, donc cela fonctionne en environnement isolé. À l'expiration, la plateforme se rétrograde gracieusement vers Community plutôt que de s'éteindre. Voir Éditions et licences.

Étapes suivantes ​

Cœur open source sous AGPL-3.0. Les composants Enterprise sont propriétaires et soumis à licence.