Datenbankbereitstellungen in der GKE planen

Auf dieser Seite werden Best Practices zum Ausführen von Datenbanken in Containern in GKE erläutert. Sie können eine Bereitstellung verwenden, um eine Reihe von Kubernetes verwalteten containerisierten Datenbankinstanzen zu erstellen. Anschließend erstellen Sie einen Dienst, um unabhängig von einem bestimmten Pod Zugriff auf die Datenbank zu gewähren. Der Dienst bleibt auch dann unverändert, wenn der Pod auf einen anderen Knoten verschoben wird.

Für den Zugriff auf die Daten in der Datenbankinstanz erstellen Sie eine PersistentVolumeClaim-Ressource (PVC) und stellen sie Ihrer Arbeitslast zur Verfügung.

Datenbanken sind für ihre Persistenz auf lokale Laufwerke angewiesen. Eine Datenbank, die als Service in einem Kubernetes-Cluster ausgeführt wird, und ihre Datenbankdateien in einer PersistentVolumeClaim sind an den Lebenszyklus des Clusters gebunden. Wenn der Cluster gelöscht wird, wird auch die Datenbank gelöscht.

Wenn Sie eine zustandsorientierte Anwendung erstellen oder bereitstellen, die in GKE ausgeführt wird, sollten Sie eine der folgenden Bereitstellungsoptionen für Datenbankinstanzen verwenden:

  • Vollständig verwaltete Datenbanken: Eine verwaltete Datenbank wie Cloud SQL oder Spanner bietet einen geringeren operativen Aufwand und ist für die Google Cloud-Infrastruktur optimiert. Verwaltete Datenbanken sind weniger mühsam zu warten und zu betreiben als eine Datenbank, die Sie direkt in Kubernetes bereitstellen.
  • Kubernetes-Anwendung: Sie können eine Datenbankinstanz (z. B. MySQL oder PostgreSQL) auf einem GKE-Cluster bereitstellen und ausführen.

Hinweise zu Datenbankbereitstellungen in GKE

Jede der vorherigen Optionen hat Kompromisse, angesichts Ihrer Geschäftsziele und Einschränkungen. Anhand der folgenden Tabelle können Sie entscheiden, ob die Datenbankbereitstellung in GKE für Sie die richtige Wahl ist.

Kaufbereitschaft Beschreibung
Datenbankunabhängigkeit Der Lebenszyklus eines PersistentVolumeClaim ist an den entsprechenden GKE-Cluster gebunden. Wenn Ihr Datenbanklebenszyklus nicht von einem bestimmten GKE-Cluster abhängig sein soll, sollten Sie die Datenbank als verwaltete Datenbank oder in einer VM-Instanz getrennt halten.
Mit GKE skalieren

Vertikale Skalierung: Sie können Ihre Pods-Anfragen so konfigurieren, dass sie automatisch skaliert werden. Sie müssen jedoch dafür sorgen, dass Ihre Datenbankanwendung Unterbrechungen standhält, wenn Ihre Pods mit vertikalem Pod-Autoscaling hochskaliert werden.

Horizontale Skalierung: Ihre Datenbank kann möglicherweise Lese- oder Schreibvorgänge horizontal hinzufügen, indem Replikate hinzugefügt werden. Ob Ihre Datenbank die horizontale Skalierung unterstützt, hängt davon ab, ob sie eine Architektur mit einem oder mehreren Autoren hat. Wenn Sie die horizontale Skalierung verwenden möchten, müssen Sie möglicherweise nicht nur die Anzahl der Replikate hochskalieren, sondern auch die Datenbankkonfiguration aktualisieren.
GKE-Overhead

Auf Autopilot-Clustern werden Ihnen keine Ressourcenreservierungen in Rechnung gestellt, sondern nur für Ressourcenanfragen.

Auf Standardclustern reserviert GKE Ressourcen für die eigenen Vorgänge. Datenbanken auf Standardclustern werden nicht automatisch skaliert, sodass bei kleinen Pods der Overhead hoch sein kann.
Anzahl der Datenbankinstanzen Im Kontext von Kubernetes wird jede Datenbankinstanz in einem eigenen Pod ausgeführt und hat einen eigenen PersistentVolumeClaim. Bei einer hohen Anzahl von Instanzen müssen Sie eine große Menge von Pods, Knoten und Volume Claims betreiben und verwalten. Sie können stattdessen eine verwaltete Datenbank verwenden.
Datenbanksicherung in GKE

Ein PersistentVolumeClaim ist einem GKE-Cluster zugeordnet. Dies bedeutet, dass der Volume Claim beim Löschen eines GKE-Clusters gelöscht wird. Außerdem werden alle Datenbankdateien im Cluster ebenfalls gelöscht. Um einen versehentlichen Verlust der Datenbankdateien zu verhindern, empfehlen wir Replikation oder häufige Sicherung.

Mit Sicherung für GKE können Sie in regelmäßigen Abständen Snapshots der Anwendungskonfiguration und der Volume-Daten erstellen. Backup for GKE übernimmt die Planung von Volume-Sicherungen, die Verwaltung des Sicherungslebenszyklus und die Wiederherstellung von Sicherungen in einem Cluster.

Kubernetes-spezifisches Wiederherstellungsverhalten Wenn ein Pod in Kubernetes fehlschlägt, wird er neu erstellt. Aus der Sicht der Datenbankinstanz bedeutet dies, dass bei einer Neuerstellung eines Pods jede Konfiguration, die nicht in einer Datenbank oder in stabilem Speicher außerhalb von Pods nichtflüchtig ist, neu erstellt wird.
Datenbankarchitektur Wenn Ihre Datenbank für eine Aktiv-Passiv-Architektur konfiguriert ist, müssen Sie dafür sorgen, dass nur ein Replikat als primär konfiguriert ist. Viele relationale Datenbanken haben eine Option für Aktiv-Passiv-Failover, bei dem ein Sekundär im Falle eines primären Ausfalls zum primären Knoten hochgestuft werden kann.
Datenbankmigration Wenn Sie Ihr vorhandenes Datenbanksystem zu GKE migrieren möchten, finden Sie weitere Informationen unter Datenbankmigration: Konzepte und Prinzipien (Teil 1) und Datenbankmigration: Konzepte und Prinzipien (Teil 2)
Erneutes Training des Nutzers Wenn Sie von einer selbstverwalteten oder anbieterverwalteten Bereitstellung zu einer Kubernetes-Datenbankbereitstellung wechseln, müssen Sie die Datenbankadministratoren schulen, damit sie in der neuen Umgebung so zuverlässig wie in der aktuellen Umgebung arbeiten. Anwendungsentwickler müssen in geringerem Ausmaß möglicherweise ebenfalls lernen, Unterschiede zu verstehen.

Die obige Tabelle enthält einige der wichtigen Aspekte für die Datenbankbereitstellung. Die Tabelle enthält jedoch nicht alle möglichen Überlegungen. Außerdem sollten Sie die Notfallwiederherstellung, das Verbindungs-Pooling und das Monitoring in Betracht ziehen.

Nächste Schritte