OpenShift ist Kubernetes mit einer Plattform-Schicht darüber. Die API spricht weiterhin Pods, Deployments und Services. Die Alltags-CLI heißt oc, nicht plain kubectl. Wer kubectl kennt, überträgt den Großteil des Wissens. Was sich ändert: Authentifizierung, wie Namespaces als Projekte erscheinen, und OpenShift-spezifische Ressourcen, die früher auftauchen als erwartet.

Dieser Beitrag ist ein praktisches Starter-Kit für oc: Verhältnis zu kubectl, Login und Projekt wählen, Befehle für den Alltag, wann welches Tool passt, und eine Debugging-Reihenfolge ohne Hektik. Kein Versuch, jedes Subkommando zu listen.

oc und kubectl: Verwandte, keine Klone

oc enthält kubectl-kompatible Befehle. Unter der Haube nutzen viele oc-Verben dieselben Client-Bibliotheken wie kubectl. Deshalb fühlt sich oc get pods vertraut an und kubectl-Spickzettel gelten meist weiter.

Die Unterschiede zählen an drei Stellen:

  • Authentifizierung — OpenShift-Cluster erwarten oc login mit Tokens oder Credentials über den Plattform-Identity-Provider. kubeconfig existiert weiter, wird aber meist über Login bezogen statt per Hand editiert.
  • Projekte — OpenShift mappt Projekte auf Kubernetes-Namespaces mit Extra-Metadaten und Default-Policies. oc project ist die Gewohnheit; -n funktioniert bei beiden Tools.
  • Plattform-Ressourcen — Routes, ImageStreams, BuildConfigs, DeploymentConfigs (Legacy) und Templates sind OpenShift-Erweiterungen. kubectl kann einiges lesen, wenn die API exponiert ist; oc hat First-Class-Support und freundlichere Defaults.

Grober Merksatz: oc = kubectl + OpenShift-Login + Plattform-Objekte. Portable Automation nutzt manchmal kubectl mit kubeconfig aus oc login. Am Cluster ist oc der Default.

Prüfen, was läuft:

oc version
oc api-resources | head -20

Zeigt oc version einen Client, erreicht aber keinen Server, liegt das Problem bei Login oder Netz — nicht am Deployment-YAML.

Login, Kontext und Projekt

Vor get oder describe klären, wo die Verbindung hingeht und welches Projekt aktiv ist. OpenShift macht das explizit; wer das überspringt, debuggt am schnellsten die falsche Umgebung.

Anmeldung am Cluster (typischer interaktiver Ablauf):

oc login https://api.cluster.example.com:6443
oc login --token=sha256~YOUR_TOKEN --server=https://api.cluster.example.com:6443

Die erste Form fragt Credentials ab oder öffnet einen Browser-Flow — je nach Cluster-Konfiguration. Die zweite ist üblich in CI und beim Kopieren eines Tokens aus der Web-Konsole.

Nach dem Login Identität und Zugriff prüfen:

oc whoami
oc whoami --show-token=false
oc auth can-i get pods
oc auth can-i create deployments

whoami zeigt, welcher User die Session repräsentiert. auth can-i klärt RBAC ohne Raten aus Forbidden-Fehlern.

Projekte sind die OpenShift-Oberfläche für Namespaces:

oc projects
oc project shop-staging
oc project

oc projects listet Sichtbares. oc project shop-staging wechselt das aktive Projekt für folgende Befehle. Bloßes oc project gibt das aktuelle aus — die Zeile, die lohnt, wenn Ergebnisse keinen Sinn ergeben.

Kubeconfig-Kontext existiert weiter. OpenShift benennt Kontexte oft nach User und Cluster:

oc config current-context
oc config get-contexts
oc config use-context my-user/api-cluster-example-com:6443/shop-staging

Projektwechsel wie Pistenwechsel am selben Flughafen behandeln. Die Abläufe sehen ähnlich aus; der Verkehr ist ein anderer.

