Kubernetes-Nodes automatisiert bereitstellen: Was gute Templates leisten müssen

Automatisierte Kubernetes-Bereitstellungen beginnen bereits beim VM- oder Node-Template. Nur wenn die Vorlage aktuell, sicher, bereinigt und korrekt vorbereitet ist, können neue Nodes zuverlässig und reproduzierbar erstellt werden. Der Beitrag zeigt, welche Rolle dabei cloud-init, Gast-Agenten und Werkzeuge wie Packer, Terraform oder Ansible spielen. Außerdem wird erklärt, warum automatisierte und versionierte Template-Builds langfristig stabiler sind als manuell gepflegte Golden Images. Die wichtigste Regel lautet: So generisch wie möglich, so plattformspezifisch wie nötig.

---

Kubernetes-Cluster lassen sich heute weitgehend automatisiert bereitstellen. Werkzeuge wie Rancher, Terraform oder Plattform-Automatisierung übernehmen viele Schritte, die früher manuell durchgeführt wurden: virtuelle Maschinen erstellen, Rollen verteilen, Kubernetes installieren und neue Nodes in einen Cluster aufnehmen.

Damit diese Automatisierung zuverlässig funktioniert, braucht es jedoch eine saubere Grundlage. Diese Grundlage entsteht nicht erst im Kubernetes-Cluster selbst, sondern bereits davor: beim VM- oder Node-Template.

Ein gutes Template sorgt dafür, dass neue Kubernetes-Nodes einheitlich, reproduzierbar und sicher bereitgestellt werden können. Ein schlechtes Template dagegen vervielfältigt Fehler nur schneller.

Warum Templates für Kubernetes so wichtig sind

Ein Kubernetes-Cluster besteht aus mehreren Nodes. Einige Nodes übernehmen Aufgaben der Control Plane, andere stellen als Worker Nodes die eigentlichen Anwendungen bereit. In produktiven Umgebungen sollen diese Systeme möglichst einheitlich, nachvollziehbar und automatisiert entstehen.

In der Praxis wird dafür häufig ein vorbereitetes VM-Template verwendet. Aus diesem Template werden später neue virtuelle Maschinen geklont, die anschließend als Kubernetes-Nodes genutzt werden.

Der Vorteil liegt auf der Hand: Wenn die Vorlage sauber vorbereitet ist, kann jeder neue Node mit derselben technischen Basis starten. Betriebssystem, Grundkonfiguration, Paketstand, Initialisierung und Sicherheitsvorgaben sind dann nicht vom Zufall oder von manuellen Einzelschritten abhängig.

Gerade bei Kubernetes ist das wichtig. Cluster werden erweitert, ersetzt, aktualisiert oder neu aufgebaut. Je reproduzierbarer die Nodes bereitgestellt werden können, desto einfacher werden Betrieb, Skalierung und Fehleranalyse.

Automatisierung beginnt vor dem eigentlichen Deployment

Oft wird beim Thema Kubernetes-Automatisierung zuerst an Rancher, GitOps, Helm, Terraform oder CI/CD gedacht. Diese Werkzeuge sind wichtig, setzen aber auf einer tieferen Ebene auf: der Infrastruktur und dem Betriebssystem.

Wenn ein Template veraltet, unsauber oder nicht korrekt vorbereitet ist, kann auch das beste Deployment-Werkzeug nur begrenzt helfen. Typische Probleme sind zum Beispiel:

• nicht zurückgesetzte SSH-Hostkeys
• doppelte Machine-IDs
• fehlerhafte oder unvollständige cloud-init-Konfiguration
• fehlende Gast-Agenten oder unvollständige Plattformintegration
• unterschiedliche Paketstände
• manuell angelegte Testbenutzer
• alte Logdateien oder Build-Artefakte
• feste Netzwerkkonfigurationen, die beim Klonen stören
• fehlende NTP- oder DNS-Konfiguration

