So nehmen Sie ein Kubernetes-Cluster vor der Produktion ab

Ein frisch installiertes OpenShift- oder OKD-Cluster begrüßt Sie mit einer Konsole voller Grün. Jeder Operator meldet available, jeder Knoten ist ready, und es ist verlockend, es für fertig zu erklären. Grün sagt Ihnen, dass die Komponenten gestartet sind. Es sagt Ihnen nicht, dass sich ein Volume wiederherstellen lässt, dass der Verkehr den Verlust eines Knotens übersteht oder dass ein Tenant die Secrets eines anderen nicht lesen kann. Das müssen Sie testen, absichtlich, bevor dort irgendetwas läuft, das Ihnen wichtig ist.

Status ist nicht Verhalten

Die Health-Checks eines Clusters sind dafür gebaut zu melden, ob eine Komponente läuft. Die Produktion hängt davon ab, wie sich die Plattform verhält, wenn etwas schiefgeht: Ein Knoten stirbt, eine Platte läuft voll, ein Rolling Update leert einen Knoten, der eine Datenbank trägt. Der einzige Weg, es zu wissen, ist, diese Zustände kontrolliert herbeizuführen und zuzusehen. Der Testplan unten deckt die Ebenen ab, die am meisten zählen. Passen Sie ihn an, aber schreiben Sie Ihren eigenen auf, führen Sie jeden Schritt beim ersten Mal von Hand aus und bewahren Sie die Belege auf.

Storage: anlegen, schreiben, vergrößern, Snapshot, Restore, vergleichen

Stateful Workloads stehen und fallen mit dem Storage. Für jede Storage Class, die Sie anbieten wollen:

oc apply -f test-pvc.yaml
oc rsh <test-pod> sh -c 'dd if=/dev/urandom of=/data/blob bs=1M count=256 && sha256sum /data/blob'
oc patch pvc test-pvc -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'
oc apply -f test-snapshot.yaml
oc apply -f restore-pvc-from-snapshot.yaml
oc rsh <restore-pod> sha256sum /data/blob

Die Prüfsummen müssen übereinstimmen. Bestätigen Sie, dass die Vergrößerung im Pod mit df sichtbar ist, nicht nur im Claim. Für geteilten Read-Write-Many-Storage mounten Sie denselben Claim aus Pods auf zwei verschiedenen Knoten und bestätigen, dass beide die Schreibvorgänge des jeweils anderen sehen. Prüfen Sie dann, was passiert, wenn ein Claim gelöscht wird: Produktionsdaten sollten auf einer Storage Class liegen, deren Reclaim Policy das Volume behält, damit ein versehentliches Löschen es nicht zerstört.

Ausfall: Knoten abschalten und die Wiederherstellung stoppen

Wählen Sie den Knoten, der den laufenden Ingress-Verkehr trägt, und schalten Sie ihn über seinen Management-Controller ab, nicht mit einem höflichen Shutdown. Lassen Sie von außerhalb des Clusters eine Schleife laufen, die jede Anfrage mit einem Zeitstempel versieht:

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code}\n' --max-time 2 https://test-app.example.com/
  sleep 0.2
done

Die Ausgabe zeigt genau, wie lange der Dienst nicht verfügbar war, und das ist die Zahl, die Ihre Nutzer spüren würden. Beobachten Sie dann, was der Orchestrator tut: wie lange, bis der Knoten als not ready markiert ist, ob Pods neu eingeplant werden, ob Stateful Pods mit ihren Daten zurückkommen. Schalten Sie den Knoten wieder ein und bestätigen Sie, dass er sauber wieder beitritt. Wie das Netzwerk vom Ausfall erfährt, zählt hier. Wird die Dienstadresse von jedem Knoten über BGP angekündigt und läuft auf der Netzwerkseite eine schnelle Ausfallerkennung wie BFD, kann der Verkehr in Sekunden von einem toten Knoten wegziehen, lange bevor Kubernetes selbst entschieden hat, dass der Knoten weg ist.

Wartung: beweisen, dass Disruption Budgets das Quorum halten

Rollierende Knotenwartung und Plattform-Updates leeren Knoten einen nach dem anderen. Eine geclusterte Datenbank braucht jederzeit eine Mehrheit laufender Mitglieder, und ein PodDisruptionBudget ist der Weg, das der Plattform mitzuteilen:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: galera-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: galera