Häufige oc-Befehle im Alltag

Der Großteil der Routine wiederholt wenige Verben. Sie spiegeln kubectl, nutzen aber OpenShift-Defaults wo es hilft.

Workloads inspizieren

oc get pods
oc get deploy,svc,route
oc get all
oc get pods -o wide
oc get pods --show-labels

oc get all enthält Routes und manche OpenShift-Typen, die kubectls all-Bundle auslässt. -o wide ergänzt Node und Pod-IP. --show-labels hilft, wenn Services keine Endpoints haben, weil Selektoren abweichen.

Describe und Events

oc describe pod web-7d4f8c9b6-xk2jp
oc describe deployment web
oc describe route web

Events am Ende der describe-Ausgabe bleiben der schnellste Hinweis bei Pending, CrashLoopBackOff und ImagePullBackOff.

Logs und Follow

oc logs deployment/web --tail=100
oc logs deployment/web -f
oc logs web-7d4f8c9b6-xk2jp -c web --previous

--previous liest den zuletzt abgestürzten Container — nützlich, wenn Restarts schon vor dem Terminal-Öffnen passierten.

Apply und Rollouts

oc apply -f deployment.yaml
oc apply -f . --dry-run=server
oc rollout status deployment/web
oc rollout restart deployment/web

rollout restart statt Pods löschen, wenn ein Deployment nur frische Container braucht.

Routes und externer Zugriff

Routes sind der OpenShift-native Weg, HTTP(S)-Services nach außen zu exponieren:

oc get route
oc describe route web
oc expose svc web --hostname=web-shop-staging.apps.cluster.example.com

Ingress gibt es auf vielen OpenShift-Versionen; viele Teams standardisieren am Rand auf Routes für TLS und Hostname-Konventionen.

ImageStreams und Builds (erster Kontakt)

Über Core-Kubernetes hinaus kommen Plattform-Objekte:

oc get imagestream
oc get buildconfig
oc get builds
oc describe buildconfig web

Sie ersetzen kein Verständnis von ImageStreams — sie zeigen, ob ein Build scheiterte, bevor ein Deployment überhaupt einen neuen Tag sah.

Komfort-Wrapper

OpenShift ergänzt Abkürzungen ohne kubectl-Pendant:

oc status
oc get pod -w
oc rsh deployment/web
oc port-forward deployment/web 8080:8080

oc status fasst Projekt-Gesundheit auf einen Blick zusammen — kein Ersatz für describe, aber gute Orientierung. oc rsh öffnet eine Remote-Shell wenn Policy es erlaubt; eher nach Logs und describe, nicht als erster Schritt.

Wann oc, wann kubectl

Beide Tools sprechen mit demselben API-Server bei gültigen Credentials. Die Wahl hängt von Features, Portabilität und Team-Konvention ab.

oc bevorzugen, wenn:

  • Login, Projektwechsel oder OpenShift-spezifische Ressourcen (Routes, ImageStreams, BuildConfigs, Templates) im Spiel sind.
  • oc new-app, oc start-build oder andere für OpenShift dokumentierte Workflows laufen.
  • Runbooks für OpenShift-Betrieb oc login und Projektkontext voraussetzen.
  • oc status, oc rsh oder integrierte Build-Deploy-Helfer genutzt werden.

kubectl bevorzugen, wenn:

  • Skripte unverändert auf Vanilla-Kubernetes und OpenShift laufen sollen.
  • Dritttools explizit kubectl aufrufen.
  • Subtiles Client-Verhalten debuggt wird — manche Edge Cases unterscheiden sich zwischen oc-Wrapper und upstream kubectl.
  • kubeconfig exportiert wurde und oc-spezifische Flags bewusst vermieden werden.

In der Praxis nutzen viele oc interaktiv und kubectl in portabler CI mit derselben kubeconfig. Das ist in Ordnung, solange klar ist, welcher Kontext und Namespace in der Pipeline gilt.

