Einen Operator installieren mit OLM

Voraussetzung: ein Cluster mit oc login als Admin. Die Default-Kataloge in openshift-marketplace müssen laufen (oc get catalogsource -A). Auf SNO reserviert der Operator-Pod plus GitOps selbst spürbar RAM – nach dem Test wieder deinstallieren (Schritt 7).

1 Die OLM-Objekte im Überblick

Fünf Objektarten, ein Weg vom Katalog zum laufenden Operator.

Der Operator Lifecycle Manager ist die Maschinerie hinter dem Installieren und Aktualisieren von Operatoren. Fünf Objekte spielen zusammen: eine CatalogSource (der Laden), eine Subscription (deine Bestellung), ein InstallPlan (die konkrete Liste, ggf. mit Freigabe), eine ClusterServiceVersion (das Paket-Manifest) und eine OperatorGroup (welche Namespaces).

Fünf Objekte, eine Kette. Die CatalogSource ist ein Pod, der einen Katalog serviert. Deine Subscription sagt „Operator X, Channel Y, Freigabe automatisch oder manuell“. OLM erzeugt daraus einen InstallPlan – die konkrete Objektliste, die bei Manual auf deine Freigabe wartet. Ist er durch, installiert eine ClusterServiceVersion (das Paket-Manifest) den Operator. Die OperatorGroup legt fest, welche Namespaces er beobachtet. Dieselbe Subscription treibt später auch die Upgrades.

eine CatalogSource ist ein Pod, der einen Katalog-Index verfügbarer Operatoren aus einem Image serviert (Namespace openshift-marketplace)
eine Subscription ist deine Bestellung – welcher Operator, welcher channel, welcher Namespace, installPlanApproval: Automatic|Manual
ein InstallPlan ist die konkrete Objektliste, die OLM anlegen wird – CRDs, RBAC, das Operator-Deployment, die CSV
bei Manual steht der InstallPlan auf RequiresApproval bis oc patch installplan <n> --type=merge -p '{"spec":{"approved":true}}' oder der Konsolen-Button
eine ClusterServiceVersion (CSV) ist das Paket-Manifest – Deployment-Spec, RBAC, eigene und benötigte CRDs, Beispiel-CRs, Install-Modi
CSV-Phasen: Pending → InstallReady → Installing → Succeeded oder Failed – eine CSV je installierter Version
eine OperatorGroup legt den Wirkbereich fest: OwnNamespace, SingleNamespace, MultiNamespace, AllNamespaces
jeder Namespace mit Operatoren braucht genau eine OperatorGroup – zwei brechen alle Operatoren dort
auf der SNO ist noch kein Operator installiert – die Bibliothek-Infra kam per Helm, OLM läuft aber bereit (oc get catalogsource -A zeigt die vier Default-Kataloge)
der erste echte Kandidat wäre OpenShift GitOps (E3) oder Pipelines (E2) aus redhat-operators
AllNamespaces auf einem Single-Node mit Vorsicht – der Operator-Pod und alle Operanden teilen sich die ~11 GB mit OKD und dem library-Stack, SingleNamespace wo möglich
wo ein Operator konfiguriert ist: die CSV (oc get csv -n <ns>) und die CR-Instanzen unter Installed Operators in der Konsole
Upgrades: neuer Katalog-Inhalt im Channel → neuer InstallPlan → Freigabe → neue CSV ersetzt die alte über die replaces-Kette
OCP-Unterschied: OLM ist bei OpenShift vorinstalliert – reines Kubernetes braucht operator-sdk olm install

CatalogSourceein Pod, der einen Katalog-Index verfügbarer Operatoren aus einem Image serviert (ns openshift-marketplace)

OperatorGrouplegt den Wirkbereich fest – jeder Namespace mit Operatoren braucht genau eine

Subscriptiondeine Bestellung: welcher Operator, welcher channel, installPlanApproval: Automatic oder Manual

InstallPlandie konkrete Objektliste, die OLM anlegen wird – CRDs, RBAC, das Operator-Deployment, die CSV

