Docker-Container laufen lokal problemlos. Aber was passiert wenn ein Container abstürzt, wenn du mehrere Instanzen brauchst oder wenn du Zero-Downtime-Updates willst? Hier fängt Kubernetes an. Es ist kein Ersatz für Docker — es ist das Werkzeug, das Docker-Container im Produktionsbetrieb koordiniert.

Was Kubernetes tut — und was nicht

Kubernetes (kurz: k8s) ist ein Container-Orchestrator. Es nimmt Container-Images entgegen und kümmert sich darum, dass sie laufen — auf welchem Node, in welcher Anzahl, mit welchen Ressourcen. Kubernetes entscheidet das selbst, basierend auf deinen Vorgaben.

Was Kubernetes nicht ist: ein einfacherer Weg, Docker auszuführen. Für einen einzelnen Server mit zwei Diensten ist docker compose die bessere Wahl. Kubernetes lohnt sich, sobald mehrere Nodes, hohe Verfügbarkeit oder komplexe Deployment-Strategien ins Spiel kommen.

Die wichtigsten Konzepte

Pod

Der kleinste Deployment-Baustein. Ein Pod enthält einen oder mehrere Container, die gemeinsam auf demselben Node laufen und sich Netzwerk und Storage teilen. In der Praxis: ein Pod, ein Container.

Pods sind flüchtig — wenn ein Pod stirbt, erstellt Kubernetes einen neuen. Die IP-Adresse ändert sich dabei. Deshalb spricht man nie direkt Pods an.

Deployment

Ein Deployment beschreibt den gewünschten Zustand: welches Image, wie viele Replikas, welche Ressourcenlimits. Kubernetes sorgt kontinuierlich dafür, dass dieser Zustand eingehalten wird. Wenn ein Pod abstürzt, wird er neu gestartet. Wenn du 3 Replikas willst und nur 2 laufen, startet Kubernetes einen dritten.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "200m"

Service

Ein Service ist ein stabiler Endpunkt vor einer Gruppe von Pods. Er hat eine feste IP und einen DNS-Namen innerhalb des Clusters, egal ob Pods neu gestartet werden oder ihre IP wechseln.

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Typen:

  • ClusterIP — nur intern im Cluster erreichbar (Default)
  • NodePort — öffnet einen Port auf jedem Node
  • LoadBalancer — provisoniert einen externen Load Balancer (Cloud-Provider oder MetalLB)

Namespace

Namespaces sind logische Trennebenen innerhalb eines Clusters. Nützlich um Umgebungen (dev, staging, prod) oder Teams voneinander zu isolieren.

kubectl create namespace production
kubectl get pods -n production

ConfigMap und Secret

Konfiguration gehört nicht ins Container-Image. ConfigMaps speichern nicht-sensible Konfiguration, Secrets sensible Daten wie Passwörter oder API-Keys.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: postgres
  LOG_LEVEL: info
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
stringData:
  DATABASE_PASSWORD: sicheres_passwort

Lokaler Einstieg mit k3s

Für HomeLab und Einstieg ist k3s die beste Wahl. Es ist ein vollständiges, zertifiziertes Kubernetes-Distribution das auf einem einzelnen Node mit 512 MB RAM läuft — ohne den Overhead einer vollständigen k8s-Installation.

k3s installieren (Single Node)

curl -sfL https://get.k3s.io | sh -

Das war es. k3s läuft als Systemd-Service. Kubeconfig liegt unter /etc/rancher/k3s/k3s.yaml.

# kubectl ist in k3s eingebaut
k3s kubectl get nodes

# Oder kubeconfig exportieren für lokales kubectl
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get nodes

Multi-Node mit k3s

Server (Control Plane):

curl -sfL https://get.k3s.io | sh -
# Token für Worker-Nodes:
cat /var/lib/rancher/k3s/server/node-token

Worker-Node:

curl -sfL https://get.k3s.io | K3S_URL=https://SERVER_IP:6443 \
  K3S_TOKEN=DEIN_TOKEN sh -

kubectl — die wichtigsten Befehle

# Ressourcen anzeigen
kubectl get pods
kubectl get pods -o wide          # mit Node und IP
kubectl get deployments
kubectl get services
kubectl get all                    # alles auf einmal

# Details
kubectl describe pod PODNAME
kubectl describe deployment nginx

# Logs
kubectl logs PODNAME
kubectl logs PODNAME -f            # live follow
kubectl logs PODNAME -c CONTAINER  # bei mehreren Containern

# Ressourcen anwenden / löschen
kubectl apply -f deployment.yaml
kubectl delete -f deployment.yaml
kubectl delete pod PODNAME

# In einen Pod einsteigen
kubectl exec -it PODNAME -- /bin/sh

# Deployment skalieren
kubectl scale deployment nginx --replicas=5

# Rollout-Status prüfen
kubectl rollout status deployment/nginx
kubectl rollout history deployment/nginx
kubectl rollout undo deployment/nginx  # letztes Deployment rückgängig

Erstes echtes Deployment

Eine einfache Nginx-Instanz mit Service und Ingress — alles in einer Datei:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx
  namespace: default
spec:
  rules:
  - host: nginx.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx
            port:
              number: 80
kubectl apply -f nginx.yaml
kubectl get pods
kubectl get ingress

k3s bringt Traefik als Ingress-Controller mit — der Ingress funktioniert direkt nach der Installation.

Wann Kubernetes, wann docker compose?

SzenarioEmpfehlung
Einzelner Server, wenige Dienstedocker compose
Mehrere Server, hohe VerfügbarkeitKubernetes / k3s
Zero-Downtime Deployments nötigKubernetes
Lernumgebung / HomeLabk3s
CI/CD, automatische SkalierungKubernetes
Schnell ausprobieren, kein Ops-Aufwanddocker compose

Nächste Schritte

Wenn das erste Deployment läuft, sind das die sinnvollen nächsten Themen:

  • Helm: Paketmanager für Kubernetes. Komplexe Anwendungen werden als Charts installiert statt als manuelle YAML-Dateien.
  • Persistent Volumes: Daten die einen Pod-Neustart überleben — notwendig für Datenbanken.
  • Resource Quotas: Limitierungen pro Namespace damit ein Dienst nicht den ganzen Cluster leer räumt.
  • RBAC: Zugriffsrechte im Cluster kontrollieren.
  • Monitoring: Prometheus + Grafana — der Standard-Stack für Kubernetes-Metriken.

Fazit

Kubernetes hat eine steile Lernkurve — das lässt sich nicht schönreden. Aber wer die Grundkonzepte (Pod, Deployment, Service) einmal verinnerlicht hat, merkt schnell wie viele Probleme Kubernetes automatisch löst, die mit docker compose manuell gemanagt werden müssen. k3s ist der ideale Einstieg: vollständiges Kubernetes, minimaler Overhead, läuft auf jedem Linux-Server mit 1 GB RAM.