OpenShift-Atlas

01 Wie ein OKD-Single-Node auf einem Server entsteht, der kein CoreOS kennt

InfrastrukturSNOInstallationHetzner

SCOS (CentOS Stream CoreOS – das unveränderliche Container-Betriebssystem, das OKD-Node voraussetzen) gibt es bei Hetzner nicht als Image, und hochladen kann man auch keins. Der Umweg: das Rescue-System booten, per kexec in die SCOS-Live-Umgebung springen, und die installiert OKD von dort aus selbst auf die Platte.

• OKD-Node brauchen SCOS oder RHCOS, ein unveränderliches Container-Betriebssystem, das der Machine Config Operator verwaltet
• Hetzner hat kein SCOS-Image und erlaubt keinen Image-Upload, deshalb der Umweg über das Rescue-System
• zuerst das Rescue-System (Ubuntu) booten und einen Hard-Reset machen, ein Soft-Reboot landet nicht im Rescue
• dann per kexec in die SCOS-Live-Umgebung springen, die Ignition liegt als /config.ign (xz-cpio) im initramfs
• bootstrap-in-place Schritt 2a: node-image und release-image ziehen (etwa 5 bis 10 Minuten), ab hier geht ssh core@
• Schritt 2b: bootkube startet eine temporäre Steuerungsebene, die die Master-Ignition rendert (etwa 6 Minuten)
• Schritt 2c: coreos-installer schreibt SCOS und die Ignition auf die Platte (etwa 1 Minute), danach Reboot
• Schritt 2d nach dem Reboot: CSRs genehmigen, alle Cluster-Operatoren starten, der CVO konvergiert (etwa 20 bis 30 Minuten)
• der Laptop steuert nur: PowerShell für hcloud, WSL2 für openshift-install und oc (die es nur für Linux gibt)
• WSL nutzt dieselbe öffentliche IP wie der Laptop, darum passt die Firewall-Regel für Port 6443 automatisch
• die Firewall okd-sno-fw lässt Port 22 und 6443 nur von deiner IP zu, Port 80 und 443 sind offen
• die reservierte IPv4 okd-sno-ip trägt die API-Zertifikate und die nip.io-Namen, ohne sie läuft up nicht
• Vorgabe-Server ist cpx52 (12 vCPU, 24 GB) – OKD belegt im Leerlauf schon etwa 11 GB RAM
• install-config.yaml und single-node-ignition-config entstehen in der WSL, mit baseDomain: <ip>.nip.io und einem Dummy-Pull-Secret
• der ganze Aufbau dauert etwa 30 bis 45 Minuten, danach liegt die kubeconfig unter ~/.kube/, dazu Konsolen-URL und kubeadmin-Passwort
• sno.ps1 down stoppt den Node, macht einen Snapshot (etwa 10 GB) und löscht den Server nur bei Erfolg. IP und Snapshot bleiben (etwa 0,75 Euro im Monat)
• sno.ps1 up baut den Server neu aus dem Snapshot mit derselben IP, in Minuten wieder da, samt Inhalt
• sno.ps1 destroy löscht alles: Server, Snapshot, reservierte IP und Firewall
• cluster.ps1, der Kill-Switch für den Multi-Node-Cluster, nimmt okd-sno ausdrücklich aus
• SCOS ist ein bewegtes Ziel – OKD released schnell, ein SCOS-Build kann brechen. Getestet mit 4.22.0-okd-scos.8 (2026-08-31), bei einem Neubau die Prozedur gegen die dann aktuelle Version prüfen
• OCP-Unterschied: dort RHCOS statt SCOS und der Assisted- oder Agent-based-Installer – kein kexec-Umweg, weil das Image im Katalog liegt
• Aufbau sicher nachvollziehen: SNO, CRC und Deploy-Weg – Installationsphasen aus den drei Skripten und dem laufenden Cluster ableiten, ohne einen Server zu starten

02 CRC – volles OpenShift auf dem Laptop, und wo es aufhört

InfrastrukturCRCOpenShift LocalLaptop

CRC (CodeReady Containers / OpenShift Local) bringt ein vollständiges OpenShift in einer VM auf dem eigenen Rechner – Konsole, Operatoren, Registry, Routes. Alles, was fehlt, folgt aus dem einen, eingefrorenen Node. Der Wert ist die kostenlose, offline nutzbare, im Screen-Share vorführbare Umgebung fürs Gespräch.

• CRC (OpenShift Local) ist volles OpenShift in einer VM auf dem Laptop – crc setup einmal, dann crc start
• Vorgabe 4 vCPU / 10,5 GB / 31 GB Disk – für den Bibliothek-Stack hochgesetzt: crc config set memory 16384, cpus 6, disk-size 45
• ein Pull-Secret von console.redhat.com, danach läuft CRC ohne Red-Hat-Abo
• ein einziger Node ist Steuerungsebene und Worker zugleich – wie die SNO, nur lokal und ohne Tailscale
• echtes OpenShift ist dabei: Web-Konsole, OLM + OperatorHub, interne Registry, Routes, SCC, oc adm, alle CRDs, OAuth
• die oc-Erfahrung ist dieselbe wie auf OKD/OCP – darum eignet sich CRC zum Üben von Konsole, Operator-Installation und RBAC
• jede Grenze hat eine von drei Wurzeln: ein Node (B6, F1, G7) · das eingefrorene Image-Bündel (G4, G5) · Laptop statt Cloud (G1, G3, RAM-Deckel) – kein Punkt ist ein fehlendes OpenShift-Feature
• wo es aufhört – 1 Node: Scheduling, Taints, topologySpread (B6) laufen ins Leere, kein OVN-Geneve-Tunnel (F1)
• kein echter StorageClass – nur ein hostpath-Provisioner, kein RWX, keine VolumeSnapshots (G3)
• oc adm upgrade ist gesperrt (G5) – die CRC-Images sind auf eine Version eingefroren, kein MachineConfig-Rollout (G4)
• Monitoring per Default aus (G1) – enable-cluster-monitoring kostet rund 3 GB RAM, die meist fehlen
• bei 10,5 GB bleiben ~700 MiB für Apps – 8 JVMs kalt sprengen das, darum deployt die Bibliothek mit replicas: 0 und fährt gestaffelt hoch
• feste Domain: *.apps-crc.testing und api.crc.testing:6443, kein nip.io – crc stop friert den Cluster ein
• die drei Umgebungen: kind = 2+ Nodes ohne OpenShift · SNO = echtes OpenShift auf Hetzner hinter Tailscale · CRC = echtes OpenShift lokal, offline, für die Vorführung
• Merksatz: CRC gibt dir die OpenShift-Fläche, nicht die OpenShift-Tiefe – Anleitungen openshift-local-auf-windows.html und bibliothek-enterprise-auf-crc.html
• CRC und SNO vergleichen: SNO, CRC und Deploy-Weg – API-Adresse, Node, Cluster Operators, Storage und Ressourcen mit ausschließlich lesenden Abfragen gegenüberstellen

03 Was läuft wo – die echte Topologie im Ruhezustand

InfrastrukturTopologieTailscaleCI/CD

Diagramm 01 zeigt die Installation. Das hier ist der Ruhezustand: Laptop, GitHub, Hetzner-SNO – verbunden über einen Tailscale-Tunnel, weil am Server nur 80/443 offen sind. Der lokale Jenkins in der podman-machine baut und deployt über genau diesen Tunnel.

• drei Hosts: der Laptop (Windows), GitHub, der Hetzner-Server okd-sno – verbunden über ein Tailscale-Tailnet
• am Server sind öffentlich nur 80 und 443 offen (okd-sno-fw) – das ist die Demo-Fläche (App-Routes + Web-Konsole)
• SSH (:22) und die Kube-API (:6443) laufen über den Tailnet-Tunnel – ein Rechner ohne Tailscale kommt nicht an den Cluster
• der hosts-Trick: das API-Zertifikat kennt nur den Namen api.sno.62.238.124.7.nip.io – der hosts-Eintrag zeigt ihn auf die Tailnet-IP 100.67.147.8, so passt der SAN
• *.nip.io ist kein DNS-Server – die IP steckt im Namen, darum braucht die SNO keine eigene Zone
• Jenkins läuft seit 2026-09-01 lokal in der podman-machine (Container shared-jenkins, Compose in shared-infra/) – vorher ein eigener Hetzner-Server
• Jenkins baut gegen die Host-Podman-Engine (9 Images, Maven im Container) – init.groovy.d spielt die 17 Stolpersteine bei jedem Boot ein
• ns library: 8 Spring-Dienste + config-server + Frontend + Postgres/Redis/Kafka/Keycloak, deployt als Helm-Releases von der SA pipeline
• Storage: ein local-path-Provisioner (RWO, am Node) – keine echte HA, passt zur SNO
• der Deploy-Weg: git push → curl-Trigger → 9 Image-Builds → podman push an die Registry-Route (80/443) → helm upgrade --install --wait ×9 über den Tunnel
• Kostenkontrolle: sno.ps1 down/up und jenkins.ps1 down/up per Hetzner-Snapshot – ausgeschaltet baut der Laptop-Jenkins lokal weiter
• SCOS ist unveränderlich – kein apt/dnf am Node, tailscaled liegt als statisches Binary in /var/usrlocal/bin
• alles nachprüfbar: oc get ns, hcloud server list, tailscale status – das Diagramm ist der Ist-Zustand, keine Skizze
• Anleitungen dazu: okd-single-node-hetzner.html, jenkins-lokal-aus-hetzner-snapshot.html, bibliothek-enterprise-via-jenkins-auf-okd.html, tailscale.html
• Topologie inventarisieren: SNO, CRC und Deploy-Weg – Kube-Kontext, Tailscale, Podman-Jenkins und Deploy-Ergebnis Schicht für Schicht nachweisen

04 Umgebungen & Konfiguration – wo alles liegt, wo man nachschaut

InfrastrukturKonfigurationUmgebungenWeb-Konsole

Die Bausteine – ConfigMap, Secret, Helm-Values, MachineConfig – sind über Block B und G verteilt. Hier die Landkarte: welche Art Konfiguration wo liegt, mit welchem oc-Befehl und über welchen Weg in der Web-Konsole man sie nachschaut – und die drei Schichten, in denen Konfiguration überhaupt passiert.