CSVdas Paket-Manifest – Deployment-Spec, RBAC, eigene und benötigte CRDs, Beispiel-CRs

2 Die vier Default-Kataloge

OperatorHub ist die Konsolen-Oberfläche über den CatalogSources – unter Operators → OperatorHub. Von der CLI aus:

OperatorHub ist die Konsolen-Oberfläche über den CatalogSources (D2). Vier Kataloge sind ab Werk da – redhat-operators, certified-operators, community-operators, redhat-marketplace – sie unterscheiden sich in Support. Ein Klick auf „Install“ erzeugt im Hintergrund die Subscription und die OperatorGroup.

Ein Store mit vier Regalen. redhat-operators ist voll unterstützt, certified-operators kommt von Partnern (Support dort), community-operators hat gar keinen Support, redhat-marketplace ist kostenpflichtig. Jeder Katalog ist eine CatalogSource (D2). Im OperatorHub wählst du Operator, Channel, Namespace-Umfang und Freigabe-Modus – die Konsole legt daraus Subscription und OperatorGroup an. Danach findest du ihn unter „Installed Operators“ und legst dort die Custom Resources an (D5).

OperatorHub ist die Konsolen-Oberfläche über den CatalogSources (D2) – unter Operators → OperatorHub
redhat-operators: von Red Hat, voll unterstützt im OCP-Abo – GitOps, Pipelines, Serverless, Logging
certified-operators: von Partnern, zertifiziert, Support beim Partner – Crunchy Postgres, Confluent Kafka
community-operators: von der Community, kein Support, gut zum Lernen – Strimzi, CloudNativePG, cert-manager
redhat-marketplace: kostenpflichtig, Kauf über marketplace.redhat.com
Install-Klick: Operator → Update channel → Installation mode → Update approval – die Konsole legt im Hintergrund Subscription + OperatorGroup an (D2)
danach: Operators → Installed Operators, dort die Custom Resources anlegen (D5)
GitOps-tauglich: statt Klick eine Subscription-YAML ins Git legen (E3) – nachvollziehbar und im Rebuild dabei (E4)
Bibliothek hat bisher keinen Operator – die zustandsbehaftete Infra kam als Bitnami-Helm-Chart, nicht aus dem Hub
wenn doch: community-operators zum Lernen (Strimzi statt Bitnami-Kafka), certified-operators für echten Betrieb
auf der SNO kosten alle vier Default-Kataloge RAM – jeder ist ein Pod in openshift-marketplace. disableAllDefaultSources: true am OperatorHub-Objekt cluster plus nur der gebrauchte Katalog spart ~300 MB
CLI-Blick in einen Katalog: oc get packagemanifests -n openshift-marketplace, oc describe packagemanifest <name> zeigt Channels und CSVs
disconnected: oc-mirror spiegelt einen Katalog, eine eigene CatalogSource zeigt darauf

Laptop · Bash

oc get catalogsource -n openshift-marketplace
oc get packagemanifests -n openshift-marketplace | grep -i gitops
oc describe packagemanifest openshift-gitops-operator -n openshift-marketplace | head -30

Katalog	ist
`redhat-operators`	von Red Hat, voll unterstützt im OCP-Abo – GitOps, Pipelines, Serverless, Logging
`certified-operators`	von Partnern zertifiziert, Support beim Partner – Crunchy Postgres, Confluent Kafka
`community-operators`	von der Community, kein Support, gut zum Lernen – Strimzi, CloudNativePG, cert-manager
`redhat-marketplace`	kostenpflichtig, Kauf über marketplace.redhat.com

RAM auf SNOJeder Katalog ist ein eigener Pod in openshift-marketplace. disableAllDefaultSources: true am OperatorHub-Objekt cluster plus nur der gebrauchte Katalog spart etwa 300 MB.

3 Voraussetzung: die OperatorGroup

Ohne OperatorGroup bleibt jede Subscription im Namespace hängen.

Laptop · Bash

oc new-project openshift-gitops-operator

cat <<'YAML' | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: gitops-og
  namespace: openshift-gitops-operator
