Datenbanken auf Kubernetes: Ja oder Nein?

Jahrelang war der Standardrat einfach: Führen Sie Ihre staatenlosen Apps auf Kubernetes und behalten Sie Ihre Datenbanken woanders. Kubernetes wurde für Rinder entwickelt, und Datenbanken sind das ultimative Haustier.

Dieser Rat wird langsam alt. Die Speicherung auf Kubernetes ist ausgereift, und die Betreiber können jetzt Failover, Backups und Upgrades besser verarbeiten als viele handgefertigte Setups. Die Frage ist also von "Können Sie?" zu "Sollen Sie?"

Speicherung auf Kubernetes, einfach

Ein paar Grundlagen, die Sie verstehen müssen:

• PersistentVolume (PV)Ein Stück Speicher, wie eine Cloud-Disk.
• PersistentVolumeClaim (PVC): eine Anfrage eines Pods für Speicher: "Ich brauche 50 GB Festplatte".
• Speicherklasse: die Art des Speichers und wie er automatisch erstellt wird, z. B. SSD-basierte Cloud-Disketten.
• CSI-Fahrer: Plugins, die Kubernetes mit dem eigentlichen Speichersystem verbinden.
• StatefulSet: wie ein Deployment, aber jede Kapsel bekommt einen stabilen Namen (db-0, db-1) und das daraus folgende anhaltende Volumen.

Mit diesen kann eine Datenbank-Kapsel neu gestartet oder bewegt werden und trotzdem ihre Daten finden.

Aber hier ist der Haken: ein StatefulSet hält nur die Daten angehängt. Es weiß nichts über Datenbank-Replikation, Failover, Backups oder Upgrades. Da kommen die Operatoren ins Spiel.

Die Arbeiter, die die harte Arbeit machen

Ein Operator ist eine Software, die in Ihrem Cluster ausgeführt wird und weiß, wie man eine bestimmte Datenbank ausführt. Sie beschreiben, was Sie wollen, und es kümmert sich um die operativen Details.

Einige von ihnen sind sehr angesehen:

• CloudNativePG für PostgreSQL: Replikation, automatischer Failover, Backups für Objektspeicher, Point-in-Time-Wiederherstellung, rollende Upgrades.
• Schwimmer für Apache Kafka.
• Percona-Betreiber für MySQL, PostgreSQL und MongoDB.
• Redis/Valkey-Betreiber von mehreren Anbietern und Gemeinden.

Ein PostgreSQL Cluster mit CloudNativePG sieht so aus:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: orders-db
spec:
  instances: 3
  storage:
    size: 50Gi
    storageClass: fast-ssd
  backup:
    barmanObjectStore:
      destinationPath: s3://my-backups/orders-db
      s3Credentials:
        inheritFromIAMRole: true
    retentionPolicy: "30d"

Drei Instanzen, Streaming-Replikation, automatischer Failover und Backups, in etwa 15 Zeilen. Das ist beeindruckend.

Eine Datenbank auf Kubernetes ohne Operator ist nur eine Datenbank mit zusätzlichen Möglichkeiten, sie zu knacken.

Ich vertraue auf Backups .

Was auch immer du machst, die Unterstützung ist das Wichtigste. Ein paar Regeln:

• Verwenden Sie die eigenen Backup-Tools der Datenbank (über den Betreiber) für konsistente, zeitlich erreichbare Sicherungen. Die meisten Datenbanken können nicht mit Datenträger-Snapshots auskommen.
• Speichern von Backups außerhalb des Clusters, idealerweise in einer anderen Region oder einem anderen Konto.
• Verwenden Sie Velero für die Sicherung von Kubernetes-Ressourcen und -Volumen als zweite Ebene, insbesondere für die Notfallwiederherstellung eines gesamten Clusters.
• Der Test stellt sich regelmäßig wieder. Eine Sicherung, die du nie wiederhergestellt hast, ist eine Hoffnung, keine Sicherung.

Die tatsächlichen Kosten

Wenn Sie Datenbanken auf Kubernetes laufen lassen, dann besitzt Ihr Team Dinge, die ein Managed Service verarbeiten würde:

• Upgrades der Datenbankversion und des Betreibers.
• Leistungs-Tuning, Speichergrößen und um 2 Uhr morgens mit vollen Festplatten.
• Sicherheitspatches.
• Fachwissen: jemand muss PostgreSQL (oder was auch immer man ausführt) wirklich verstehen, wenn etwas schief geht.

Wenn ich immer noch eine verwaltete Datenbank wählen würde

Ich würde einen Managed Service (RDS, Cloud SQL, Azure Database und ähnliches) wählen, wenn:

• Die Datenbank ist geschäftlich kritisch und das Team ist klein.
• Niemand im Team hat Erfahrung mit Datenbankoperationen.
• Sie sind bereits bei einem Cloud-Anbieter und die verwaltete Option passt zum Budget.
• Die Anforderungen an die Einhaltung sind mit einem zertifizierten Managed Service leichter zu erfüllen.

Wenn Kubernetes Sinn macht

Und ich würde es auf Kubernetes laufen lassen, wenn:

• Sie sind vor Ort oder in einer souveränen oder Randumgebung ohne gut verwaltete Optionen.
• Sie benötigen viele kleine Datenbanken, zum Beispiel eine pro Vorschaumöglichkeit oder Mieter.
• Sie wollen Konsistenz über die Wolken hinweg.
• Kosten sind in der Größenordnung wichtig, und Sie haben die Fähigkeiten, sie zu betreiben.
• Das Team hat bereits starke Erfahrung mit Kubernetes und Datenbanken.

Also, ja oder nein?

Das hängt davon ab, aber die Antwort ist nicht mehr "nie". Mit einem guten Betreiber, soliden Backups und einem Team, das die Datenbank versteht, ist Kubernetes ein absolut vernünftiges Zuhause für den Staat. Ohne diese wird Ihnen ein Managed Service viele schlaflose Nächte ersparen.

Meine Meinung: Die Datenbank interessiert nicht, wo sie läuft. Es interessiert sich, ob sich jemand um sie kümmert, der sie versteht.

Desly