Voraussetzung: ein laufender Cluster und
oc login – SNO-Aufbau in
OKD Single-Node auf Hetzner,
der Bibliothek-Deploy in
Bibliothek via Jenkins auf OKD.
Die Konsole erreichst du unter console-openshift-console.apps.<cluster>.
Das Modell: drei Schichten
Konfiguration liegt nicht an einem Ort. Bevor du suchst, hilft es zu wissen, welche Schicht du gerade meinst.
values.yaml, env/okd-values.yaml), GitOps-Manifeste. Liegt in Git, versioniert, reviewbar.helm upgrade oder Argo rendert die Schablone → ConfigMap, Secret, Deployment entstehen als echte Objekte, mit den Werten des passenden Overlays.etcd hält die Objekte, der Pod liest sie beim Start als env (eingefroren) oder als Datei-Mount (nach ~1 min live). Eine Änderung rollt den Pod nicht von selbst.Praktisch heisst das: den Wert ändern → im Git-Repo (Quelle). Sehen, was der Cluster gerade benutzt → das Objekt im Namespace (Wirkung). Und zwischen beidem steht der Deploy, der aus dem einen das andere macht.
1 Die zwei Perspektiven
Oben links im Konsolen-Menü steht ein Umschalter. Er ändert nur, welche Menüs du siehst – nicht deine Rechte.
| Perspektive | zeigt | wann |
|---|---|---|
| Administrator | alle Ressourcen nach Art gruppiert: Workloads, Networking, Storage, Builds, Observe, Compute, Administration, Operators | der DevOps-Alltag – nachschauen, konfigurieren, debuggen |
| Developer | die App-Sicht: Topology (Karte einer Anwendung), Helm-Releases, Builds, eine schlanke Ansicht je Projekt | schneller Überblick über eine Anwendung, der Topology-Graph, Helm-Werte |
Das Project (= Namespace) wählst du immer oben in der Leiste, z. B.
library. In der CLI ist das oc project library bzw. das -n library
an jedem Befehl.
2 Die Landkarte der Konsole
Administrator-Perspektive, das linke Menü von oben nach unten – was wo steckt.
| Menü | was drin ist |
|---|---|
| Home | Overview (Cluster-Gesundheit auf einen Blick), Projects, Search (jede Ressourcenart, über alle Namespaces, mit Label-Filter), API Explorer, Events |
| Workloads | Deployments, Pods, DeploymentConfigs, ConfigMaps, Secrets, Jobs, CronJobs, HPAs – hier liegt die App-Konfiguration |
| Networking | Services (interne Adresse), Routes (externe URL), Ingresses, NetworkPolicies |
| Storage | PersistentVolumeClaims, PersistentVolumes, StorageClasses (welche ist Default), VolumeSnapshots |
| Builds | BuildConfigs, Builds, ImageStreams – die OpenShift-eigene Build-Kette |
| Observe | Alerting, Metrics (PromQL-Eingabe), Dashboards, Targets (up/down), und der Logs-View, wenn Logging installiert ist |
| Compute | Nodes, MachineConfigs, MachineConfigPools – die Nodes-Konfiguration |
| Operators | OperatorHub (installieren) und Installed Operators (Konfiguration = die CR-Reiter des Operators) |
| Administration | Cluster Settings (Version, Update-Channel, und der Reiter Configuration = die Config-API), Namespaces, RoleBindings, ResourceQuotas, CustomResourceDefinitions |
3 Eine App im Blick behalten
Developer-Perspektive → Topology: jeder Kreis ist ein
Deployment, Linien sind Verbindungen, der kleine Pfeil oben rechts öffnet die
Route. Für die Bibliothek siehst du hier library-frontend, api-gateway,
die acht Fachdienste, config-server.
Ein Klick auf einen Kreis → das Deployment. Oder Administrator → Workloads →
Deployments → catalog-service. Die Reiter oben:
| Reiter | zeigt | oc-Entsprechung |
|---|---|---|
| Details | Replicas, Strategie, Labels, Selektor, Status | oc get deploy/catalog-service -n library |
| YAML | die volle Wahrheit, editierbar | oc get deploy/catalog-service -n library -o yaml |
| Environment | alle env-Variablen – welche literal, welche aus ConfigMap/Secret (anklickbar) | oc set env deploy/catalog-service -n library --list |
| Pods | die laufenden Pods, ihr Status, Restart-Zähler | oc get pods -n library -l app=catalog-service |
| Logs | stdout/stderr des Pods, Container wählbar, live oder mit Zeitfenster | oc logs -f deploy/catalog-service -n library |
| Events | was der Scheduler/kubelet zuletzt gemacht hat – hier steht der Grund für „Pending“ oder „CrashLoopBackOff“ | oc get events -n library --sort-by=.lastTimestamp |
| Terminal | eine Shell im Container | oc rsh deploy/catalog-service -n library |
| Metrics | CPU/RAM/Netz des Deployments (wenn Monitoring läuft) | – (Observe → Metrics mit PromQL) |
4 App-Konfiguration nachschauen
Die Kernfrage: wo liegt das DB-Passwort, der Endpunkt, die Einstellung –
und wie schaue ich rein. Immer Konsole und oc. Beispiel-Namespace
library.
| was du suchst | wo es liegt | Konsole | oc |
|---|---|---|---|
App-Einstellung (nicht geheim), das Frontend-env.js | ConfigMap im Namespace | Workloads → ConfigMaps → anklicken (Data steht im Klartext) | oc get cm -n libraryoc get cm/<name> -n library -o yaml |
| DB-Passwort, Keycloak-Client-Secret, Pull-Secret | Secret im Namespace | Workloads → Secrets → anklicken → Reveal values | oc extract secret/<name> -n library --to=- |
| welche DB-URL / welchen Endpunkt ein Dienst benutzt | env im Deployment, oft valueFrom einer ConfigMap/Secret | Deployments → <dienst> → Reiter Environment | oc set env deploy/<dienst> -n library --list |
| interne Adresse (Endpunkt im Cluster) | Service (ClusterIP). DNS: <svc>.library.svc.cluster.local, aus demselben Namespace reicht <svc> | Networking → Services → <svc> | oc get svc -n library |
| externe URL (Endpunkt von aussen) | Route | Networking → Routes → Spalte Location (anklickbar) | oc get route -n library |
| was der Helm-Chart wirklich gesetzt hat | im Helm-Release-Secret sh.helm.release.v1.<name>.<rev> | Developer → Helm → Releases → <release> → Values / Resources / Revision history | helm get values <release> -n libraryhelm get manifest <release> -n library |
Frontend-Runtime-Config (window.__env) | ConfigMap, als env.js in den nginx-Pod gemountet | Workloads → ConfigMaps → library-frontend-env | oc get cm library-frontend-env -n library -o yaml |
| Keycloak-Realm, OIDC-Client-Secrets | in Keycloak, nicht in OpenShift-Objekten (ausser der Realm kommt per Import-ConfigMap) | die Keycloak-Route öffnen → Admin-Konsole → Realm library → Clients → Credentials | – (Keycloaks eigenes DB-Passwort: oc get secret keycloak-postgresql -n library) |
Merke: der Environment-Reiter des Deployments ist fast immer
der schnellste Weg. Er zeigt in einer Ansicht, welche Werte literal drinstehen und
welche aus welcher ConfigMap oder welchem Secret kommen – und jeder valueFrom
ist ein Link direkt zum Objekt.
5 Cluster-Konfiguration nachschauen
Nicht im Namespace, sondern am Cluster: Auth, Ingress, die interne Registry, Node-Einstellungen, Operator-Konfiguration.
| was | Konsole | oc |
|---|---|---|
| Auth / OAuth / Identity Provider, Ingress, Image, Proxy, APIServer, Console | Administration → Cluster Settings → Reiter Configuration → die Kachel | oc get authentication cluster -o yamloc get ingresses.config cluster -o yaml |
| Cluster-Version, Update-Channel, Update-Status | Administration → Cluster Settings → Details | oc get clusterversion |
| Node-Config: chrony, Kernel-Argumente, zusätzliche CA-Zertifikate | Compute → MachineConfigs (gerendert + Quelle), Compute → MachineConfigPools (Rollout-Stand) | oc get mc · oc get mcp |
| pro Node: Labels, Taints, Kapazität | Compute → Nodes → <node> | oc describe node <name> |
| Operator-Konfiguration (z. B. LokiStack, ServiceMeshControlPlane) | Operators → Installed Operators → <operator> → der CR-Reiter | oc get <cr> -n <ns> -o yaml |
| StorageClasses (welche ist Default, Provisioner, Reclaim-Policy) | Storage → StorageClasses | oc get sc |
| Netz (Cluster-/Service-CIDR, CNI) | Cluster Settings → Configuration → Network | oc get network cluster -o yaml |
| Gesundheit der Kern-Operatoren | Administration → Cluster Settings → ClusterOperators | oc get co |
Die Config-API ist der Kern: Objekte wie authentication,
ingress, image, proxy heissen alle cluster
(Singleton) und liegen unter der API-Gruppe config.openshift.io. Was du in
„Cluster Settings → Configuration“ klickst, ist genau das.
6 Ein CrashLoopBackOff nachvollziehen
Ein Pod startet nicht. So gehst du in der Konsole vor – in dieser Reihenfolge.
Back-off restarting failed container, ist es die App. Steht dort FailedScheduling oder FailedMount, ist es Infrastruktur.env oder ein Secret. Deployment → Environment: zeigt eine Variable CreateContainerConfigError? Dann fehlt das referenzierte Secret (siehe Abschnitt 4).readinessProbe/livenessProbe. Ein zu kurzes initialDelaySeconds killt eine App mit langsamem Kaltstart, bevor sie oben ist.oc get co. Ist ingress, authentication oder image-registry Degraded?Auf der SNO nach sno.ps1 up: hängt image-registry an einer alten
Leader-Lease. Der Post-up-Hook (sno-wsl.sh remediate) räumt das,
manuell wäre es oc -n openshift-image-registry delete lease openshift-master-controllers
plus oc -n openshift-image-registry rollout restart deployment/cluster-image-registry-operator.
7 Der Secret-Klartext-Hinweis
Die Konsole dekodiert Secret-Werte und zeigt sie im Klartext – für
jeden mit get secret-Recht. Das haben die ClusterRoles admin und
edit, nicht view. „Reveal values“ ist
kein Sicherheitsschalter, nur eine UI-Anzeige.
Deshalb funktioniert „DB-Passwort im Dashboard nachschauen“
– und deshalb sind Kubernetes-Secrets auch keine Verschlüsselung:
was in etcd liegt, ist per Default nur base64. Echte Verschlüsselung at-rest
ist ein Cluster-Schalter (Diagramm B9 im Atlas). Wer die Werte nicht sehen soll, bekommt
view statt edit.
8 Wo die Konsole aufhört
Die Konsole ist gut zum Nachschauen und für einzelne Änderungen.
Für diese Dinge nimmst du oc:
| Aufgabe | warum CLI |
|---|---|
| etwas an vielen Objekten gleichzeitig ändern | die Konsole editiert eins nach dem anderen |
| reproduzierbare Änderung (in Git, in einem Skript) | oc apply -f / oc patch ist versionierbar, ein Konsolen-Klick nicht |
| vorher sehen, was passiert | oc diff -f / --dry-run=server |
| auf den Node | oc debug node/<name> → chroot /host (RHCOS/SCOS ist unveränderlich, kein SSH-Editieren) |
| Logs mehrerer Pods gleichzeitig, mit Filter | oc logs -l app=… --all-containers --tail=…, stern |
| ein Objekt exportieren, um es woanders anzulegen | oc get … -o yaml, Felder wie status und metadata.uid wegputzen |
+ Mehrere Umgebungen
Wie man Dev / Test / QS / Prod trennt – und wie dieses Projekt es macht.
| so trennt man richtig | dieses Projekt |
|---|---|
| Namespace-pro-Stufe (ein Cluster) oder Cluster-pro-Stufe (echte Trennung) | ein Namespace library auf einer SNO |
ein Helm-Values-Overlay je Stufe: values-test.yaml, values-prod.yaml | ein Overlay: infra/helm/values/env/okd-values.yaml |
| GitOps: eine Argo-Application je Stufe, gleicher Chart | Jenkins deployt direkt mit helm upgrade je Dienst (GitOps ist Atlas-Block E) |
| Promotion = denselben Chart mit dem nächsten Overlay deployen, der auslösende Wert (Bild-Tag) ändert sich in Git | lokal (Spring dev, H2) → CRC (volles OpenShift lokal) → SNO (die Demo-Prod) |
Was sich je Stufe ändert: DB-Host, Replica-Zahl, Ressourcen-Limits, Log-Level,
Feature-Flags. Was gleich bleibt: der Chart, die Image-Digest, die App-Logik. Der Weg zu vier
echten Stufen wäre je Stufe ein values-<stufe>.yaml plus ein eigener
Namespace – die Mechanik (ConfigMap, Secret, Helm) bleibt dieselbe, nur mehr davon.
+ Alles auf einmal: Search & API Explorer
| Werkzeug | wofür |
|---|---|
| Home → Search | eine Ressourcenart wählen (Secret, ConfigMap, Route…), über alle Namespaces, mit Label-Filter. oc get secret --all-namespaces -l app=library |
| Home → API Explorer | jede Ressourcenart im Cluster durchblättern, ihr Schema sehen, Instanzen listen. Gut, um herauszufinden wie eine CRD heisst. |
| jede Ressource → Reiter YAML | die volle, ungefilterte Wahrheit – und editierbar. Der Details-Reiter ist die freundliche Zusammenfassung derselben Daten. |
jede Ressource → Events / YAML → status | was der Controller gerade tut und warum – status.conditions ist fast immer die Antwort auf „warum ist das so“ |