Cluster-Betrieb in OpenShift

1 oc get co lesen

Jede Kern-Fähigkeit – auth, ingress, dns, image-registry, monitoring, network, etcd, kube-apiserver… – ist ein ClusterOperator-Objekt, rund 30 Stück, verwaltet vom Cluster Version Operator.

oc get co
oc get co -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="Available")].status}{"\t"}{.status.conditions[?(@.type=="Degraded")].status}{"\n"}{end}'

2 Einen kaputten ClusterOperator debuggen

Hier fängt jede „der Cluster fühlt sich komisch an“-Untersuchung an.

# wer ist nicht True/False/False?
oc get co | grep -v "True.*False.*False"

# die message lesen:
oc describe co image-registry

# dann in den Related-Objects-Namespace:
oc get pods -n openshift-image-registry
oc logs deployment/cluster-image-registry-operator -n openshift-image-registry --tail=50
oc get events -n openshift-image-registry --sort-by=.lastTimestamp | tail -20

Alarme zum selben Zustand landen im Alertmanager: ClusterOperatorDown / ClusterOperatorDegraded (Schritt 3).

3 Der Monitoring-Stack

Zwei getrennte Stacks: Plattform-Monitoring (immer an) und User-Workload-Monitoring (opt-in).

cat <<'YAML' | oc apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true
YAML

oc get pods -n openshift-user-workload-monitoring -w

4 Einen ServiceMonitor live anlegen

Anmelden bei Prometheus, dann eine eigene Alarmregel.

oc create deployment demo-metrics -n library --image=registry.access.redhat.com/ubi9/httpd-24
oc expose deployment demo-metrics -n library --port=8080

cat <<'YAML' | oc apply -f -
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: demo-metrics
  namespace: library
spec:
  selector:
    matchLabels: { app: demo-metrics }
  endpoints:
    - port: 8080-tcp
      path: /metrics
      interval: 30s
YAML

cat <<'YAML' | oc apply -f -
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: demo-metrics-alerts
  namespace: library
spec:
  groups:
    - name: demo.rules
      rules:
        - alert: DemoTargetDown
          expr: up{job="demo-metrics"} == 0
          for: 5m
          labels: { severity: warning }
          annotations: { summary: "demo-metrics antwortet nicht" }
YAML

oc get servicemonitor,prometheusrule -n library

Im Konsolen-Tab Observe: Metrics (PromQL), Alerts (+ Silences), Dashboards, Targets (up/down – genau hier sieht man, ob der ServiceMonitor wirklich scrapt). Rechte dafür: die Rolle monitoring-edit im Namespace. Merksatz: ServiceMonitor = „scrap diese Pods“, PrometheusRule = „alarmiere bei diesem Ausdruck“.

5 Storage: PVC, StorageClass, RWO/RWX

Ein PersistentVolumeClaim ist der Antrag, eine StorageClass die clusterweite Vorlage.

volumeBindingMode: WaitForFirstConsumer wartet, bis der Pod geschedult ist – sonst landet das PV in der falschen Zone und der Pod scheduled nie (B6). reclaimPolicy: Delete löscht das PV mit dem PVC, Retain behält es (Released) für manuelle Rettung.

6 Ein PVC anlegen und binden sehen

Ein Deployment mit zwei Replicas an einem RWO-PVC – und live sehen, warum nur ein Pod läuft.

cat <<'YAML' | oc apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-data
  namespace: library
spec:
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 1Gi } }
YAML

oc get pvc demo-data -n library -w
# Pending -> Bound (mit WaitForFirstConsumer erst, sobald ein Pod ihn nutzt)

oc get pv $(oc get pvc demo-data -n library -o jsonpath='{.spec.volumeName}')

PVC vergrössern geht nur grösser, nie kleiner, und nur bei allowVolumeExpansion: true an der StorageClass. VolumeSnapshot/VolumeSnapshotClass sind die Basis für Point-in-Time-Kopien (Velero-Backups, E4).

7 Cluster-Upgrades

Ein Upgrade ist ein Release-Image – der Cluster Version Operator (CVO) gleicht den Cluster darauf ab: erst die ClusterOperatoren in Abhängigkeitsreihenfolge, dann die Nodes (G4).

oc get clusterversion
oc adm upgrade
# zeigt aktuelle Version und verfuegbare Ziele
oc adm upgrade --to=4.16.7
oc get clusterversion -w

Vorbedingung: kein ClusterOperator Degraded (Schritt 1), sonst blockiert der CVO. admin-acks bestätigen für bekannte Breaking Changes zwischen Minors, deprecated APIs vorher prüfen. Kein Rollback – nur vorwärts. Nach dem Start nicht abbrechen, ein halb-upgradeter Cluster ist der schlechteste Zustand.

OCP-Unterschied: OCP hat Subscription-Channels und den OpenShift Update Service (disconnected). OKD nutzt community-gepflegte Update-Graphen. etcd-Backup vorher (G7).

8 Typische Fallen

9 Wie die Bibliothek es macht

Fehlschlag-Reflex: schlägt ein helm upgrade mit wirren Fehlern fehl, ist der erste Blick oc get co – ist ingress oder authentication Degraded, weil der Cluster nach einem sno.ps1 up noch nicht ganz durch ist?

+ Die Kurzfassung