• die Bausteine sind verteilt – ConfigMap/Secret (B8), Secret-Details (B9, B10), Helm-Values (B11), MachineConfig (A7, G4), Operator-CR (D5). Dieses Diagramm ist die Landkarte darüber
• drei Schichten: Quelle (Git: Helm-Values, GitOps-Repo) → Übersetzung (Deploy rendert die Objekte) → Wirkung (etcd hält, Pod liest)
• vier Stufen im Ideal: Entwicklung, Test, QS, Produktion – je eigener Namespace oder Cluster, eigenes Values-Overlay, eigene GitOps-Application (E3)
• Promotion = denselben Chart mit dem nächsten Overlay deployen – der auslösende Wert (Bild-Tag, Werte-Datei) ändert sich in Git, nichts wird von Hand kopiert
• dein Projekt hat drei Stufen: lokal (Spring dev, H2) → CRC (02, volles OpenShift auf dem Laptop) → SNO ns library (produktionsnah) – kein getrenntes Test/QS, das wäre der nächste Ausbau
• ein Values-Overlay: infra/helm/values/env/okd-values.yaml – setzt Replicas, Ressourcen, Probes, Kafka/Redis-Hosts und den Keycloak-Issuer für die SNO
• App-Config nachschauen: oc get cm -n library und oc extract secret/<name> -n library --to=-, in der Konsole unter Workloads → ConfigMaps / Secrets
• welche DB-URL ein Dienst benutzt: oc set env deploy/<dienst> -n library --list, in der Konsole der Reiter Environment am Deployment – zeigt auch, ob der Wert direkt steht oder aus einer ConfigMap/Secret kommt
• Endpunkte: intern die Service-Adresse <svc>.<ns>.svc (oc get svc), extern die Route-URL (oc get route / Konsole Networking → Routes)
• gerenderte Helm-Werte (was der Chart wirklich gesetzt hat): helm get values <release> -n library und helm get manifest, in der Konsole Developer → Helm → Releases
• Keycloak-Realm und Client-Secrets liegen in Keycloak, nicht in OpenShift-Objekten – über die Keycloak-Route zur Admin-Konsole. Keycloaks eigenes DB-Passwort ist ein Secret in der ns
• Cluster-Config (Auth, Ingress, Image, Proxy): die Config-API-Objekte, oc get authentication cluster -o yaml – in der Konsole Administration → Cluster Settings → Configuration
• Node- und Operator-Config: MachineConfig (oc get mc / Compute → MachineConfigs) und die Operator-CR (oc get <cr> -o yaml / Installed Operators → CR-Reiter)
• Vorsicht Secrets: die Konsole zeigt Werte im Klartext für admin/edit (nicht view) – „Reveal values“ ist keine Sicherheitsgrenze (B9). Ausführlich in okd-konfiguration-nachschauen.html

A Was OpenShift zu Kubernetes hinzufügt

OKD/OCP/K8s, Project, oc, Authentifizierung, RBAC, ServiceAccount, SCC – in dieser Reihenfolge. SCC kommt zuletzt, weil es auf ServiceAccount und Project aufbaut.

A1 OKD vs OCP vs Kubernetes – welche Teile kommen obendrauf?

FundamentOKD/OCPOperatorenArchitekturEX280

Kurz: der Kubernetes-Kern bleibt unverändert. Alles, was OpenShift ausmacht, läuft als Operatoren (Controller, die eine Fähigkeit automatisieren) und zusätzliche API-Objekte darauf. OKD (die quelloffene Variante) und OCP (das kommerzielle Produkt von Red Hat) sind zwei Auslieferungen derselben Schicht.

• OpenShift ist unverändertes Kubernetes, darauf eine feste Schicht aus Operatoren und CRDs, kein Fork
• der Kern bleibt gleich: API-Server, etcd, Scheduler, Controller-Manager, kubelet, CRI-O, OVN-CNI
• die OpenShift-Schicht sind lauter Operatoren: Router und Route, OAuth-Server, SCC, interne Registry, Web-Konsole, OLM und OperatorHub, Monitoring, dazu BuildConfig, ImageStream und S2I
• der CVO und rund 30 ClusterOperatoren verwalten den Cluster als eine versionierte Einheit und aktualisieren ihn (G5, G6)
• ebenfalls Teil der Schicht: Project mit Quota-Vorgaben, OVN-Kubernetes, der DNS- und der Ingress-Operator
• das Node-Betriebssystem ist SCOS oder RHCOS, unveränderlich und vom MCO verwaltet (G4), kein eigenes Ubuntu oder Debian
• deine Anwendung (Deployment, Service, Ingress, ConfigMap) läuft unverändert
• OKD ist die quelloffene Variante: SCOS oder Fedora CoreOS, kostenlos, Community-Support, community-operators, Dummy-Pull-Secret
• OCP ist das Produkt von Red Hat: RHCOS, Subscription je Core, SLA, dazu redhat- und certified-operators, echtes Pull-Secret von console.redhat.com
• Kern und Schicht sind praktisch gleich – im Job meist OCP, die Konzepte gelten eins zu eins. Dieser Atlas läuft auf OKD (SNO auf Hetzner), OCP-Unterschiede stehen inline
• oc ist ein Superset von kubectl – dieselbe Binary redet mit jedem Kubernetes (auch dem k3s aus biblio.yaml), die OpenShift-Extras schalten sich frei, sobald es OpenShift ist
• oc adm bündelt Admin-Aufgaben, oc new-app, oc debug, oc rsh und oc rollout sind Abkürzungen
• die OpenShift-Objekte kommen über einen aggregierten API-Server, gleicher Port 6443, andere Pfade – oc api-resources und oc explain route zeigen, was dieser Cluster kann
• Folge: ein Helm-Chart mit reinen Kubernetes-Objekten läuft auf beiden. Eine Route kennt nur OpenShift – wer portabel bleiben will, schreibt stattdessen ein Ingress
• die Web-Konsole hat zwei Perspektiven: Administrator für den Cluster, Developer für ein einzelnes Project
• von Hand durchspielen: kern-und-authentifizierung-openshift.html – live mit oc api-resources die OpenShift-Schicht von Kubernetes trennen

A2 Project vs Namespace – was oc new-project automatisch anlegt

FundamentProjectNamespaceQuotaEX280

Ein Namespace (Kubernetes) ist nur ein Namensraum mit RBAC- und Quota-Grenze. Ein Project ist derselbe Namespace – nur angelegt über einen Weg, der gleich Rollen, ServiceAccounts und SCC-Annotationen mitbringt (eine Annotation ist eine an ein Objekt geheftete Notiz, die Werkzeuge lesen).

• ein Namespace in Kubernetes ist nur ein Namensraum mit RBAC- und Quota-Grenze plus ein default-ServiceAccount, sonst nichts
• kubectl create namespace foo legt nur die Hülle an, du bist darin nicht automatisch berechtigt
• oc new-project library erzeugt zuerst einen ProjectRequest, das einzige Objekt, das ein Nicht-Admin anlegen darf
• daraufhin legt das project-request-Template den Namespace plus eine admin-RoleBinding für dich an (das Template liegt in openshift-config und ist editierbar)
• danach ergänzen Cluster-Controller (nicht das Template) die ServiceAccounts default, builder, deployer samt ihren RoleBindings system:image-builder und system:deployer (A6)
• Annotation: ein an ein Objekt geheftetes Schlüssel-Wert-Paar, das Werkzeuge und Controller lesen. Anders als ein label ist es nicht zum Filtern da, sondern zum Mitgeben von Information (darf lang sein, darf JSON enthalten). Merksatz: Labels sagen „wie man es findet“, Annotationen sind „Notizen dran, meist von Maschinen“
• der SCC-Allocator schreibt drei Annotationen auf den Namespace (openshift.io/sa.scc.uid-range, .mcs, .supplemental-groups) – dein Pod bekommt dadurch eine zufällige hohe UID (etwa 1000680000) und kein festes $HOME (A7)
• der Namespace erhält Zugriff auf die SCC restricted-v2, über die clusterweite Gruppe system:authenticated
• weitere Annotationen: openshift.io/description, display-name und requester
• nicht automatisch da: LimitRange (sonst Pods ohne Requests), ResourceQuota (sonst kein Deckel), NetworkPolicy (sonst erreicht jeder Pod jeden, F2)
• wer das für alle Projekte will, trägt es ins project-request-Template ein. Über mehrere Projekte hinweg geht eine ClusterResourceQuota per Label-Selektor
• Befehle: oc new-project library (du wirst admin darauf), oc project library (Namespace wechseln, schreibt die kubeconfig), oc projects, oc delete project library (geht in Terminating), oc adm new-project (als Admin, umgeht Template und Selbstbedienung)
• ein Project ist keine stärkere Isolation als ein Namespace, nur ein paar Annotationen plus die automatische admin-RoleBinding
• Netz-Trennung zwischen Projekten kommt separat über NetworkPolicy (F2) – ein frisches Project ist nach aussen offen
• bleibt der Namespace ewig in Terminating, klemmt ein Finalizer (nachsehen mit oc get ns library -o yaml im Feld spec.finalizers)
• die Rolle self-provisioner (an system:authenticated:oauth) erlaubt jedem angemeldeten Nutzer oc new-project – Admins entfernen diese Bindung oft
• im Projekt: oc new-project library ist der erste Schritt des Bibliothek-Deploys – danach hängt Jenkins die pipeline-SA und ihre Bindungen (A5) dran und Helm installiert die Bitnami-Infra
• von Hand durchspielen: namespace-oc-serviceaccount-openshift.html – oc new-project live verfolgen und sehen, was wirklich automatisch entsteht

A3 oc vs kubectl, API-Ressourcen, CRDs, Web-Konsole

Fundamentoc / kubectlAPIkubeconfigKonsoleEX280

Dieselbe Binary, derselbe Port 6443 – nur redet oc zusätzlich mit den OpenShift-eigenen API-Gruppen und bringt Bequem-Verben mit. Die kubeconfig sagt, mit welchem Cluster und als wer.

• oc ist kubectl plus die OpenShift-Verben (new-app, expose, rollout, rsh, debug, adm) und login / project
• dieselbe Binary redet auch mit reinem Kubernetes (k3s, biblio.yaml), dort fehlen nur die *.openshift.io-Objekte
• ein Port 6443, viele API-Gruppen: core/v1, die benannten (apps, batch, rbac und weitere), *.openshift.io und die CRD-gestützten
• die OpenShift-Gruppen laufen über den aggregierten API-Server, einen Extra-Prozess hinter denselben Pfaden
• eine CRD registriert einen neuen Typ – danach ist kind: PostgresCluster gleichwertig zu Pod und wird genauso mit oc get bedient (D2)
• oc api-resources listet alle Typen (Kurzname, apiVersion, NAMESPACED, KIND), --namespaced=false filtert auf Cluster-Objekte
• oc explain route.spec.tls gibt die Schema-Referenz direkt aus diesem Cluster
• eine kubeconfig besteht aus drei Teilen: Cluster (Adresse und CA), User (Token oder x509-Zertifikat) und Context (welcher Cluster, welcher Namespace)
• im Projekt: ~/.kube/okd-sno-hetzner.yaml (SNO), ~/.kube/biblio.yaml (k3s), die Variable $KUBECONFIG wählt – oc login schreibt die Datei, oc project setzt den Namespace
• die SNO-API (api.sno.<ip>.nip.io:6443) ist nur übers Tailnet offen (Ports 22/6443 in der Firewall zu) – ein hosts-Eintrag zeigt den Namen auf die Tailnet-IP, sonst passt der Zert-SAN nicht (Diagramm 03)
• die Web-Konsole ist eine Route (console-openshift-console.apps.<cluster>) mit zwei Perspektiven, Administrator und Developer – Adresse mit oc whoami --show-console
• alles, was die Konsole tut, geht auch per oc – sie schreibt nur dieselben Objekte (die Klick-Wege stehen in okd-konfiguration-nachschauen.html)
• Bibliothek-Alltag: oc get pods -n library (Spalte READY), oc get route -n library, oc logs --previous, oc get endpoints, oc rsh <pod>, oc debug node/<name>
• oc cp unter Git Bash braucht :// statt :/ (die Umgebung schreibt Pfade um), unter PowerShell nicht
• OCP-Unterschied: keiner – oc, die API-Gruppen und die Konsole sind bei OKD und OCP identisch
• von Hand durchspielen: namespace-oc-serviceaccount-openshift.html – die API mit oc api-resources und oc explain selbst erkunden, ohne Doku

