Die Infrastruktur hinter der Infrastruktur

Donnerstag, 2:47 Uhr nachts. Der Kubernetes-Cluster in Falkenstein läuft seit vier Monaten stabil. Sechs Entwickler in Köln haben drei Hetzner-Server mit K3s aufgesetzt, Traefik konfiguriert, die CI/CD-Pipeline eingerichtet. Alles läuft. Bis jetzt.

PostgreSQL erreicht seine Verbindungsgrenze, doch kein Alarm geht los, keine Benachrichtigung erscheint. Der API-Server liefert Timeout-Fehler an die Endnutzer. Drei Stunden später, um kurz vor sechs, fällt es dem ersten Entwickler auf, weil die morgendliche Cronjob-E-Mail ausgeblieben ist. Bis das Problem behoben ist, vergehen weitere 90 Minuten. Vier Stunden Ausfall, weil niemand hingeschaut hat.

Container-Orchestrierung ohne Monitoring, ohne Datenbank-Hochverfügbarkeit, ohne Backup-Strategie ist wie ein Auto ohne Armaturenbrett. Es fährt. Aber der Fahrer merkt nicht, dass der Öldruck sinkt. Dieser letzte Teil der Serie behandelt die Bausteine, die ein Container-Cluster zuverlässig machen: Monitoring, Datenbank-HA, Logging, Backups und Security-Grundlagen.

Monitoring: Warum Prometheus und Grafana zum Standard wurden

Prometheus sammelt Metriken, Grafana macht sie sichtbar. Diese Kombination hat sich als Industriestandard durchgesetzt, nicht weil sie die einzige Option ist, sondern weil sie kostenlos, gut dokumentiert und tief in die Kubernetes-Welt integriert ist. 2018 wurde Prometheus von der Cloud Native Computing Foundation als zweites Projekt nach Kubernetes selbst in den „graduated“-Status aufgenommen. Dieser Status sagt einiges über die Bedeutung.

Das Prinzip ist simpel. Prometheus fragt regelmäßig die Endpunkte aller überwachten Dienste ab, ein Vorgang namens Scraping. Jeder Container stellt seine Metriken über einen HTTP-Endpunkt bereit: CPU-Auslastung, Speicherverbrauch, Anzahl der Anfragen, Fehlerrate, Antwortzeiten. Grafana verbindet sich mit Prometheus und zeigt die Daten als Dashboards an. Farben, Graphen, Schwellenwerte. Grün heißt alles in Ordnung, Rot bedeutet Handlungsbedarf.

Beim Aufsetzen eines Prometheus-Stacks in Kubernetes hat sich der kube-prometheus-stack als Einstiegspunkt bewährt. Per Helm-Chart installiert das Team Prometheus, Grafana, Alertmanager und eine Sammlung vorkonfigurierter Dashboards für Kubernetes-Metriken. Nach 20 Minuten sieht das Team CPU-Auslastung pro Node, Speicherverbrauch pro Pod, Netzwerkdurchsatz und Festplatten-IO. 80 Prozent der Teams kommen mit dieser Grundkonfiguration ohne Anpassungen aus. Retention sollte allerdings von Anfang an konfiguriert werden: Prometheus speichert standardmäßig 15 Tage Daten, was für Kapazitätsplanung und Trendanalyse zu kurz sein kann.

Welche Metriken sind wirklich wichtig?

Googles SRE-Buch hat mit den „Four Golden Signals“ einen Rahmen definiert, der sich bewährt hat. Vier Metriken, nicht 40. Latenz misst, wie schnell ein Dienst antwortet. Traffic erfasst, wie viele Anfragen pro Sekunde eingehen. Die Fehlerrate zeigt den Anteil gescheiterter Anfragen. Saturation beschreibt, wie nah ein Dienst an seiner Kapazitätsgrenze arbeitet.

Container-Umgebungen bringen spezifische Metriken mit. CPU- und Speicherlimits gegenüber der tatsächlichen Nutzung sind entscheidend, weil Kubernetes einen Container beendet, der sein Speicherlimit überschreitet, und Neustart-Zähler liefern dabei Hinweise auf wiederkehrende Crashes oder OOM-Kills. Pod-Evictions zeigen an, dass ein Node seinen Speicher erschöpft und Kubernetes Pods herauswirft. Startet ein Container alle fünf Minuten neu, funktioniert er technisch, ist aber eine tickende Zeitbombe.

