Red Hat OpenShift Container Platform lernen

Überblick und Lernziele

Was du am Ende können sollst

• OpenShift als Enterprise-Kubernetes-Plattform erklären und von Vanilla Kubernetes abgrenzen.
• Mit oc, Web Console und YAML sicher arbeiten.
• Projekte, Deployments, Services, Routes, ConfigMaps, Secrets, Volumes und Operatoren einsetzen.
• Applikationen aus Quellcode, Container Images und Git-Repositories deployen.
• Logs, Events, Ressourcenverbrauch und Health Checks analysieren.
• Security-Grundlagen wie RBAC, ServiceAccounts, Security Context Constraints, NetworkPolicies und Image-Sicherheit anwenden.
• CI/CD mit OpenShift Builds, Pipelines/Tekton und GitOps/Argo CD einordnen und praktisch nutzen.
• Grundlagen zu Installation, Upgrades, Nodes, Storage, Netzwerk, Monitoring, Backup und Day-2-Betrieb verstehen.

Zielrollen

Empfohlene Lernumgebung

1. Einsteigerfreundlich: Red Hat Developer Sandbox für OpenShift.
2. Lokale Labs: Single Node OpenShift, CodeReady Containers/OpenShift Local oder eine vorbereitete VM-Umgebung, wenn verfügbar.
3. Team-/Admin-Lab: Nicht-produktiver OCP-Cluster auf Cloud, vSphere, Bare Metal oder Lab-Infrastruktur.

Wichtig: Viele Admin-Aufgaben erfordern cluster-admin. In der Developer Sandbox sind einige Berechtigungen eingeschränkt; nutze sie vor allem für Developer- und CI/CD-Labs.

Voraussetzungen und Setup

Technische Voraussetzungen

Du solltest vor dem Start diese Grundlagen besitzen oder parallel nachholen:

• Linux CLI: Prozesse, Dateien, Rechte, SSH, Paketmanager, Shell-Basics.
• Container: Images, Container, Registries, Dockerfile/Containerfile, Podman oder Docker.
• Netzwerk: DNS, HTTP/HTTPS, TLS, Ports, Load Balancing-Grundbegriffe.
• YAML und JSON: Einrückung, Listen, Maps, einfache Manifest-Strukturen.
• Git: Branches, Commits, Pull Requests, .gitignore.

Lokale Tools

Installiere oder bereite vor:

# Pflicht
oc version
kubectl version --client
podman --version || docker --version
git --version

# Optional, aber hilfreich
tkn version      # OpenShift Pipelines / Tekton CLI
argocd version   # GitOps CLI, falls genutzt
helm version
jq --version
yq --version

Erstes Login

oc login --token=<TOKEN> --server=<API_SERVER>
oc whoami
oc cluster-info
oc project

Arbeitsverzeichnis

Lege dir ein Repo an, in dem du alle Übungen dokumentierst:

openshift-learning/
├── _intern/sources/_intern\sources\README.md
├── week-01-foundations/
├── week-02-kubernetes-basics/
├── week-03-openshift-core/
├── week-04-app-deployments/
├── week-05-config-storage/
├── week-06-networking/
├── week-07-security/
├── week-08-observability/
├── week-09-builds-cicd/
├── week-10-gitops/
├── week-11-operations/
└── week-12-capstone/

12-Wochen-Fahrplan

Lernplan in Phasen

Wöchentliche Routine

1. 60–90 Minuten Theorie lesen.
2. 2–3 Stunden Hands-on-Lab.
3. 60 Minuten Fehler bewusst erzeugen und debuggen.
4. 30 Minuten Notizen, Diagramm oder Runbook aktualisieren.
5. 15 Minuten Selbsttest mit Kontrollfragen.

Woche 1 — Cloud-native und OpenShift-Grundlagen

Lernziele

• Verstehen, warum Container-Orchestrierung notwendig ist.
• Kubernetes-Kernobjekte einordnen: Pod, ReplicaSet, Deployment, Service, Namespace.
• OpenShift als Kubernetes-Distribution mit Enterprise-Funktionen verstehen.
• OpenShift-Begriffe lernen: Project, Route, Build, ImageStream, Operator, SCC, ClusterOperator.