spec:
  targetNamespaces:
    - openshift-gitops-operator
YAML

oc get operatorgroup -n openshift-gitops-operator

Der Wirkbereich entscheidet, wen die im Namespace laufenden Operatoren sehen dürfen: OwnNamespace, SingleNamespace, MultiNamespace, AllNamespaces (leere targetNamespaces). Zwei OperatorGroups im selben Namespace brechen alle Operatoren dort – vorher immer prüfen, ob schon eine existiert.

4 Eine Subscription abonnieren

installPlanApproval: Manual – auf einer Single-Node immer Manual, ein Auto-Upgrade mitten in einer Demo ist unschön.

Drei Dinge entscheiden, wie eine Installation läuft. Der Channel ist der Versions-Zug (stable, alpha). Die Dependency-Resolution zieht benötigte Operatoren automatisch mit. Die Approval (Manual) lässt dich jedes Upgrade freigeben – so gatet man Produktion.

Drei Hebel. Der Channel ist der Versions-Zug – die Subscription hält dich auf seiner Spitze, ein Channel-Wechsel ist ein Upgrade-Pfad. Die Dependency-Resolution liest die required-APIs einer CSV und installiert die Anbieter mit. Die Approval auf Manual lässt jeden neuen InstallPlan auf deine Freigabe warten – so testest du erst und gibst dann Produktion frei. Der häufigste „hängt“-Fall ist ein nicht freigegebener InstallPlan.

Channels (stable, latest, alpha) sind Release-Züge – die Subscription nennt einen, OLM hält dich auf dessen Spitze
ein Channel-Wechsel ist ein Upgrade-Pfad – startingCSV in der Subscription pinnt eine bestimmte Version
jede Version nennt per replaces/skips, was sie ablöst – OLM geht die Kette Schritt für Schritt, nicht in einem Sprung
Dependency-Resolution: eine CSV deklariert required APIs → OLM findet einen Anbieter im Katalog und installiert ihn mit
der InstallPlan zeigt alle Objekte, auch die der Abhängigkeiten – die deinstallieren sich nicht mit
Approval: Automatic zieht sofort mit, Manual lässt jeden InstallPlan warten (Zustand RequiresApproval)
hands-on auf der SNO: oc apply -f subscription.yaml für OpenShift GitOps – das ist der erste Operator, den das Projekt real braucht (E3)
auf einem Single-Node immer Manual – ein Auto-Upgrade mitten in einer Demo ist unschön, und der Reconcile-Sturm eines frischen Operators kostet kurz CPU
freigeben: der Konsolen-Button oder oc patch installplan <ip> --type=merge -p '{"spec":{"approved":true}}'
zusehen: oc get csv -w -n openshift-gitops-operator – Phasen Pending → InstallReady → Installing → Succeeded
was hängt steht in status.conditions der Subscription – oc describe sub <name>
Rollback ist unschön: Subscription + CSV löschen, ältere Version neu abonnieren – CRDs und Custom Resources bleiben
maxOpenShiftVersion in der CSV kann sogar ein Cluster-Upgrade blocken (G5) – vor einem OKD-Upgrade die Operator-CSVs prüfen
OCP-Unterschied: identisch – Channels, Approval und Dependency-Resolution sind reine OLM-Mechanik

Laptop · Bash

cat <<'YAML' | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-gitops-operator
spec:
  channel: latest
  name: openshift-gitops-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
YAML

oc get subscription -n openshift-gitops-operator
oc describe sub openshift-gitops-operator -n openshift-gitops-operator | grep -A3 Conditions

Channels (stable, latest, alpha) sind Release-Züge – die Subscription nennt einen, OLM hält dich auf dessen Spitze. startingCSV pinnt eine bestimmte Version. Jede Version nennt per replaces/skips, was sie ablöst – OLM geht die Kette Schritt für Schritt, nicht in einem Sprung.

5 Den InstallPlan genehmigen

Bei Manual steht der InstallPlan auf RequiresApproval, bis du ihn freigibst.

Laptop · Bash