A4 Authentifizierung – Identity Provider, OAuth-Stack, htpasswd, oc login

FundamentAuthOAuthIdPhtpasswdEX280

Kubernetes hat keinen Benutzerspeicher. OpenShift bringt einen eigenen OAuth-Server mit, der gegen einen konfigurierten Identity Provider prüft und ein Bearer-Token ausstellt. kubeadmin und system:admin sind zwei Wege daran vorbei.

• OpenShift bringt einen eigenen OAuth-Server mit, Kubernetes hat keinen
• bis zum ersten Login gibt es keinen User in etcd – danach entstehen ein User, eine Identity und das Mapping dazwischen
• IdP-Typen: HTPasswd, LDAP, GitHub, GitLab, Google, OIDC, Keystone, RequestHeader – konfiguriert in genau einem Objekt, oauth/cluster
• HTPasswd ist ein Secret mit einer htpasswd-Datei, referenziert in oauth/cluster
• oc login -u <user> --server=https://api.<cluster>:6443 holt ein Bearer-Token vom OAuth-Server – das Passwort wird interaktiv eingegeben, das Token läuft nach einer Weile ab und steht dann in der kubeconfig
• kubeadmin ist temporär – ein Secret in kube-system, das man nach dem eigenen IdP löscht
• system:admin ist ein x509-Client-Zertifikat in der Install-kubeconfig, ganz ohne OAuth
• zwei Token-Arten: ein OAuthAccessToken für die Nutzer-Session, ein ServiceAccount-Token für einen Pod (A6)
• Gruppen kommen nicht automatisch – per LDAP-Sync (oc adm groups sync) oder von Hand (oc adm groups new <name>)
• Rechte kommen nicht vom IdP – erst oc adm policy bindet Rollen an einen User oder eine Gruppe (A5)
• im Projekt ist kein eigener IdP eingerichtet – der Zugang läuft komplett über oc login -u kubeadmin -p $(cat cfg/auth/kubeadmin-password), dasselbe für CRC. Für ein Bewerbungsgespräch wäre HTPasswd der erste Ausbau
• die SNO-API ist nur übers Tailnet erreichbar – oc login von einem Rechner ohne Tailscale und ohne den hosts-Eintrag scheitert am Zertifikat, nicht am Passwort (Diagramm 03)
• Token weg oder abgelaufen: oc whoami sagt Unauthorized – neu oc login, oder oc whoami -t zeigt das aktuelle Token
• von Hand durchspielen: kern-und-authentifizierung-openshift.html – einen HTPasswd-IdP live anlegen, einloggen, Rechte binden

A5 RBAC – Role, RoleBinding, oc adm policy, Default-Rollen

FundamentRBACRollenoc adm policyEX280

Nach dem Anmelden (A4) weiß der Cluster wer du bist – aber noch nicht, was du darfst. Das klärt RBAC mit genau zwei Objektarten: einer Rolle (Liste erlaubter Aktionen) und einer Bindung (hängt die Rolle an eine Person, Gruppe oder einen ServiceAccount). Ein frischer User darf zuerst fast nichts.

• es gibt zwei Objektarten: Role und ClusterRole sind die Regelliste, RoleBinding und ClusterRoleBinding sind die Zuordnung
• eine Regel kreuzt drei Achsen: verbs (get, list, watch, create, update, patch, delete), resources und apiGroups (der leere String steht für die Kern-Gruppe)
• eine Role gilt in einem Namespace, eine ClusterRole clusterweit oder als wiederverwendbare Vorlage
• Subjekte sind: ein User (aus dem IdP, A4), eine Group oder eine ServiceAccount (system:serviceaccount:<ns>:<name>, A6)
• die Default-ClusterRoles: view darf lesen (ohne Secrets), edit darf Workloads ändern und Secrets lesen (ohne RBAC), admin darf zusätzlich RBAC im Namespace (aber nicht Quota), cluster-admin darf alles
• oc new-project legt eine admin-RoleBinding auf den Anleger an (A2) – darum darfst du im eigenen Projekt sofort fast alle normalen Namespace-Ressourcen verwalten
• eine Rolle binden: oc adm policy add-role-to-user <role> <user> -n <ns>, -z <sa> statt des Namens für eine ServiceAccount, add-cluster-role-to-user für clusterweit
• aggregierte Rollen: admin, edit und view sammeln automatisch jede ClusterRole mit dem Label aggregate-to-*, so erweitern Operatoren sie von selbst
• RBAC ist rein additiv, es gibt kein „deny“ – Entzug geht über remove-role-from-user oder das Löschen der Bindung
• prüfen mit oc auth can-i --as <user> <verb> <resource>, oc adm policy who-can <verb> <resource> oder oc describe clusterrole edit
• Bibliothek: die SA pipeline in library bekommt drei Bindungen – admin (Helm-Deploy), system:image-builder und registry-editor (Push in die interne Registry). Sonst nichts (E1, B12)
• bei einem kaputten Jenkins-Deploy ist oc auth can-i --as=system:serviceaccount:library:pipeline <verb> <resource> -n library die schnellste Antwort auf „darf die pipeline-SA das“
• auch die SCC wird über dieselbe Mechanik vergeben: add-scc-to-user bindet die ClusterRole system:openshift:scc:<name> (A7)
• von Hand durchspielen: rbac-und-scc-openshift.html – view/edit/admin live vergleichen, can-i/who-can, RBAC additiv, dann die SCC-Auswahl live gewinnen

A6 ServiceAccount – welche Identität bekommt ein Pod?

FundamentServiceAccountTokenIdentitätEX280

Ein Mensch meldet sich per oc login an (A4). Ein Pod kann das nicht – er braucht trotzdem eine Identität, sobald er mit dem API-Server redet. Diese Identität ist eine ServiceAccount: ein „Benutzer für Maschinen“, an den man genauso Rollen (A5) und SCCs (A7) bindet, nur ohne IdP und ohne Passwort.

• es gibt drei Identitätsarten: User (aus dem IdP, A4), Group und ServiceAccount (system:serviceaccount:<ns>:<name>). Alle drei sind RBAC-Subjekte (A5)
• jeder Namespace bekommt automatisch default, builder, deployer – builder und deployer sind OpenShift-eigen
• ein Pod ohne serviceAccountName läuft als default – jeder App-Pod hat immer eine SA
• der Pod bekommt ein projiziertes Volume unter /var/run/secrets/kubernetes.io/serviceaccount/ mit den Dateien token, ca.crt und namespace
• das Bound Token ist kurzlebig (etwa eine Stunde) und an eine audience gebunden – der kubelet holt es über die TokenRequest-API und rotiert es. Es wird generiert, nicht anfassen
• früher (bis OCP 4.15) hatte jede SA ein nie ablaufendes Token-Secret (kubernetes.io/service-account-token) in etcd
• einen statischen Token braucht man nur für externe Nutzer: oc create token <sa> --duration=<dauer> oder ein Secret von Hand (das du anlegst)
• im Projekt: genau so ein Secret ist pipeline-token in library (Annotation kubernetes.io/service-account.name: pipeline) – Jenkins nutzt es als podman login-Passwort und in KUBECONFIG_PROD. Es verschwindet nach jedem sno.ps1 up, der Post-up-Hook legt es neu an
• automountServiceAccountToken: false an SA oder Pod, wenn der Pod die API gar nicht ruft (die meisten App-Pods)
• eine SA startet mit keinen Rechten – Rollen bindet man mit oc adm policy add-role-to-user edit -z <sa> -n <ns> (-z steht für ServiceAccount)
• die SCC kommt von der SA, nicht vom User – oc adm policy add-scc-to-user anyuid -z <sa> steuert den erlaubten securityContext (A7)
• Pull-Secret anhängen mit oc secrets link <sa> <secret> --for=pull – die default-SA hat schon eins für die interne Registry (B10)
• builder darf in die interne Registry pushen (Rolle system:image-builder), deployer steuert DeploymentConfig-Rollouts
• von aussen meldet sich Jenkins als system:serviceaccount:library:pipeline mit dessen Token an (A5, B12, E1)
• prüfen mit oc auth can-i --as=system:serviceaccount:<ns>:<sa>, oc describe sa <sa> oder oc create token <sa>
• von Hand durchspielen: namespace-oc-serviceaccount-openshift.html – eine eigene ServiceAccount anlegen, binden und mit can-i pruefen

A7 SCC (Security Context Constraints) – warum ein Container nicht als root läuft

FundamentSCCSecurityrootAdmissionEX280

Eine SCC ist eine OpenShift-Admission, die beim Erstellen eines Pods prüft, was sein securityContext darf – und Felder, die der Pod offen lässt, selbst setzt (vor allem die UID). Welche SCC ein Pod bekommt, hängt daran, welche SCCs seine ServiceAccount (A6) per RBAC (A5) nutzen darf. Die Vorgabe restricted-v2 verbietet Root – das ist die häufigste Starthürde bei fremden Images.

• eine SCC ist eine OpenShift-Admission für den securityContext – sie begrenzt ihn und setzt offene Felder selbst. Älter als das Kubernetes-PodSecurity
• die Auswahl: die Admission nimmt alle SCCs, die die ServiceAccount (A6) per RBAC (A5) nutzen darf, sortiert nach Priorität absteigend und dann Restriktivität aufsteigend, und nimmt die erste, die passt
• welche SCC gewonnen hat, steht in der Pod-Annotation openshift.io/scc (sie wird generiert)
• die Vorgabe restricted-v2 gilt für jeden authentifizierten Account, über die Gruppe system:authenticated
• restricted-v2 setzt eine zufällige UID (runAsUser: MustRunAsRange), privileged: false, wirft alle Capabilities weg, verlangt seccomp RuntimeDefault und erlaubt keinen Host-Zugriff
• UID, MCS-Label und fsGroup kommen aus den Namespace-Annotationen openshift.io/sa.scc.*, gesetzt bei oc new-project (A2)
• die eingebauten SCCs von locker nach streng: privileged, anyuid, hostmount-anyuid, hostnetwork-v2, nonroot-v2, restricted-v2
• Unterschied restricted (v1) zu restricted-v2: v2 verlangt seccomp und allowPrivilegeEscalation:false ausdrücklich
• typische Startfehler: das Image hat USER 0 und schreibt ins RootFS, bindet einen Port unter 1024, erwartet einen festen UID und macht chown, oder gerät in den runAsNonRoot-Konflikt
• Fix in dieser Reihenfolge: erstens das Image UID-agnostisch bauen (UBI ist es schon), zweitens ein Chart-Override oder adaptSecurityContext=auto, drittens als letztes eine lockere SCC an genau die eine SA
• zuweisen mit oc adm policy add-scc-to-user nonroot-v2 -z <sa> -n <ns> – das erzeugt eine RoleBinding auf die ClusterRole system:openshift:scc:<name> (A5)
• Bibliothek: die 8 Spring-Dienste passen unter restricted-v2, die Bitnami-Images brauchen global.compatibility.openshift.adaptSecurityContext=auto (Keycloak, Postgres, Redis, Kafka)
• library-frontend läuft als nginx-unprivileged – trotzdem braucht das Image chmod g+w /etc/nginx/conf.d, weil der Entrypoint die Config zur Laufzeit schreibt und die zufällige UID sonst nicht darf
• von Hand durchspielen: rbac-und-scc-openshift.html – ein Pod scheitert unter restricted-v2 und gewinnt live eine andere SCC
• Legacy-Vertiefung: was bei einer EJB- oder WAS-App bricht, die UID 0 erwartet, steht in H1

