Kubernetes Zero-Touch Provisioning: Cluster in 15 Minuten statt 3 Stunden

TL;DR

• Zero-Touch Provisioning bedeutet: Ein Git-Push oder API-Call startet den kompletten Cluster-Aufbau, inkl. CNI, Storage, Monitoring und Anwendungen, ohne dass jemand manuell eingreifen muss
• Die Toolchain besteht typischerweise aus Terraform (Infrastruktur), Cloud-Init oder Cluster API (Node-Bootstrap), und einem GitOps-Operator (Argo CD oder Flux) fuer die Cluster-Konfiguration
• Der groesste Zeitgewinn liegt nicht beim ersten Cluster, sondern bei Cluster 2 bis N und bei Disaster Recovery
• Voraussetzung ist eine saubere Trennung von Infrastruktur-Code, Cluster-Konfiguration und Anwendungs-Manifesten in separaten Git-Repositories

Was Zero-Touch Provisioning eigentlich bedeutet

Der Begriff wird inflationaer benutzt, also eine klare Definition: Zero-Touch Provisioning heisst, dass nach einem einzigen Ausloeser (Git-Commit, API-Call, Webhook) ein kompletter Kubernetes-Cluster entsteht, der produktionsbereit ist. Kein SSH auf Nodes, kein manuelles kubectl apply, kein Klicken in einer Web-UI.

Das Ergebnis ist ein Cluster mit installiertem CNI-Plugin, funktionierendem Ingress Controller, konfiguriertem Monitoring, eingerichteten RBAC-Regeln und den ersten Anwendungen. Alles aus Code, alles reproduzierbar, alles in Git versioniert.

Das ist kein theoretisches Ideal. Mit den richtigen Tools und einer durchdachten Repository-Struktur ist das in wenigen Wochen umsetzbar.

Warum sich der Aufwand lohnt

Manuelles Cluster-Setup dauert typischerweise 2-4 Stunden, wenn alles glattlaeuft. Mit Troubleshooting schnell einen halben Tag. Das ist akzeptabel, wenn Sie einen Cluster pro Jahr aufsetzen.

In der Praxis sieht es anders aus. Typische Szenarien, in denen Zero-Touch seinen Wert zeigt:

Disaster Recovery. Ihr Cluster ist nicht mehr erreichbar. Jede Minute zaehlt. Mit Zero-Touch Provisioning koennen Sie einen identischen Cluster in 15 Minuten hochfahren und die Anwendungen aus dem GitOps-Repository synchronisieren. Ohne Zero-Touch beginnt die Suche nach der Dokumentation, die hoffentlich aktuell ist.

Multi-Cluster-Setups. Sie betreiben separate Cluster fuer Entwicklung, Staging und Produktion. Oder Sie brauchen Cluster in verschiedenen Regionen. Jeder Cluster manuell aufgesetzt bedeutet Konfigurationsdrift. Mit Zero-Touch sind alle Cluster aus demselben Code gebaut, mit definierten Overlays fuer umgebungsspezifische Unterschiede.

Compliance und Auditierbarkeit. Regulierte Branchen (Finanzen, Pharma, KRITIS) verlangen Nachweise ueber den Zustand der Infrastruktur. Wenn der Cluster aus Code gebaut wird, ist der Git-Log der Audit-Trail.

Die Architektur in drei Schichten

Zero-Touch Provisioning laesst sich in drei Schichten aufteilen, die jeweils eigene Tools und Repositories haben:

Die Trennung ist wichtig. Infrastruktur-Code aendert sich selten und hat andere Reviewprozesse als Anwendungsmanifeste. Wenn alles in einem Repository liegt, wird das Review unuebersichtlich und die Berechtigungen schwer zu steuern.

Schicht 1: Infrastruktur mit Terraform

Terraform provisioniert die Basis: VMs (oder Managed-Kubernetes-Control-Planes), Netzwerke, Firewalls, Load Balancer und DNS-Eintraege.

# main.tf -- Kubernetes-Nodes auf Hetzner Cloud provisionieren