oc get installplan -n openshift-gitops-operator
IP=$(oc get installplan -n openshift-gitops-operator -o jsonpath='{.items[0].metadata.name}')
oc get installplan $IP -n openshift-gitops-operator -o jsonpath='{.spec.clusterServiceVersionNames}{"\n"}'

# ansehen was alles kommt (CRDs, RBAC, Deployment, ...):
oc get installplan $IP -n openshift-gitops-operator -o yaml | grep -A20 "resources:"

# freigeben:
oc patch installplan $IP -n openshift-gitops-operator --type=merge -p '{"spec":{"approved":true}}'

Dependency-Resolution: deklariert eine CSV required APIs, findet OLM selbst einen Anbieter im Katalog und installiert ihn mit – der InstallPlan zeigt dann auch die Objekte der Abhängigkeiten. Die deinstallieren sich beim Aufräumen (Schritt 7) nicht automatisch mit.

6 Die CSV-Phasen verfolgen

Von der Genehmigung bis zum laufenden Operator – live mitverfolgt.

Laptop · Bash

oc get csv -n openshift-gitops-operator -w
# Pending -> InstallReady -> Installing -> Succeeded

oc describe sub openshift-gitops-operator -n openshift-gitops-operator | grep -i state
oc get pods -n openshift-gitops-operator

Was hängt, steht in status.conditions der Subscription (oc describe sub <name>) – und in den Pod-Logs des Operator-Deployments, sobald es existiert. maxOpenShiftVersion in der CSV kann sogar ein Cluster-Upgrade blocken (G5) – vor einem OKD-Upgrade lohnt ein Blick auf die installierten CSVs.

7 Wieder deinstallieren

Rollback ist unschön: Subscription und CSV löschen, CRDs und Custom Resources bleiben stehen.

Laptop · Bash

oc delete subscription openshift-gitops-operator -n openshift-gitops-operator
oc delete csv -n openshift-gitops-operator --all
oc delete project openshift-gitops-operator

# CRDs bleiben clusterweit stehen, falls gewuenscht mit aufraeumen:
oc get crd | grep -i gitops

Ein älterer Kanal neu abonnieren funktioniert genauso – Subscription mit dem alten channel/startingCSV neu anlegen. Die vorhandenen CRDs und Custom Resources bleiben dabei unberührt.

8 Typische Fallen

Symptom	meist
Subscription bleibt ohne InstallPlan	keine passende OperatorGroup im Namespace, oder zwei auf einmal
InstallPlan hängt bei `RequiresApproval`	erwartet bei `Manual` – ganz normal, wartet auf `oc patch ... approved:true`
CSV bleibt `Pending`	eine benötigte API/Abhängigkeit fehlt im Katalog, oder RBAC für den Operator selbst reicht nicht
Operator-Pod `CrashLoopBackOff`	Cluster-CPU/RAM knapp (häufig auf SNO), oder eine SCC/RBAC-Einschränkung passt nicht

9 Warum die Bibliothek (noch) keinen Operator hat

Die zustandsbehaftete Infra der Bibliothek – Postgres, Kafka, Redis, Keycloak – kommt als Bitnami-Helm-Chart, nicht aus dem OperatorHub. Auf der SNO ist noch kein Operator installiert, OLM läuft aber bereit (oc get catalogsource -A zeigt die vier Default-Kataloge). Der erste echte Kandidat wäre OpenShift GitOps (E3) oder Pipelines (E2) aus redhat-operators – genau das Beispiel dieser Anleitung.

AllNamespaces auf einem Single-Node nur mit Vorsicht – der Operator-Pod und alle Operanden teilen sich die begrenzten ~11 GB RAM mit OKD und dem library-Stack, SingleNamespace wo möglich.

+ Die Kurzfassung

KetteCatalogSource + OperatorGroup + Subscription → InstallPlan → CSV-Phasen bis Succeeded

Manualauf SNO immer – jeder InstallPlan wartet auf approved:true, kein Überraschungs-Upgrade

AufräumenSubscription + CSV weg, CRDs und Custom Resources bleiben – kein automatisches Rollback