Theorie

Lerne diese Konzepte:

• Container Image vs. laufender Container.
• Declarative State: gewünschter Zustand wird in YAML beschrieben.
• Controller Pattern: Kubernetes/OpenShift korrigiert Ist-Zustand Richtung Soll-Zustand.
• Multi-Tenancy: Projekte, Quotas, RBAC und Security Boundaries.
• OpenShift-Erweiterungen: Web Console, Routes, integrierte Registry, Operators, Builds, Pipelines, GitOps, Security Defaults.

Praxislab

1. Erstelle ein Glossar mit mindestens 30 Begriffen.
2. Zeichne eine grobe Architektur: Benutzer → Route → Service → Pod → Container → Image.
3. Melde dich an einem Cluster an und inspiziere deine Berechtigungen:

oc whoami
oc auth can-i --list
oc projects
oc get clusterversion
oc get clusteroperators

Kontrollfragen

• Was ist der Unterschied zwischen Kubernetes Namespace und OpenShift Project?
• Warum sollte man Applikationen deklarativ beschreiben?
• Was macht ein Operator?
• Was ist der Unterschied zwischen Service und Route?

Ergebnis

Eine Markdown-Datei week-01-foundations/_intern/sources/_intern\sources\README.md mit Glossar, Diagramm und deinen ersten oc-Befehlen.

Woche 2 — Kubernetes-Basics für OpenShift

Lernziele

• Kubernetes-Objekte aus YAML erstellen, ändern und löschen.
• Pods, Deployments und Services debuggen.
• Labels und Selectors verstehen.
• Ressourcenlimits und Probes einsetzen.

Zentrale Objekte

Praxislab

oc new-project learn-k8s-basics
oc create deployment hello --image=quay.io/openshift/origin-hello-openshift:latest
oc expose deployment hello --port=8080
oc get pods,deploy,svc
oc logs deploy/hello
oc describe pod -l app=hello

Skaliere die Anwendung:

oc scale deployment hello --replicas=3
oc get pods -o wide

Erzeuge bewusst einen Fehler:

oc set image deployment/hello hello=quay.io/does-not-exist/broken:latest
oc rollout status deployment/hello
oc get events --sort-by=.lastTimestamp
oc rollout undo deployment/hello

Kontrollfragen

• Wie findet ein Service die passenden Pods?
• Was ist der Unterschied zwischen oc get, oc describe und oc logs?
• Warum ist ein Deployment besser als ein einzelner Pod?
• Was passiert bei einem kaputten Image?

Ergebnis

Ein Ordner mit YAML-Manifests, Fehlernotizen und einem Mini-Troubleshooting-Protokoll.

Woche 3 — OpenShift Core: Projects, Routes, CLI und Console

Lernziele

• OpenShift-spezifische Developer-Flows verstehen.
• Mit Web Console und oc parallel arbeiten.
• Routes für externen Zugriff nutzen.
• ImageStreams und oc new-app kennenlernen.

Praxislab: App per CLI deployen

oc new-project learn-openshift-core
oc new-app quay.io/openshift/origin-hello-openshift:latest --name=hello
oc expose service/hello
oc get route hello
oc status

Teste die Route:

ROUTE=$(oc get route hello -o jsonpath='{.spec.host}')
curl -i "http://$ROUTE"

Praxislab: App per Source-to-Image-ähnlichem Flow

Je nach Cluster-Berechtigung kannst du eine App direkt aus Git erzeugen:

oc new-app nodejs:latest~https://github.com/sclorg/nodejs-ex.git --name=node-demo
oc logs -f bc/node-demo || oc logs -f deploy/node-demo
oc expose service/node-demo

Falls BuildConfig oder ImageStreams in deiner Umgebung eingeschränkt sind, nutze stattdessen ein fertiges Container Image.

Console-Aufgaben

