Kubernetes unter 500 Euro: K3s-Cluster aufsetzen

TL;DR

• Ein 3-Node K3s-Cluster auf Raspberry Pi 4 (8 GB) kostet ca. 300-400 Euro Hardware; auf Hetzner Cloud ca. 15 Euro/Monat
• K3s ist ein vollwertiges, CNCF-zertifiziertes Kubernetes -- nur mit kleinerem Footprint (eine Binary, ~512 MB RAM fuer den Server-Prozess)
• Fuer Produktion auf Raspberry Pi: Unbedingt von SSD booten, nicht von SD-Karte (SD-Karten sterben unter Kubernetes-Workloads)
• Monitoring mit Prometheus + Grafana laeuft problemlos auf dem gleichen Cluster, solange Sie Resource Limits setzen
• Dieses Setup eignet sich fuer interne Tools, Staging-Umgebungen, IoT-Edge und Lernumgebungen -- nicht fuer hochverfuegbare, kundenseitige Produktions-APIs

Wann macht das Sinn?

Nicht jeder braucht einen Managed Kubernetes Service fuer 200+ Euro im Monat. Es gibt genuegend Szenarien, in denen ein guenstiger K3s-Cluster die bessere Wahl ist:

Lernumgebung: Sie wollen Kubernetes lernen, ohne Cloud-Kosten zu produzieren. Ein Raspberry-Pi-Cluster ist dafuer ideal -- anfassen, kaputtmachen, neu aufsetzen.

Interne Tools: Gitea, Drone CI, Wiki, Monitoring-Dashboards -- alles, was nur innerhalb des Teams genutzt wird und keine 99.99% SLA braucht.

Staging/Preview-Umgebungen: Pull-Request-Previews auf einem guenstigen Cluster statt auf teurer Cloud-Infrastruktur.

IoT Edge: K3s ist fuer Edge-Szenarien gebaut. Wenig RAM, wenig CPU, ARM-Architektur -- genau der Anwendungsfall.

Fuer kundenseitige Produktions-APIs mit hohen Verfuegbarkeitsanforderungen sollten Sie sich die Hosting-Kosten im Vergleich anschauen. Managed Services haben dort ihre Berechtigung.

Hardware-Vergleich: Raspberry Pi vs. Hetzner Cloud

Beide Varianten bleiben unter 500 Euro im ersten Jahr. Die Raspberry-Pi-Variante ist langfristig guenstiger, die Hetzner-Variante schneller einsatzbereit.

K3s auf Hetzner Cloud mit Terraform

Wenn Sie den Cloud-Weg gehen, automatisieren Sie die Infrastruktur mit Terraform. Hier ein minimales Setup fuer drei Nodes:

terraform {
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.45"
    }
  }
}

variable "hcloud_token" {
  sensitive = true
}

provider "hcloud" {
  token = var.hcloud_token
}

resource "hcloud_ssh_key" "k3s" {
  name       = "k3s-key"
  public_key = file("~/.ssh/id_ed25519.pub")
}

resource "hcloud_server" "k3s_server" {
  name        = "k3s-server"
  server_type = "cx22"
  image       = "ubuntu-24.04"
  location    = "fsn1"
  ssh_keys    = [hcloud_ssh_key.k3s.id]

  user_data = <<-EOF
    #!/bin/bash
    curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server \
      --disable traefik \
      --tls-san ${self.ipv4_address}" sh -
  EOF
}

resource "hcloud_server" "k3s_agent" {
  count       = 2
  name        = "k3s-agent-${count.index}"
  server_type = "cx22"
  image       = "ubuntu-24.04"
  location    = "fsn1"
  ssh_keys    = [hcloud_ssh_key.k3s.id]

  depends_on = [hcloud_server.k3s_server]
}

output "server_ip" {
  value = hcloud_server.k3s_server.ipv4_address
}

output "agent_ips" {
  value = hcloud_server.k3s_agent[*].ipv4_address
}

Nach terraform apply muessen Sie die Agents noch manuell mit dem Server verbinden (Token vom Server holen und auf den Agents installieren). Alternativ koennen Sie das ueber ein Provisioner-Script automatisieren.

# Token vom Server holen
ssh root@$(terraform output -raw server_ip) cat /var/lib/rancher/k3s/server/node-token

# Agents joinen (fuer jeden Agent ausfuehren)
ssh root@AGENT_IP "curl -sfL https://get.k3s.io | K3S_URL=https://$(terraform output -raw server_ip):6443 K3S_TOKEN=YOUR_TOKEN sh -"

# Kubeconfig holen
scp root@$(terraform output -raw server_ip):/etc/rancher/k3s/k3s.yaml ~/.kube/k3s-config
sed -i '' "s/127.0.0.1/$(terraform output -raw server_ip)/" ~/.kube/k3s-config
export KUBECONFIG=~/.kube/k3s-config
kubectl get nodes

K3s auf Raspberry Pi: Einkaufsliste und Setup

Falls Sie den Bare-Metal-Weg bevorzugen, hier die konkrete Einkaufsliste:

Wichtig: Booten Sie von SSD, nicht von SD-Karte. SD-Karten haben begrenzte Write-Cycles und sterben unter Kubernetes-Workloads (etcd, Logs, Container Layers) innerhalb von Wochen bis Monaten. USB-Boot ist beim Raspberry Pi 4 standardmaessig aktiviert.

Die K3s-Installation auf den Pis funktioniert analog zur Cloud-Variante. Installieren Sie zuerst ein aktuelles Ubuntu Server 24.04 (ARM64) oder Raspberry Pi OS Lite (64-bit) auf die SSDs.