Ein Template sollte deshalb nicht als einmalig manuell erstelltes „Golden Image“ verstanden werden. Besser ist ein reproduzierbarer Build-Prozess, bei dem klar dokumentiert ist, wie das Template entstanden ist, welche Version verwendet wird und welche technischen Anforderungen erfüllt sind.

Was ist mit einem Kubernetes-Node-Template gemeint?

Mit einem Kubernetes-Node-Template ist in diesem Zusammenhang keine Kubernetes-YAML-Datei gemeint. Gemeint ist eine vorbereitete Betriebssystem- oder VM-Vorlage, aus der später Kubernetes-Nodes entstehen.

Dieses Template enthält die technische Basis, zum Beispiel:

• ein unterstütztes Linux-Betriebssystem
• aktuelle Sicherheitsupdates
• cloud-init für die Initialisierung beim ersten Start
• einen passenden Gast-Agenten für die Integration in die jeweilige Virtualisierungsplattform
• grundlegende Netzwerk- und Zeitsynchronisation
• vorbereitete Benutzer- und SSH-Konfiguration
• notwendige Pakete und Dienste
• Cleanup-Schritte für das spätere Klonen
• eine eindeutige Versionierung

Das Template sollte so allgemein wie möglich bleiben und gleichzeitig alles enthalten, was für die spätere Automatisierung erforderlich ist. Konkrete Werte wie Hostname, IP-Adresse oder SSH-Schlüssel sollten nicht fest im Template stehen, sondern beim ersten Start über Mechanismen wie cloud-init gesetzt werden.

Die Rolle von cloud-init

cloud-init ist einer der wichtigsten Bausteine bei automatisiert bereitgestellten Linux-VMs. Es wird beim ersten Start einer Instanz ausgeführt und kann dabei systemspezifische Einstellungen übernehmen.

Dazu gehören unter anderem:

• Hostname setzen
• Benutzer anlegen
• SSH-Keys hinterlegen
• Pakete installieren
• Dateien erzeugen
• Befehle beim ersten Start ausführen
• Netzwerk- und Systemparameter übernehmen

Gerade in automatisierten Deployment-Prozessen ist cloud-init entscheidend. Eine Virtualisierungsplattform oder ein Management-Werkzeug kann eine neue VM aus einem Template erstellen. Damit daraus aber ein individueller Kubernetes-Node wird, muss die VM beim ersten Start korrekt initialisiert werden.

Ohne funktionierendes cloud-init ist ein VM-Template für automatisierte Kubernetes-Deployments nur eingeschränkt nutzbar. Die VM kann zwar geklont werden, aber sie ist danach nicht automatisch korrekt personalisiert.

Ein gutes Kubernetes-Node-Template sollte deshalb cloud-init nicht nur installiert haben. Es muss auch sauber vorbereitet sein. Dazu gehört, dass alte cloud-init-Zustände entfernt werden, bevor die VM als Template gespeichert wird. Nur so wird sichergestellt, dass cloud-init beim ersten Start des neuen Nodes erneut korrekt ausgeführt wird.

Manuelles Golden Image oder automatischer Template-Build?

Viele Umgebungen starten mit einem manuell gebauten Golden Image. Dabei wird eine VM installiert, angepasst, bereinigt und anschließend als Template gespeichert. Für erste Tests kann das funktionieren.

Langfristig hat dieser Ansatz aber Nachteile:

• Änderungen sind schwer nachvollziehbar.
• Der genaue Build-Stand ist oft unklar.
• Manuelle Schritte lassen sich schlecht wiederholen.
• Fehler werden erst spät sichtbar.
• Updates und Anpassungen sind aufwendig.
• Es besteht die Gefahr, dass Altlasten im Template bleiben.
• Sicherheitslücken werden nicht konsequent geschlossen.

Besser ist ein automatisierter Template-Build. Dabei wird das Template aus definierten Quellen und Skripten erzeugt. Jede Änderung kann dokumentiert, versioniert und bei Bedarf erneut ausgeführt werden.

Ein typischer automatisierter Build-Prozess kann so aussehen:

