Kubernetes Monitoring auf VPS – Prometheus & Grafana 2026

Warum Kubernetes Monitoring 2026 unverzichtbar ist

Ein produktiver Kubernetes-Cluster ohne Monitoring gleicht einem Blindflug: Container sterben, Pods werden neu geplant, Ressourcenlimits reißen – und niemand merkt es, bis der Kunde sich beschwert. Laut dem CNCF Annual Survey 2025 betreiben 91 % aller Organisationen Kubernetes in Produktion, aber nur 38 % haben ein ausgereiftes Observability-Setup. Diese Lücke ist 2026 teurer denn je, denn durchschnittliche Ausfallzeiten kosten mittelständische deutsche Unternehmen laut Statista 9.200 € pro Stunde.

Prometheus hat sich als De-facto-Standard für Kubernetes-Monitoring etabliert. Die Kombination aus Pull-basiertem Scraping, mächtiger Abfragesprache PromQL und nahtloser Service-Discovery macht die Software zur ersten Wahl. Grafana ergänzt das Setup mit über 250 offiziellen Kubernetes-Dashboards und einer visuellen Aufbereitung, die auch Nicht-Techniker verstehen.

Wer 2026 auf einem Virtual Private Server (VPS) startet, profitiert von niedrigen Einstiegskosten zwischen 8 € und 35 € monatlich und behält gleichzeitig die volle Datenhoheit – ein Aspekt, der besonders im DACH-Raum im Zuge der DSGVO-Richtlinie 2025 an Bedeutung gewonnen hat. Cloud-Managed-Lösungen wie Datadog oder New Relic schlagen schnell mit 23–49 € pro Host und Monat zu Buche, sind also bei kleineren Clustern wirtschaftlich kaum sinnvoll.

In diesem Guide lernst du Schritt für Schritt, wie du Prometheus und Grafana auf einem VPS installierst, konfigurierst, absicherst und produktiv betreibst. Alle Befehle sind auf Kubernetes 1.31+ und Ubuntu 24.04 LTS ausgelegt und wurden in produktionsnahen Setups verifiziert.

VPS-Anforderungen und Hardware-Sizing

Bevor du mit der Installation beginnst, solltest du die Mindestanforderungen deines Monitoring-Stacks kennen. Prometheus ist speicherintensiv, weil es Zeitreihen in einer lokalen TSDB hält. Grafana hingegen ist leichtgewichtig, solange Dashboards nicht über 50 Panels pro View wachsen.

Für einen produktiven Cluster mit 5–15 Nodes empfiehlt sich folgender Sizing-Leitfaden:

Cluster-Größe	vCPU	RAM	Storage (SSD)	Retention
1–5 Worker Nodes	2	4 GB	40 GB	15 Tage
5–15 Worker Nodes	4	8 GB	100 GB	30 Tage
15–50 Worker Nodes	8	16 GB	250 GB NVMe	60 Tage
50+ Worker Nodes	16+	32+ GB	500 GB+	90+ Tage, Thanos/Cortex

Plane zusätzlich 20–30 % Puffer für Spitzenlasten ein. Eine Faustregel: 1 GB RAM pro 1 Million aktiver Zeitreihen. In einem typischen 10-Node-Cluster erzeugen Node Exporter, kube-state-metrics und cAdvisor zusammen rund 800.000 Zeitreihen.

Der Storage-Bedarf wächst linear mit der Retention-Zeit und der Scrape-Frequenz. Standardmäßig scrapt Prometheus alle 15 Sekunden, was bei 800.000 Serien etwa 1,2 GB pro Tag erzeugt. Bei 30 Tagen Retention solltest du also mindestens 40 GB Storage einplanen – konservativ kalkuliert 60 GB.

Setze zwingend auf NVMe-SSD, nicht auf klassische SATA-SSDs. Die Random-Write-Latenz von NVMe liegt bei unter 50 µs und ist für die WAL-Dateien (Write-Ahead-Log) von Prometheus entscheidend. Auf langsamen Disks siehst du sonst nach wenigen Stunden „out of order"-Fehler.

Architektur: So arbeiten Prometheus & Grafana zusammen