Prüfung, die mit beiden Binaries funktioniert:

kubectl get pods -n shop-staging
oc get pods -n shop-staging

Dieselben Objekte; andere Login-Ergonomie.

Debugging-Workflow auf OpenShift

Die Reihenfolge zählt mehr als das Tool-Label. Wenn in einem Projekt etwas hakt, vermeidet diese Sequenz gesunde Pods neu zu starten oder Logs von Containern zu lesen, die nie starteten.

1. Cluster, User und Projekt bestätigen

oc whoami
oc project
oc cluster-info

Falsches Projekt ist das OpenShift-Äquivalent zum falschen Namespace upstream.

2. Headline-Status

oc get pods
oc get deploy,svc,route
oc status

CrashLoopBackOff, ImagePullBackOff, Pending notieren — und ob Routes für den erwarteten Service existieren.

3. Describe vor Logs

oc describe pod web-7d4f8c9b6-xk2jp
oc describe deployment web

Zuerst Events lesen. Image-Pull-Fehler, Quota-Verletzungen, Probe-Fails und SCC-Ablehnungen stehen oft dort.

4. Builds und Image-Referenzen prüfen

OpenShift-Apps ziehen häufig aus ImageStreams, nicht nur aus öffentlichen Registries:

oc get buildconfig,builds
oc describe buildconfig web
oc get imagestream web -o yaml

Ein Deployment mit ImagePullBackOff kann auf einen fehlgeschlagenen Build oder einen Tag zurückgehen, der nie aktualisiert wurde.

5. Route und Service abstimmen

oc get svc web -o yaml
oc get route web -o yaml
oc get endpoints web

Externe Nutzer treffen Routes; Pods müssen Service-Selektoren erfüllen; Endpoints dürfen nicht leer sein.

6. Logs, wenn der Pod läuft

oc logs deployment/web --tail=200

Direkt zu Logs bei ImagePullBackOff kostet Zeit. describe bei Pending überspringen verpasst Scheduling- und Quota-Events.

7. Plattform-spezifische Ablehnungen

Security Context Constraints und Projekt-Limits erscheinen als klare Events:

oc describe pod web-7d4f8c9b6-xk2jp | grep -i scc
oc describe quota
oc describe limitrange

Starten Pods nie und Events erwähnen SCC oder verbotene Capabilities, liegt die Lösung bei Policy oder Pod-Spec — nicht bei einem weiteren Rollout-Restart.

Kleine Gewohnheiten, die sich summieren

  • oc whoami und oc project zu Beginn eines Incidents — ins Ticket kopieren.
  • Explizites -n in Runbooks, auch wenn das Projekt gesetzt ist; Copy-Paste soll nicht aus Versehen Production treffen.
  • oc describe statt Pods neu starten, wenn Events den Fehler erklären.
  • BuildConfigs und ImageStreams prüfen, wenn Image-Tags veraltet wirken oder Pulls auf interne Namen scheitern.
  • oc auth can-i vor dem Beschuldigen des Anwendungscodes bei Forbidden-Fehlern.
  • kubeconfig für Automation erst exportieren, wenn Kontext und Namespace in der Pipeline-Konfiguration stimmen.

Abschluss

oc ist kein anderes Kubernetes — dieselbe API mit OpenShift-Login, Projekten und Plattform-Ressourcen. Fluency in wenigen Verben zählt mehr als jedes Flag auswendig zu kennen. Wer schnell ankommt, ist selten der mit dem längsten Befehl zuerst. Es sind die, die Projekt und User bestätigen, Events lesen bevor etwas neu gestartet wird, und wissen, wann ein fehlgeschlagener Build erklärt, warum ein Deployment nie vorwärts rollte. Diese Reihenfolge früh aufbauen; Routes und ImageStreams werden Teil der Story statt Überraschungen.