1. Betriebssystem-ISO oder Basis-Image auswählen
2. Installation unbeaufsichtigt durchführen
3. Updates installieren
4. notwendige Pakete ergänzen
5. cloud-init und Gast-Agent vorbereiten
6. Sicherheitskonfiguration setzen
7. Cleanup durchführen
8. Template testen
9. Template versionieren und bereitstellen

So entsteht ein Template, das nicht nur einmal funktioniert, sondern regelmäßig reproduzierbar neu gebaut werden kann.

Technologien für den automatisierten Template-Build

Für die automatische Erstellung von VM- und Node-Templates gibt es verschiedene Technologien. Welche Lösung sinnvoll ist, hängt stark von der Plattform, dem Betriebssystem und dem gewünschten Automatisierungsgrad ab.

Packer

Packer ist eines der bekanntesten Werkzeuge für den automatisierten Image-Build. Es kann aus einer ISO-Datei oder einem bestehenden Basis-Image eine neue VM erstellen, diese konfigurieren und anschließend als Template oder Image bereitstellen.

Der Vorteil von Packer liegt darin, dass Templates nicht mehr rein manuell gepflegt werden müssen. Installationsschritte, Provisioning-Skripte, Paketinstallationen und Cleanup können in einem definierten Build-Prozess abgebildet werden.

Packer ist dabei nicht auf eine einzelne Virtualisierungsplattform beschränkt. Je nach Umgebung können unterschiedliche Builder oder Plugins verwendet werden, zum Beispiel für VMware vSphere, Proxmox, QEMU/KVM, Hyper-V oder weitere Plattformen. Dadurch eignet sich Packer besonders dann, wenn Unternehmen ihre Template-Erstellung standardisieren und gleichzeitig gegenüber verschiedenen Hypervisoren offen bleiben möchten.

cloud-init

cloud-init ist kein klassisches Image-Build-Tool, sondern ein Initialisierungswerkzeug. Trotzdem gehört es zwingend in diesen Kontext, weil es entscheidet, wie eine geklonte VM beim ersten Start personalisiert wird.

Während Packer oder andere Werkzeuge das Template bauen, sorgt cloud-init später dafür, dass aus der Vorlage ein individueller Node wird. Diese Trennung ist wichtig: Das Template bleibt generisch, die konkrete Konfiguration erfolgt erst beim Deployment.

Viele Virtualisierungs- und Cloud-Plattformen können cloud-init-Daten an neue VMs übergeben. Dadurch lassen sich generische Templates flexibel für unterschiedliche Umgebungen nutzen.

Autoinstall und Kickstart

Viele Linux-Distributionen bieten eigene Mechanismen für unbeaufsichtigte Installationen. Bei Ubuntu ist das zum Beispiel Autoinstall, bei Red Hat-basierten Systemen Kickstart.

Damit kann die Betriebssysteminstallation automatisiert werden. In Kombination mit Packer entsteht daraus ein vollständiger Build-Prozess: Die Installation läuft automatisch, anschließend werden Pakete, Dienste und Konfigurationen ergänzt.

KIWI NG

Im SUSE- und openSUSE-Umfeld ist KIWI NG ein wichtiges Werkzeug zum Erstellen eigener Systemimages. Damit lassen sich angepasste Images für unterschiedliche Zielplattformen bauen.

KIWI ist besonders dann interessant, wenn nicht nur eine klassische VM installiert werden soll, sondern ein reproduzierbares Systemimage aus einer definierten Beschreibung entstehen soll.

SUSE Edge Image Builder

Für moderne Edge- und Kubernetes-Szenarien im SUSE-Umfeld ist der SUSE Edge Image Builder interessant. Er kann angepasste Images für RKE2- und K3s-Szenarien erzeugen und dabei auch Anforderungen wie Netzwerk, NTP, Zertifikate, Pakete oder Air-Gap-Umgebungen berücksichtigen.