B1 Pod → ReplicaSet → Deployment – die Kette in einem Bild

WorkloadsPodReplicaSetDeploymentRollout

Du legst ein Objekt an – ein Deployment – und beschreibst darin nur den Sollzustand: welches Image, wie viele Kopien. Drei ineinandergreifende Regelkreise machen daraus laufende Container. Ein Pod wird dabei nie repariert, sondern immer ersetzt.

• ein Pod ist die kleinste Einheit: ein oder mehr Container mit gemeinsamer IP, localhost und Volumes – flüchtig, wird nie repariert, nur ersetzt
• ein ReplicaSet hält genau N Pods am Leben, die Auswahl läuft über einen selector auf Labels (nach dem Anlegen unveränderlich)
• ein Deployment verwaltet ReplicaSets und gibt dir declarative Updates: du änderst die Vorlage, es macht den Rest
• eine neue Vorlage führt zu einem neuen ReplicaSet mit neuem pod-template-hash (im RS-Namen und als Pod-Label). Das alte RS bleibt stehen (revisionHistoryLimit, Vorgabe 10)
• beim Rolling Update steuern maxSurge und maxUnavailable das Tempo (wie viele Pods über bzw. unter Soll, Vorgabe je 25 %)
• zwei Strategien: RollingUpdate (Vorgabe) oder Recreate (erst alle alten weg, dann die neuen)
• ein neuer Pod zählt erst als verfügbar, wenn seine readiness-Probe grün ist (B5) – eine kaputte Probe blockiert den Rollout
• steuern mit oc rollout und seinen Unterbefehlen status, history, undo [--to-revision=N], pause, resume, restart – jeweils mit deploy/<n> als Ziel
• oc rollout restart deploy/<n> startet einen neuen Rollout mit gleicher Vorlage und liest dabei ConfigMaps und Secrets neu (B8)
• ein gelöschter Pod kommt sofort zurück – wirklich weg über oc delete deploy/<n> (kaskadiert nach unten) oder oc scale --replicas=0
• die Besitzkette läuft über ownerReferences: Deployment besitzt ReplicaSet, ReplicaSet besitzt die Pods (die Garbage Collection räumt von oben)
• die Zahl der Replicas setzt oc scale deploy/<n>, ein HPA (Autoscaler, G1) oder das Image-/Replica-Value im Helm-Chart (B11)
• verwandte Objekte: DaemonSet (ein Pod je Node – so läuft Vector G2 und ovnkube-node F1), StatefulSet (feste Identität + eigenes PVC je Pod – so laufen Postgres, Redis und Kafka aus den Bitnami-Charts), Job/CronJob
• Bibliothek: die 8 Fachdienste + api-gateway + config-server sind einfache Deployments. Beim Deploy setzt Jenkins --set image.tag=$GIT_SHA (B11) → neue Pod-Vorlage → neues ReplicaSet mit neuem pod-template-hash, das alte bleibt für oc rollout undo deploy/<dienst> stehen
• das Deployment ist reines Kubernetes – die OpenShift-Variante DeploymentConfig steht in B2
• von Build bis Pod durchspielen: Build bis Rollout – Besitzkette und zwei neue ReplicaSet-Versionen live nachweisen

B2 Deployment vs DeploymentConfig – Trigger, Lifecycle-Hooks, wann welches?

WorkloadsDeploymentDeploymentConfigTriggerHooksEX280

Beide machen dasselbe – aus einer Pod-Vorlage laufende, ersetzbare Pods (B1). Der Unterschied: das Deployment ist reines Kubernetes und hält sich zurück, der DeploymentConfig ist OpenShift-eigen, älter und bringt eingebaute Trigger und Hooks mit – wird aber ausgephast. Für alles Neue: Deployment.

• das Deployment ist Kubernetes-Standard (apps/v1), gefahren vom kube-controller-manager in-process
• der DeploymentConfig ist OpenShift-eigen und wird ausgephast (apps.openshift.io/v1) – neu anlegen immer ein Deployment
• das Kind-Objekt: Deployment → ReplicaSet (B1), DC → ReplicationController
• den Rollout fährt das Deployment im Controller selbst, der DC über einen eigenen deployer-Pod (<dc>-<n>-deploy, SA deployer, A6) – langsamer, klemmt eher
• eingebaute DC-Trigger: ImageChange (ein neuer ImageStreamTag löst automatisch einen Rollout aus, C1) und ConfigChange
• das Deployment hat keine eingebauten Trigger – für ImageChange-Verhalten die Annotation image.openshift.io/triggers (C6)
• DC-Hooks sind pre, mid (nur bei Recreate) und post: ein Kommando in einem Pod, mit einer failurePolicy
• beim Deployment ersetzt man die Hooks durch Helm-Hook-Jobs, initContainers oder einen eigenen Job
• DC-Strategien: Rolling, Recreate und Custom (ein eigenes Deployer-Image für Blue-Green oder Canary)
• manuell: beim DC oc rollout latest dc/<n> und oc rollout retry dc/<n>, beim Deployment oc rollout undo deploy/<n> (dazu restart, pause)
• warum DC weggeht: kein server-side apply, sperrig mit GitOps (E3), der Deployer-Pod ist langsam, kein sauberes maxSurge
• seit OCP 4.14 legt oc new-app Deployments an – der DC bleibt unterstützt, bekommt aber keine neuen Features
• Bibliothek: alle 8 Dienste sind Deployment (aus dem Helm-Chart, B11), einen DC triffst du im Novaris-Legacy-Block (H)
• Kernsatz: Deployment ist passiv (du oder Helm löst aus), DeploymentConfig ist aktiv (beobachtet Image und Config selbst)
• von Hand durchspielen: workload-feinschliff-openshift.html – Deployment vs DeploymentConfig live vergleichen

B3 Service, Endpoints, Cluster-DNS – wie ein Name zum Pod wird

NetzwerkServiceEndpointSliceCluster-DNSEX280

Pods kommen und gehen, ihre IPs auch. Ein Service legt einen festen Namen und eine feste IP davor. Ein Controller pflegt im Hintergrund die Liste der bereiten Pods dahinter, das Cluster-DNS löst den Namen auf, und OVN biegt jedes Paket auf eine dieser Pod-IPs um – hinter der Service-IP steckt kein Prozess.

• ein Service ist ein fester Name plus feste clusterIP vor einer wechselnden Menge Pods – das Objekt bleibt, die Pods dahinter nicht
• der selector (Labels) sagt, welche Pods dazugehören – der endpoints-Controller pflegt daraus die Liste
• die EndpointSlice listet die bereiten Pod-IPs – nur Pods mit passendem Label und grüner Readiness-Probe (B5). Sie löst das alte Endpoints-Objekt ab
• hinter der ClusterIP läuft kein Prozess – OVN-Kubernetes (früher kube-proxy) programmiert die Nodes-Datapath und macht DNAT auf eine ready Pod-IP, round-robin
• das Cluster-DNS (CoreDNS) löst <svc>.<ns>.svc.cluster.local zur ClusterIP auf, kurz <svc> im selben Namespace, <svc>.<ns> übergreifend
• Service-Typen: ClusterIP (Vorgabe, clusterintern), NodePort (+ hoher Port je Node), LoadBalancer (externe IP via Cloud/MetalLB), ExternalName (CNAME), Headless (clusterIP: None, DNS gibt Pod-IPs direkt)
• port ist der Service-Port, targetPort der Container-Port – named ports gehen auch
• sessionAffinity: None (round-robin je Verbindung) oder ClientIP (klebrig nach Quell-IP, mit Timeout)
• die interne API ist selbst nur ein Service: kubernetes.default.svc
• prüfen: oc describe svc catalog (Zeile Endpoints leer = Selector-Mismatch oder kein Pod ready), oc get endpointslices -l kubernetes.io/service-name=catalog
• Fallen: Selector ≠ Pod-Labels, falscher targetPort, flappender Pod → sporadische 502 an der Route, falscher Namespace angenommen
• Bibliothek: jeder der 8 Dienste ist ein ClusterIP-Service auf 8080 – api-gateway ruft die Fachdienste über http://catalog-service:8080 usw. auf. Der Name kommt aus fullnameOverride im Helm-Chart (B11) und muss exakt passen, sonst geht die Auflösung ins Leere
• von aussen erst über Route/Ingress (B4) – der Service allein hört nur im Cluster
• OCP-Unterschied: keiner – der DNS-Operator verwaltet CoreDNS, sonst reines Kubernetes
• von Hand durchspielen: service-route-probes-openshift.html – einen Service anlegen und per DNS auflösen, den Selector live kaputt machen und die Endpoints leer laufen sehen

B4 Route – edge / passthrough / reencrypt, der HAProxy-Router, das Wildcard-Zertifikat

NetzwerkRouteTLSRouterHAProxyEX280

Ein Service hört nur im Cluster (B3). Eine Route macht ihn von aussen erreichbar: sie sagt welcher Hostname auf welchen Service zeigt und wie TLS behandelt wird. Der Router (HAProxy als Pod) hält die öffentlichen Ports 80 und 443 und setzt jede Route in HAProxy-Konfig um.

