Prérequis

Avant d'installer l'opérateur, assurez-vous que votre environnement répond aux exigences suivantes.

Cluster

• Un cluster Kubernetes, v1.28 ou plus récent. Testé sur AKS, EKS, GKE, OpenShift, ainsi que sur des clusters locaux (Kind / Minikube) pour le développement.
• kubectl configuré pour le cluster cible avec des privilèges cluster-admin pour l'installation (l'opérateur installe les CRD, le RBAC et les webhooks).
• Une StorageClass par défaut prenant en charge le provisionnement dynamique si vous prévoyez d'exécuter des datastores en mode managed (Postgres, ClickHouse, Redis, MongoDB, Meilisearch).
• Un contrôleur d'ingress (par exemple ingress-nginx) et un DNS si vous souhaitez exposer publiquement les endpoints de la gateway, de l'interface de chat, de Langfuse ou de la console de gestion.

Ressources

L'opérateur installe plusieurs opérateurs en amont et attend qu'ils soient prêts ; certains exécutent des webhooks d'admission. Prévoyez suffisamment de marge sur le cluster :

• Le manager lui-même demande peu de CPU mais bénéficie d'environ 1 Gi de mémoire — le moteur Helm intégré au binaire et le rendu des charts sont gourmands en mémoire, et les limites par défaut de Kubebuilder sont trop faibles pour un fonctionnement en cluster.
• Chaque datastore en mode managed met en place son propre opérateur et ses propres pods ; dimensionnez les nœuds en conséquence.

Backend de secrets

SecretsManagement est requis, choisissez donc un backend avant de commencer :

• External Secrets (ESO) avec l'une des options suivantes :
  • Azure Key Vault via Workload Identity (la valeur par défaut en production sur AKS) — nécessite une federated identity credential et un ServiceAccount activé pour Workload Identity.
  • Azure Key Vault via un Service Principal — fonctionne partout, y compris sur les clusters non-AKS et sur Kind.
  • HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, ou tout autre fournisseur ESO (un passthrough de fournisseur brut les prend tous en charge).
• Sealed Secrets — manifestes chiffrés déchiffrés dans le cluster, sans store externe.

Consultez Gestion des secrets pour la matrice complète.

Accès sortant (ou un miroir)

Lors de la première utilisation, l'opérateur installe des charts en amont qui sont embarqués dans le binaire — les téléchargements de charts ne nécessitent donc aucun accès réseau. En revanche, les images référencées par ces charts sont téléchargées depuis des registres publics (ghcr.io, quay.io, Docker Hub, etc.). Pour les clusters air-gapped, recopiez ces images dans votre registre interne et faites pointer les charts dessus via les surcharges de valeurs de l'opérateur.

Optionnel : une licence Enterprise

L'opérateur fonctionne pleinement en édition open-source Community sans licence. Pour débloquer le multi-instance, la multi-tenance, l'auto-wiring, le SSO/SCIM ou le guardrail PII, vous avez besoin d'un jeton de licence signé fourni par Navique. Il est appliqué sous forme de Secret référencé par la ressource License. Obtenez-en un — un essai, un achat ou le téléchargement de votre licence existante — sur le portail client Navique à l'adresse portal.navique.dev ; consultez Gérer une licence.

Suite

Continuez vers Installation.