Was ist der Unterschied zwischen einem Kubernetes-Datenvolumen und Daten aus containerisierten Datenbanken?


Antwort 1:

Die Containerisierung einer Datenbankanwendung ist vom Speicher für die Datenbankdaten getrennt. Wenn Sie einfach eine Datenbank wie MySQL in einen regulären Kubernetes-Pod einfügen, werden die Daten im Pod gespeichert, und wenn der Pod oder der Host sterben, gehen Ihre Daten verloren. Offensichtlich ist das nicht das, was die meisten Leute mit ihrer Datenbank wollen. Aber für Spielzeug- oder Testdatenbanken kann es nützlich sein.

Die zuverlässigere Lösung besteht darin, Ihre Daten in einem separaten Datenvolumen zu speichern, das an jeden Pod angehängt und einfach gesichert werden kann. Wenn der Datenbank-Pod bei Verwendung eines separaten Volumes stirbt, startet Kubernetes einen Ersatz-Pod und hängt das vorhandene Volume an, um den Betrieb fortzusetzen. Beachten Sie, dass dies kein nahtloses Failover ist. Die meisten Datenbanken werden beim Betrieb des Pods unterbrochen. Daher ist es wichtig, Pod-Fehler nach Möglichkeit zu vermeiden.

Ein Kubernetes-Pod kann verschiedene Arten von Volumes verwenden, um als PersistentVolume bereitgestellt zu werden. Im Allgemeinen erstellt ein Datenbank-Pod einen PersistentVolumeClaim, der einem PersistentVolume zugeordnet ist. Bei Verwendung von Kubernetes PersistentVolumeClaims und PersistentVolumes muss sich der Benutzer keine Gedanken darüber machen, wie ein Volume angehängt wird oder wo sich das Volume befindet. Kubernetes kümmert sich darum, einen Knoten zu finden, auf dem der Pod ausgeführt werden kann, und stellt dann die erforderlichen Volumes für den Pod bereit, bevor er gestartet wird.

Kubernetes unterstützt viele verschiedene Volume-Typen. Nur einige davon sind:

  1. NFS: Bekanntes altes netzwerkgebundenes DateisystemAWS EBS (Elastic Block Storage) Volume: Volume-Typ, der in AWS am häufigsten verwendet wird, Funktionen wie Snapshots enthält und nur auf einem Host bereitgestellt werden kann. GCE PD (Persistent Disk): Google Cloud-Volume. Kann im Lese- / Schreibmodus erstellt und auf einem Host bereitgestellt werden. Kann auf vielen Hosts bereitgestellt werden, wenn alle schreibgeschützt sind. Ceph und GlusterFS: Verteilte, redundante Blockspeichermechanismen, die in Bare-Metal-Umgebungen beliebt sind. HostPath: Hiermit wird ein Volume direkt vom Host bereitgestellt. Im Allgemeinen nicht nützlich, da Daten verloren gehen, wenn dieser Host ausfällt.

… Und noch mehr Arten von Bänden.