Meine Erfahrung: Der größte Fehler beim Monitoring ist nicht zu wenig Daten, sondern zu viele Alerts. Wer bei jedem Anstieg der CPU-Last eine Benachrichtigung bekommt, ignoriert nach zwei Wochen alle Benachrichtigungen. Alert Fatigue nennt sich dieses Phänomen, und es ist gefährlicher als gar kein Monitoring, weshalb Alerts auf Symptome gehören und nicht auf Ursachen. Nicht „CPU über 80 Prozent“, sondern „Antwortzeit über zwei Sekunden für fünf Minuten“. Nur dann wird das Team gestört, wenn Endnutzer tatsächlich betroffen sind.

Konkret heißt das: Prometheus löst einen Alert aus, wenn die Antwortzeit eines Service fünf Minuten lang über zwei Sekunden liegt, und schickt ihn via Alertmanager an Slack oder PagerDuty, idealerweise mit einem Link zum Runbook, das die ersten Diagnoseschritte beschreibt.

Was bietet der LGTM-Stack darüber hinaus?

Grafana Labs hat mit dem LGTM-Stack eine Observability-Plattform aus vier Komponenten gebaut: Loki für Logs, Grafana für Visualisierung, Tempo für Distributed Traces, Mimir für die langfristige Speicherung von Metriken. Alle vier sind Open Source unter AGPLv3-Lizenz und kostenlos nutzbar. Prometheus bleibt dabei die Sammelschicht für Metriken, und Mimir ergänzt es als horizontally scalable Langzeitspeicher, was Prometheus allein nicht gut beherrscht. Zusammen ergeben diese fünf Werkzeuge eine vollständige Observability-Lösung ohne Lizenzkosten.

SigNoz hat sich als Alternative positioniert: eine einzige Plattform für Metriken, Logs und Traces, basierend auf OpenTelemetry. Eine Oberfläche statt fünf Werkzeuge, das klingt verlockend. Allerdings ist die Community kleiner, vorgefertigte Dashboards gibt es weniger, und bei spezifischen Integrationen stößt SigNoz schneller an Grenzen. Teams, die den Betriebsaufwand minimieren wollen und keine ausgefallenen Anforderungen haben, sollten SigNoz in Betracht ziehen. Ab 50 Services im Cluster bleibt der LGTM-Stack die sicherere Wahl.

Datenbank-Hochverfügbarkeit: Das schwierigste Stück

Container sind entworfen, um jederzeit beendet und neu gestartet zu werden. Datenbanken nicht. Eine PostgreSQL-Instanz braucht persistenten Speicher, konsistente Verbindungen und im Idealfall eine zweite Instanz, die bei einem Ausfall übernimmt, und genau diese Spannung zwischen zustandsloser Container-Welt und zustandsbehafteter Datenbank bleibt der schwierigste Teil jedes Container-Deployments. Unterschätzt wird er trotzdem.

Patroni löst das Problem für PostgreSQL. Entwickelt bei Zalando, verwaltet Patroni einen PostgreSQL-Cluster mit automatischem Failover, wobei der Primary-Server Schreibzugriffe entgegennimmt und eine oder mehrere Replicas synchrone Kopien der Daten halten. Fällt der Primary aus, wählt Patroni innerhalb weniger Sekunden eine Replica zum neuen Primary. Die Anwendung merkt bestenfalls einen kurzen Verbindungsabbruch.

In Kubernetes-Umgebungen hat sich CloudNativePG als modernere Alternative etabliert. Dieser Operator, entwickelt von EnterpriseDB, verwaltet den gesamten Lebenszyklus einer PostgreSQL-Instanz (Installation, Konfiguration, Backups, Replikation und Failover), sodass operatives Wissen im Operator-Code steckt und nicht im Kopf eines einzelnen Administrators. Per YAML-Manifest beschreibt das Team den gewünschten Zustand (drei Instanzen, tägliche Backups auf S3, automatisches Failover), und der Operator setzt ihn um.

Wie läuft ein Failover konkret ab?

Konkretes Szenario: Drei PostgreSQL-Instanzen laufen auf drei Kubernetes-Nodes. Der Primary auf Node 1 verliert die Netzwerkverbindung. Patroni (oder CloudNativePG) erkennt den Ausfall innerhalb von 30 Sekunden, eine Replica auf Node 2 wird zum neuen Primary befördert, und die dritte Instanz richtet ihre Replikation auf den neuen Primary aus. Anwendungen, die über einen PgBouncer oder einen Kubernetes-Service verbunden sind, verlieren für wenige Sekunden die Verbindung und verbinden sich automatisch neu. Von außen betrachtet sieht der Ausfall aus wie ein kurzer Schluckauf, nicht wie ein vierstündiger Totalausfall.