• eine Route ist ein OpenShift-Objekt: Hostname → Service, mit Port, TLS-Modus und optional einem Pfad – Kubernetes-Pendant ist Ingress
• der Router (HAProxy als Pod) hält Port 80 und 443 auf den Nodes, liest alle Routes clusterweit und schreibt daraus die HAProxy-Konfig
• das Wildcard-DNS *.apps.<cluster> ist ein einziger A-Record, der auf den Router zeigt – du legst ihn einmal an
• der Router bringt ein Default-Wildcard-Zertifikat für *.apps.<cluster> mit – darum braucht eine edge-Route kein eigenes Zertifikat (auf OKD/SNO selbstsigniert)
• edge: TLS endet am Router, dahinter HTTP zum Pod – der Router setzt X-Forwarded-*, Pfad-Routing geht
• passthrough: der Router fässt TLS nicht an, der Pod hält das Zertifikat – nötig für Client-Zertifikate, dafür kein Pfad-Routing und keine Header
• reencrypt: Router terminiert und baut eine neue TLS-Verbindung zum Pod (mit destinationCACertificate) – Ende-zu-Ende und L7-Routing
• eigenes Zertifikat: inline in route.spec.tls.certificate/.key, oder ein Secret über cert-manager
• Keycloak-Falle: bei edge sieht der Pod HTTP und baut http://-Redirects. Aktuelle Images brauchen KC_PROXY_HEADERS=xforwarded plus passende KC_HOSTNAME/KC_HTTP_ENABLED=true, alte Images KC_PROXY=edge. Bei Spring hilft server.forward-headers-strategy
• anlegen: oc expose svc/library-frontend (reine HTTP-Route), oc create route edge --service=library-frontend --hostname=...
• Route-Status Admitted: True = der Router hat sie angenommen. HostAlreadyClaimed wenn zwei Routes denselben Host wollen
• ein Service ohne Endpoints → der Router antwortet 503. Ein flappender Pod → sporadische 502 (B5)
• OpenShift übersetzt ein Ingress automatisch in eine Route – wer portabel bleiben will, schreibt Ingress (F3)
• Bibliothek: drei edge-Routes – library-frontend, api-gateway und keycloak unter *.apps.sno.<ip>.nip.io, in der Jenkins-Prod-Stage per oc expose angelegt. Die anderen 6 Dienste sind rein clusterintern
• von Hand durchspielen: service-route-probes-openshift.html – eine edge-Route anlegen, Wildcard-Zertifikat und Router-Verhalten live sehen

B5 Probes – liveness, readiness, startup: was jede steuert

WorkloadsProbesreadinesslivenessstartupEX280

Drei Sonden, drei Fragen. readiness: soll dieser Pod gerade jetzt Verkehr bekommen? liveness: hängt der Container und braucht einen Neustart? startup: ist er mit dem Hochfahren fertig? Jede greift woanders ein – und eine falsch eingestellte Probe verursacht die meisten „läuft, aber tut nichts“-Fälle.

• readinessProbe: entscheidet allein über die Endpoint-Mitgliedschaft (B3) – fällt sie, kein Verkehr, der Pod bleibt am Leben und kommt zurück, wenn sie wieder grün ist
• livenessProbe: fällt sie failureThreshold-mal, tötet der kubelet den Container und restartPolicy startet ihn neu – zu knapp = CrashLoop
• startupProbe: solange sie läuft, sind readiness und liveness pausiert – für langsame Starter, failureThreshold × periodSeconds = maximale Bootzeit
• readiness prüft Abhängigkeiten (DB erreichbar, Cache warm), liveness bleibt flach („antwortet der Prozess“) – sonst startet ein DB-Blip alle Replicas neu
• Arten: httpGet (200–399 = ok), tcpSocket, exec (exit 0), grpc
• Parameter: initialDelaySeconds, periodSeconds (10), timeoutSeconds (1 – oft zu kurz), failureThreshold (3), successThreshold
• „0/1 Running“ = läuft, aber nicht ready → in keinem Endpoint → 503 an der Route
• ohne startupProbe auf einer JVM tötet die liveness den Container mitten im Boot → CrashLoop – früher half ein großes initialDelaySeconds
• feste Health-Pfade: Spring Actuator /actuator/health/liveness und /actuator/health/readiness, MicroProfile Health /health/live und /health/ready
• der Rollout ohne Ausfall hängt an der readiness (B1) – ein neuer Pod bekommt erst Verkehr, wenn bereit, und maxUnavailable zählt bereite Pods
• prüfen: oc describe pod <p> (Events), die Spalte READY bei oc get pod ist die Summe der readiness-Ergebnisse
• Bibliothek-Stolperstein: die liveness mit initialDelaySeconds: 30 tötete catalog-service mitten im Spring-Kaltstart auf der geladenen SNO → hochgesetzt auf 150 s liveness / 90 s readiness. Alle 8 Dienste mit Actuator-Probes, Keycloak zusätzlich mit startupProbe (langer Boot)
• OCP-Unterschied: keiner – Probes sind reines Kubernetes, die Konsole zeigt sie zusätzlich in der Topologie-Ansicht
• von Hand durchspielen: service-route-probes-openshift.html – eine readiness-Probe live scheitern lassen und beobachten, wie der Pod aus den Endpoints fliegt, ohne zu sterben

B6 Scheduling – nodeSelector, Taints/Tolerations, Affinity

WorkloadsSchedulingTaintsAffinityEX280

Der Scheduler weist jedem neuen Pod einen Node zu: erst filtern (welche Nodes können ihn tragen?), dann bewerten (welcher ist am besten?), dann binden. Vier Regeln steuern das mit – und die Platzierung hängt an den Requests, nicht am tatsächlichen Verbrauch.

• der Scheduler arbeitet in zwei Phasen: filtern (welche Nodes können?) dann bewerten (welcher am besten?), dann spec.nodeName setzen
• Requests treiben die Platzierung – nicht Limits, nicht der Ist-Verbrauch. Ein Pod ohne Requests packt schlecht und ist BestEffort
• nodeSelector: Pod nur auf einem Node mit passendem Label – harte Kurzform, kein Match bedeutet Pending
• Taint am Node + Toleration am Pod: der Node weist ab, wer nicht toleriert – Effekte NoSchedule, PreferNoSchedule, NoExecute
• der Node-Controller taintet automatisch bei disk-pressure, memory-pressure, not-ready – Control-Plane-Nodes sind per Default getaintet
• nodeAffinity: wie nodeSelector, aber mit Operatoren und required (hart) / preferred (weich)
• podAffinity / podAntiAffinity: nah bei / fern von anderen Pods, immer mit einem topologyKey (hostname, zone) – Anti-Affinity spreizt Replicas
• topologySpreadConstraints: der moderne Weg, Replicas gleichmäßig zu verteilen (maxSkew, topologyKey, whenUnsatisfiable)
• Priorität & Preemption: ein wartender Pod mit höherer PriorityClass kann niedriger priorisierte verdrängen
• auf SNO ist alles einerlei (ein Node) – ein lokaler 2-Node-kind-Cluster reicht, um die Verteilung zu sehen
• Pod bleibt Pending = kein Node passt – oc describe pod <p> nennt den Grund in den Events
• Bibliothek: podAntiAffinity auf catalog-service (2 Replicas auf verschiedene Nodes), Postgres per nodeSelector auf einen Storage-Node
• OCP-Unterschied: der Scheduler ist Kubernetes – OpenShift ergänzt Infra-/Worker-Rollen als Node-Labels und einen Scheduler-Operator mit Profilen
• von Hand durchspielen: workload-feinschliff-openshift.html – einen Pod per nodeSelector gezielt (nicht) platzieren, Pending live sehen

B7 ResourceQuota & LimitRange – Ressourcengrenzen je Project

WorkloadsResourceQuotaLimitRangeQoSEX280

Zwei Objekte, die zusammen arbeiten. LimitRange füllt fehlende Requests/Limits je Container auf und setzt Min/Max. ResourceQuota ist der Deckel für den ganzen Namespace. Der Haken: eine Quota auf requests.* lässt nur Pods durch, bei denen jeder Container einen Request hat – ohne LimitRange werden Deploys plötzlich abgelehnt.

• LimitRange (je Namespace): füllt fehlende requests/limits je Container mit Default-Werten auf und setzt Min/Max – ein Admission-Plugin mutiert den Pod
• ResourceQuota (je Namespace): Obergrenze für alles zusammen – Summe requests.cpu/limits.memory, Anzahl pods/services/secrets/pvc, requests.storage
• der Haken: eine Quota auf requests.* lässt nur Pods durch, bei denen jeder Container einen Request hat – ohne LimitRange werden Deploys abgelehnt (must specify requests.cpu)
• Reihenfolge: erst die LimitRange, dann die Quota – sonst brechen alte Deploys, die nie Requests angegeben haben
• QoS-Klassen (abgeleitet, nicht gesetzt): Guaranteed (requests == limits überall) stirbt zuletzt, Burstable dazwischen, BestEffort (nichts gesetzt) stirbt zuerst
• request = reserviert fürs Scheduling (B6), limit = harte Obergrenze – CPU über Limit wird gedrosselt, Memory über Limit wird OOMKilled (Exit 137)
• ClusterResourceQuota (OpenShift): eine Quota über mehrere Projekte, per Label- oder Annotation-Selektor
• gehört ins project-request-Template (A2), wenn jedes Projekt automatisch eine Grenze haben soll
• Scopes schränken ein, worauf die Quota zählt: BestEffort, NotTerminating, PriorityClass
• prüfen: oc describe quota -n library (Used gegen Hard), oc describe limitrange -n library
• Bibliothek: oc new-project library bringt aus dem project-request-Template (A2) schon eine Quota und eine LimitRange mit. Real belegen OKD + die 8 JVMs + Postgres/Redis/Kafka/Keycloak zusammen ~15,6 GB – darum läuft die SNO auf cpx52 (24 GB). Ohne die LimitRange würden mehrere der 8 Deploys abgelehnt, sobald die Quota existiert
• OCP-Unterschied: ClusterResourceQuota ist OpenShift-eigen, LimitRange und ResourceQuota sind reines Kubernetes
• von Hand durchspielen: workload-feinschliff-openshift.html – eine Quota live gegen einen Deploy laufen lassen, mit und ohne LimitRange

B8 ConfigMap & Secret – wie ein Pod an Konfiguration und Secrets kommt

KonfigurationConfigMapSecretenv / volumeEX280

Beides sind Schlüssel/Wert-Ablagen im Namespace. ConfigMap für Nicht-Geheimes, Secret für Geheimes (base64-kodiert, separat behandelt – aber nicht verschlüsselt). Ein Pod nimmt sie entweder als Umgebungsvariablen (bei Start eingefroren) oder als Datei-Mount (aktualisiert sich live).

• ConfigMap = nicht-geheime Key/Value- oder Datei-Config, Secret = dasselbe, nur base64-kodiert und separat behandelt (nicht in describe, tmpfs beim Mount)
• base64 ist keine Verschlüsselung – jeder mit get secrets sieht den Klartext (oc extract secret/x --to=-)
• zwei Konsumwege: als Umgebungsvariablen (envFrom, env.valueFrom) oder als Datei-Mount (volumeMounts)
• env ist bei Pod-Start eingefroren, ein Mount aktualisiert sich im laufenden Pod (~1 min) – ausser bei subPath, dann auch eingefroren
• eine Änderung an ConfigMap/Secret rollt den Pod nicht neu – kein Trigger. Muster: checksum/config-Annotation (Helm rollt) oder oc rollout restart
• Secret-Typen: Opaque, kubernetes.io/tls, kubernetes.io/dockerconfigjson, service-account-token, basic-auth, ssh-auth – der Typ erzwingt Schlüssel
• Verschlüsselung at-rest: etcd speichert Secrets per Default nur base64 – echte Verschlüsselung schaltet man ein (B9)
• RBAC: view darf keine Secrets lesen. edit darf sie lesen, aber keine Rollen oder Bindings verwalten (A5)
• immutable: true – nur ersetzen statt ändern, schützt vor Versehen und entlastet den apiserver-Watch. Größe max 1 MiB
• anlegen: oc create secret generic --from-literal/--from-file, oc create secret tls, oc set env --from, oc set volume
• projizierte Volumes: mehrere ConfigMaps/Secrets und der SA-Token in einen Verzeichnisbaum
• Bibliothek: App-Config je Dienst als ConfigMap, DB-Passwort / Keycloak-Client-Secret / Kafka-Credentials als Secret – das Frontend-env.js ist eine als Datei gemountete ConfigMap (J4)
• OCP-Unterschied: keiner – ConfigMap und Secret sind reines Kubernetes, oc extract/oc set sind Komfort
• von Hand durchspielen: workload-feinschliff-openshift.html – env vs Mount live vergleichen, wenn sich eine ConfigMap ändert