• Wechsle zwischen Developer und Administrator Perspective.
• Öffne die Topology View.
• Prüfe Pods, Logs, Events und Route-Details.
• Ändere die Replica-Anzahl in der UI und prüfe sie mit oc get deploy.

Kontrollfragen

• Was ist eine OpenShift Route?
• Wann nutzt du oc new-app, wann YAML-Manifeste?
• Welche Informationen liefert oc status?
• Was unterscheidet Developer- und Administrator-Perspektive?

Ergebnis

Eine öffentlich erreichbare Demo-App mit Route und Screenshots/Notizen aus Console und CLI.

Woche 4 — Deployments, Rollouts, Health Checks und Ressourcen

Lernziele

• Deployment-Strategien und Rollbacks sicher anwenden.
• Readiness, Liveness und Startup Probes konfigurieren.
• Requests und Limits setzen.
• Grundlegende Hochverfügbarkeit für stateless Apps erreichen.

Beispielmanifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: quay.io/openshift/origin-hello-openshift:latest
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 250m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 20

Praxislab

oc apply -f deployment.yaml
oc rollout status deploy/web
oc set image deploy/web web=quay.io/openshift/origin-hello-openshift:latest
oc rollout history deploy/web
oc rollout undo deploy/web
oc adm top pods  # falls Metrics verfügbar sind

Fehlerübungen

• Setze absichtlich einen falschen Probe-Pfad.
• Setze ein zu niedriges Memory-Limit.
• Skaliere auf 0 und wieder hoch.
• Lösche einen Pod und beobachte die Selbstheilung.

Kontrollfragen

• Worin unterscheiden sich Readiness und Liveness Probe?
• Warum sind Requests wichtig für Scheduling?
• Was passiert bei oc rollout undo?
• Warum sollten Images möglichst immutable getaggt werden?

Ergebnis

Ein Deployment-Runbook mit Standardwerten für Probes, Ressourcen und Rollback-Schritte.

Woche 5 — Konfiguration, Secrets und Storage

Lernziele

• ConfigMaps und Secrets als Environment Variables und Dateien mounten.
• PersistentVolumeClaims nutzen.
• Stateful vs. stateless Workloads unterscheiden.
• Backup-Anforderungen für Daten verstehen.

ConfigMap und Secret

oc create configmap app-config \
  --from-literal=APP_MODE=training \
  --from-literal=FEATURE_FLAG=true

oc create secret generic app-secret \
  --from-literal=DB_PASSWORD='change-me'

In ein Deployment einbinden:

oc set env deployment/web --from=configmap/app-config
oc set env deployment/web --from=secret/app-secret
oc describe deployment/web

PVC-Beispiel

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Praxislab

• Erstelle ConfigMap und Secret.
• Binde beide in eine App ein.
• Erstelle einen PVC und mounte ihn in einen Pod.
• Schreibe eine Datei in das Volume, lösche den Pod und prüfe Persistenz.

Kontrollfragen

• Warum gehören Secrets nicht ins Git-Repo?
• Was ist der Unterschied zwischen ReadWriteOnce und ReadWriteMany?
• Welche Daten dürfen in einem Container-Layer liegen und welche nicht?
• Wie würdest du Konfigurationsänderungen kontrolliert ausrollen?

Ergebnis

Eine App, deren Verhalten über ConfigMap/Secret gesteuert wird, plus Storage-Testprotokoll.

Woche 6 — Networking: Services, Routes, DNS, TLS und Policies

Lernziele

• OpenShift-Netzwerkpfad Ende-zu-Ende verstehen.
• Cluster-internen und externen Zugriff unterscheiden.
• Routes mit TLS einordnen.
• NetworkPolicies als Mikrosegmentierung einsetzen.

Netzwerkpfad

Client
  ↓ HTTPS/HTTP
OpenShift Route / Ingress Controller
  ↓
Service
  ↓ label selector
Pod Endpoint
  ↓
Container Port

Wichtige Befehle

oc get svc,route,endpoints
oc describe route <name>
oc get dns.operator/default -o yaml 2>/dev/null || true
oc get network.operator/cluster -o yaml 2>/dev/null || true

NetworkPolicy-Beispiel

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}

