Skip to content

Installation ​

Der Operator wird mit drei Installationsmethoden ausgeliefert. Wählen Sie diejenige, die zu Ihrem Bereitstellungsmodell passt:

MethodeAm besten geeignet für
Helm-ChartDie meisten Cluster; GitOps und templatebasierte Installationen
kustomize (config/)Einfaches kubectl apply -k, ohne Helm
OLM-BundleOpenShift / OperatorHub.io und Operator Lifecycle Manager

Alle drei installieren dasselbe: das Operator-Deployment, seine CRDs, RBAC und (optional) Webhooks. Der Operator installiert anschließend bei Bedarf Upstream-Capability-Operatoren aus Charts, die in seinem Binary eingebettet sind.

Cluster-admin für die Installation

Der Operator verwaltet CRDs, Cluster-RBAC und Webhooks über Namespaces hinweg, daher benötigt die Installation cluster-admin-Rechte. Die tägliche Nutzung der Custom Resources nicht.

Option 1 – Helm ​

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

Nützliche Values (die vollständige Liste finden Sie in der values.yaml des Charts):

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 ​

Aus einem Checkout des Operator-Repositorys:

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

Oder wenden Sie das kustomize-Overlay direkt an:

bash
kubectl apply -k config/default

CRD-kustomization

Wenn Sie aus dem Quellcode bauen, muss jede CRD in config/crd/kustomization.yaml aufgeführt sein, andernfalls lässt eine kustomize-Installation sie stillschweigend aus. Die mitgelieferten Overlays enthalten bereits alle.

Option 3 – OLM / OperatorHub ​

Auf einem Cluster mit installiertem Operator Lifecycle Manager bauen und deployen Sie das Bundle aus dem Quellcode:

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

Auf OpenShift erscheint der Operator zudem in OperatorHub, sobald die Catalog Source veröffentlicht ist.

Die Installation überprüfen ​

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

Sie sollten sehen, dass das Operator-Deployment verfügbar ist, die *.core.navique.com-CRDs etabliert sind und die Management-Plane-Konsole läuft. Die Konsole wird standardmäßig bereitgestellt – die ManagementPlane-Ressource konfiguriert sie lediglich (Host, Ingress, SSO).

Was später, bei Bedarf, installiert wird ​

Der Operator installiert nicht alle Upstream-Operatoren im Voraus. Capability-Operatoren (CloudNativePG, External Secrets, cert-manager, …) werden lazy installiert – nur dann, wenn eine Custom Resource sie benötigt – und jeder ist eine eigenständige, Provenance-bewusste Helm-Release. Siehe Gebündelte Charts und Provenance & Lebenszyklus.

Weiter ​

Bringen Sie eine Plattform mit dem Quick Start zum Laufen oder passen Sie den Manager über die Seite Konfiguration an.

Open Core unter AGPL-3.0. Enterprise-Komponenten sind proprietär und lizenzgebunden.