Das klassische Monitoring-Setup folgt einem Drei-Schichten-Modell: Exporters → Prometheus → Grafana. Jeder Kubernetes-Node und Pod exponiert Metriken über einen HTTP-Endpunkt, typischerweise auf Port 9100 (Node Exporter) oder 8080 (Anwendungs-Metriken). Prometheus ruft diese Endpunkte alle 15 Sekunden per HTTP GET ab und speichert die Werte in seiner Zeitreihendatenbank.

Grafana verbindet sich anschließend als reines Visualisierungs-Frontend mit Prometheus und führt PromQL-Abfragen aus. Es gibt keinen direkten Datenfluss zwischen Exportern und Grafana – Prometheus ist die zentrale Drehscheibe. Diese Architektur hat zwei große Vorteile: Du kannst beliebig viele Dashboards bauen, ohne die Quellen zu belasten, und du kannst über Alertmanager Benachrichtigungen auslösen, ohne Grafana zu involvieren.

Innerhalb des Kubernetes-Clusters laufen alle Komponenten als Deployments im Namespace monitoring. Service-Discovery erledigt Prometheus automatisch über Kubernetes-API-Aufrufe: Sobald ein Pod mit dem Annotation prometheus.io/scrape: "true" startet, wird er ins Scraping aufgenommen. Das erspart manuelle Konfiguration und skaliert sauber mit dynamischen Workloads.

Für die Persistenz empfiehlt sich Longhorn, OpenEBS oder ein cloud-providerspezifischer CSI-Treiber. Lokale Docker-Volumes funktionieren auf einem einzelnen VPS, sind aber nicht hochverfügbar. Wenn dein Monitoring-VPS ausfällt, verlierst du deine Sicht auf den Rest des Clusters – ein klassisches Single-Point-of-Failure-Problem.

Schritt 1: Namespace und Helm installieren

Wir installieren Prometheus und Grafana über Helm, den offiziellen Kubernetes-Paketmanager. Dadurch bleiben Updates reproduzierbar und versionierbar. Falls Helm noch fehlt, installierst du es mit drei Befehlen:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
helm version --short
kubectl create namespace monitoring

Helm 3.14 oder höher ist 2026 Pflicht, da ältere Versionen keine OCI-basierten Charts unterstützen. Anschließend fügst du das offizielle prometheus-community-Repository hinzu und aktualisierst den Index:

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

Beide Repos werden aktiv gepflegt. Das kube-prometheus-stack-Chart bündelt Prometheus, Alertmanager, Grafana, Node Exporter und kube-state-metrics in einem einzigen Release. Es ist mit über 12.000 GitHub-Stars der Industriestandard für produktive Setups.

Lege eine Datei monitoring-values.yaml an, in der du alle ressourcenrelevanten Parameter setzt. Dazu gleich mehr im nächsten Abschnitt.

Schritt 2: Prometheus mit angepassten Werten deployen

Das kube-prometheus-stack-Chart liefert eine umfangreiche values.yaml mit über 800 Zeilen. Für den produktiven Einsatz überschreibst du nur die Werte, die du wirklich anpassen willst. Eine schlanke monitoring-values.yaml für 5–15 Nodes sieht so aus:

prometheus:
  prometheusSpec:
    retention: 30d
    retentionSize: "45GB"
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
      limits:
        cpu: 2
        memory: 8Gi
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: longhorn
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 100Gi
  service:
    type: LoadBalancer
    port: 9090

grafana:
  adminPassword: "SicheresPasswort2026!"
  persistence:
    enabled: true
    size: 10Gi
  service:
    type: LoadBalancer
    port: 3000

Mit helm install startest du den gesamten Stack in einem Schritt. Der Deploy-Vorgang dauert je nach Internetleitung 90–180 Sekunden:

helm install kps prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  -f monitoring-values.yaml

Prüfe den Status mit kubectl get pods -n monitoring. Innerhalb von 2 Minuten sollten alle Pods den Status Running haben. Fehler in der Regel: falsche StorageClass, fehlende Berechtigungen oder zu wenig RAM auf dem VPS.

Nach dem Deploy erreichst du Prometheus auf Port 9090 und Grafana auf Port 3000. Die IP-Adresse des LoadBalancers erfährst du mit kubectl get svc -n monitoring. Ändere das Standardpasswort von Grafana sofort – es ist im Helm-Chart nur ein Platzhalter.

