Kubernetes in 30 Tagen: Vom leeren Cluster zum produktionsreifen Setup

TL;DR

Tag 1-7: Cluster aufsetzen (Managed empfohlen), kubectl lernen, erste Pods und Deployments deployen
Tag 8-14: Services, Ingress, ConfigMaps, Secrets -- die Bausteine fuer echte Anwendungen
Tag 15-21: Monitoring mit Prometheus/Grafana, Logging, Health Checks und Resource Limits
Tag 22-30: RBAC, Network Policies, CI/CD-Integration und das erste produktionsnahe Deployment
30 Tage reichen fuer ein solides Fundament, nicht fuer Production-Grade -- dafuer braucht es mehr Erfahrung

Bevor es losgeht: Die richtige Umgebung waehlen

Die erste Entscheidung ist die Cluster-Umgebung. Fuer den Lernprozess gibt es drei sinnvolle Optionen:

Option	Kosten	Aufwand	Empfehlung
kind (Kubernetes in Docker)	Kostenlos	5 Minuten Setup	Zum Lernen auf dem Laptop
Managed Cloud (EKS/AKS/GKE)	~70-150 EUR/Monat	15 Minuten Setup	Fuer produktionsnahe Erfahrung
kubeadm auf VMs	Kostenlos (eigene Hardware)	2-4 Stunden	Um die Interna zu verstehen

Meine Empfehlung: Startet mit kind fuer die ersten zwei Wochen, dann wechselt auf einen Managed Service. So lernt man die Konzepte ohne Cloud-Kosten und sieht spaeter, wie es in der echten Welt aussieht.

# kind installieren und Cluster erstellen
# (Voraussetzung: Docker laeuft)
brew install kind   # macOS
# oder: go install sigs.k8s.io/kind@latest

kind create cluster --name lerncluster

# kubectl konfiguration pruefen
kubectl cluster-info
kubectl get nodes

Woche 1 (Tag 1-7): Grundlagen und erste Deployments

Tag 1-2: kubectl und Pods verstehen

Alles in Kubernetes ist eine Ressource, die ueber die API verwaltet wird. kubectl ist das CLI-Tool dafuer. Die wichtigsten Befehle am Anfang:

# Cluster-Status
kubectl get nodes
kubectl get namespaces

# Einen Pod starten (nicht so in Produktion, aber zum Lernen)
kubectl run nginx-test --image=nginx:1.27-alpine

# Was laeuft?
kubectl get pods
kubectl describe pod nginx-test
kubectl logs nginx-test

# In den Container schauen
kubectl exec -it nginx-test -- /bin/sh

# Pod loeschen
kubectl delete pod nginx-test

Pods direkt zu erstellen ist nur zum Testen sinnvoll. In der Praxis nutzt man Deployments.

Tag 3-5: Deployments und ReplicaSets

Ein Deployment beschreibt den gewuenschten Zustand: Welches Image, wie viele Replicas, welche Ressourcen. Kubernetes sorgt dafuer, dass dieser Zustand eingehalten wird.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 256Mi
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5

# Deployment erstellen
kubectl apply -f deployment.yaml

# Status beobachten
kubectl get deployment web-app
kubectl get replicaset
kubectl get pods -l app=web-app

# Skalieren
kubectl scale deployment web-app --replicas=5

# Rolling Update
kubectl set image deployment/web-app web=nginx:1.28-alpine

# Rollback
kubectl rollout undo deployment/web-app
kubectl rollout history deployment/web-app

Tag 6-7: Namespaces und grundlegendes Ressourcen-Management

Namespaces trennen Workloads logisch. In der Praxis nutzt man sie fuer Teams, Umgebungen oder Applikationen:

# Namespace erstellen
kubectl create namespace staging
kubectl create namespace production

# Workloads in Namespace deployen
kubectl apply -f deployment.yaml -n staging

# Default-Namespace setzen (spart Tipparbeit)
kubectl config set-context --current --namespace=staging

# Alle Pods in allen Namespaces
kubectl get pods -A

Woche 2 (Tag 8-14): Services, Ingress und Konfiguration

Tag 8-10: Services -- Pods erreichbar machen

Pods bekommen dynamische IPs und koennen jederzeit neu erstellt werden. Services bieten eine stabile Adresse:

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP
---
# Fuer externen Zugriff (z.B. in der Cloud)
apiVersion: v1
kind: Service
metadata:
  name: web-app-external
spec:
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Service-Typen im Ueberblick:

Typ	Erreichbar von	Typischer Use Case
ClusterIP	Innerhalb des Clusters	Backend-Services
NodePort	Ueber Node-IP:Port	Development, On-Prem
LoadBalancer	Extern (Cloud LB)	Oeffentliche Services

Tag 11-12: ConfigMaps und Secrets

Konfiguration gehoert nicht ins Container-Image. ConfigMaps speichern nicht-sensible Werte, Secrets sensible Daten. Beides laesst sich als Environment-Variablen oder Volume Mounts in Pods injizieren:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
---
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
stringData:
  DATABASE_URL: "postgresql://user:password@db:5432/myapp"

Im Deployment werden beide per envFrom referenziert. ConfigMaps lassen sich auch als Dateien mounten, was fuer Config-Files praktisch ist.