B9 Secret-Schwerpunkt – Typen, Konsum, Verschlüsselung at-rest Schwerpunkt

KonfigurationSecretTypenVerschlüsselungEX280

Ein Secret ist kein monolithisches Ding: der Typ legt fest, welche Schlüssel drin sein müssen und wofür es taugt. Was in etcd liegt, ist per Default nur base64 – echte Verschlüsselung ist ein Schalter. Und der Weg zum Klartext ist ein Einzeiler, den jeder Auditor kennt.

• der Typ erzwingt die Schlüssel: Opaque (frei), kubernetes.io/tls (tls.crt/tls.key), …/dockerconfigjson, …/service-account-token, …/basic-auth, …/ssh-auth
• in etcd liegt per Default nur base64 – jedes etcd-Backup und jedes Disk-Image ist Klartext
• echte Verschlüsselung at-rest einschalten: oc edit apiserver cluster → spec.encryption.type: aescbc (oder aesgcm)
• der kube-apiserver-Operator rollt eine EncryptionConfiguration aus, verschlüsselt Secrets, ConfigMaps und Token, Schlüssel in openshift-config-managed, Rotation wöchentlich
• ein Migrations-Job schreibt alle bestehenden Objekte neu – prüfen: oc get apiserver cluster -o yaml Feld status.encryption
• der Klartext-Weg: oc get secret db -o jsonpath='{.data.password}' | base64 -d oder oc extract secret/db --to=./dir
• oc describe pod zeigt nur env-Namen, nicht die Werte – aber ein Crash-Dump oder oc get secret -o yaml > all.yaml leakt alles
• immutable: true schützt vor versehentlicher Änderung, Größe max 1 MiB (etcd)
• Secrets sind namespaced – ein Pod sieht nur die seines Namespace, das begrenzt den Schaden bei einem kompromittierten Pod
• projiziertes Volume: mehrere Secrets/ConfigMaps und der SA-Token in einen Verzeichnisbaum, je Quelle ein Pfad
• Konsum (B8): env eingefroren, Volume live (tmpfs, Dateien 0644/root – ausser fsGroup/defaultMode)
• Bibliothek: jedes Secret gehört genau einem der 8 Dienste, alles im Namespace library – die Trennung begrenzt den Schaden
• OCP-Unterschied: die apiserver/cluster-Verschlüsselung mit Auto-Rotation ist OpenShift-Komfort – Kubernetes pur ist manuelle EncryptionConfiguration

B10 Secret-Schwerpunkt – Herkunft, Pull-Secrets, Rotation, raus aus Git Schwerpunkt

KonfigurationSecretPull-SecretRotationGitOps

Woher kommt ein Secret? Wie zieht ein Pod ein privates Image? Wie tauscht man einen Wert aus, ohne dass etwas bricht? Und der Kernkonflikt: ein Klartext-Secret gehört nicht in Git, aber die restliche Config schon – drei Werkzeuge lösen das unterschiedlich.

• Herkunft: du (oc create secret), der SA-Token-Controller (A6), der service-ca-Operator (F5), cert-manager, ein Helm-Chart (Klartext, schlecht), die CI-Pipeline (E), Sealed Secrets / ESO
• Pull-Secret: oc create secret docker-registry regcred --docker-server=... --docker-username=... --docker-password=...
• anhängen: oc secrets link default regcred --for=pull (je SA) oder global in openshift-config/pull-secret
• die default-SA jedes Namespace hat schon ein Pull-Secret für die interne Registry (C5) – imagePullSecrets steht an der SA oder am Pod
• Rotation von Hand: Secret ersetzen, dann oc rollout restart – env übernimmt sonst nichts, ein Mount holt die Datei, die App muss neu lesen
• Rotation automatisch: tls-Secrets vom service-ca-Operator (F5), cert-manager erneuert vor Ablauf – ein Reloader löst den Rollout aus
• warum kein Klartext-Secret in Git: base64 ist lesbar – jeder mit Repo-Zugriff hat die Zugangsdaten
• Sealed Secrets: du verschlüsselst mit dem Public Key des Controllers → SealedSecret-CRD in Git → Controller entschlüsselt im Cluster (clusterspezifisch)
• External Secrets Operator: ExternalSecret-CRD referenziert einen Key in Vault / AWS SM / Azure KV → Operator synct ihn in ein Secret (der Wert lebt außerhalb)
• SOPS (+ age/PGP): verschlüsselte Werte-Datei in Git, ein GitOps-Plugin entschlüsselt beim Apply – Vergleich in E5
• die Vorlage bauen: oc create secret … --dry-run=client -o yaml, dann versiegeln
• Merksatz: Sealed Secrets = Key im Cluster, ESO = Store außerhalb, SOPS = Key beim Deployer
• Bibliothek / cloud-host: der konkrete Weg wird im GitOps-Teil (Block E) gebaut – bis dahin Secrets von Hand
• von Hand durchspielen: secrets-in-openshift.html – Typen anlegen, env vs Mount live, at-rest einschalten, Pull-Secrets, Rotation, die drei Git-Modelle
• OCP-Unterschied: keiner – Sealed Secrets, ESO und SOPS sind Community-Werkzeuge, laufen auf jedem Cluster

B11 Helm-Schwerpunkt – Chart, Values, Template, Release: das mentale Modell Schwerpunkt

AuslieferungHelmChartRelease

Helm ist keine magische Deploy-Maschine. Es ist eine Textschablone plus eine Release-Verwaltung für ein Bündel Kubernetes-Manifeste. Kein Server im Cluster, keine laufende Überwachung. Der ganze Ablauf ist: Werte einsetzen → rendern → anwenden → das Ergebnis als Secret merken.

• Helm ist eine Textschablone plus Release-Verwaltung für ein Bündel Manifeste – kein Server im Cluster, keine laufende Überwachung
• ein Chart ist ein Ordner: Chart.yaml (Metadaten, Versionen, Dependencies), values.yaml (die Knöpfe), templates/ (Manifeste mit {{ }}), charts/ (Subcharts)
• die Werte haben einen Vorrang, später schlägt früher: values.yaml, dann -f meine-werte.yaml, dann --set key=val – alles zu einem Baum verschmolzen, im Template .Values.x.y
• neben .Values gibt es .Release.Name, .Release.Namespace, .Chart.* und .Capabilities.* – darum rendert dasselbe Chart je Release anders
• beim Rendern werden Chart und Werte zu fertiger YAML (helm template zeigt sie, ohne etwas zu ändern), danach wird sie intern angewendet
• ein Release ist eine benannte, versionierte Installation in einem Namespace, gespeichert als Secret sh.helm.release.v1.<name>.v<n> (base64 und gzip)
• Befehle sind helm install, upgrade, rollback, uninstall, list, history – nützliche Flags --dry-run, --atomic, upgrade --install
• version ist die Chart-Version, appVersion die Version der App dahinter – zwei verschiedene Dinge
• Helm handelt als du (mit deinem kubeconfig-Token) und kann nur, was deine RBAC erlaubt (A5) – seit Helm 3 kein Tiller mehr
• Helm ist kein Operator: eine Abweichung am Cluster wird erst beim nächsten helm upgrade korrigiert, ein Rollback rührt keine Daten an (D1)
• in OpenShift ist die helm-CLI unverändert – die Web-Konsole hat einen Helm-Katalog, die HelmChartRepository-CR listet Quellen
• Bibliothek: ein Werteblock je Dienst (Image-Tag, Replicas, Ressourcen), fullnameOverride für stabile Namen. Jenkins ruft helm upgrade --install je Dienst auf (E1)
• Alternativen: Kustomize (oc apply -k, patcht statt zu templaten), Argo CD rendert Charts selbst (E3), oc process für die alten OpenShift-Templates

B12 Helm-Schwerpunkt – Praxis am Bibliothek-Chart, wo Helm aufhört Schwerpunkt

AuslieferungHelmPraxisRollback

B11 war das Modell – hier der Alltag. Immer zuerst helm template lesen. Dann upgrade --install --atomic. helm history und rollback als Sicherheitsnetz. Hooks für DB-Migrationen, Dependencies für Subcharts – und ein paar Stellen, an denen Helm einfach nichts mehr tut.

• immer zuerst helm template – die gerenderte YAML lesen, bevor man installiert
• Erst-Installation: helm install biblio ./chart -n library -f werte-sno.yaml – ein Chart, eine Werte-Datei je Umgebung
• helm diff upgrade (Plugin) zeigt, was sich ändert, bevor es passiert
• helm upgrade --install --atomic --timeout 10m – der CI-taugliche Aufruf (idempotent, rollt bei Fehler zurück)
• helm history biblio + helm rollback biblio <rev> – ein Rollback wendet die Manifeste der alten Revision neu an, als neue Revision
• Hooks: pre-install / post-upgrade als annotierte Jobs (helm.sh/hook, hook-weight, hook-delete-policy) – z. B. DB-Migration vor dem Rollout
• Hooks laufen außerhalb der Release-Manifeste – ein Rollback macht sie nicht rückgängig
• Dependencies: helm dependency update zieht Subcharts nach charts/, Chart.lock pinnt die Versionen, condition/tags schalten sie an/aus
• wo Helm aufhört: verwaiste Objekte nach Template-Löschung, CRDs aus crds/ ohne Upgrade, kein Schutz der Daten-Volumes, keine Drift-Korrektur
• Umbrella-Chart (ein Release, alles-oder-nichts) vs Einzelchart je Dienst (8 Releases, unabhängiger Rollback, keine dienstübergreifende Atomarität)
• Bibliothek: je Dienst getrennt – die 8 Deploys sind lose gekoppelt (eigene DB, eigenes Tempo), Jenkins ruft upgrade --install je Dienst
• der pipeline-SA (A5/A6) begrenzt, was helm upgrade anfassen darf
• wo Helm aufhört und ein Operator anfängt (Block D): Betriebslogik, die laufend auf den Cluster-Zustand reagieren muss
• nicht vergessen: helm get manifest biblio zeigt, was gerade installiert ist – gegen oc get vergleichen
• einmal von Hand durchspielen: helm-am-bibliothek-chart.html geht den ganzen Ablauf am echten Chart durch – template, install, Release-Secret, upgrade, kaputtes Upgrade, Drift, uninstall

C1 ImageStream & ImageStreamTag – Digest statt Tag, und warum das die Tag-Falle löst