Dann testen Sie es. Mit einem Cluster aus drei Mitgliedern und einem bereits ausgefallenen Mitglied (sein Knoten geleert, sodass nur zwei Mitglieder laufen) versuchen Sie, den Knoten eines zweiten Mitglieds zu leeren:

oc adm cordon <node-a>
oc adm drain <node-b> --ignore-daemonsets --delete-emptydir-data
oc get pdb

Der Drain sollte warten statt zu evakuieren, weil das Evakuieren das Quorum brechen würde. Evakuiert er, ist das Budget falsch oder fehlt, und Sie haben es gerade in einem Test herausgefunden statt während eines Updates. Verteilen Sie die Mitglieder mit Topology Spread Constraints oder Anti-Affinity über die Knoten, damit ein einzelner Knotenausfall niemals zwei Mitglieder mitnehmen kann.

Builds und die Registry

Bestätigen Sie, dass das Cluster seine eigenen Images bauen und ausführen kann, denn eine interne Registry, die keinen Push annimmt, wird erst an einem Deploy-Tag entdeckt:

oc new-build --name=smoke --binary --strategy=docker
oc start-build smoke --from-dir=. --follow
oc new-app smoke

Zugriff: testen, was ein Tenant nicht kann

Mandantentrennung definiert sich darüber, was einem Benutzer verweigert wird. Legen Sie pro Tenant einen eingeschränkten Testbenutzer an und prüfen Sie die Grenzen ausdrücklich:

oc auth can-i get secrets -n tenant-b --as=tenant-a-user
oc auth can-i create pods -n tenant-a --as=tenant-a-user
oc auth can-i list nodes --as=tenant-a-user

Die erste und die dritte Antwort müssen nein lauten, die zweite ja. Prüfen Sie, dass Quotas einen Tenant daran hindern, das Cluster aufzubrauchen, dass der Ingress jedes Tenants nur seine eigenen Domains mit gültigem Zertifikat ausliefert und dass der Verkehr, der das Cluster in Richtung Ihrer anderen Systeme verlässt, von der Egress-Identität kommt, die Ihre Firewall erwartet.

Belege aufbewahren

Halten Sie jeden Test mit Befehl, Ausgabe und Ergebnis fest. Wenn sich später etwas ändert, ein Plattform-Update oder eine neue Storage Class, führen Sie den betreffenden Abschnitt erneut aus und vergleichen Sie. Ein Cluster, das seine Tests einmal bestanden hat und nie wieder getestet wurde, wird langsam zu einem ungetesteten Cluster.

Wie wir es machen

Wir bauen OpenShift und OKD auf dedizierten HPE-Servern, mit persistentem Block- und geteiltem Storage im Cluster, öffentlichen Dienstadressen, die von den Knoten über BGP angekündigt werden, und Ingress und Zertifikaten pro Tenant. Bevor ein Cluster eine Kunden-Workload trägt, durchläuft es mehr als dreißig manuelle Prüfungen dieser Art, von Byte-für-Byte-Storage-Restores über erzwungene Ausfälle bis zur Eingrenzung von Zugriffen. In einem Abnahmetest haben wir den Knoten abgeschaltet, der den laufenden Verkehr trug, und das Netzwerk hat in etwa drei Sekunden umgeleitet, lange bevor der Orchestrator den Knoten für verloren erklärte. Geclusterte Datenbanken auf der Plattform werden nach dem obigen Standard gebaut: Disruption Budgets, die das Quorum halten, Storage, der erhalten bleibt, Mitglieder, die über Knoten verteilt sind.

Wenn Sie dabei sind, Produktion auf ein neues Cluster zu legen, und es bisher nur grün gesehen haben, helfen wir Ihnen gern, es vorher richtig zu testen.

Mit einem Ingenieur sprechen

related line: Verwandt: Privates Kubernetes auf Bare Metal, OpenShift und OKD · Bare-Metal-Server auf HPE und Dell · Private Cloud auf KVM mit OLVM

footer line: Veröffentlicht am 22. Oktober 2026. Alle Notizen aus der Praxis