Читать книгу Kubernetes - Kelsey Hightower - Страница 11

Container und Kubernetes unterstützen Entwickler dabei, verteilte Systeme zu bauen, die sich an den Prinzipien der immutablen Infrastruktur orientieren. Bei einer solchen immutablen (unveränderlichen) Infrastruktur ändert sich ein Artefakt, sobald es einmal im System erzeugt wurde, nicht mehr durch die Anwender.

Klassisch wurden Computer- und Software-Systeme als mutable (änderbare) Infrastruktur betrachtet. Dabei werden Änderungen als inkrementelle Updates auf ein bestehendes System angewendet. Diese Updates können alle auf einmal vorgenommen werden oder auf einen langen Zeitraum verteilt sein. Ein System-Upgrade per apt-get update ist ein gutes Beispiel für ein Update eines mutablen Systems. Durch die Ausführung von apt werden nacheinander aktualisierte Binaries heruntergeladen, über die ältere Binaries kopiert und inkrementelle Anpassungen an Konfigurationsdateien vorgenommen werden. Bei einem mutablen System ist der aktuelle Status der Infrastruktur nicht als einzelnes Artefakt repräsentiert, sondern als Ansammlung inkrementeller Updates und Änderungen. Bei vielen Systemen kommen diese inkrementellen Updates nicht nur durch System-Updates zustande, sondern auch über Eingriffe durch den Nutzer. Zudem ist es in jedem von einem großen Team betreuten System sehr wahrscheinlich, dass diese Änderungen von vielen verschiedenen Leuten vorgenommen werden und sehr gerne nirgendwo dokumentiert wurden.

Im Gegensatz dazu wird bei einem immutablen System nicht eine Folge inkrementeller Updates und Änderungen angewendet, sondern es wird ein neues, vollständiges Image gebaut, und beim Update in einem einzigen Schritt das gesamte alte Image durch das neue ersetzt. Es gibt keine inkrementellen Änderungen. Wie Sie sich vorstellen können, ist das ein deutlicher Unterschied zum eher klassischen Wert des Konfigurations-Managements.

Um das in der Welt der Container konkreter zu machen, schauen Sie sich diese beiden verschiedenen Wege an, Ihre Software zu aktualisieren:

1 Sie können sich an einem Container anmelden, einen Befehl ausführen, um Ihre neue Software herunterzuladen, den alten Server abschießen und den neuen starten.

2 Sie können ein neues Container-Image bauen, es in eine Container-Registry schieben, den bestehenden Container abschießen und einen neuen starten.

Auf den ersten Blick mögen diese beiden Ansätze kaum unterscheidbar sein. Warum sorgt dann das Bauen eines neuen Containers für eine verbesserte Zuverlässigkeit?

Der entscheidende Unterschied ist das Artefakt, das Sie erstellen, und die Aufzeichnung, die beim Erstellen entsteht. Diese Aufzeichnung erleichtert es, die exakten Unterschiede in einer neuen Version zu verstehen. Geht etwas schief, können Sie herausfinden, was sich geändert hat und wie sich das korrigieren lässt.

Zudem sorgt das Bauen eines neuen Images statt des Anpassens eines bestehenden dafür, dass das alte Image immer noch verfügbar ist, sodass Sie dieses für ein Rollback nutzen können, wenn ein Fehler auftritt. Haben Sie im Gegensatz dazu Ihr neues Binary über ein bestehendes kopiert, ist solch ein Rollback nahezu unmöglich.

Immutable Container-Images bilden den Kern von allem, was Sie in Kubernetes bauen. Es ist möglich, im Notfall laufende Container anzupassen, aber das ist ein Antipattern, das nur in extremen Fällen eingesetzt werden sollte, wenn es keine anderen Optionen gibt (zum Beispiel, wenn es die einzige Möglichkeit ist, ein unternehmenskritisches Produktiv-System kurzfristig zu reparieren). Und selbst dann müssen die Änderungen später über ein deklaratives Konfigurations-Update dokumentiert werden, nachdem der Brand gelöscht wurde.