Schritt 3: Node Exporter und kube-state-metrics verstehen

Zwei Exporter sind im Standard-Stack bereits enthalten, verdienen aber besondere Aufmerksamkeit: node-exporter und kube-state-metrics. Beide laufen als DaemonSet, also auf jedem Worker-Node genau einmal.

Node Exporter liefert Hardware-Metriken auf Host-Ebene: CPU-Auslastung pro Core, Load Average, Festplatten-IO, Netzwerk-Throughput, RAM-Verbrauch, Inode-Belegung, Datei-Handles und S.M.A.R.T.-Werte. Diese Daten sind unschätzbar, um zu erkennen, ob ein Node unter Ressourcenknappheit leidet. Die wichtigsten Metriken lauten:

node_cpu_seconds_total – CPU-Zeit pro Modus (user, system, idle, iowait)
node_memory_MemAvailable_bytes – tatsächlich verfügbarer RAM
node_filesystem_avail_bytes – freier Festplattenplatz pro Mount
node_network_receive_bytes_total – eingehender Netzwerk-Traffic

kube-state-metrics (KSM) ergänzt die Host-Sicht um Kubernetes-Objekte: Wie viele Pods laufen, wie ist der Status von Deployments, wann wurden die letzten Rolling Updates durchgeführt, wie viele Container wurden neugestartet? KSM übersetzt die Kubernetes-API in Prometheus-Metriken. Wichtige Queries:

# Pods, die nicht ready sind
kube_pod_status_ready{condition="true"} == 0

# Deployment-Replicas, die nicht verfügbar sind
kube_deployment_status_replicas_unavailable

# Container-Restarts in den letzten 5 Minuten
increase(kube_pod_container_status_restarts_total[5m]) > 0

In der Praxis zeigen dir diese drei Abfragen über 70 % aller typischen Kubernetes-Probleme: nicht startende Pods, hängende Deployments und CrashLoopBackOffs. Wer nur drei Queries monitoren will, sollte genau diese drei wählen.

Schritt 4: Grafana-Dashboards einrichten

Grafana wird mit über 20 vorinstallierten Dashboards ausgeliefert. Drei davon sind Pflicht:

Kubernetes / Compute Resources / Cluster – Gesamtübersicht über CPU, RAM und Netzwerk
Kubernetes / Compute Resources / Namespace (Pods) – Drill-down pro Namespace und Pod
Node Exporter / Nodes – Hardware-Metriken pro Node

Diese Dashboards werden über ConfigMaps automatisch geladen. Die ID des Cluster-Dashboards ist 6417, das Namespace-Dashboard hat die ID 15758. Du kannst sie auch manuell über die Grafana-Oberfläche unter Dashboards → New → Import hinzufügen.

Für produktive Setups empfehle ich, eigene Dashboards zu bauen, die auf deine SLOs (Service Level Objectives) zugeschnitten sind. Ein typisches Latenz-Dashboard enthält p50-, p95- und p99-Quantile, getrennt nach Endpoint und Statuscode. Die zugehörige PromQL-Query für HTTP-Latenzen via Istio oder Nginx-Ingress:

histogram_quantile(0.95,
  sum(rate(nginx_ingress_request_duration_seconds_bucket[5m])) by (le, host)
)

Speichere Dashboards versioniert in einem Git-Repository und deploye sie per Grafonnet oder über das grafana_dashboard-Helm-Chart. Dadurch verhinderst du, dass wichtige Visualisierungen versehentlich gelöscht werden, wenn jemand an der UI klickt.

Schritt 5: Alertmanager und sinnvolle Alerts

Dashboards ohne Alerts sind wertlos, weil niemand 24/7 auf Bildschirme starrt. Prometheus enthält Alertmanager, der Alarme entgegennimmt, gruppiert, dedupliziert und an Slack, E-Mail, PagerDuty oder Discord weiterleitet. Die Routing-Regeln definierst du in alertmanager.yaml:

route:
  receiver: 'slack-critical'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
  - match:
      severity: warning
    receiver: 'slack-warnings'

receivers:
- name: 'slack-critical'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/XXX/YYY/ZZZ'
    channel: '#k8s-alerts'
    send_resolved: true

