Konfiguration

So konfigurieren Sie den Operator-Manager selbst. Zur Konfiguration der Plattform siehe die Referenzseiten der Custom Resources. Eine kompakte Liste der Flags und Umgebungsvariablen finden Sie auf der Seite Konfigurationsreferenz.

Überwachte Namespaces

Standardmäßig überwacht der Operator alle Namespaces. Um ihn einzuschränken – beispielsweise um einer Operator-Instanz einen Ausschnitt eines großen Clusters zuzuweisen – setzen Sie --watch-namespaces (oder die Umgebungsvariable WATCH_NAMESPACES) auf eine kommagetrennte Liste:

--watch-namespaces=forge-gateway,forge-langfuse,forge-ui,forge-data

System-Namespaces erreichbar halten

Wenn Sie die Überwachung einschränken, müssen die cluster-scoped License und die *-system-Namespaces der Capability-Operatoren erreichbar bleiben. Der Operator verwendet einen nicht gecachten Reader für diese namespaceübergreifenden Lesezugriffe, stellen Sie jedoch sicher, dass Ihr RBAC sie weiterhin zulässt.

In Helm setzen Sie watchNamespaces: [...] (leere Liste = alle Namespaces).

Leader Election

Leader Election ist standardmäßig aktiviert. Da die im Binary integrierte Helm-Engine auf einen einzelnen aktiven Reconciler angewiesen ist (die Helm-action.Configuration ist nicht nebenläufigkeitssicher), sollten Sie Leader Election aktiviert lassen, selbst wenn Sie eine einzelne Replica betreiben. Jeder Controller läuft zudem mit MaxConcurrentReconciles = 1.

Ressourcen

Der Manager rendert und installiert Helm-Charts in-process, was speicherhungrig ist. Geben Sie ihm ausreichend Arbeitsspeicher – ~1Gi ist eine sichere Basis:

resources:
  requests: { cpu: 100m, memory: 512Mi }
  limits:   { memory: 1Gi }

Die Standard-Limits von Kubebuilder sind zu niedrig und äußern sich in OOM-Kills nur im Cluster (nicht bei lokalem make run, das Ihre kubeconfig und den Arbeitsspeicher Ihrer Maschine verwendet).

RBAC

Der Operator liefert eine breit gefasste ClusterRole, da er CRDs, Cluster-RBAC, Admission-Webhooks und Workloads über Namespaces hinweg installiert. Die Installationsmethoden stellen dies für Sie bereit. Falls Sie RBAC manuell zusammenstellen, benötigt der Operator unter anderem:

• Vollständige Verwaltung der *.core.navique.com-Ressourcen und ihres /status.
• Verwaltung der Upstream-CRDs, die er emittiert (postgresql.cnpg.io, external-secrets.io, litellm.palena.ai, langfuse.palena.ai, …).
• customresourcedefinitions get/list/watch (um auf Established zu warten).
• Objekte zur Verwaltung von Helm-Releases (Secrets in den Release-Namespaces).
• Lease-Objekte für Leader Election.
• Den least-privilege-ServiceAccount und RBAC der Management-Plane-Konsole.

Installationsverhalten der Capability-Operatoren

Jedes gebündelte Chart verfügt über geprüfte Standard-Installations-Values, die in der Registry des Operators hinterlegt sind – siehe Gebündelte Charts. In der Regel müssen Sie diese nicht anpassen. Wo die Upstream-Defaults eines Charts veraltet sind (zum Beispiel ein gepinnter, aber alter Image-Tag), überschreibt der Operator sie, damit sie zur Chart-Version passen, mit der er ausgeliefert wird.

Für Air-Gapped-Cluster spiegeln Sie die Upstream-Images in Ihre Registry und geben Image-Overrides an; die Charts selbst sind im Binary eingebettet und benötigen keinen Netzwerkzugriff.

Management-Konsole

Der Operator stellt die Management-Plane-Konsole standardmäßig bereit, selbst wenn keine ManagementPlane-Ressource vorhanden ist. Um Host, Ingress, SSO, Image oder Discovery-Verhalten zu ändern, erstellen Sie eine ManagementPlane-Ressource. Um sie vollständig zu deaktivieren, setzen Sie den entsprechenden Chart-/Installations-Value (die Konsole kann dort abgeschaltet werden, wo sie nicht erwünscht ist).

Hochverfügbarkeit

Betreiben Sie den Manager mit mehreren Replicas und aktivierter Leader Election; nur der Leader reconciliert, und das Failover erfolgt automatisch. Die Plattform-Workloads selbst werden über ihre eigenen Ressourcen HA-fähig gemacht (z. B. PostgresCluster.managed.instances: 3, Gateway.instance.replicas, Langfuse-Datenspeicher-Replicas).