Das ist besonders relevant, wenn Kubernetes nicht nur im zentralen Rechenzentrum, sondern auch an verteilten Standorten oder in stark standardisierten Umgebungen ausgerollt werden soll.

Image Builder der Betriebssystemhersteller

Auch Betriebssystemhersteller bieten eigene Image-Build-Lösungen an. Red Hat stellt beispielsweise einen Image Builder bereit, mit dem angepasste RHEL-Systemimages erstellt werden können.

Solche Werkzeuge sind besonders dann sinnvoll, wenn Unternehmen stark innerhalb eines Hersteller-Ökosystems arbeiten und möglichst nah an den unterstützten Standardwerkzeugen bleiben möchten.

Ansible und Terraform

Ansible und Terraform werden häufig im gleichen Kontext genannt, haben aber andere Schwerpunkte.

Terraform beschreibt und erstellt Infrastruktur, zum Beispiel virtuelle Maschinen, Netzwerke oder Ressourcen in einer Virtualisierungs-, Cloud- oder HCI-Umgebung. Ansible konfiguriert Systeme nach der Bereitstellung.

Beide Werkzeuge können Teil einer Template- oder Deployment-Pipeline sein. Sie ersetzen aber nicht zwangsläufig den eigentlichen Image-Build. In einer sauberen Automatisierungskette können sie sich gut ergänzen: Packer baut das Template, Terraform stellt Infrastruktur bereit, Ansible übernimmt zusätzliche Konfigurationen.

Anforderungen an gute Kubernetes-Node-Templates

Ein gutes Template muss mehrere Anforderungen erfüllen. Es soll möglichst schlank bleiben, aber alle notwendigen Grundlagen für den späteren Betrieb enthalten.

Einheitliche Betriebssystembasis

Alle Nodes sollten auf einer klar definierten Betriebssystemversion basieren. Unterschiedliche Paketstände oder manuell veränderte Systeme erschweren später Updates, Fehlersuche und Support.

Aktueller Patchstand

Das Template sollte zum Zeitpunkt der Erstellung aktuelle Sicherheitsupdates enthalten. Gleichzeitig sollte klar dokumentiert sein, wann das Template gebaut wurde und welche Version es hat.

Funktionierende Initialisierung

cloud-init muss installiert, aktiviert und korrekt vorbereitet sein. Der erste Start eines geklonten Nodes muss zuverlässig dazu führen, dass Hostname, Benutzer, SSH-Zugriff und weitere Einstellungen übernommen werden.

Saubere Plattformintegration

Je nach Hypervisor oder HCI-Plattform sollte der passende Gast-Agent vorhanden sein. Dieser sorgt dafür, dass die Plattform Informationen zur VM auslesen und grundlegende Aktionen sauber durchführen kann.

Welche Komponente dafür notwendig ist, hängt von der eingesetzten Umgebung ab. In VMware-Umgebungen sind es beispielsweise VMware Tools oder open-vm-tools. In KVM- oder Proxmox-Umgebungen kann der QEMU Guest Agent relevant sein. Andere Plattformen bringen eigene Integrationskomponenten oder empfohlene Agenten mit.

Wichtig ist nicht der konkrete Herstellername, sondern das Ziel: Die VM soll sauber mit der Plattform zusammenarbeiten und für automatisierte Bereitstellungsprozesse zuverlässig steuerbar sein.

Keine eindeutigen Altlasten

Ein Template darf keine Werte enthalten, die nach dem Klonen eindeutig sein müssen. Dazu gehören zum Beispiel SSH-Hostkeys, Machine-ID, temporäre Installer-Dateien oder alte cloud-init-Zustände.

Keine Secrets im Template

Passwörter, Tokens, Zertifikate oder private Schlüssel gehören nicht fest in ein Template. Sie sollten über sichere Mechanismen beim Deployment bereitgestellt oder aus zentralen Systemen bezogen werden.

Netzwerkfähigkeit

