Skip to content

Installation ​

L'opérateur propose trois méthodes d'installation. Choisissez celle qui correspond à votre modèle de livraison :

MéthodeIdéale pour
Chart HelmLa plupart des clusters ; GitOps et installations templatisées
kustomize (config/)Un simple kubectl apply -k, sans Helm
Bundle OLMOpenShift / OperatorHub.io et Operator Lifecycle Manager

Les trois installent la même chose : le Deployment de l'opérateur, ses CRD, son RBAC, et (optionnellement) ses webhooks. L'opérateur installe ensuite à la demande les opérateurs de capacités en amont depuis les charts embarqués dans son binaire.

Cluster-admin pour l'installation

L'opérateur gère les CRD, le RBAC du cluster et les webhooks à travers les namespaces ; l'installation nécessite donc des privilèges cluster-admin. L'usage quotidien des custom resources ne les requiert pas.

Option 1 — Helm ​

bash
helm install navique-ai-core-operator \
  oci://ghcr.io/scigility/charts/navique-ai-core-operator \
  --namespace navique-system --create-namespace

Valeurs utiles (voir le values.yaml du chart pour la liste complète) :

yaml
image:
  repository: ghcr.io/scigility/navique-ai-core-operator
  tag: ""               # defaults to the chart appVersion
# Restrict which namespaces the operator watches (empty = all namespaces).
watchNamespaces: []
resources:
  limits:   { memory: 1Gi }
  requests: { cpu: 100m, memory: 512Mi }
# Leader election is on by default for HA-safe single-active reconciliation.
leaderElection: true

Option 2 — kustomize ​

Depuis un checkout du dépôt de l'opérateur :

bash
# Install the CRDs.
make install

# Deploy the manager (set IMG to your image).
make deploy IMG=ghcr.io/scigility/navique-ai-core-operator:latest

Ou appliquez directement l'overlay kustomize :

bash
kubectl apply -k config/default

Kustomization des CRD

Lors d'une construction depuis les sources, chaque CRD doit être listée dans config/crd/kustomization.yaml, sinon une installation kustomize l'omettra silencieusement. Les overlays fournis les incluent déjà toutes.

Option 3 — OLM / OperatorHub ​

Sur un cluster où Operator Lifecycle Manager est installé, construisez et déployez le bundle depuis les sources :

bash
make bundle IMG=ghcr.io/scigility/navique-ai-core-operator:latest
make bundle-build bundle-push BUNDLE_IMG=ghcr.io/scigility/navique-ai-core-operator-bundle:latest
operator-sdk run bundle ghcr.io/scigility/navique-ai-core-operator-bundle:latest \
  --namespace navique-system

Sur OpenShift, l'opérateur apparaît également dans OperatorHub une fois la catalog source publiée.

Vérifier l'installation ​

bash
# The manager should be Running.
kubectl -n navique-system get deploy navique-ai-core-operator

# All CRDs should be present.
kubectl get crds | grep core.navique.com

# The management console is deployed by default (no CR required).
kubectl -n navique-system get deploy,svc -l app.kubernetes.io/component=management-plane

Vous devriez voir le Deployment de l'opérateur disponible, les CRD *.core.navique.com établies, et la console du management-plane en cours d'exécution. La console se déploie par défaut — la ressource ManagementPlane ne fait que la configurer (host, ingress, SSO).

Ce qui est installé ultérieurement, à la demande ​

L'opérateur n'installe pas chaque opérateur en amont d'emblée. Les opérateurs de capacités (CloudNativePG, External Secrets, cert-manager, …) sont installés de manière paresseuse — uniquement lorsqu'une custom resource en a besoin — et chacun est une release Helm autonome et provenance-aware. Consultez Charts embarqués et Provenance & cycle de vie.

Suite ​

Mettez en place une plateforme avec le Démarrage rapide, ou ajustez le manager via la page Configuration.

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