Einführung in Red Hat OpenShift

OpenShift basiert auf Kubernetes und ergänzt es um Plattform-APIs und abgestimmte Betriebswege. Sie ordnen Web Console, oc CLI, Projects, Routes, Builds, ImageStreams, SCCs und Operators in eine gemeinsame Architektur ein. Im DevNinjas Dojo, unserer Cloud-Lernumgebung, unterscheiden Sie unveränderte Kubernetes-Ressourcen von OpenShift-spezifischen Erweiterungen und klären die jeweiligen Verantwortlichkeiten.

Seit OpenShift 4.19 sind die Perspektiven der Web Console vereinheitlicht; die Developer-Perspektive ist standardmäßig nicht mehr aktiviert, kann aber von Clusteradministratoren aktiviert werden. Sie melden sich mit oc an und untersuchen dieselben Ressourcen, Logs und Events über Console und CLI. Dabei vergleichen Sie, wie Console und CLI dieselben Clusterressourcen darstellen.

Ein OpenShift Project erweitert einen Kubernetes-Namespace um Metadaten und dient als Grenze für Zugriffe, Quotas und ServiceAccounts. Sie erstellen Projects, weisen Benutzern die Rollen view, edit und admin zu und prüfen Berechtigungen mit oc. Dabei verfolgen Sie, welche RoleBindings entstehen und wie sich Projekt- und Clusterrechte unterscheiden.

OpenShift unterstützt Anwendungsbereitstellung über Katalog, CLI und deklarative Manifeste. Sie deployen dieselbe Beispielanwendung über die Web Console, CLI und ein deklaratives Manifest. Danach beobachten Sie Rollout, Pods, Logs und Events und vergleichen in Ihrer Lernumgebung, welcher der drei Bereitstellungswege jeweils zu welcher konkreten Aufgabe passt.

Eine OpenShift Route veröffentlicht einen Service unter einem Hostnamen und kann TLS unterschiedlich terminieren. Sie erzeugen eine Route und vergleichen die drei TLS-Varianten Edge, Passthrough und Reencrypt. Anschließend beobachten Sie die Weiterleitung über den Router in der Lernumgebung und grenzen Routes von Kubernetes Ingress ab.

BuildConfig-Ressourcen verbinden Quellcode, Build-Strategie und Ausgabe-Image. Sie erstellen einen Source-to-Image-Build aus einem Git-Repository und vergleichen ihn mit einem Dockerfile-basierten Build. Dabei untersuchen Sie Builder-Image, Build-Logs, Parameter und Ergebnis und ordnen mehrstufige Pipeline-Abläufe als separate Erweiterung ein.

ImageStreams halten Referenzen und Tags für Container-Images innerhalb von OpenShift nach. Sie erstellen einen ImageStream, verbinden ihn mit einer BuildConfig und konfigurieren Webhook- sowie ImageChange-Trigger für Code- und Image-Änderungen. Anschließend lösen Sie einen Build über diese Eingänge aus und verfolgen seinen Status, ohne daraus eine vollständige externe CI-Pipeline abzuleiten.

Standard-Kubernetes-Deployments steuern ReplicaSets und unterstützen RollingUpdate sowie Recreate. Sie arbeiten mit Deployments und konfigurieren beide Strategien für unterschiedliche Aktualisierungsanforderungen. DeploymentConfigs ordnen Sie als weiterhin unterstützte, aber veraltete OpenShift-Bestandsressourcen ein und vergleichen ihre wichtigsten Unterschiede sowie den Migrationspfad zu Deployments für neue Workloads.

ConfigMaps und Secrets trennen Laufzeitkonfiguration vom Container-Image, schützen Werte jedoch nicht automatisch vor jedem Zugriff. Sie erstellen beide Ressourcen, binden Schlüssel als Umgebungsvariablen und Dateien ein und aktualisieren eine Anwendung kontrolliert. An einer Beispielanwendung sehen Sie, wie ConfigMaps und Secrets gemeinsam die Laufzeitkonfiguration im Pod steuern.

PersistentVolumeClaims fordern Speicher über eine StorageClass an und entkoppeln Workloads vom konkreten Backend. Sie erstellen einen Claim, binden ihn an eine Anwendung und prüfen den Datenerhalt nach einem Pod-Wechsel. Dabei ordnen Sie Dynamic Provisioning mit StorageClasses ein, durch das OpenShift Volumes automatisch anlegt, und unterscheiden Block-, Datei- und Objektspeicher im OpenShift-Kontext.

RBAC entscheidet, wer eine Security Context Constraint verwenden darf; die SCC prüft anschließend die Pod-Konfiguration. Sie binden Rollen an Benutzer und ServiceAccounts, untersuchen restricted-v2 und testen zugelassene sowie abgewiesene Workloads. Dabei korrigieren Sie ein inkompatibles Container-Image, ohne pauschal weitreichende Rechte zu vergeben.

ResourceQuota, LimitRange und HorizontalPodAutoscaler setzen Grenzen auf unterschiedlichen Ebenen. Sie definieren konkrete Projektbudgets und passende Standardwerte, ergänzen Requests und Limits für einen Workload und konfigurieren einen HPA. Anschließend erzeugen Sie kontrolliert Last und prüfen dabei gemeinsam, wie Metriken, Skalierungsentscheidung und verbleibende Quota das Verhalten bestimmen.

Der OpenShift-Softwarekatalog macht Operators auffindbar; Operator Lifecycle Manager verwaltet Installation und Abonnements. Sie wählen einen passenden Operator, prüfen InstallMode, Channel und erforderliche Berechtigungen und erstellen anschließend eine Custom Resource. Dabei beobachten Sie Controller und Status und vergleichen das fortlaufende Betriebsmodell mit einer einmaligen Paketinstallation.

Helm Charts und OpenShift Templates stellen Anwendungen über wiederverwendbare Beschreibungen bereit. Sie installieren ein Helm Chart über die Web Console, passen Values an und vergleichen diesen Ablauf mit dem Operator-Ansatz. Templates lernen Sie als älteres OpenShift-Konzept zur Einordnung kennen; der praktische Schwerpunkt bleibt auf Helm und dessen Release-Verwaltung.

OpenShift erfasst Plattformmetriken mit Prometheus und leitet Alerts über Alertmanager weiter. Sie nutzen den Observe-Bereich der Web Console, fragen Metriken ab und untersuchen eine Alert-Regel sowie deren Ziel. Abschließend ordnen Sie User Workload Monitoring, GitOps, Service Mesh und Multi-Cluster-Management als mögliche Vertiefungen ein.