Kubernetes-Plattform in 12 Wochen aufbauen: Unser Festpreis-Ansatz mit Terraform + Flux

Zwölf Wochen ist eine konkrete Zusage — keine Schätzung mit Sternchen. In diesem Artikel beschreiben wir, wie wir bei Kubewerk eine produktionsfertige Kubernetes-Plattform in genau diesem Zeitrahmen liefern, welche Entscheidungen wir in jeder Phase treffen, und warum ein Festpreis für beide Seiten besser funktioniert als Tagesatz-Consulting.

Warum 12 Wochen — und nicht weniger?

Eine Kubernetes-Plattform, die wirklich hält, ist mehr als ein Cluster mit ein paar Deployments. Sie besteht aus Infrastructure as Code, einem GitOps-System, Observability, Security-Policies, CI/CD-Integration und — am wichtigsten — einem Team, das sie eigenständig betreiben kann. Weniger als 12 Wochen reicht nicht, um alle diese Schichten sauber zu implementieren und das Wissen zu transferieren.

Mehr als 12 Wochen braucht es nicht, wenn der Scope klar definiert ist. Das ist der Kerngedanke hinter dem Festpreismodell: wir definieren gemeinsam, was “fertig” bedeutet, bevor wir anfangen — nicht während des Projekts.

Phase 1 — Woche 1–2: Infrastruktur mit Terraform

Jede Plattform beginnt mit der Frage: Wo läuft der Cluster? Hetzner, Azure, AWS oder GCP — die Wahl beeinflusst den restlichen Stack, aber nicht das Vorgehen. Wir verwenden Terraform für alle Cloud-Ressourcen: Cluster, Netzwerk, Identitäten, Storage.

Der State liegt in einem Remote Backend (Azure Storage Account oder S3), das ebenfalls per Terraform provisioniert wird. Kein lokaler State, der auf Laptops stirbt.

Typische Terraform-Module, die wir in Phase 1 aufbauen:

• Managed Kubernetes (AKS / EKS / GKE / Hetzner Robot + k3s)
• Node Pools mit separatem System- und Workload-Pool
• Virtual Network / VPC mit privaten Subnetzen
• Managed Identity / IAM-Rolle für GitOps-Controller
• Key Vault / Secrets Manager für externe Secrets
• Container Registry mit Pull-Zugriffsrechten für Kubelet

Phase 2 — Woche 3–4: GitOps mit Flux v2

Wenn der Cluster steht, kommt Flux v2. Flux ist der GitOps-Controller unserer Wahl — weil er CNCF-graduated ist, kein eigenes Control Plane braucht und sich natürlich in Kustomize integriert.

Wir bootstrappen Flux direkt aus dem Git-Repository des Kunden. Ab diesem Moment ist Git die einzige erlaubte Quelle für Cluster-Änderungen. kubectl apply direkt gegen Production ist danach nicht mehr der Standardweg.

Die Kustomize-Overlay-Struktur, die wir aufbauen:

clusters/
  production/
    kustomization.yaml      # entry point for Flux
infrastructure/
  base/                     # shared manifests
  overlays/
    production/             # environment-specific patches
apps/
  base/
  overlays/
    production/

Diese Struktur trennt Infrastruktur-Komponenten (Traefik, cert-manager, ESO) von Anwendungs-Deployments und erlaubt es, dieselben Basis-Manifeste in mehreren Umgebungen zu verwenden.

Phase 3 — Woche 5–6: Observability Stack

Ein Cluster ohne Observability ist ein Cluster, den man nicht betreiben kann. Wir installieren den kube-prometheus-stack (Prometheus, Grafana, Alertmanager) via HelmRelease durch Flux — nicht manuell per Helm-CLI.

Was wir in Phase 3 konfigurieren:

• Prometheus mit ServiceMonitor-Ressourcen für alle relevanten Komponenten
• Grafana mit vordefinierten Dashboards für Cluster-Health, Node-Ressourcen und Anwendungsmetriken
• Alertmanager mit Routing-Regeln und Slack/E-Mail-Integration
• Loki + Promtail für zentrales Log-Aggregation — damit Logs und Metriken in einem Tool sind

Phase 4 — Woche 7–8: Security

Security ist kein Add-on, sondern ein integraler Bestandteil. In Woche 7–8 implementieren wir:

• Network Policies mit Default-Deny-All pro Namespace — jede erlaubte Verbindung muss explizit definiert sein
• External Secrets Operator mit Workload Identity — kein Secret wird als Klartext in Git gespeichert, alles kommt aus Key Vault oder Secrets Manager
• Kyverno Policies für runAsNonRoot, disallow-privileged, require resource requests — Admission Controller als letzte Verteidigungslinie
• RBAC nach Least-Privilege-Prinzip — Entwickler können in ihren Namespaces lesen und debuggen, aber nicht in anderen Namespaces oder cluster-weit schreiben

Phase 5 — Woche 9–10: CI/CD Integration

GitOps bedeutet nicht, dass CI/CD irrelevant wird — es bedeutet, dass CI/CD Images baut und pusht, während GitOps das Deployment orchestriert. Wir verbinden beides:

• Build-Pipeline (GitHub Actions / Azure Pipelines / GitLab CI) baut das Docker-Image und pusht in die Container Registry
• Flux ImageRepository + ImagePolicy + ImageUpdateAutomation erkennt neue Tags und öffnet automatisch Pull Requests ins GitOps-Repository
• Nach Merge in main deployt Flux automatisch auf den Cluster

Das Ergebnis: Ein Commit in den Anwendungs-Repository triggert einen Build, der in einem automatischen PR in den GitOps-Repository resultiert — kein manuelles Eingreifen nötig.

Phase 6 — Woche 11–12: Dokumentation und Übergabe

Die letzten zwei Wochen gehören nicht uns — sie gehören dem Team des Kunden. Wir liefern:

• Runbooks für die häufigsten Operationen: Deployment, Rollback, Scaling, Cluster-Upgrade, Secret-Rotation
• Architekturdiagramm der gesamten Plattform mit Datenflüssen und Abhängigkeiten
• Pair-Programming-Sessions mit dem Engineering-Team — kein Frontal-Training, sondern gemeinsames Arbeiten an echten Aufgaben
• Finales Übergabe-Gespräch mit offenen Fragen, Upgrade-Empfehlungen für die nächsten 12 Monate, und einem klar definierten Support-Modell falls gewünscht

Warum Festpreis funktioniert

Tagesatz-Consulting hat einen inhärenten Interessenskonflikt: je länger das Projekt dauert, desto mehr verdient der Berater. Festpreis kehrt diesen Anreiz um — wir haben ein direktes Interesse daran, effizient zu liefern.

Der Festpreis funktioniert nur, weil wir den Scope genau definieren. Was nicht im Scope ist, ist nicht im Scope — keine surprise invoices. Was sich während des Projekts ändert, wird als Change Request transparent kommuniziert und bepreist.

Fazit

12 Wochen, Festpreis, vollständige Übergabe — das ist kein Marketing-Versprechen, sondern ein Prozess, den wir mehrfach durchgeführt haben. Der Schlüssel liegt im klar definierten Scope, in erfahrenen Engineers die keine Lernkurve auf Kundenkosten durchlaufen, und in einem GitOps-Ansatz der von Anfang an auf Übergabe ausgelegt ist.

Wenn Sie wissen möchten, ob und wie dieser Ansatz auf Ihre Situation passt — melden Sie sich für ein 30-minütiges Gespräch. Keine Vertriebspräsentation, sondern direkt mit den Engineers die das Projekt durchführen würden.