Praxislab

1. Deploye zwei Apps in zwei Projekten.
2. Teste Kommunikation mit curl aus Debug-Pods.
3. Erstelle eine deny-by-default Policy.
4. Erlaube gezielt Traffic von App A zu App B.
5. Dokumentiere, welche Verbindungen funktionieren.

Kontrollfragen

• Wann nutzt du Service, wann Route?
• Was passiert, wenn ein Service keinen Endpoint hat?
• Warum kann eine NetworkPolicy scheinbar „nichts tun“, wenn das CNI-Plugin sie anders behandelt oder keine passende Auswahl greift?
• Welche TLS-Varianten können bei Routes relevant sein?

Ergebnis

Ein Netzwerkdiagramm und mindestens zwei getestete NetworkPolicies.

Woche 7 — Security: RBAC, ServiceAccounts, SCC und Image-Sicherheit

Lernziele

• Least Privilege auf Projekt- und Cluster-Ebene anwenden.
• Rollen, RoleBindings, ClusterRoles und ServiceAccounts verstehen.
• Security Context Constraints konzeptionell einordnen.
• Container Images sicherer bauen und betreiben.

RBAC-Befehle

oc get rolebindings
oc get roles
oc adm policy who-can get pods
oc auth can-i create deployments
oc create serviceaccount app-runner
oc adm policy add-role-to-user view system:serviceaccount:<project>:app-runner

Security-Prinzipien

• Keine Root-Container, wenn nicht zwingend notwendig.
• Images aus vertrauenswürdigen Registries beziehen.
• Keine Secrets in Images oder Logs.
• Ressourcenlimits setzen, um Noisy-Neighbor-Probleme zu reduzieren.
• Nur benötigte Berechtigungen vergeben.
• NetworkPolicies als zweite Schutzschicht nutzen.

Praxislab

1. Lege eine Person oder einen ServiceAccount mit view-Rechten an.
2. Prüfe, welche Aktionen erlaubt und verboten sind.
3. Deploye eine App mit eigenem ServiceAccount.
4. Vergleiche Pod-Security-Kontext und Events bei nicht erlaubten Einstellungen.
5. Erstelle eine Security-Baseline für neue Projekte.

Kontrollfragen

• Unterschied zwischen Role und ClusterRole?
• Was bedeutet Least Privilege praktisch in OpenShift?
• Warum blockt OpenShift bestimmte Container-Patterns standardmäßig?
• Welche Risiken entstehen durch privilegierte Builds oder Container?

Ergebnis

Eine Security-Baseline mit RBAC-Minimalrollen, ServiceAccount-Pattern und Image-Regeln.

Woche 8 — Observability und Troubleshooting

Lernziele

• Logs, Events, Status Conditions und Metriken systematisch auswerten.
• Häufige Fehlerbilder erkennen.
• Debug-Container und oc debug nutzen.
• Ein Troubleshooting-Playbook erstellen.

Troubleshooting-Kette

oc get pods
oc describe pod <pod>
oc logs <pod> --all-containers
oc get events --sort-by=.lastTimestamp
oc get deploy,rs,svc,route,endpoints
oc rollout status deploy/<name>
oc adm top pods  # falls verfügbar

Häufige Fehlerbilder

Praxislab

Erzeuge diese Fehler absichtlich:

1. Falsches Image.
2. Falscher Container-Port im Service.
3. Kaputte Readiness Probe.
4. Zu niedriges Memory-Limit.
5. Fehlende Berechtigung für eine Aktion.

Dokumentiere jeweils: Symptom, Befehl, Diagnose, Fix, Prävention.

Kontrollfragen

• Wann verwendest du logs --previous?
• Warum sind Events oft schneller hilfreich als Logs?
• Wie findest du heraus, ob eine Route auf einen gesunden Pod zeigt?
• Welche Informationen gehören in ein Incident-Runbook?

Ergebnis

Ein Troubleshooting-Playbook mit mindestens fünf realen Fehlerfällen.

Woche 9 — Builds, Images und CI/CD mit OpenShift Pipelines

Lernziele