DNS, Gateway, NTP und grundlegende Netzwerkkonfiguration müssen so vorbereitet sein, dass der neue Node nach dem ersten Start erreichbar und zeitlich synchron ist. Zeitabweichungen können gerade in Kubernetes-Umgebungen zu schwer nachvollziehbaren Problemen führen.

Testbarkeit

Ein Template sollte nicht ungeprüft produktiv verwendet werden. Vor der Freigabe sollte getestet werden, ob eine VM daraus erfolgreich startet, cloud-init korrekt läuft, SSH-Zugriff funktioniert und die spätere Kubernetes-Installation möglich ist.

Dieser Test sollte möglichst auf der Zielplattform erfolgen. Ein Template, das auf einer Plattform funktioniert, muss nicht automatisch auf jeder anderen Plattform identisch funktionieren. Unterschiede bei cloud-init-Datenquellen, Gast-Agenten, Netzwerkkonfiguration oder Storage-Treibern sollten deshalb früh geprüft werden.

Versionierung und Dokumentation

Templates sollten eindeutig versioniert werden. Eine Bezeichnung wie „linux-template-neu“ reicht im produktiven Betrieb nicht aus. Sinnvoller sind nachvollziehbare Namen mit Betriebssystem, Version, Build-Datum und Einsatzzweck.

Best Practices für den Template-Build

Aus der Praxis ergeben sich einige Grundregeln:

Ein Template sollte nicht dauerhaft manuell gepflegt werden. Besser ist ein Build-Prozess, der bei Bedarf erneut ausgeführt werden kann.

Das Template sollte so wenig Spezialkonfiguration wie möglich enthalten. Alles, was pro Node unterschiedlich ist, gehört in die Initialisierung oder in das spätere Deployment.

Vor dem Speichern als Template sollten temporäre Dateien, Logs, SSH-Hostkeys, Machine-ID und cloud-init-Zustände bereinigt werden.

Der Build-Prozess sollte dokumentiert und idealerweise versioniert sein. So ist später nachvollziehbar, warum ein Template so aussieht, wie es aussieht.

Außerdem sollte jedes Template getestet werden, bevor es in automatisierten Deployment-Prozessen verwendet wird. Automatisierung ist nur dann hilfreich, wenn die Grundlage zuverlässig funktioniert.

Offenheit gegenüber unterschiedlichen Plattformen

Neben bekannten Lösungen wie VMware rücken zunehmend auch Alternativen wie Proxmox, KVM-basierte Systeme, Hyper-V oder verschiedene HCI-Plattformen in den Fokus.

Für Kubernetes-Node-Templates bedeutet das: Der Build-Prozess sollte möglichst nicht unnötig an eine einzelne Plattform gebunden sein. Natürlich gibt es plattformspezifische Unterschiede, etwa bei Gast-Agenten, Storage-Anbindung, Netzwerkkonfiguration oder cloud-init-Datenquellen. Die grundlegenden Anforderungen bleiben jedoch ähnlich.

Ein gutes Template sollte deshalb nach einem klaren Prinzip aufgebaut sein: so generisch wie möglich, so plattformspezifisch wie nötig.

Dadurch können Unternehmen ihre Kubernetes-Automatisierung flexibler gestalten und bleiben bei der Auswahl der darunterliegenden Infrastruktur offener.

Fazit

Automatisiertes Kubernetes-Deployment beginnt nicht erst im Cluster. Es beginnt bereits bei der Erstellung der Node-Templates.

Wer Kubernetes-Umgebungen zuverlässig, sicher und reproduzierbar bereitstellen möchte, sollte Templates nicht als manuell gepflegte Einmal-Vorlage betrachten. Sie sind ein zentraler Bestandteil der Automatisierungskette.

Gute Templates sind aktuell, schlank, cloud-init-fähig, sauber bereinigt, dokumentiert und wiederholbar gebaut. Sie berücksichtigen die Anforderungen der jeweiligen Zielplattform, bleiben aber dort generisch, wo es für spätere Automatisierung sinnvoll ist.

Denn am Ende gilt: Je besser die Vorlage, desto stabiler das automatische Deployment.