Build-KetteImageStreamDigestRegistryEX280

Ein ImageStream speichert keine Image-Bytes – das Image liegt in einer Registry. Der Stream führt Buch: welcher Digest (sha256) stand wann hinter welchem Tag. Zusammen mit dem Image-Trigger (C6) löst das die klassische Tag-Falle: ein neuer Push unter :latest löst auf OpenShift wirklich einen Rollout aus.

• ein ImageStream ist ein clusterinterner, namespaced Zeiger auf Images – er speichert keine Bytes, sondern je Tag die Digest-Historie
• ein ImageStreamTag (catalog-service:9f3ab21, catalog-service:prod) ist eine Marke, die zu einem Digest (sha256) auflöst
• die Tag-Falle: mit reinem Kubernetes bleibt die Pod-Vorlage bei catalog:latest – ein erneuter Push ändert sie nicht, es passiert nichts
• OpenShift löst sie auf zwei Arten: der Image-Trigger (C6) trägt den neuen Digest in die Pod-Vorlage – oder man pusht von vornherein unter einem unveränderlichen Tag (so macht es die Bibliothek)
• der einzige Ort, an dem :latest zuverlässig wirkt – im Chart und im Deployment sonst nie :latest
• Freigabe durch Um-Taggen: oc tag catalog-service:9f3ab21 catalog-service:prod – ein Release ist nur ein Zeiger, atomar und umkehrbar
• ein externes Image in den Cluster holen: oc import-image catalog --from=ghcr.io/org/catalog:1.4 --confirm, importPolicy.scheduled: true importiert periodisch nach
• lookupPolicy.local: true lässt ein reines Deployment den Tag über den Stream auflösen, statt die Registry direkt zu nennen
• Pods ziehen mit dem Token der default-/builder-SA – kein Extra-Secret für die interne Registry (C5)
• Befehle: oc get is, oc get istag, oc describe is catalog-service (Digest-Historie), oc tag, oc import-image
• Preis: ImageStream gibt es nur bei OpenShift – ein Helm-Chart, das ImageStreamTag-Referenzen nutzt, läuft auf reinem Kubernetes nicht
• Bibliothek: Jenkins baut die 9 Images ausserhalb und podman push sie in die interne Registry – der Pfad library/catalog-service:<git-sha> legt automatisch einen ImageStream catalog-service in ns library an. Ein unveränderlicher Tag je Build, darum kein :latest und kein Image-Trigger nötig
• OCP-Unterschied: identisch – ImageStreams sind Kern-OpenShift, in OKD und OCP gleich
• von Hand durchspielen: build-kette-openshift.html – einen ImageStream live sehen, die Tag-Falle nachstellen, per Um-Taggen freigeben

C2 BuildConfig & Build-Strategien – S2I, Docker, custom

Build-KetteBuildConfigS2IStrategienEX280

Ein BuildConfig beschreibt, wie aus Quellcode ein Image wird. Jeder Lauf ist ein Build-Objekt, ausgeführt in einem Build-Pod (als builder-SA). Drei Strategien: S2I (Code + Builder-Image, kein Dockerfile), Docker (aus einem Dockerfile), custom (eigenes Builder-Image steuert alles). Ergebnis landet als ImageStreamTag (C1).

• ein BuildConfig ist das Rezept „wie entsteht dieses Image“ – jeder Lauf ist ein Build-Objekt in einem Build-Pod (als builder-SA)
• Source (S2I): Quellcode + Builder-Image → fertiges App-Image, kein Dockerfile – das assemble-Skript baut (C3)
• Docker: baut aus einem Dockerfile im Repo – intern mit Buildah, kein Docker-Daemon im Cluster
• Custom: ein eigenes Builder-Image bestimmt den ganzen Ablauf (selten, für Spezial-Tooling)
• Input: Git (mit ref), Binary (oc start-build --from-dir), Dockerfile inline, Files aus einem anderen Image – contextDir für Monorepos
• Trigger am BuildConfig: Webhook (GitHub / GitLab / Bitbucket / generic, eine URL im Repo), ImageChange am Builder-Image (holt Base-Image-Patches automatisch), ConfigChange
• Output: gepusht als ImageStreamTag in die interne Registry (C5) – der neue Digest kann über einen Image-Trigger den Rollout auslösen (C1, C6)
• Lebenszyklus: New → Pending → Running → Complete / Failed / Error / Cancelled. runPolicy: Serial / Parallel / SerialLatestOnly
• der Haken: Build-Pods brauchen Cluster-CPU – auf der Single-Node-SNO konkurrieren sie direkt mit den 8 laufenden Diensten
• wann man S2I doch nimmt: kein Dockerfile pflegen wollen, oder Auto-Rebuild bei einem Base-Image-CVE (ImageChange am Builder). Wer schon eine CI hat, baut besser dort
• Befehle: oc start-build catalog --from-dir=. --follow, oc logs -f build/catalog-3, oc cancel-build catalog-3, oc get builds
• Bibliothek: kein BuildConfig im Cluster – Jenkins baut die 9 Images mit podman build (Maven im Container gegen die Host-Engine), dann podman push in die interne Registry. Die ImageStreams entstehen durch den Push, nicht durch einen Build-Pod
• OCP-Unterschied: identisch – die Docker-Strategie nutzt in beiden Buildah
• von Hand durchspielen: build-kette-openshift.html – ein BuildConfig anlegen und einen S2I-Build wirklich laufen lassen

C3 Source-to-Image von innen – assemble/run-Skripte, Builder-Image, inkrementell

Build-KetteS2Iassemble/runBuilder-Image

S2I baut ein Image ohne Dockerfile, weil das Builder-Image die Verpackung schon kann. Es bringt zwei Skripte mit: assemble (baut, zur Build-Zeit) und run (startet, im Container). Der Gedanke: wer Java schreibt, soll kein Dockerfile pflegen – das Builder-Image kodiert die Best Practice.

• das Builder-Image bringt zwei Skripte mit: assemble (baut, zur Build-Zeit) und run (startet, im Container – wird der Entrypoint)
• assemble: mvn package / npm run build anwerfen und das Ergebnis an den Ort legen, den run erwartet
• der Ablauf: Builder starten → Quellcode nach /tmp/src → assemble → Container als neues Image committen mit run als Entrypoint
• inkrementeller Build: save-artifacts hebt den ~/.m2-/node_modules-Cache in die nächste Runde – incremental: true im BuildConfig
• eigene Skripte im Repo unter .s2i/bin/ überschreiben die des Images, .s2i/environment für Env-Variablen
• Chained Build: Build-Stufe mit vollem JDK produziert nur das Artefakt, Runtime-Stufe mit nur JRE kopiert es hinein – kleines Laufzeit-Image, wie ein mehrstufiges Dockerfile
• der Gedanke: wer Java schreibt, soll kein Dockerfile pflegen – das Builder-Image kodiert Base-Image, Verpackung, Nicht-Root
• Red-Hat-Builder-Images (ubi9/openjdk-17, ubi9/nodejs-20) respektieren beliebige UID (A7)
• lokal testen mit der s2i-CLI: s2i build . ubi9/openjdk-17 catalog – debuggen mit S2I_DEBUG=1 oder oc rsh
• Was-wäre-wenn für die Bibliothek: ein nodejs-S2I für library-frontend (Angular-Build → statisches nginx) würde das zweistufige Dockerfile ersparen – heute baut die Pipeline das Frontend selbst (Node 22 im Container)
• Liberty-s2i: assemble legt das WAR nach /config/apps/ (Liberty-Gedankenspiel Zeichnung 10)
• das Ergebnis ist ein gewöhnliches OCI-Image – nichts S2I-spezifisches zur Laufzeit, läuft überall
• OCP-Unterschied: identisch – S2I ist ein eigenes Projekt, OpenShift ruft es über die BuildConfig auf
• S2I von innen durchspielen: Build bis Rollout – lokale Binärquelle bauen und assemble, run, Build-Pod sowie Image-Digest auseinanderhalten

C4 oc new-app / oc new-build – welche Objekte sie erzeugen

Build-Ketteoc new-appoc new-buildEX280

oc new-app ist ein schlaues Gerüst-Werkzeug: du gibst ihm etwas, es rät, was du willst, und legt einen Satz Objekte an. Eine Git-URL wird zu Build-Kette plus Deployment, ein Image nur zu einem Deployment, ein Template zu dessen Objekten. Gut zum Ausprobieren – für Produktion nimmt man Helm.

• oc new-app rät aus der Eingabe: Git-URL → BuildConfig + S2I, Image → nur Deployment, Template → dessen Objekte
• legt typisch an: ImageStream(s), BuildConfig, Deployment, Service
• keine Route – die kommt separat mit oc expose svc/catalog (B4)
• die Sprache wird an Dateien im Repo erkannt (pom.xml, package.json, go.mod…) → passendes Builder-Image
• oc new-app -o yaml --dry-run=client zeigt alles vorher, ohne etwas anzulegen
• oc new-build: nur die Build-Seite (ImageStream + BuildConfig), kein Deployment – für den Fall, dass der Deploy woanders liegt
• -l app=catalog setzt gemeinsame Labels → oc delete all -l app=catalog räumt den ganzen Satz zusammen auf
• weitere Flags: --name=, -e KEY=val, --strategy=docker|source, -i <imagestream>, --context-dir=
• seit OCP 4.14 entsteht ein Deployment, nicht DeploymentConfig (B2)
• gut zum Ausprobieren und für die Prüfung – für Produktion nimmt man Helm (B11) oder Kustomize (deklarativ, versioniert, reviewbar)
• Trick: oc new-app --dry-run -o yaml als Startpunkt für ein eigenes Chart abgreifen
• Bibliothek: new-app höchstens zum Skizzieren – die 8 Dienste kommen als Helm-Chart (ein generisches library-service-Chart je Dienst gefüllt), deployt von Jenkins nach dem externen Build (E1)
• OCP-Unterschied: oc new-app ist OpenShift-eigen – das nächste Kubernetes-Äquivalent ist kubectl create deployment
• von Hand durchspielen: build-kette-openshift.html – oc new-app live starten und sehen, welche Objekte dabei entstehen

C5 Die interne Registry – der image-registry-Operator, die zwei Adressen, Pruning

Build-Ketteinterne Registryimage-registryPruningEX280

OpenShift bringt eine eigene Container-Registry mit, verwaltet von einem Operator. Sie hat zwei Adressen: eine interne (im Cluster, zum Ziehen und für Build-Pods) und eine externe Route (zum Schieben von aussen, muss erst freigeschaltet werden). Pods ziehen ohne Extra-Secret. oc adm prune images hält sie klein.