• Container Image Build-Strategien vergleichen.
• OpenShift Builds, BuildConfig und moderne Builds einordnen.
• OpenShift Pipelines/Tekton-Grundobjekte verstehen.
• Eine einfache CI/CD-Pipeline erstellen.

CI/CD-Grundobjekte

Minimaler Pipeline-Gedanke

Git Push
  ↓
Clone Source
  ↓
Build Image
  ↓
Push Image
  ↓
Deploy to OpenShift
  ↓
Smoke Test

Praxislab

1. Erstelle ein Beispiel-App-Repo.
2. Baue ein Image mit Podman oder Cluster-Build.
3. Pushe das Image in eine Registry.
4. Deploye es nach OpenShift.
5. Automatisiere Clone → Build → Deploy mit einer Pipeline, wenn OpenShift Pipelines verfügbar ist.

Beispielhafte Befehle:

oc get operators
oc get pods -n openshift-pipelines 2>/dev/null || true
tkn pipeline list
tkn pipelinerun list

Kontrollfragen

• Warum sollte CI/CD nicht mit Cluster-Admin-Rechten laufen?
• Was ist der Unterschied zwischen Build und Deployment?
• Welche Secrets braucht eine Pipeline typischerweise?
• Wie machst du Pipeline-Ergebnisse nachvollziehbar?

Ergebnis

Eine dokumentierte Pipeline oder ein lokal reproduzierbarer Build-und-Deploy-Prozess.

Woche 10 — GitOps mit OpenShift GitOps / Argo CD

Lernziele

• Git als Source of Truth für Cluster- und App-Konfiguration nutzen.
• Argo CD / OpenShift GitOps-Grundkonzepte verstehen.
• Drift erkennen und Sync-Verhalten kontrollieren.
• Repo-Strukturen für mehrere Umgebungen planen.

Empfohlene Repo-Struktur

app-gitops/
├── apps/
│   └── demo-app/
│       ├── base/
│       └── overlays/
│           ├── dev/
│           ├── test/
│           └── prod/
├── platform/
│   ├── namespaces/
│   ├── rbac/
│   └── networkpolicies/
└── clusters/
    ├── lab/
    └── prod/

Konzepte

• Desired State liegt im Git.
• Argo CD vergleicht Cluster-Zustand mit Git-Zustand.
• Sync kann manuell oder automatisch erfolgen.
• Drift wird sichtbar, muss aber bewusst behandelt werden.
• Secrets benötigen zusätzliche Strategie, z. B. External Secrets, Sealed Secrets oder Vault-Integration.

Praxislab

1. Lege ein GitOps-Repo an.
2. Packe Deployment, Service und Route deiner App hinein.
3. Erstelle eine Argo CD Application, falls OpenShift GitOps verfügbar ist.
4. Ändere manuell ein Replica-Feld im Cluster und beobachte Drift.
5. Stelle den Git-Zustand wieder her.

Kontrollfragen

• Warum ist „kubectl/oc apply direkt auf Produktion“ riskant?
• Welche Änderungen gehören ins Git, welche nicht?
• Wie trennst du App- und Plattform-GitOps?
• Wie würdest du Secrets in GitOps behandeln?

Ergebnis

Ein GitOps-Repo mit App-Manifests und einer kurzen Erklärung des Sync-Flows.

Woche 11 — Betrieb: Nodes, Upgrades, Quotas, Backup und Day-2

Lernziele

• Cluster-Betriebsobjekte einordnen.
• Ressourcensteuerung mit Quotas und LimitRanges nutzen.
• Node- und Maschinenkonzepte verstehen.
• Upgrade-, Backup- und Disaster-Recovery-Basics kennen.

Admin-Objekte

Quota-Beispiel

apiVersion: v1
kind: ResourceQuota
metadata:
  name: project-quota
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    pods: "20"

Praxislab

1. Lege eine ResourceQuota und LimitRange in einem Testprojekt an.
2. Deploye Pods mit und ohne Ressourcenangaben.
3. Beobachte Fehlermeldungen bei Überschreitung.
4. Prüfe ClusterOperators und dokumentiere ihre Bedeutung.
5. Skizziere einen Upgrade- und Rollback-Plan für ein Lab-Cluster.

