Introduzione

Il Navique AI Core Operator è un operatore Kubernetes che distribuisce e gestisce end-to-end una piattaforma AI completa, governata e self-hosted. Applicando le sue custom resource metti in piedi il gateway LiteLLM, l'interfaccia chat LibreChat, l'osservabilità LLM Langfuse, i relativi datastore e l'infrastruttura dei segreti — e, lungo il percorso, vengono installati tutti gli operatori di capacità upstream necessari.

È realizzato con l'Operator SDK (Go / Kubebuilder). Gli operatori upstream vengono installati tramite i loro Helm chart ufficiali, inclusi nel binario dell'operatore e applicati con l'SDK Go di Helm v4 dall'interno dei reconciler.

Il problema che risolve

In precedenza la piattaforma veniva distribuita come un albero di Helm chart orchestrato da ArgoCD. Funziona, ma accoppia aspetti che dovrebbero restare separati:

• Gli operatori di capacità (CloudNativePG, External Secrets, cert-manager…) e i workload che ne dipendono finiscono intrecciati nello stesso grafo di chart.
• Un operatore singleton incluso come subchart di due release diverse si ritrova con due release in conflitto sugli stessi CRD (Helm rifiuta la proprietà condivisa dei CRD).
• L'ordine di provisioning è espresso con sync wave globali anziché con l'effettiva readiness di ciascuna dipendenza.
• Le credenziali finiscono committate in git nei valori dei chart.

L'operatore risolve tutto questo. Dichiari la piattaforma come oggetti Kubernetes; l'operatore porta il cluster allo stato corrispondente — installando in modo lazy gli operatori di capacità, effettuando il provisioning dei datastore, collegando le credenziali tra i componenti ed esponendo status condition precise a ogni passaggio.

Cosa fa, in due livelli

L'operatore separa deliberatamente i due livelli che gli Helm chart mescolavano:

1. Installa gli operatori di capacità upstream — LiteLLM, Langfuse, External Secrets, Sealed Secrets, CloudNativePG, cert-manager, l'operatore Redis, l'operatore ClickHouse e i controller MongoDB — tramite i loro Helm chart ufficiali. Ogni chart è una release Helm autonoma (mai una dipendenza subchart), installata tenendo conto della provenienza: viene saltata e adottata se è già stata installata dall'utente, e disinstallata solo quando è di proprietà dell'operatore e nulla ne ha più bisogno.

2. Gestisce i workload della piattaforma tramite i propri CRD, emettendo le custom resource upstream (LiteLLMInstance, LangfuseInstance, CNPG Cluster/Database, ESO SecretStore/ExternalSecret, …) e installando il chart del workload LibreChat.

Consulta Come funziona per l'architettura e Concetti fondamentali per il vocabolario.

Cosa ottieni

Custom resource	Cosa mette in piedi
License	Licenza a livello di cluster; abilita le funzionalità enterprise e i limiti di istanze
SecretsManagement	Backend delle credenziali External Secrets oppure Sealed Secrets
PostgresCluster	PostgreSQL tramite CloudNativePG (managed), oppure adopt/external
ClickHouseCluster	ClickHouse (managed), oppure adopt/external
RedisInstance	Redis tramite l'operatore OT-Container-Kit, oppure adopt/external
MongoCluster	MongoDB tramite l'operatore MCK, oppure adopt/external
MeilisearchInstance	Backend di ricerca Meilisearch (nativo dell'operatore)
Gateway	Gateway AI LiteLLM + modelli / team / organizzazioni
Observability	Osservabilità LLM (Langfuse v3)
ChatUI	Interfaccia web LibreChat, collegata a un Gateway
ManagementPlane	Configura la console di amministrazione (distribuita di default)

Principi di progettazione

• CRD per componente, nessun ombrello. Ogni capacità è una risorsa a sé. Uno Stack opzionale si colloca sopra per i bundle in un'unica operazione, ma le risorse granulari restano un modo di prima classe per comporre a mano.
• Chart inclusi autonomi. Ogni operatore di capacità è una propria release Helm, installata una sola volta e condivisa — mai una dipendenza subchart.
• Consapevole della provenienza. L'operatore non reinstalla né elimina mai un operatore installato dall'utente; ripulisce solo ciò che possiede. Consulta Provenienza e ciclo di vita.
• Datastore external-first. Qualsiasi datastore può essere gestito dall'operatore, adottato da una risorsa esistente nel cluster o puntato verso un host esterno.
• Mai segreti inline. Le credenziali provengono da Key Vault (tramite External Secrets) o da Sealed Secrets. Consulta Gestione dei segreti.
• Idempotente e guidato dalla readiness. I reconciler rimettono in coda la richiesta mentre attendono la readiness, invece di restituire errori; ogni apply è un install-or-upgrade sicuro.

A chi si rivolge

• Team di piattaforma che mettono in piedi un gateway AI e un'interfaccia chat governati e multi-tenant su Kubernetes — su AKS, EKS, GKE, OpenShift o on-prem (anche air-gapped).
• Organizzazioni regolamentate che necessitano di self-hosting, osservabilità, SSO e di un guardrail sul percorso dei dati per le PII.
• Chiunque stia valutando il core open source: l'edizione gratuita distribuisce una piattaforma completa a istanza singola senza alcuna licenza.

Le licenze in un paragrafo

Il core dell'operatore è open source sotto AGPL-3.0 e funziona completamente senza licenza (l'edizione Community). Le estensioni enterprise — istanze aggiuntive, multi-tenancy, collegamento automatico tra componenti, SSO/SCIM, il guardrail PII — si sbloccano con una licenza firmata e offline, verificata con una chiave pubblica compilata nel binario. Non esiste alcun server di licenze né phone-home, quindi funziona anche in ambienti air-gapped. Alla scadenza la piattaforma torna gradualmente all'edizione Community invece di spegnersi. Consulta Edizioni e licenze.

Passi successivi

• Come funziona — l'architettura e il modello di riconciliazione.
• Concetti fondamentali — provenienza, modalità, collegamento automatico e i termini usati in tutta questa documentazione.
• Avvio rapido — metti in piedi una piattaforma completa su un cluster.