Kubernetes Proof of Concept: Strukturiert evaluieren statt blind migrieren

TL;DR

• Ein PoC ist kein Pilotprojekt. Ziel ist die Validierung konkreter Hypothesen, nicht der Aufbau einer Produktionsumgebung.
• Definieren Sie maximal 3-5 messbare Erfolgskriterien, bevor Sie den ersten Cluster provisionieren.
• Nutzen Sie Managed Kubernetes (AKS, EKS, GKE) fuer den PoC, um den Overhead der Control Plane zu eliminieren.
• Zeitrahmen: 4-6 Wochen genuegen fuer einen fokussierten PoC. Laenger bedeutet meist, dass der Scope zu breit ist.
• Dokumentieren Sie Erkenntnisse laufend -- der PoC-Report ist das wichtigste Deliverable, nicht der Cluster.

Warum ein PoC statt direkt loslegen?

Die Versuchung ist gross, direkt mit Kubernetes in Produktion zu gehen. Managed Services machen den Einstieg einfach, Tutorials gibt es reichlich. Aber Kubernetes ist nicht nur ein technisches System -- es veraendert Workflows, Team-Strukturen und Deployment-Prozesse.

Ein PoC klaert vorab, ob diese Veraenderungen fuer die eigene Organisation tragbar und sinnvoll sind. Er beantwortet Fragen, die sich erst im praktischen Betrieb zeigen:

• Kann unser bestehendes CI/CD-System Kubernetes-Deployments abbilden?
• Wie lange braucht das Team, um die grundlegenden Konzepte (Pods, Services, Deployments, Namespaces) produktiv einzusetzen?
• Welche unserer Anwendungen lassen sich ohne groesseren Umbau containerisieren?
• Welche Storage-Anforderungen haben unsere Stateful Workloads, und wie bildet Kubernetes diese ab?
• Koennen wir unsere Compliance-Anforderungen (Zugriffskontrolle, Audit-Logging, Datenhaltung) mit Kubernetes-Bordmitteln erfuellen?

Fuer Details zu Storage-Optionen: Kubernetes Storage.

Erfolgskriterien definieren

Der wichtigste Schritt kommt vor dem ersten kubectl-Befehl. Ohne klare Erfolgskriterien wird der PoC zum Spielplatz ohne verwertbare Ergebnisse.

Gute Erfolgskriterien sind:

Schlechte Erfolgskriterien sind vage Formulierungen wie "Kubernetes soll unsere Infrastruktur verbessern" oder "wir wollen cloud-native werden". Diese lassen sich nicht auswerten.

PoC-Cluster mit Terraform provisionieren

Fuer den PoC empfehle ich Managed Kubernetes. Damit entfaellt die Verwaltung der Control Plane, und Sie koennen sich auf die Evaluation der Plattform konzentrieren. Das folgende Terraform-Beispiel provisioniert einen minimalen EKS-Cluster auf AWS:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.1"

  name = "k8s-poc-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-central-1a", "eu-central-1b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]

  enable_nat_gateway   = true
  single_nat_gateway   = true
  enable_dns_hostnames = true

  tags = {
    Environment = "poc"
    Project     = "kubernetes-evaluation"
  }
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.8.0"

  cluster_name    = "k8s-poc"
  cluster_version = "1.29"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  cluster_endpoint_public_access = true

  eks_managed_node_groups = {
    poc_nodes = {
      instance_types = ["t3.medium"]
      min_size       = 2
      max_size       = 4
      desired_size   = 2

      labels = {
        environment = "poc"
      }
    }
  }

  tags = {
    Environment = "poc"
    Project     = "kubernetes-evaluation"
  }
}

output "cluster_endpoint" {
  value = module.eks.cluster_endpoint
}

output "cluster_name" {
  value = module.eks.cluster_name
}

Provisionierung:

terraform init
terraform plan -out=poc.tfplan
terraform apply poc.tfplan

# kubeconfig konfigurieren
aws eks update-kubeconfig --region eu-central-1 --name k8s-poc

# Cluster verifizieren
kubectl get nodes
kubectl cluster-info

Die Region eu-central-1 (Frankfurt) stellt sicher, dass Daten innerhalb der EU bleiben -- relevant fuer DSGVO-Anforderungen.

Fuer alternative Cluster-Setups siehe Kubernetes Cluster Setup Production.

Referenzanwendung deployen

Waehlen Sie fuer den PoC eine reale Anwendung aus Ihrem Stack. Kein "Hello World", sondern etwas, das typische Anforderungen abbildet: Datenbank-Anbindung, Environment-Variablen, Health Checks, vielleicht einen Background Worker.

Hier ein Beispiel-Setup fuer eine typische Web-Anwendung mit Redis-Cache:

apiVersion: v1
kind: Namespace
metadata:
  name: poc-app
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: poc-app
data:
  REDIS_HOST: "redis"
  REDIS_PORT: "6379"
  LOG_LEVEL: "info"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: poc-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: your-registry/your-app:latest
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: app-config
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 20
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: poc-app
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: poc-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
        - name: redis
          image: redis:7-alpine
          ports:
            - containerPort: 6379
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: poc-app
spec:
  selector:
    app: redis
  ports:
    - port: 6379
      targetPort: 6379

Deployment und erste Validierung:

kubectl apply -f poc-app.yaml

# Status pruefen
kubectl -n poc-app get pods -w

# Logs einsehen
kubectl -n poc-app logs -l app=web --tail=50

# Port-Forward fuer lokalen Test
kubectl -n poc-app port-forward svc/web 8080:80

Testszenarien durchfuehren

Mit der laufenden Anwendung koennen Sie jetzt die definierten Erfolgskriterien systematisch pruefen.

Rolling Update testen