Wichtig: Kubernetes Secrets sind nur Base64-kodiert, nicht verschluesselt. Fuer echte Sicherheit braucht man Encryption at Rest (siehe DSGVO-konforme Kubernetes-Cluster) oder einen External Secrets Operator.

Tag 13-14: Ingress -- HTTP-Routing

Ein Ingress Controller routet externen HTTP-Traffic an die richtigen Services. Installation mit Helm: helm install ingress-nginx ingress-nginx/ingress-nginx. Danach koennen Ingress-Ressourcen definiert werden:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-app
                port:
                  number: 80

Woche 3 (Tag 15-21): Monitoring und Observability

Tag 15-17: Prometheus und Grafana aufsetzen

Ein Cluster ohne Monitoring ist blind. Der kube-prometheus-stack installiert Prometheus, Grafana und Alertmanager in einem Schritt:

# kube-prometheus-stack installieren
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=changeme

# Grafana UI aufrufen
kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80
# Browser: http://localhost:3000

Nach der Installation hat man sofort Dashboards fuer Node-Auslastung, Pod-Metriken und Cluster-Health. Die vorinstallierten Alerting-Rules warnen bei hoher CPU, Memory-Druck oder Pod-Crashes.

Tag 18-19: Resource Requests und Limits richtig setzen

Ohne Resource-Limits kann ein einzelner Pod den gesamten Node in die Knie zwingen. Requests garantieren Ressourcen, Limits begrenzen sie:

resources:
  requests:    # Wird beim Scheduling garantiert
    cpu: 100m  # 0.1 CPU Cores
    memory: 128Mi
  limits:      # Darf nicht ueberschritten werden
    cpu: 500m
    memory: 512Mi

Faustregeln:

Requests: Orientierung am normalen Verbrauch (p50)
Limits: Orientierung am Peak-Verbrauch (p99) plus Puffer
CPU-Limit: Oft besser weglassen (Throttling ist unvorhersagbar)
Memory-Limit: Immer setzen (OOM-Kill ist besser als Node-Crash)

Tag 20-21: Health Checks

Liveness Probes pruefen, ob der Container noch laeuft. Readiness Probes pruefen, ob er Traffic annehmen kann. Beide sollten in jedem Deployment definiert sein -- sie ermoeglichen Self-Healing und Zero-Downtime-Deployments. In der Woche-1-Deployment-YAML oben sind beide bereits enthalten.

Woche 4 (Tag 22-30): Security und CI/CD

Tag 22-24: RBAC-Grundlagen

RBAC regelt, wer was im Cluster darf. Fuer den Einstieg die wichtigsten Konzepte:

# Role: Was darf getan werden? (in einem Namespace)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: developer
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services"]
    verbs: ["get", "list", "watch", "create", "update"]
  - apiGroups: [""]
    resources: ["pods/log", "pods/exec"]
    verbs: ["get", "create"]
---
# RoleBinding: Wer bekommt die Rolle?
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: staging
  name: developer-binding
subjects:
  - kind: User
    name: max.mustermann
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

Tag 25-27: Network Policies

Ohne Network Policies kann jeder Pod mit jedem anderen Pod kommunizieren. Die Strategie: Erst alles verbieten, dann gezielt erlauben.

# Schritt 1: Default Deny fuer den gesamten Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Schritt 2: Gezielt Traffic erlauben
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 8080

Tag 28-30: CI/CD-Integration

Der letzte Schritt: Deployments automatisieren. Das Grundprinzip: Die CI-Pipeline baut das Image, pusht es in eine Registry und aktualisiert das Deployment. Der einfachste Weg:

# In der CI-Pipeline (GitHub Actions, GitLab CI, etc.)
docker build -t registry.example.com/myapp:${COMMIT_SHA} .
docker push registry.example.com/myapp:${COMMIT_SHA}

kubectl set image deployment/myapp \
  app=registry.example.com/myapp:${COMMIT_SHA} \
  --namespace=production
kubectl rollout status deployment/myapp --timeout=120s

Fuer produktionsreife Setups empfehle ich stattdessen GitOps mit ArgoCD -- Details dazu in ArgoCD GitOps Tutorial.

Nach den 30 Tagen: Wie geht es weiter?

30 Tage sind ein guter Start, aber kein Endpunkt. Die wichtigsten naechsten Themen:

Helm: Package Management fuer Kubernetes -- Helm Charts fuer Anfaenger
GitOps: Deklaratives Deployment mit ArgoCD -- ArgoCD Tutorial
Storage: Persistente Daten in Kubernetes -- Kubernetes Storage
Security vertiefen: Kubernetes Security Hardening
Zertifizierung: Wer es ernst meint -- CKA Zertifizierung

Fazit

Kubernetes hat eine steile Lernkurve, aber sie ist beherrschbar, wenn man strukturiert vorgeht. In 30 Tagen kann man ein solides Fundament aufbauen: Deployments, Services, Monitoring, grundlegende Security. Das reicht, um erste Workloads sinnvoll zu betreiben.

Was danach kommt -- Helm, GitOps, Service Mesh, Operator-Patterns -- baut auf diesem Fundament auf. Der schwierigste Schritt ist der erste Cluster. Danach wird es iterativ einfacher.

Wenn Sie Unterstuetzung beim Einstieg in Kubernetes brauchen oder Ihr Team strukturiert aufbauen wollen, sprechen Sie uns an unter /kontakt.

Kubernetes in 30 Tagen lernen: Strukturierter Plan