Einführung in Red Hat OpenShift

Wer mit Kubernetes arbeitet, kennt die Herausforderungen: Ingress konfigurieren, CI/CD selbst aufsetzen, Security Policies manuell verwalten. Dieses Modul zeigt, welche Komponenten OpenShift zusätzlich mitbringt: integrierte Image Registry, Routes statt Ingress, Source-to-Image (S2I) für automatische Builds und ein striktes Security-Modell mit SCCs. Sie verstehen danach, wann sich OpenShift gegenüber einem selbst verwalteten Kubernetes-Cluster lohnt.

OpenShift bietet zwei Zugangswege zum Cluster: die Web Console mit Developer- und Administrator-Perspektive und die Kommandozeile mit oc. Sie wechseln zwischen beiden Ansichten, erstellen ein erstes Projekt und vergleichen, wie sich oc von kubectl unterscheidet. Am Ende navigieren Sie sicher durch Dashboards, Logs und Events, sowohl grafisch als auch im Terminal.

Projects sind OpenShifts Erweiterung von Kubernetes Namespaces: sie bringen automatische Netzwerkisolation und Standard-Policies mit. Sie legen Projects an, erstellen lokale Users und weisen Rollen wie view, edit und admin zu. Dabei erleben Sie direkt, wie sich Rechte auf den Zugriff in Console und CLI auswirken.

Jetzt wird es praktisch: Sie deployen eine Container-Anwendung über drei Wege. Zuerst über die Web Console per Katalog, dann mit oc new-app auf der Kommandozeile und schließlich mit einem Kubernetes-Manifest (YAML). Sie beobachten den Rollout live und prüfen Pod-Status, Logs und Events. Danach wissen Sie, welcher Weg sich wann eignet.

In vanilla Kubernetes brauchen Sie einen Ingress Controller plus Konfiguration. OpenShift Routes ersetzen das mit einem einzigen Befehl: oc expose. Sie erstellen eine Route, konfigurieren TLS-Terminierung (Edge, Passthrough, Re-encrypt) und sehen, wie der integrierte HAProxy Router den Traffic verteilt. Der Vergleich zu Ingress zeigt, warum Routes in der Praxis oft schneller zum Ziel führen.

Wie wird aus Quellcode ein laufender Container? OpenShift bietet drei Wege: Source-to-Image (S2I) baut direkt aus einem Git-Repository, ohne dass Sie ein Dockerfile schreiben. Docker Build nutzt ein vorhandenes Dockerfile. Und Pipelines (Tekton-basiert) ermöglichen mehrstufige CI/CD-Abläufe. Sie probieren S2I und Docker Build hands-on aus und sehen, wann welche Strategie passt.

ImageStreams sind ein Konzept ohne Pendant in vanilla Kubernetes. Sie abstrahieren Container-Images und ermöglichen automatische Rebuilds, sobald sich ein Base Image ändert. Sie erstellen einen ImageStream, verknüpfen ihn mit einer BuildConfig und konfigurieren Trigger: bei Code-Änderungen (Webhook), Image-Updates oder Konfigurationsänderungen. Das Ergebnis ist eine automatisierte Build-Pipeline ohne externes CI-Tool.

OpenShift hat lange auf eigene DeploymentConfigs gesetzt, doch seit Version 4.14 sind diese deprecated. In diesem Modul arbeiten Sie mit Standard-Kubernetes-Deployments und konfigurieren Rollout-Strategien: RollingUpdate für unterbrechungsfreie Updates und Recreate für Szenarien mit exklusivem Datenbankzugriff. Wer bestehende DeploymentConfigs migrieren muss, lernt die wichtigsten Unterschiede und den Migrationspfad kennen.

Konfiguration gehört nicht ins Container-Image. Sie erstellen ConfigMaps für Anwendungseinstellungen und Secrets für Zugangsdaten, mounten sie als Dateien oder Umgebungsvariablen in Pods und sehen, wie die OpenShift Web Console das Management erleichtert. Praktische Übung: eine Anwendung, deren Datenbankverbindung komplett über ConfigMaps und Secrets gesteuert wird.

Container sind kurzlebig, aber Datenbanken brauchen persistenten Speicher. Sie erstellen PersistentVolumeClaims, binden sie an Pods und testen, ob Daten einen Pod-Neustart überleben. Dann konfigurieren Sie Dynamic Provisioning mit StorageClasses, damit OpenShift Volumes automatisch anlegt. Am Ende verstehen Sie den Unterschied zwischen Block-, File- und Object-Storage im OpenShift-Kontext.

OpenShift ist restriktiver als vanilla Kubernetes: Container laufen standardmäßig ohne Root-Rechte. Sie erstellen Roles und ClusterRoles, binden sie an Users und ServiceAccounts und testen, was passiert, wenn ein Pod mehr Rechte anfordert als die zugewiesene SCC erlaubt. Dieses Modul erklärt, warum manche Container-Images in OpenShift nicht starten und wie Sie SCCs gezielt lockern oder einschränken.

In Multi-Tenant-Umgebungen darf kein Team den gesamten Cluster beanspruchen. Sie konfigurieren ResourceQuotas pro Project, setzen LimitRanges als Leitplanken für CPU und RAM und richten einen Horizontal Pod Autoscaler (HPA) ein, der Pods bei steigender Last automatisch skaliert. Dann beobachten Sie live, wie OpenShift auf einen Lasttest reagiert.

Operators sind das Rückgrat des OpenShift-Ökosystems: sie automatisieren Installation, Updates und Lifecycle-Management komplexer Software. Sie installieren einen Operator aus dem OperatorHub (z.B. eine Datenbank), beobachten, wie er Custom Resources anlegt und verwaltet, und verstehen die Maturity-Level (Basic Install bis Auto Pilot). Danach wissen Sie, wann ein Operator die bessere Wahl gegenüber einem Helm Chart ist.

Neben Operators unterstützt OpenShift auch Helm Charts und eigene Templates. Sie installieren eine Anwendung per Helm über die Web Console, passen Values an und vergleichen den Workflow mit dem Operator-Ansatz. Templates als älteres OpenShift-Konzept lernen Sie zur Einordnung kennen, der Fokus liegt auf Helm als dem Standard für wiederverwendbare Kubernetes-Pakete. Tiefer einsteigen können Sie in unserer Helm Schulung.

OpenShift liefert Prometheus und Grafana als eingebauten Monitoring-Stack. Sie öffnen die vorinstallierten Dashboards, betrachten Cluster- und Pod-Metriken und erstellen eine erste Alert Rule. Zum Abschluss werfen wir einen Blick auf weiterführende Themen: GitOps mit ArgoCD, Service Mesh, Advanced Cluster Management und den Pfad zur EX280-Zertifizierung.