• ein Operator (image-registry-ClusterOperator) verwaltet sie im Namespace openshift-image-registry – auf SNO/CRC steht sie per Default auf Removed
• einschalten: oc patch configs.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"managementState":"Managed","defaultRoute":true}}' plus ein Storage-Backend
• zwei Adressen: innen image-registry.openshift-image-registry.svc:5000 (ClusterIP, zum Ziehen und für Build-Pods)
• aussen default-route-openshift-image-registry.apps.<cluster> (eine Route) – existiert erst nach defaultRoute: true, dahin schiebt man vom Laptop oder aus der CI
• selbstsigniertes Zertifikat → podman push --tls-verify=false oder die Router-CA vertrauen
• Anmeldung: oc whoami -t | podman login -u kubeadmin --password-stdin default-route-openshift-image-registry.apps.<cluster> – das Token landet nicht in der Shell-History
• Pods ziehen ohne Extra-Secret: die default-/builder-SA jedes Namespace hat ein auto-provisioniertes Pull-Secret für die interne Registry (A6, B10)
• cross-namespace ziehen: der ziehenden SA die Rolle oc policy add-role-to-user system:image-puller ... -n <quell-namespace> geben
• Pruning: oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m zeigt eine Vorschau, --confirm erst nach Prüfung ergänzen
• automatisch: der imagePruner-CronJob (im Operator konfiguriert) – ohne Pruning läuft der Storage voll und Pushes schlagen fehl
• jeder Push aktualisiert die Tag-Historie des ImageStream (C1)
• Bibliothek: die interne Registry ist das Ziel für alle 9 Images. Einmalig managementState: Managed, ein Storage-PVC (vorab als RWO anlegen – der Operator will RWX, local-path kann nur RWO), defaultRoute: true. Jenkins pusht mit dem Dauer-Token der pipeline-SA (Rollen system:image-builder + registry-editor), Cred okd-registry
• nach sno.ps1 up hängt der Operator an einer veralteten Leader-Lease (Attempting to acquire leader lease) – der Post-up-Hook (sno-wsl.sh remediate) löscht sie, sonst bekommt der erste podman login ein connection refused
• Status: oc get co image-registry. OCP-Unterschied: identisch – Quay ist ein zusätzliches Produkt, keine Voraussetzung
• von Hand durchspielen: build-kette-openshift.html – die interne Registry einschalten, von Hand pushen und pullen, aufräumen mit prune images

C6 Deployment-Trigger – ImageChange und ConfigChange

Build-KetteTriggerImageChangeConfigChange

Reines Kubernetes rollt nur aus, wenn sich die Pod-Vorlage ändert. Ein neuer Push unter demselben Tag ändert sie nicht – also passiert nichts, und du suchst den Fehler im Code. Der OpenShift-Image-Trigger löst das: er trägt den neuen Digest in die Vorlage. ConfigChange meint die Vorlage selbst – nicht referenzierte ConfigMaps.

• reines Kubernetes: die Pod-Vorlage sagt image: catalog:latest – ein erneuter Push unter demselben Tag ändert die Vorlage nicht, nichts passiert
• der OpenShift-Image-Trigger ist eine Annotation am Deployment: image.openshift.io/triggers mit einem ImageStreamTag und einem fieldPath
• der openshift-controller-manager beobachtet den Tag – neuer Digest → er patcht die Vorlage auf catalog@sha256:<digest> → neues ReplicaSet → Rollout
• hinzufügen: oc set triggers deploy/catalog --from-image=catalog:latest -c catalog – --manual pausiert ihn
• DeploymentConfig hat denselben Mechanismus eingebaut als spec.triggers[].type: ImageChange (B2)
• ConfigChange: eine Änderung an der Pod-Vorlage selbst löst aus – beim Deployment implizit, beim DeploymentConfig muss man type: ConfigChange deklarieren
• wichtige Grenze: ConfigChange meint die Vorlage, nicht referenzierte ConfigMaps/Secrets – eine gemountete ConfigMap zu ändern rollt den Pod nicht (B8)
• Abhilfe: checksum/config-Annotation (Helm rollt), oc rollout restart deploy/catalog, oder ein Reloader-Operator
• oc rollout restart setzt eine restartedAt-Annotation → Vorlagenänderung → Rollout, und liest dabei ConfigMaps/Secrets neu
• nicht verwechseln: image.openshift.io/triggers am Deployment (löst Rollout) vs BuildConfig-Trigger am BuildConfig (löst Build, C2)
• die Trigger-Kette: Push → ImageStream-Digest (C1) → Trigger → neues ReplicaSet → Rollout (B1)
• Bibliothek: kein Image-Trigger. Jenkins ruft helm upgrade --set image.tag=$GIT_SHA je Dienst – der Tag-Wert in der Pod-Vorlage ändert sich, also rollt Kubernetes ganz normal aus. Der Trigger-Weg wäre die Alternative, wenn nicht die CI den Tag setzt
• OCP-Unterschied: der Image-Trigger ist OpenShift-eigen – reines Kubernetes hat kein Äquivalent (nur externe Tools wie Argo Image Updater)
• beide Triggerwege durchspielen: Build bis Rollout – erst einen neuen Image-Digest automatisch ausrollen, danach eine Pod-Vorlagenänderung als ConfigChange-Wirkung beweisen

D1 Was ist ein Operator? – Controller + CRD + Betriebswissen als Code

OperatorenControllerCRDReconcile

Ein Operator ist ein eigener Controller plus eine CRD. Die CRD führt einen neuen Objekttyp ein (z. B. Kafka), eine Custom Resource davon ist der Sollzustand. Der Operator läuft in einer Reconcile-Schleife: Custom Resources beobachten, mit der Realität vergleichen, handeln – er kodiert das Betriebswissen, das sonst ein Admin von Hand anwendet.

• ein Operator ist ein Controller plus eine CRD – die CRD führt einen neuen Objekttyp ein (kind: Kafka), danach gleichwertig zu Pod (A3)
• eine Custom Resource dieses Typs ist der Sollzustand – nur was (spec.replicas: 3), nicht wie
• der Operator läuft in einer Reconcile-Schleife – Custom Resources beobachten, Ist gegen Soll vergleichen, handeln, endlos
• er reagiert auch auf Pod-Ausfälle, Zeit und externe Events, nicht nur auf CR-Änderungen – das ist der Unterschied zu einem einmaligen Deploy
• was er baut: StatefulSets, Services, ConfigMaps, PVCs, Rollen – alles per ownerReferences an die CR gebunden, CR weg = alles weg
• die CR ist die einzige Wahrheit – änderst du direkt am StatefulSet, dreht der Operator es beim nächsten Reconcile zurück
• Unterschied zu Helm (B11): Helm rendert einmal und hört auf, der Operator gleicht ständig ab und heilt Drift
• Faustregel: einmaliges Deploy → Helm, etwas das betrieben werden muss → Operator
• Capability Levels I–V – Basic Install, Seamless Upgrades, Full Lifecycle (Backup/Restore), Deep Insights, Auto Pilot – im OperatorHub je Operator angegeben (D3)
• Bibliothek heute: Postgres, Redis, Kafka, Keycloak laufen als Bitnami-Helm-Charts, nicht als Operatoren – einmal helm upgrade, danach kein Abgleich und keine Selbstheilung
• der Operator wäre der nächste Schritt für Kafka oder Postgres, sobald Backup, Failover oder Rebalancing (Capability Level III+) gebraucht werden
• die 8 Spring-Dienste + config-server sind einfache Deployments – kein Operator, kein StatefulSet, die brauchen nur ein Rolling Update
• Befehle: oc get crd, oc api-resources, oc explain kafka.spec, oc get kafka -o yaml (Feld status)
• OCP-Unterschied: das Muster ist Kubernetes – OpenShift liefert OLM (D2) und OperatorHub (D3) mit, reines Kubernetes muss beides nachrüsten
• von Hand durchspielen: Operator-Reconcile und Service-Zertifikate – Soll/Ist-Schleife am eingebauten Service-CA-Operator sichtbar machen und optional eine echte ArgoCD-CR untersuchen

D2 OLM – CatalogSource, Subscription, InstallPlan, ClusterServiceVersion, OperatorGroup

OperatorenOLMSubscriptionCSVEX280

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).

• 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
• von Hand durchspielen: operator-installieren-olm.html – die OLM-Objekte am Beispiel OpenShift GitOps einmal komplett durchspielen

D3 OperatorHub – die vier Default-Kataloge, Installation über die Konsole

OperatorenOperatorHubKatalogeEX280

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.

• 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
• von Hand durchspielen: operator-installieren-olm.html – die vier Default-Kataloge von der CLI aus ansehen

D4 Einen Operator hands-on installieren – Channels, Dependency-Resolution, Approval

OperatorenInstallationChannelsDependenciesEX280

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.

• 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
• von Hand durchspielen: operator-installieren-olm.html – eine Subscription mit Manual-Approval abonnieren, den InstallPlan live genehmigen, die CSV-Phasen verfolgen

D5 Operator-verwaltete Last – eine Custom Resource anlegen, Reconcile beobachten

OperatorenCustom ResourceReconcilehands-on

Jetzt der Nutzen aus D1–D4. Du legst eine Custom Resource an (kind: Kafka, spec.replicas: 3) und siehst zu, wie der Operator daraus StatefulSets, Services und ConfigMaps baut. Änderst du die CR, gleicht er nach. Löschst du sie, räumt er alles weg.

• du legst eine Custom Resource an (oc apply -f kafka.yaml – kind: Kafka, spec.kafka.replicas: 3) – das Schema prüft die CRD (D1)
• Beispiel-CRs liefert die CSV mit (Annotation alm-examples) – ein guter Startpunkt
• der Operator reconciled – sieht die CR, rechnet aus was fehlt, legt die Objekte in Reihenfolge an
• was entsteht: StatefulSets (B1), headless Services (B3), ConfigMaps, Secrets, PVCs (G3), PDB, NetworkPolicy, RBAC
• alles mit ownerReferences auf die CR – CR löschen räumt den ganzen Satz weg (Garbage Collection)
• der Operator schreibt status.conditions zurück in die CR – Ready: True, Reconciling: True
• wo die Operator-Config liegt: in der CR selbst (oc get kafka events -o yaml), nicht in einer ConfigMap – die ConfigMaps darunter erzeugt und überschreibt der Operator
• CR ändern (replicas: 5) → der Operator skaliert die StatefulSets hoch und rebalanced – beim Helm-Chart wäre das values.yaml + helm upgrade
• direkt am StatefulSet ziehen → der Operator dreht es beim nächsten Reconcile zurück – die CR ist die einzige Wahrheit (D1)
• nur der Operator merkt, wenn ein Broker wegfällt, und ersetzt ihn – das Bitnami-Helm-Chart tut das nicht
• oft bringt der Operator weitere CRDs mit (KafkaTopic, KafkaUser) – auch die gehören dann ins Git (E3)
• Bibliothek heute: keine Operator-CRs – Kafka und Postgres kommen aus Bitnami-Helm-Charts. Der Umbau wäre helm uninstall, Strimzi-Operator, eine Kafka-CR – und die Helm-Werte weichen CRD-Feldern
• Debugging: oc describe kafka events (Events + Conditions), oc logs deploy/<operator> -n <ns>
• OCP-Unterschied: keiner – sobald der Operator läuft, ist das reine Custom-Resource-Mechanik
• von Hand durchspielen: Reconcile beobachten – ein verwaltetes TLS-Secret löschen und seine Neuerzeugung beweisen; optional danach eine ArgoCD-Custom-Resource anlegen