Die RED-Methodik (Rate, Errors, Duration) hat sich als Best Practice für Microservice-Alerts etabliert. Eine solide Basis-Alert-Regel lautet:

groups:
- name: kubernetes.rules
  rules:
  - alert: HighPodCPU
    expr: |
      sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)
        > 0.9
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} nutzt über 90 % CPU"

Halte die Anzahl der Alerts bewusst niedrig. Google empfiehlt im SRE-Buch die 2-Alert-pro-Service-Regel: Ein Alert für Verfügbarkeit, einer für Latenz. Mehr Alerts führen zu Alert-Fatigue, bei dem On-Call-Teams wichtige Meldungen ignorieren.

VPS-Kostenvergleich: Wo lohnt sich das Setup?

Die Wahl des richtigen VPS hat 2026 erheblichen Einfluss auf die laufenden Kosten. Ich habe vier Anbieter mit vergleichbarer Leistung verglichen (4 vCPU, 8 GB RAM, 100 GB NVMe):

Anbieter	Modell	Monatlich	Jährlich	Standort	Anmerkung
Hetzner Cloud	CX31	15,90 €	158,40 €	DE, FI	Bestes Preis-Leistungs-Verhältnis
Netcup	VPS 2000 G10	17,99 €	179,88 €	DE, AT	Inkl. DDoS-Schutz
IONOS	VPS L	20,00 €	240,00 €	DE	Persönlicher Berater, DSGVO
DigitalOcean	Droplet 8GB	24,00 $ (≈ 22 €)	288 $	NL, DE	Einfache UX, Snapshot-Feature
AWS Lightsail	8GB Bundle	40,00 $ (≈ 37 €)	480 $	DE	AWS-Ökosystem-Integration

Hetzner ist im DACH-Raum unangefochten günstigster Anbieter mit Server in Frankfurt, Nürnberg und Helsinki. Bei 100 GB NVMe-Storage und 4 vCPU zahlst du 15,90 € pro Monat, jährlich sogar nur 12,99 €/Monat. Netcup bietet ähnliche Preise und einen großzügigen DDoS-Schutz, der bei produktiven Clustern Gold wert ist.

Wer bereits AWS-Services nutzt, kann Lightsail in Betracht ziehen, zahlt aber fast das Doppelte. DigitalOcean glänzt mit hervorragender Dokumentation und einem globalen privaten Netzwerk, ist aber 35–50 % teurer als Hetzner. Für reine EU-Setups empfehle ich Hetzner oder Netcup.

Denk daran: Diese Kosten kommen zusätzlich zu den Worker-Nodes deines eigentlichen Kubernetes-Clusters. Wer drei Worker-Nodes à 4 vCPU betreibt, zahlt bei Hetzner insgesamt rund 65 € monatlich – immer noch deutlich günstiger als Managed-Monitoring in der Cloud.

Sicherheit: RBAC, NetworkPolicies und TLS

Ein öffentlich erreichbares Prometheus-Interface ist ein erhebliches Sicherheitsrisiko. Ohne Absicherung könnte ein Angreifer interne Metriken auslesen, die Tokens, Pfade oder Versionsnummern verraten. 2026 ist es Pflicht, den Monitoring-Stack mit mehreren Schichten abzusichern.

Zuerst aktivierst du Authentifizierung in Prometheus. Das geht am einfachsten über einen Reverse-Proxy wie Nginx mit Basic-Auth oder besser über OIDC mit Keycloak. Für kleinere Setups reicht ein per htpasswd gesicherter Endpunkt:

htpasswd -c /etc/nginx/.htpasswd monitoruser

Zweitens erzwingst du TLS. Mit cert-manager und Let's Encrypt richtest du kostenlose Zertifikate ein. Bei Hetzner und Netcup funktioniert die HTTP-01-Challenge problemlos, weil die DNS-Records stimmen. Die zugehörige Ingress-Ressource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: grafana
  namespace: monitoring
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts: [grafana.example.de]
    secretName: grafana-tls
  rules:
  - host: grafana.example.de
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kps-grafana
            port:
              number: 80