Sauber klingt das, doch in der Praxis gibt es Fallstricke. Split-Brain-Szenarien entstehen, wenn beide Instanzen glauben, sie seien der Primary. Patroni verhindert das über einen Distributed Consensus Store (etcd, Consul, ZooKeeper oder die Kubernetes-API), der als Schiedsrichter fungiert. Ohne diesen Konsens-Dienst ist automatisches Failover ein Glücksspiel. CloudNativePG nutzt stattdessen die Kubernetes-eigene Leader-Election, was eine zusätzliche Komponente spart.

Wann lohnt sich eine managed Datenbank?

Die ehrliche Antwort: öfter, als viele DevOps-Teams zugeben wollen, denn PostgreSQL mit Patroni selbst betreiben kostet zwar keine Lizenz, aber erhebliche Arbeitszeit. Allein die Einrichtung dauert ein bis zwei Tage. Laufende Wartung (Minor-Updates, WAL-Archivierung prüfen, Replica-Lag kontrollieren, Patroni-Konfiguration pflegen) kommt auf sechs bis zwölf Stunden pro Monat.

Managed-PostgreSQL-Dienste nehmen diese Arbeit ab. AWS RDS kostet ab 20 Euro im Monat für eine kleine Instanz (db.t4g.micro), Multi-AZ-Setups mit automatischem Failover ab 50 Euro. Ubicloud bietet managed PostgreSQL auf Hetzner-Infrastruktur ab 12 Dollar pro Monat und ist damit die günstigste Option für Teams, die ihre Daten in deutschen Rechenzentren halten wollen. Hetzner selbst bietet keinen nativen managed-PostgreSQL-Service an. Ubicloud läuft auf Hetzner-Servern, ist aber ein eigenständiger Drittanbieter. Wichtig bei managed Services: Die Datenbank sollte im selben Rechenzentrum wie der Cluster laufen, denn eine managed-DB in einer anderen Region fügt bei jeder Abfrage Millisekunden Latenz hinzu, die sich unter Last schnell summieren.

Für ein Team ohne Datenbank-Spezialisten ist ein managed Service fast immer die richtige Entscheidung. PostgreSQL-Administration sieht in ruhigen Wochen trivial aus. Aber wenn ein Major-Upgrade ansteht (aktuell Version 18), wenn die WAL-Archivierung plötzlich 40 GB pro Tag produziert oder wenn der Replica-Lag auf drei Minuten anwächst, braucht es Spezialwissen, das in vielen Entwicklungsteams fehlt.

Logging und Tracing: Fehler in verteilten Systemen finden

Auf einem einzelnen Server genügt ein Blick in die Logdatei, doch in einem Cluster mit 15 Containern auf drei Nodes verteilen sich die Logs auf drei Maschinen und 15 Ausgabeströme. Den Fehler finden heißt: wissen, wo suchen.

Zentralisiertes Logging sammelt alle Logs an einem Ort, und Loki, entwickelt von Grafana Labs, hat sich als leichtgewichtige Alternative zum ELK-Stack (Elasticsearch, Logstash, Kibana) durchgesetzt. Entscheidend ist: Loki indiziert nicht den Inhalt der Logs, sondern nur die Metadaten, sogenannte Labels. Welcher Namespace, welcher Pod, welcher Container. Das spart Speicherplatz und Rechenleistung in einer Größenordnung, die bei 50 Containern den Unterschied zwischen einem dedizierten Logging-Server und gar keinem ausmacht.

ELK war jahrelang der Standard für zentralisiertes Logging. Drei Komponenten, die jeweils eigene Cluster bilden, eigene Updates brauchen und erhebliche Ressourcen verbrauchen. Elasticsearch braucht in der Praxis mindestens 4 GB Heap, in Produktionsumgebungen eher 8 GB. Zusammen mit Logstash und Kibana kommt ein ELK-Stack schnell auf 16 GB RAM allein für die Logging-Infrastruktur. Für große Unternehmen mit dedizierten Ops-Teams funktioniert das. Fünfköpfige Teams greifen besser zu Loki.

Was bringt Distributed Tracing?

