Ein Single-Node-Cluster in der Produktion ist ein Einzelserver mit mehr Komplexität

Ganz ehrlich: Für mich ist ein Kubernetes-Cluster mit nur einem Node ein Entwicklungswerkzeug. Wann immer es geht, tendiere ich in Produktion zu mindestens drei Nodes. Wer trotzdem mit einem Node startet, hat im Kern einen einzelnen Server, nur mit mehr Schichten obendrauf.

Produktionsreif heißt nicht ausfallsicher

In k3s-Diskussionen taucht ein Argument auf, dem ich nicht widerspreche: k3s mit einem Node sei nicht weniger produktionsreif, HA sei eine Frage der Anforderung. An der Software liegt es auch nicht.

Aber wer k3s mit einem Node aufsetzt, muss sich im Klaren sein, dass es nicht ausfallsicher ist. Das ist das Entscheidende. Software-Reife und Ausfallsicherheit sind zwei verschiedene Dinge, und beim einzelnen Node fehlt die zweite.

Der Node ist der Korb

Auf dem einen Node läuft alles: Control Plane, Anwendung, Datenbank. Fällt er aus, steht das Cluster.

Stürzt ein Container ab, startet der kubelet ihn neu. Das klappt auch allein. Aber Kubernetes verschiebt keine Pods, es legt sie über einen Controller neu an, und dafür braucht es einen zweiten Node. Drei Replicas auf demselben Node sind drei Eier im selben Korb.

Radiologische Praxen mit einem Node

Ich habe ein Unternehmen geschult, das Single-Node-Cluster bei seinen Kunden einsetzt: radiologische Praxen. Es hat den Praxen gesagt, dass ein kleineres Cluster weniger kostet, dafür aber nicht ausfallsicher ist.

Das ist ehrlich, und genau das ist die Bedingung. Ein einzelner Node ist eine seltene Ausnahme, und der Kunde muss ausdrücklich wissen, dass er nicht ausfallsicher ist. Dann hat er gekauft, was er bekommt, und niemand wird überrascht.

Wie es dort im Ernstfall läuft, weiß ich nicht. Gut gehen kann es trotzdem, aber das merkt man erst, wenn der Node weg ist.

Warum ich zu drei Nodes tendiere

Zwei Kumpels und eine Abstimmung: Solange beide da sind, geht es. Fällt einer aus, hat der andere keine Mehrheit, und es entscheidet keiner mehr. Mit drei reichen zwei.

Genau so arbeitet etcd, der Datenspeicher der Control Plane. Bei drei Mitgliedern darf eines ausfallen. Bei einem oder zwei Mitgliedern darf keines ausfallen. Die Kubernetes-Doku zur Hochverfügbarkeit mit kubeadm nennt deshalb drei oder mehr Control-Plane-Maschinen.

Zwei Mitglieder sind kein halber Schritt dahin. Du hast dann doppelt so viele Maschinen, die ausfallen können, und verkraftest trotzdem keinen Ausfall.

Wann ein Node doch reicht

Ein Node reicht, wenn du den Desaster-Fall wirklich durchgespielt hast. Die Wiederherstellung muss sitzen: durchgetestet, und entweder weitgehend automatisiert oder sehr stringent manuell, mit einer Anleitung, die dein müdester Kollege nachts um drei noch abarbeiten kann.

Dazu brauchst du zwei Zahlen schwarz auf weiß: die Reaktionszeit und die maximale Zeit, bis das Cluster wieder im Ready-Zustand ist. Wer die nicht aufschreiben kann, hat kein Backup-Konzept, sondern eine Hoffnung.

Meine klare Ansage

Entwicklung, Test, Lernen: ein Node, gerne. Produktion: wann immer möglich mindestens drei. Wer in Produktion trotzdem mit einem Node startet, braucht zwei Dinge: Er weiß, dass das Cluster nicht ausfallsicher ist, und er hat die Wiederherstellung durchgetestet und dokumentiert.

Wie du ein Cluster mit mehreren Nodes sauber aufbaust und betreibst, üben wir im Training “Kubernetes Advanced” am Live-Cluster.