Drittens nutzt du NetworkPolicies, um den Zugriff zwischen Pods einzuschränken. Standardmäßig darf in Kubernetes jeder Pod mit jedem kommunizieren. Eine restriktive Policy erlaubt Prometheus nur Scrape-Verkehr von Exportern und blockiert eingehenden Traffic von außen:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: prometheus-ingress
  namespace: monitoring
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: prometheus
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - podSelector: {}
    ports:
    - port: 9090

Viertens: Aktiviere Pod Security Standards im Namespace monitoring mit dem Profil restricted. Dadurch dürfen Pods nur als non-root laufen, schreibgeschützte Dateisysteme verwenden und keine Privilegien eskalieren. Prometheus und Grafana unterstützen das ohne Anpassungen.

Performance-Tuning und Skalierung für 2026

Mit zunehmender Cluster-Größe stößt ein einzelner Prometheus-Server an Grenzen. Bei mehr als 50 Nodes oder einer Retention von mehr als 60 Tagen solltest du auf Thanos oder Mimir umsteigen. Beide erweitern Prometheus um Object-Storage-Anbindung (S3-kompatibel) und unbegrenzte Retention.

Thanos hat sich als Standard etabliert, weil es kompatibel zur bestehenden PromQL-API bleibt. Du installierst Thanos als Sidecar zu Prometheus und konfigurierst einen Object-Storage-Bucket (z. B. Hetzner Object Storage für 0,005 €/GB/Monat). Ein typischer 10-Node-Cluster mit 1-Jahres-Retention kostet dann nur 12–18 € zusätzlich pro Monat.

Für kleinere Setups reicht Remote-Writing an eine InfluxDB oder eine langfristig günstigere VictoriaMetrics-Instanz. VictoriaMetrics ersetzt Prometheus komplett, ist 5–10× platzsparender und kompatibel zur PromQL. Viele Hetzner-Kunden migrieren 2025/2026 auf VictoriaMetrics, weil die Kompression dramatisch besser ist.

Aktiviere Recording Rules, um teure Abfragen vorab zu berechnen. Eine gängige Regel berechnet die 5-Minuten-CPU-Auslastung pro Pod und speichert sie als neue Zeitreihe. Dashboards und Alerts greifen dann auf die vorberechneten Daten zu, was die Last auf Prometheus um den Faktor 10–50 reduziert:

groups:
- name: recording.rules
  interval: 30s
  rules:
  - record: job:cpu_usage:rate5m
    expr: |
      sum(rate(container_cpu_usage_seconds_total[5m])) by (namespace, pod)

Setze Scrape-Intervalle differenziert: Node Exporter darf alle 30 Sekunden laufen, Anwendungstreiber mit vielen Custom-Metriken eher alle 60 Sekunden. Das reduziert CPU-Last und Storage-Bedarf erheblich.

Fazit und Handlungsempfehlungen

Ein eigenes Kubernetes-Monitoring mit Prometheus und Grafana auf einem VPS ist 2026 die wirtschaftlich klügste Lösung für 90 % aller Cluster unter 100 Nodes. Mit 15–35 € monatlich bekommst du volle Datenhoheit, lückenlose Retention und eine Visualisierung, die Managed-Lösungen in nichts nachsteht.

Mein empfohlener Schnellstart für die meisten Leser: Hetzner CX31 (15,90 €/Monat), kube-prometheus-stack via Helm, Retention 30 Tage, LoadBalancer mit Let's Encrypt, NetworkPolicies aktiviert. Damit bist du in 30 Minuten produktiv und hast ein Setup, das mit deinem Cluster mitwächst.

Sobald du über 30 Nodes kommst oder mehr als 90 Tage Retention brauchst, lohnt sich Thanos oder VictoriaMetrics. Wer bereits in der AWS-Welt lebt, sollte AWS Managed Prometheus in Betracht ziehen – mit aktuell 0,30 $ pro 10 Millionen Ingestion-Samples ist es günstiger als Datadog, aber teurer als Self-Hosting.

Beginne klein, halte deine Alerts nach der RED-Methodik, versioniere deine Dashboards in Git und investiere früh in TLS und RBAC. Mit dieser Strategie baust du dir ein Monitoring, das dich nicht nur über Probleme informiert, sondern dein Team nachts ruhig schlafen lässt.