Distributed Tracing geht einen Schritt weiter als Logging. Wenn eine Benutzeranfrage durch fünf Services wandert (Reverse Proxy, API, Authentifizierung, Datenbank, Cache), zeichnet ein Trace den gesamten Weg auf. Jeder Abschnitt bekommt eine Zeitangabe. Am Ende sieht das Team: Die API brauchte 12 Millisekunden, aber die Datenbank 1,4 Sekunden. Der Flaschenhals ist gefunden.

OpenTelemetry hat sich als herstellerneutraler Standard für die Instrumentierung durchgesetzt. Bibliotheken für alle gängigen Sprachen (Python, Go, Java, Node.js) sammeln Metriken, Logs und Traces und senden sie an beliebige Backends. Tempo von Grafana Labs oder Jaeger speichern die Traces und machen sie durchsuchbar, wobei sich Tempo direkt in den LGTM-Stack integriert und Jaeger eigenständig funktioniert. Wer gerade erst mit Observability anfängt, setzt Tracing oft als letzten Schritt um. Monitoring zuerst, dann Logging, dann Tracing, denn ohne die anderen beiden bringt es wenig.

Structured Logging verdient besondere Erwähnung. Statt Freitext-Zeilen wie „User 4711 hat Produkt bestellt“ produziert Structured Logging JSON-Objekte mit definierten Feldern: user_id, action, product_id, timestamp. Loki kann diese Felder filtern und durchsuchen. Der Initialaufwand beim Einrichten ist gering, der Nutzen bei der Fehlersuche enorm. Ein grep über 50 Container-Logs ist mühsam, während die Abfrage auf action=order_failed in Loki Sekunden dauert.

Backups und Disaster Recovery: Was Teams bis zum Ernstfall ignorieren

Eine ernüchternde Zahl aus dem Veeam Data Protection Trends Report 2024: Weniger als drei von fünf Servern (58 Prozent) konnten innerhalb der erwarteten Zeit wiederhergestellt werden. Anders formuliert: Bei 42 Prozent der Server dauerte die Wiederherstellung länger als geplant. Backups existierten, funktionierten aber nicht so, wie die Teams es angenommen hatten.

Für PostgreSQL-Datenbanken gibt es drei Backup-Strategien. Logische Backups mit pg_dump erzeugen eine SQL-Datei, die die Datenbank vollständig rekonstruieren kann. Schnell eingerichtet, leicht verständlich, aber bei großen Datenbanken langsam. Physische Backups mit pg_basebackup kopieren die binären Datenbankdateien. Schneller, aber sie erzeugen größere Dateien und sind versionsgebunden. WAL-Archivierung (Write-Ahead Log) speichert kontinuierlich alle Änderungen und ermöglicht Point-in-Time-Recovery: Die Datenbank auf einen beliebigen Zeitpunkt in der Vergangenheit zurücksetzen.

Kombiniert man pg_basebackup und WAL-Archivierung, ergibt sich der empfohlene Ansatz. Tägliche Basis-Backups plus kontinuierliche WAL-Archivierung auf Object Storage. Barman (von EnterpriseDB) oder pgBackRest automatisieren beide Schritte und übernehmen die Verwaltung von Aufbewahrungsfristen und Konsistenzprüfungen.

Entscheidend ist die Frage nach RTO und RPO. Recovery Time Objective definiert, wie lange ein Ausfall maximal dauern darf, Recovery Point Objective bestimmt, wie viel Datenverlust akzeptabel ist. Braucht ein Team vier Stunden RTO und 15 Minuten RPO, reichen tägliche pg_dumps nicht mehr aus, und WAL-Archivierung wird zur Pflicht.

Container-Workloads selbst brauchen keine Backups im klassischen Sinn, weil die Container zustandslos sind, das Docker-Image in der Container-Registry liegt und die Konfiguration im Git-Repository. Was gesichert werden muss: Datenbanken, Object Storage und Kubernetes-Konfigurationen. Secrets, ConfigMaps, Custom Resources, Persistent Volume Claims. Velero von VMware (jetzt Broadcom) ist das Standardwerkzeug für Kubernetes-Backups und sichert sowohl Cluster-Ressourcen als auch Persistent Volumes.

Wie oft testen Teams ihre Restores?

Zu selten. Der Restore-Test ist der unbeliebteste Punkt auf jeder Ops-Checkliste, denn er bringt keinen sichtbaren Mehrwert, solange alles läuft. Genau deshalb wird er verschoben, bis er vergessen ist. Ein Backup ohne Restore-Test ist kein Backup. Es ist eine Hoffnung.