resource "hcloud_server" "control_plane" {
  count       = 3
  name        = "cp-${count.index}"
  server_type = "cpx31"
  image       = "ubuntu-24.04"
  location    = "fsn1"
  ssh_keys    = [hcloud_ssh_key.deploy.id]

  labels = {
    role    = "control-plane"
    cluster = var.cluster_name
  }

  user_data = templatefile("${path.module}/cloud-init/control-plane.yaml", {
    kubernetes_version = var.kubernetes_version
    join_token         = random_password.join_token.result
    cluster_name       = var.cluster_name
  })
}

resource "hcloud_server" "worker" {
  count       = var.worker_count
  name        = "worker-${count.index}"
  server_type = "cpx41"
  image       = "ubuntu-24.04"
  location    = "fsn1"
  ssh_keys    = [hcloud_ssh_key.deploy.id]

  labels = {
    role    = "worker"
    cluster = var.cluster_name
  }

  user_data = templatefile("${path.module}/cloud-init/worker.yaml", {
    kubernetes_version = var.kubernetes_version
    join_token         = random_password.join_token.result
    api_server         = hcloud_server.control_plane[0].ipv4_address
  })
}

resource "hcloud_load_balancer" "api" {
  name               = "${var.cluster_name}-api-lb"
  load_balancer_type = "lb11"
  location           = "fsn1"
}

Cloud-Init uebernimmt den Rest auf der Node: Pakete installieren, kubeadm ausfuehren, dem Cluster beitreten. Nach dem terraform apply laufen die Nodes hoch und bilden selbststaendig den Cluster.

Schicht 2: Cluster API als Alternative

Fuer Teams, die viele Cluster verwalten, ist Cluster API (CAPI) die bessere Wahl. CAPI laeuft selbst auf einem Management-Cluster und provisioniert Workload-Cluster deklarativ ueber Kubernetes-CRDs.

Der Vorteil gegenueber Terraform: CAPI betrachtet Cluster als laufende Kubernetes-Ressourcen. Es kann Nodes austauschen, Kubernetes-Versionen upgraden und den Zustand kontinuierlich abgleichen -- alles mit dem Reconcile-Loop, den Kubernetes-Operatoren nutzen.

Der Nachteil: Ein zusaetzlicher Management-Cluster, der selbst gepflegt werden muss. Fuer ein einzelnes Team mit 2-3 Clustern ist Terraform pragmatischer.

Schicht 3: GitOps fuer die Cluster-Konfiguration

Sobald der Cluster laeuft, uebernimmt ein GitOps-Operator die Konfiguration. Argo CD oder Flux synchronisieren den Cluster-Zustand mit einem Git-Repository.

Ein typisches GitOps-Repository fuer die Cluster-Konfiguration sieht so aus:

gitops-repo/
  clusters/
    production/
      kustomization.yaml
    staging/
      kustomization.yaml
  infrastructure/
    namespaces/
    rbac/
    network-policies/
    monitoring/
      kube-prometheus-stack.yaml
    ingress/
      nginx-ingress.yaml
    cert-manager/
    storage-classes/
  applications/
    app-a/
    app-b/

Der entscheidende Punkt: Argo CD wird als Teil des Cluster-Bootstrap installiert. Das heisst, Cloud-Init oder ein Post-Install-Script installiert Argo CD mit einer initialen Konfiguration, die auf das GitOps-Repository zeigt. Ab diesem Moment synchronisiert sich der Cluster selbststaendig.

Dieser Ansatz wird oft als "App of Apps" Pattern bezeichnet. Eine Root-Application in Argo CD referenziert alle anderen Applications. Sobald die Root-Application synchronisiert ist, rollt Argo CD die gesamte Cluster-Konfiguration aus.

Ablauf eines Zero-Touch-Deployments

1. Engineer merged einen PR im infra-repo (z.B. neuer Worker-Node-Pool)
2. CI-Pipeline fuehrt terraform plan aus und zeigt den Diff
3. Nach Approval: terraform apply provisioniert die Infrastruktur
4. Cloud-Init auf den neuen Nodes installiert Kubernetes und joined den Cluster
5. Argo CD erkennt die neuen Nodes und synchronisiert ausstehende Workloads
6. Monitoring (Prometheus) beginnt automatisch, Metriken der neuen Nodes zu scrapen

Kein manueller Schritt. Kein SSH. Kein kubectl.

Sicherheit im Zero-Touch-Modell

Automatisierung ohne Sicherheit ist ein Antipattern. Hier sind die wichtigsten Massnahmen:

Secrets Management. Secrets gehoeren nicht in Git. Verwenden Sie Sealed Secrets, External Secrets Operator mit HashiCorp Vault, oder SOPS fuer verschluesselte Secrets im Repository. Der GitOps-Operator entschluesselt sie erst zur Laufzeit im Cluster.

RBAC fuer CI/CD. Die CI/CD-Pipeline und der GitOps-Operator brauchen nur minimale Berechtigungen. Terraform benoetigt Cloud-Provider-Credentials (zeitlich begrenzt via OIDC). Argo CD benoetigt Cluster-Admin im Zielcluster, aber keinen Zugang zu den Cloud-Provider-APIs.

Image Security. Container-Images werden in der CI-Pipeline mit Trivy gescannt und mit Cosign signiert. Ein Admission Controller im Cluster lehnt unsignierte oder verwundbare Images ab. Mehr dazu in unserem Beitrag zur Kubernetes Security Automation.

Network Policies. Default-Deny in allen Namespaces, explizite Allow-Rules nur fuer benoetigen Traffic. Details zu Netzwerksicherheit finden Sie unter Kubernetes Network Security.

Monitoring von Tag 1

Ein Cluster ohne Monitoring ist ein Blindflug. Im Zero-Touch-Modell wird das Monitoring als Teil der Cluster-Konfiguration ausgerollt, nicht nachtraeglich installiert.

Der kube-prometheus-stack (Prometheus, Grafana, Alertmanager, diverse Exporter) wird als Helm-Release im GitOps-Repository definiert. Sobald Argo CD den Cluster synchronisiert, laeuft das Monitoring. Alerts fuer Node-Ausfaelle, hohe Pod-Restart-Raten und Certificate-Expiry sind vorkonfiguriert.

Fuer die Langzeitspeicherung von Metriken eignet sich Thanos oder Mimir als Prometheus-Remote-Write-Target. So bleiben Metriken auch nach einem Cluster-Neuaufbau verfuegbar. Einen tieferen Einstieg bietet unser Artikel zu Kubernetes Monitoring.

Vergleich: Manuell vs. Zero-Touch

Haeufige Fehler beim Einstieg

Alles auf einmal automatisieren wollen. Starten Sie mit der Infrastruktur-Schicht (Terraform) und fuegen Sie GitOps hinzu, sobald das stabil laeuft. Versuchen Sie nicht, alle drei Schichten gleichzeitig aufzubauen.

Kein Testen der Automatisierung. Wenn Sie Ihren Zero-Touch-Prozess nicht regelmaessig testen, indem Sie einen Cluster komplett abreissen und neu aufbauen, wissen Sie nicht, ob er im Ernstfall funktioniert. Planen Sie monatliche Rebuild-Tests ein.

Zu viel Abstraktion. Helm-Charts, die Kustomize-Overlays wrappen, die wiederum in Argo CD ApplicationSets referenziert werden: Irgendwann versteht niemand mehr, was deployed wird. Halten Sie die Toolchain so flach wie moeglich.

Secrets im Git. Auch "nur fuer die Testumgebung" landen Secrets frueher oder spaeter dort, wo sie nicht hingehoeren. Fuehren Sie Sealed Secrets oder External Secrets von Anfang an ein.

Fuer einen detaillierten Leitfaden zum produktionsreifen Cluster-Setup empfehlen wir Kubernetes Production Setup. Wenn Sie mehrere Cluster verwalten, lohnt sich auch ein Blick auf Multi-Cluster-Management.

Fazit

Zero-Touch Provisioning ist kein Luxus fuer grosse Unternehmen. Es ist eine Investition, die sich ab dem zweiten Cluster oder dem ersten Disaster-Recovery-Fall bezahlt macht. Die Toolchain ist ausgereift, die Patterns sind erprobt, und der initiale Aufwand liegt typischerweise bei 2-4 Wochen fuer ein erfahrenes Team.

Der Schluessel zum Erfolg ist eine saubere Schichtentrennung (Infrastruktur, Cluster-Bootstrap, Cluster-Konfiguration), ein konsequenter GitOps-Ansatz und das Commitment, den Prozess regelmaessig zu testen.

Wenn Sie Unterstuetzung bei der Umsetzung brauchen oder eine Bewertung Ihrer aktuellen Automatisierungsstrategie wuenschen, sprechen Sie uns an unter /kontakt.