Kontrollfragen

• Warum sind Quotas in Multi-Tenant-Clustern wichtig?
• Was ist der Unterschied zwischen Node, Machine und MachineSet?
• Warum müssen Upgrades vorab mit Operator-Kompatibilität geprüft werden?
• Welche Daten müssen für Disaster Recovery gesichert werden?

Ergebnis

Ein Plattform-Runbook mit Quota-Standard, Upgrade-Checkliste und Backup-Fragenkatalog.

Woche 12 — Capstone-Projekt

Ziel

Baue eine kleine, aber produktionsnahe Anwendung auf OpenShift und dokumentiere sie so, als würdest du sie an ein Team übergeben.

Mindestumfang

Dein Capstone sollte enthalten:

• Ein eigenes Projekt/Namespace.
• Eine App mit mindestens zwei Replikas.
• Service und Route.
• ConfigMap und Secret.
• Readiness und Liveness Probe.
• Requests und Limits.
• Optional: PVC, wenn die App Daten persistiert.
• NetworkPolicy.
• RBAC mit eigenem ServiceAccount.
• Build-/Deploy-Automatisierung oder Pipeline.
• GitOps-Struktur oder mindestens deklarative YAML-Manifeste im Git.
• Monitoring-/Troubleshooting-Notizen.

Beispielidee

Frontend: einfache Web-App
Backend: REST API
Daten: PostgreSQL oder persistenter Dummy-Service
Delivery: GitOps oder Pipeline
Security: NetworkPolicy + nicht-root Container + minimale Rechte

Abnahmekriterien

• App ist über Route erreichbar.
• Rollout kann wiederholt ausgeführt werden.
• Ein kaputtes Image oder eine kaputte Probe kann diagnostiziert und zurückgerollt werden.
• Secrets sind nicht im Klartext im Repo.
• Ressourcenlimits sind gesetzt.
• Dokumentation erklärt Setup, Betrieb und Troubleshooting.

Abschlusspräsentation

Erstelle eine 10-minütige Demo:

1. Architektur zeigen.
2. Deployment zeigen.
3. Route aufrufen.
4. Config ändern und Rollout erklären.
5. Fehler erzeugen und debuggen.
6. Pipeline/GitOps zeigen.
7. Lessons Learned nennen.

Vertiefung nach dem Lernpfad

Admin-Vertiefung

• Installation: Assisted Installer, IPI, UPI, Bare Metal, vSphere, Cloud.
• Cluster Lifecycle: Upgrades, Channels, Operator-Kompatibilität, Maintenance Windows.
• Maschinenverwaltung: MachineSets, MachineConfigPools, Node Tuning.
• Disconnected/Restricted Networks: Mirror Registry, ImageContentSourcePolicy/ImageDigestMirrorSet, Zertifikate.
• Backup/Restore: etcd-Snapshots, OADP/Velero-Konzepte, Restore-Tests.
• Multi-Cluster: Red Hat Advanced Cluster Management, Hosted Control Planes.

Developer-Vertiefung

• Dev Spaces, odo/Developer Tools, Helm/Kustomize.
• Progressive Delivery: Blue/Green, Canary, Feature Flags.
• Service Mesh: Traffic Splitting, mTLS, Retries, Circuit Breaking.
• Serverless: Knative Services, Eventing.
• App Modernization: 12-Factor-App, externalisierte Konfiguration, Health Checks.

Security-Vertiefung

• Supply Chain Security: Signierte Images, SBOMs, Vulnerability Scanning.
• Admission Control und Policy-as-Code.
• Secrets Management mit Vault oder External Secrets.
• Compliance Operator, Audit Logs, FIPS-Anforderungen.
• Tenant Isolation und Netzsegmentierung.

Platform Engineering-Vertiefung

• Golden Paths für Teams.
• Self-Service-Projektanlage.
• Standardisierte Templates und Helm Charts.
• Developer Portal / Backstage / Red Hat Developer Hub.
• SLOs, Error Budgets und Betriebsmetriken.