Mindestens einmal pro Quartal gehört ein vollständiger Restore-Test in den Kalender. Backup aus dem Object Storage laden, auf einen Testserver einspielen, prüfen, ob die Anwendung mit den wiederhergestellten Daten funktioniert. Besser: automatisierte Restore-Tests. Per Cronjob lässt sich wöchentlich ein Restore auf eine temporäre Datenbank automatisieren, und der Aufwand für die Einrichtung liegt bei einem halben Tag. Ob sich das lohnt, stellt niemand mehr in Frage, der schon einmal ein korruptes Backup im Ernstfall erlebt hat.

cert-manager automatisiert TLS-Zertifikate in Kubernetes und erneuert sie nach zwei Dritteln der Laufzeit (bei 90-Tage-Zertifikaten also rund 30 Tage vor Ablauf). Das klingt komfortabel, aber auch hier gilt: Monitoring ist Pflicht. Wenn der DNS-Provider oder die Let’s-Encrypt-Verifizierung hakt, läuft ein Zertifikat still und leise ab. Alerts auf Zertifikate mit weniger als sieben Tagen Restlaufzeit gehören in jedes Monitoring-Setup.

Security-Grundlagen: Was viele Cluster-Setups vergessen

Monitoring und Backups schützen vor Ausfällen. Security schützt vor Angriffen. In vielen Anleitungen zum Container-Deployment taucht Security erst im letzten Absatz auf, als Randnotiz. Das rächt sich. Laut dem Red Hat State of Kubernetes Security Report 2024 haben 67 Prozent der befragten Unternehmen Container-Deployments verzögert oder verlangsamt, weil Sicherheitsbedenken im Weg standen.

Container-Image-Scanning gehört in jede CI/CD-Pipeline. Trivy (von Aqua Security, Open Source) prüft Images auf bekannte Schwachstellen in Betriebssystempaketen und Abhängigkeiten, und jeder Build, der ein Image mit einer kritischen CVE in die Registry schiebt, sollte fehlschlagen. Grype von Anchore ist eine Alternative mit ähnlichem Funktionsumfang. Entscheidend ist nicht welches Tool, sondern dass überhaupt eines läuft, denn viele Teams starten ohne Image-Scanning und wundern sich später über Hunderte offener CVEs in ihren Produktions-Images. Minimale Basis-Images (Alpine, Distroless) reduzieren die Angriffsfläche von vornherein.

Halten Network Policies, was sie versprechen?

Kubernetes Network Policies kontrollieren, welche Pods miteinander kommunizieren dürfen. Standardmäßig kann in einem Kubernetes-Cluster jeder Pod jeden anderen Pod erreichen. Bequem für die Entwicklung, fatal für die Sicherheit. Wird der Frontend-Container kompromittiert, könnte er direkt auf die Datenbank zugreifen.

Network Policies ändern das. Eine Policy kann festlegen, dass der Datenbank-Pod nur Verbindungen vom API-Server-Pod akzeptiert. Nicht vom Frontend, nicht von anderen Namespaces, nicht von außen. Calico und Cilium sind die verbreitetsten CNI-Plugins für die Durchsetzung dieser Policies, wobei K3s standardmäßig Flannel als CNI nutzt und es um einen kube-router-basierten Network-Policy-Controller ergänzt, sodass einfache Policies funktionieren. Für erweiterte Funktionen wie Layer-7-Policies und eBPF-basiertes Networking empfiehlt sich der Wechsel auf Cilium.

Secrets-Management ist das dritte Sicherheitsthema, das in Produktionsclustern selten gut gelöst ist. Kubernetes Secrets sind base64-kodiert, nicht verschlüsselt. Jeder mit Lesezugriff auf den Namespace kann sie dekodieren. Sealed Secrets (von Bitnami) verschlüsseln Secrets so, dass sie sicher im Git-Repository liegen können und erst im Cluster entschlüsselt werden. External Secrets Operator verbindet Kubernetes mit externen Secret-Stores wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault und synchronisiert Secrets automatisch in den Cluster.

Für die meisten Teams im DACH-Raum reichen Sealed Secrets als Einstieg. Vault lohnt sich ab einer bestimmten Cluster-Größe, bringt aber eigene Betriebskomplexität mit, weil Vault selbst hochverfügbar betrieben werden muss und regelmäßige Unseal-Vorgänge erfordert. Wer Datenbank-Passwörter, API-Keys und TLS-Zertifikate als Klartext in YAML-Dateien ins Git-Repository committet, hat kein Sicherheitskonzept. Das passiert trotzdem in überraschend vielen Projekten.