Erste Workload deployen

Nach dem Cluster-Setup deployen Sie eine einfache Anwendung, um zu pruefen, ob alles funktioniert:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-test
  template:
    metadata:
      labels:
        app: nginx-test
    spec:
      containers:
      - name: nginx
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 50m
            memory: 32Mi
          limits:
            cpu: 100m
            memory: 64Mi
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-test
  namespace: default
spec:
  type: LoadBalancer
  selector:
    app: nginx-test
  ports:
  - port: 80
    targetPort: 80

Auf Hetzner Cloud bekommen Sie ueber den Hetzner Cloud Controller Manager automatisch eine oeffentliche IP. Auf dem Raspberry-Pi-Cluster nutzt K3s den integrierten ServiceLB (fruher Klipper), der auf den Node-IPs lauscht.

Resource Requests und Limits sind auf einem Budget-Cluster besonders wichtig. Ohne Limits kann ein einzelner Pod den gesamten Node lahmlegen. Mehr zum Thema im Artikel zu Resource Management.

Monitoring: Prometheus + Grafana

Auch ein kleiner Cluster braucht Monitoring. Der kube-prometheus-stack Helm Chart ist der schnellste Weg:

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 prometheus.prometheusSpec.retention=7d \
  --set prometheus.prometheusSpec.resources.requests.memory=256Mi \
  --set prometheus.prometheusSpec.resources.limits.memory=512Mi \
  --set grafana.resources.requests.memory=128Mi \
  --set grafana.resources.limits.memory=256Mi \
  --set alertmanager.enabled=false

Die reduzierten Memory-Limits sind fuer den Budget-Cluster angepasst. Standard-Werte gehen von Nodes mit 16+ GB RAM aus und wuerden hier sofort OOM-Kills produzieren. Wenn Sie OOM-Kills vermeiden wollen, lesen Sie den Artikel zu OOM-Kills in Kubernetes vermeiden.

Storage-Optionen

K3s bringt den local-path-provisioner mit, der automatisch lokale Verzeichnisse als PersistentVolumes bereitstellt. Das funktioniert, hat aber einen grossen Nachteil: Daten sind an einen bestimmten Node gebunden. Wenn der Node ausfaellt, sind die Daten weg.

Fuer persistente, replizierte Daten auf dem Raspberry-Pi-Cluster gibt es zwei pragmatische Optionen:

NFS-Share: Einfach, bewaehrt, funktioniert. Einer der Pis (oder ein bestehendes NAS) stellt ein NFS-Share bereit, das alle Nodes mounten. Nicht schnell, aber fuer die meisten Workloads ausreichend.

Longhorn: Distributed Block Storage von Rancher, speziell fuer Kubernetes. Repliziert Daten ueber mehrere Nodes. Braucht allerdings mehr RAM und CPU als NFS. Auf 8-GB-Nodes machbar, aber eng.

Fuer eine tiefere Betrachtung der Storage-Optionen empfehle ich den Artikel zu Kubernetes Storage.

Was dieses Setup nicht kann

Ehrlichkeit gehoert dazu. Ein 500-Euro-Cluster hat Grenzen:

Keine echte Hochverfuegbarkeit: Mit einem einzigen Control-Plane-Node ist der Cluster nicht HA. Faellt der Server-Node aus, ist der gesamte Cluster nicht mehr steuerbar (laufende Workloads auf den Agents laufen weiter, aber kein neues Scheduling). K3s unterstuetzt embedded etcd fuer Multi-Server-HA, aber das braucht mindestens 3 Server-Nodes.

Begrenzte Rechenleistung: Ein Raspberry Pi 4 hat weniger CPU-Power als ein durchschnittliches Smartphone. Fuer CPU-intensive Workloads (Builds, ML-Training, Video-Encoding) ist das Setup ungeeignet.

Kein Autoscaling: Sie haben drei Nodes, Punkt. Mehr Kapazitaet erfordert mehr Hardware. Auf Hetzner Cloud koennen Sie manuell Nodes hinzufuegen, aber echtes Cluster-Autoscaling gibt es nur bei Managed Services.

ARM-Kompatibilitaet (nur Raspberry Pi): Nicht jedes Container-Image ist fuer ARM64 verfuegbar. Die meisten populaeren Images (nginx, postgres, redis, node) bieten Multi-Arch-Builds. Bei Nischen-Software muessen Sie ggf. selbst bauen.

Kosten im ersten Jahr

Ab dem zweiten Jahr ist der Raspberry-Pi-Cluster deutlich guenstiger. Die Hetzner-Variante ist im ersten Jahr billiger und erfordert null Hardware-Management.

Zusammenfassung

Ein Kubernetes-Cluster fuer unter 500 Euro ist nicht nur moeglich, sondern fuer viele Anwendungsfaelle die richtige Wahl. K3s hat sich als leichtgewichtige, produktionsreife Distribution etabliert, die auf kleiner Hardware zuverlaessig laeuft.

Der wichtigste Rat: Starten Sie einfach. Ein einzelner Raspberry Pi mit K3s reicht, um die Grundlagen zu lernen. Skalieren Sie spaeter, wenn Sie wissen, was Sie brauchen.

Weitere relevante Artikel:

• Capacity Planning: Cluster richtig dimensionieren
• Performance-Optimierung fuer Kubernetes
• GitOps-Workflows fuer Kubernetes

Wenn Sie Unterstuetzung beim Setup oder bei der Migration bestehender Workloads auf Kubernetes benoetigen, erreichen Sie uns unter /kontakt.