OpenShift CLI Cheat Sheet

Login und Kontext

oc login --token=<token> --server=<server>
oc whoami
oc project
oc projects
oc config current-context

Ressourcen anzeigen

oc get all
oc get pods -o wide
oc get deploy,rs,svc,route
oc describe pod <pod>
oc explain deployment.spec.template.spec.containers

Logs und Debugging

oc logs <pod>
oc logs deploy/<deployment>
oc logs <pod> --previous
oc get events --sort-by=.lastTimestamp
oc debug pod/<pod>
oc rsh <pod>

Deployments

oc create deployment app --image=<image>
oc expose deployment app --port=8080
oc expose service app
oc scale deployment app --replicas=3
oc rollout status deployment/app
oc rollout history deployment/app
oc rollout undo deployment/app

Konfiguration

oc create configmap app-config --from-literal=KEY=value
oc create secret generic app-secret --from-literal=PASSWORD=change-me
oc set env deployment/app --from=configmap/app-config
oc set env deployment/app --from=secret/app-secret

RBAC

oc auth can-i create pods
oc auth can-i --list
oc get rolebindings
oc adm policy add-role-to-user view <user> -n <project>
oc adm policy remove-role-from-user view <user> -n <project>

Admin-Blick

oc get clusterversion
oc get clusteroperators
oc get nodes
oc adm top nodes
oc adm top pods -A

Selbsttest und Kompetenzmatrix

Kompetenzmatrix

Bewerte dich am Ende jeder Woche von 1 bis 5.

Prüfungsnahe Übungsaufgaben

• Erstelle ein neues Projekt mit Quota und LimitRange.
• Deploye eine App aus einem Image und veröffentliche sie per Route.
• Füge ConfigMap, Secret, Probes und Ressourcenlimits hinzu.
• Erstelle einen ServiceAccount und gib ihm minimale Rechte.
• Beschränke Traffic mit einer NetworkPolicy.
• Simuliere ImagePullBackOff, CrashLoopBackOff und Route-503.
• Rolle ein fehlerhaftes Deployment zurück.
• Automatisiere Build und Deployment.
• Dokumentiere alle Schritte so, dass jemand anderes sie wiederholen kann.

Wann bist du bereit für reale Projekte?

Du bist bereit für ein Teamprojekt, wenn du ohne Spickzettel:

1. Eine App deklarativ deployen kannst.
2. Eine nicht funktionierende Route debuggen kannst.
3. RBAC-Fehler erkennst.
4. Logs, Events und Rollout-History nutzt.
5. Secrets nicht unsicher behandelst.
6. Eine einfache Pipeline oder GitOps-Struktur erklären kannst.

Offizielle Ressourcen und nächste Schritte

Offizielle Ressourcen

• Red Hat OpenShift Container Platform Dokumentation: https://docs.redhat.com/en/documentation/openshift_container_platform/
• OpenShift Tutorials: https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/tutorials/index
• OpenShift CLI Tools: https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/cli_tools/index
• CI/CD Overview: https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html-single/cicd_overview/index
• OpenShift GitOps: https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/gitops/index
• Red Hat Developer Sandbox: https://developers.redhat.com/developer-sandbox
• EX280 OpenShift Administrator Exam: https://www.redhat.com/en/services/training/red-hat-certified-openshift-administrator-exam
• EX288 OpenShift Application Developer Exam: https://www.redhat.com/en/services/training/ex288-red-hat-certified-openshift-application-developer-exam

Empfohlene nächste Schritte

1. Starte mit Woche 1 und erstelle dein persönliches Lern-Repo.
2. Nutze die Developer Sandbox für Developer-Labs.
3. Plane zusätzlich ein Admin-Lab, falls du EX280- oder Platform-Engineering-Ziele hast.
4. Sammle alle Fehlerfälle als Runbook; Troubleshooting ist der wichtigste Lernhebel.
5. Schließe mit dem Capstone ab und präsentiere es wie ein echtes Übergabeprojekt.