Fazit: Der Weg vom Container zur Produktionsplattform

Monitoring, Datenbank-HA, zentralisiertes Logging, getestete Backups und Security-Grundlagen sind keine optionalen Extras. Sie sind die Voraussetzung dafür, dass ein Container-Cluster den Sprung vom Hobbyprojekt zur Produktionsplattform schafft. Das Kölner Team aus der Einleitung hätte seinen Vier-Stunden-Ausfall mit einem einzigen Prometheus-Alert auf PostgreSQL-Verbindungen verhindern können. 15 Minuten Konfiguration gegen vier Stunden Ausfall. Die Rechnung ist simpel.

Der LGTM-Stack (Loki, Grafana, Tempo, Mimir) zusammen mit Prometheus als Metrik-Sammler deckt Monitoring, Logging und Tracing ab, ohne Lizenzkosten. PostgreSQL mit Patroni oder CloudNativePG liefert Datenbank-Hochverfügbarkeit. Velero sichert Kubernetes-Ressourcen. Trivy scannt Images. Network Policies und Sealed Secrets schließen die gröbsten Sicherheitslücken. Alle Werkzeuge sind Open Source, gut dokumentiert und in Produktion erprobt.

Wer heute anfängt: Prometheus und Grafana am ersten Tag, Loki am zweiten, eine solide Backup-Strategie in der ersten Woche. Alles andere kann organisch wachsen, sobald das Team die Grundlagen verinnerlicht hat und weiß, wo die eigenen Schwächen liegen.

Diese Serie hat den Bogen gespannt: von den Grundlagen zustandsloser Container-Architektur in Teil 1 über das erste Produktiv-Deployment mit Traefik und CI/CD in Teil 2, die Wahl des Orchestrierungswerkzeugs in Teil 3 und den Kostenvergleich zwischen Hetzner und Hyperscalern in Teil 4 bis zur Produktionsinfrastruktur in diesem letzten Teil. Fünf Teile, ein roter Faden: Pragmatismus vor Perfektion. Nicht jedes Projekt braucht Kubernetes. Nicht jedes Team braucht Multi-Region-Failover. Aber jedes Projekt, das in Produktion geht, braucht Monitoring, Backups und ein Minimum an Security.

Der K3s-Cluster auf drei Hetzner-Servern mit Traefik, Prometheus, Loki und automatischen Backups ist keine Kompromiss-Architektur. Für die Mehrheit der Projekte im DACH-Raum, die keine zehnköpfige Plattform-Abteilung mitbringen, ist es die richtige Architektur. Weniger Komplexität bedeutet weniger Fehlerquellen. Und weniger Fehlerquellen bedeutet, dass um 2:47 Uhr nachts niemand aufstehen muss.

Quellenverzeichnis

1. Prometheus: Documentation, prometheus.io/docs (Stand: Februar 2026)
2. Grafana Labs: Grafana, Loki, Tempo, Mimir Documentation, grafana.com/docs (Stand: Februar 2026)
3. Google SRE Book: „Monitoring Distributed Systems“, Kapitel 6: The Four Golden Signals, sre.google/sre-book/monitoring-distributed-systems
4. Zalando: Patroni Documentation, github.com/patroni/patroni (Stand: Februar 2026)
5. EnterpriseDB: CloudNativePG Documentation, cloudnative-pg.io/docs (Stand: Februar 2026)
6. OpenTelemetry: Documentation, opentelemetry.io/docs (Stand: Februar 2026)
7. SigNoz: „Open Source APM“, signoz.io (Stand: Februar 2026)
8. Veeam: „Data Protection Trends Report 2024“, veeam.com, 2024
9. VMware/Broadcom: Velero Documentation, velero.io/docs (Stand: Februar 2026)
10. EnterpriseDB: Barman Documentation, pgbarman.org (Stand: Februar 2026)
11. Aqua Security: Trivy Documentation, trivy.dev/docs (Stand: Februar 2026)
12. Red Hat: „State of Kubernetes Security Report 2024“, redhat.com, 2024
13. Ubicloud: Managed PostgreSQL on Hetzner, ubicloud.com (Stand: Februar 2026)
14. Bitnami: Sealed Secrets, github.com/bitnami-labs/sealed-secrets (Stand: Februar 2026)