# Neues Image deployen
kubectl -n poc-app set image deployment/web web=your-registry/your-app:v2

# Rollout-Status beobachten
kubectl -n poc-app rollout status deployment/web

# Bei Problemen: Rollback
kubectl -n poc-app rollout undo deployment/web

# Rollout-History anzeigen
kubectl -n poc-app rollout history deployment/web

Resilienz pruefen

# Pod manuell loeschen -- Kubernetes sollte sofort einen neuen starten
kubectl -n poc-app delete pod -l app=web --wait=false

# Beobachten, wie schnell der Ersatz-Pod ready wird
kubectl -n poc-app get pods -w

Auto-Scaling testen

Installieren Sie den Metrics Server (falls nicht vorhanden) und erstellen Sie einen HPA:

# Metrics Server pruefen
kubectl top nodes
kubectl top pods -n poc-app

# Last generieren (in einem separaten Terminal)
kubectl run load-generator --image=busybox --restart=Never -- \
  /bin/sh -c "while true; do wget -q -O- http://web.poc-app.svc.cluster.local; done"

# HPA beobachten
kubectl -n poc-app get hpa -w

Mehr zu Auto-Scaling-Strategien: Kubernetes Rolling Updates.

Monitoring waehrend des PoC

Ohne Monitoring ist ein PoC blind. Ein minimales Setup mit Prometheus und Grafana laesst sich ueber Helm schnell installieren:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=poc-admin-2024 \
  --set prometheus.prometheusSpec.retention=7d

Damit haben Sie sofort Dashboards fuer Node-Metriken, Pod-Ressourcen und Cluster-Gesundheit. Die gesammelten Daten fliessen direkt in den PoC-Report.

Detaillierte Monitoring-Konfiguration: Kubernetes Monitoring.

PoC-Report: Was muss rein?

Der Report ist das zentrale Ergebnis des PoC. Er muss fuer technische und nicht-technische Stakeholder verstaendlich sein.

Struktur:

1. Zusammenfassung: 1 Seite. Empfehlung (Go/No-Go) mit Begruendung.
2. Erfolgskriterien und Ergebnisse: Tabelle mit Soll- und Ist-Werten. Jedes Kriterium bewertet als erfuellt/nicht erfuellt.
3. Technische Erkenntnisse: Was hat funktioniert? Wo gab es Probleme? Welche Anpassungen waren noetig?
4. Aufwandsschaetzung fuer Produktivbetrieb: Was muesste zusaetzlich implementiert werden (HA, Backup, Monitoring, RBAC-Konzept)?
5. Team-Feedback: Wie war die Lernkurve? Welche Schulungen werden benoetigt?
6. Kostenvergleich: PoC-Kosten vs. geschaetzte Produktivkosten vs. aktuelle Infrastrukturkosten.
7. Risiken und offene Punkte: Was wurde im PoC nicht abgedeckt?

Haeufige Fehler bei Kubernetes-PoCs

Scope Creep: Der PoC soll "alles" testen. Ergebnis: nichts wird gruendlich getestet. Beschraenken Sie sich auf eine Anwendung und 3-5 Hypothesen.

Kein dediziertes Team: Der PoC laeuft "nebenbei". Ergebnis: er zieht sich ueber Monate und liefert keine belastbaren Daten. Planen Sie mindestens 50% Kapazitaet fuer 1-2 Personen ein.

Unrealistische Anwendungswahl: "Hello World" validiert nichts. Ein kritisches Legacy-System mit 20 Abhaengigkeiten ueberfordert den PoC. Waehlen Sie etwas dazwischen.

Managed Services ignorieren: Den PoC mit kubeadm auf Bare Metal zu starten, verschwendet Wochen fuer Infrastruktur-Setup, die nichts ueber den Nutzen von Kubernetes aussagen.

Monitoring vergessen: Ohne Metriken koennen Sie die Erfolgskriterien nicht auswerten. Monitoring ist kein Nice-to-have, sondern Teil des PoC-Setups ab Tag 1.

Nach dem PoC: Wie weiter?

Ein positiver PoC ist kein Freifahrtschein fuer eine sofortige Vollmigration. Die naechsten Schritte:

1. PoC-Cluster zerstoeren. Ernsthaft. Er war ein Experiment, keine Produktionsumgebung. terraform destroy.

2. Produktionscluster planen. Basierend auf den PoC-Erkenntnissen: Cluster-Sizing, HA-Konzept, Netzwerk-Architektur, Backup-Strategie. Siehe Kubernetes Resilienz.

3. Team schulen. Der PoC hat Wissensluecken aufgezeigt. Investieren Sie in Schulungen, bevor Sie produktiv gehen. Zertifizierungen wie CKA oder CKAD geben Struktur: CKA Zertifizierung.

4. Schrittweise migrieren. Beginnen Sie mit unkritischen Services. Sammeln Sie Betriebserfahrung. Erweitern Sie sukzessive.

5. Backup und DR von Anfang an. Nicht nachtraeglich, sondern als Teil der initialen Produktions-Architektur.

Fazit

Ein Kubernetes PoC ist eine Investition von 4-6 Wochen, die Monate an Fehlentscheidungen verhindern kann. Der Schluessel liegt in der Vorbereitung: klare Hypothesen, messbare Kriterien, fokussierter Scope. Die technische Umsetzung -- Cluster provisionieren, Anwendung deployen, Tests durchfuehren -- ist der einfache Teil. Die Disziplin, beim definierten Scope zu bleiben und am Ende einen ehrlichen Report zu schreiben, ist die eigentliche Herausforderung.

Sie planen einen Kubernetes PoC und moechten Unterstuetzung bei der Strukturierung oder Durchfuehrung? Kontaktieren Sie uns fuer ein unverbindliches Gespraech.