Hinweis perev. : Der Originalartikel wurde kürzlich im Kubernetes-Blog veröffentlicht und von Mitarbeitern von Google und Huawei (Jing Xu, Xing Yang, Saad Ali) verfasst, deren Aktivitäten Sie sicherlich im GitHub des Projekts gesehen haben, falls Sie jemals an den Funktionen und Problemen von K8 interessiert waren mit Datenspeicherung. Ingenieure sprechen über den Zweck von Volume-Snapshots, ihre aktuellen Funktionen und die Grundlagen der Arbeit mit ihnen. In Kubernetes v1.12 wurde eine Alpha-Version der Unterstützung für Snapshots für Volumes eingeführt. Mit dieser Funktion können Sie Snapshots von Volumes erstellen und löschen sowie neue Volumes aus Snapshots mit den "nativen" Mitteln des Systems erstellen - über die Kubernetes-API.
Was ist ein Schnappschuss?
Viele Speichersysteme (wie Google Cloud Persistent Disks, Amazon Elastic Block Storage und zahlreiche lokale Speichersysteme) bieten die Möglichkeit, einen Snapshot („Snapshot“) für ein permanentes Volume zu erstellen. Ein Snapshot ist eine Kopie eines Volumes zu einem bestimmten Zeitpunkt. Es kann verwendet werden, um ein neues Volume bereitzustellen (das bereits mit Daten aus einem Snapshot gefüllt ist) oder um ein vorhandenes Volume auf den vorherigen Status zurückzusetzen (der in einem Snapshot dargestellt wird).
Warum sollten Sie Kubernetes Snapshots hinzufügen?
Im Volume-Plug-In-System von Kubernetes ist bereits eine leistungsstarke Abstraktion verfügbar, die das Bereitstellen, Verbinden und Mounten von Block- und Dateispeichern automatisiert.
Die Bereitstellung all dieser Funktionen ist Teil der Kubernetes-Workload-Toleranzziele: Kubernetes zielt darauf ab, eine Abstraktionsebene zwischen Anwendungen, die als verteilte Systeme arbeiten, und zugrunde liegenden Clustern zu erstellen, damit Anwendungen unabhängig von dem spezifischen Cluster sind, auf dem sie ausgeführt werden, und die Anwendungsbereitstellung nicht erforderlich ist jegliches clusterspezifisches Wissen.
Kubernetes Storage SIG hat Snapshot-Vorgänge als wichtige Funktionen für eine Vielzahl von Stateful Workloads identifiziert. Beispielsweise möchte ein Datenbankadministrator möglicherweise einen Snapshot seiner Datenbank erstellen, bevor eine Operation daran ausgeführt wird.
Nachdem Kubernetes-Benutzer die Standardmethode zum Aufrufen von Snapshot-Vorgängen in der Kubernetes-API erhalten haben, können sie ohne Problemumgehungen (und manuellen Aufruf von speicherspezifischen Vorgängen) mit ihnen arbeiten. Stattdessen erhielten Benutzer die Möglichkeit, Snapshot-Vorgänge in ihre Tools und Richtlinien einzubetten, mit dem ruhigen Verständnis, dass alles mit allen Kubernetes-Clustern funktioniert, unabhängig vom zugrunde liegenden Speicher.
Darüber hinaus fungieren diese Kubernetes-Grundelemente als Grundbausteine und eröffnen den Weg für die Entwicklung fortschrittlicherer Funktionen auf Unternehmensebene für das Speichermanagement - beispielsweise für Schutz, Replikation und Datenmigration.
Welche Volume-Plugins unterstützen Snapshots in Kubernetes?
Kubernetes unterstützt drei Arten von Volume-Plugins: In-Tree, Flex und CSI. Weitere Informationen finden Sie in den häufig gestellten
Fragen zum
Kubernetes Volume Plugin .
Snapshots werden nur für CSI-Treiber unterstützt (weder für In-Tree- noch für Flex-Treiber). Stellen Sie sicher, dass der CSI-Treiber, der die Snapshot-Unterstützung implementiert, im Kubernetes-Cluster bereitgestellt wird, um diese Funktion nutzen zu können.
Zum Zeitpunkt dieses Blogposts
(9. Oktober 2018 - ca. Übersetzung ) werden Snapshots von den folgenden CSI-Treibern unterstützt:
Die Unterstützung für Snapshots für
andere Treiber befindet sich in der Entwicklung und sollte bald verfügbar sein. Weitere Informationen zu CSI und zur Bereitstellung von CSI-Treibern finden Sie in der Veröffentlichung „
CSI (Container Storage Interface) für Kubernetes Goes Beta “
(und lesen Sie auch unsere Übersetzung des Hinweises „ Grundlegendes zur Container Storage Interface (in Kubernetes und mehr) “). - ca. Transl. ) .
Kubernetes API für Snapshots
Zum Verwalten von Snapshots führt Kubernetes Volume Snapshots drei neue API-Objekte auf dieselbe Weise wie in der Kubernetes Persistent Volumes-API ein:
VolumeSnapshot
- Erstellt vom Kubernetes-Benutzer, um einen Snapshot für das angegebene Volume anzufordern. Enthält Informationen zum Snapshot-Vorgang, z. B. den Zeitstempel zum Entfernen des Snapshots und ob er einsatzbereit ist.
- Wie beim
PersistentVolumeClaim Objekt entspricht das Erstellen und Löschen dieses Objekts dem Wunsch des Benutzers, eine Clusterressource (Snapshot) zu erstellen oder zu löschen.
VolumeSnapshotContent
- Erstellt vom CSI-Treiber, als der Snapshot erfolgreich erstellt wurde. Enthält Informationen zum Snapshot einschließlich seiner ID.
- Wie ein
PersistentVolume Objekt stellt es eine Ressource dar, die bereits vom Cluster bedient wird (Snapshot). - Wie bei den Objekten
PersistentVolumeClaim und PersistentVolume wird beim VolumeSnapshotContent eines Snapshots das VolumeSnapshotContent Objekt an den VolumeSnapshot angehängt, für den es erstellt wurde (es wird eine Eins-zu-Eins-Zuordnung verwendet).
VolumeSnapshotClass
- Wird von Clusteradministratoren definiert, um zu beschreiben, welche Snapshots erstellt werden können. Enthält Treiberinformationen, Geheimnisse für den Zugriff auf Schnappschüsse usw.
Es ist wichtig zu beachten, dass diese Snap-Shot-Objekte im
Gegensatz zu den Hauptobjekten für
persistente Volumes in Kubernetes als
CustomResourceDefinitions (CRDs) definiert sind . Das Kubernetes-Projekt entfernt sich allmählich von vordefinierten Ressourcentypen im API-Server und nähert sich einem Modell, bei dem der API-Server unabhängig von API-Objekten ist. Mit diesem Ansatz können Sie den API-Server in anderen Projekten (außer Kubernetes) wiederverwenden, und Verbraucher (wie Kubernetes) können die Arten von Ressourcen festlegen, die sie als CRD benötigen.
CSI-Treiber , die Snapshots unterstützen, installieren automatisch die erforderlichen CRDs. Kubernetes-Endbenutzer müssen nur überprüfen, ob der CSI-Treiber, der Snapshots unterstützt, im Cluster bereitgestellt wird.
Zusätzlich zu diesen neuen Objekten verfügt der vorhandene
PersistentVolumeClaim ein neues
DataSource Feld:
type PersistentVolumeClaimSpec struct { AccessModes []PersistentVolumeAccessMode Selector *metav1.LabelSelector Resources ResourceRequirements VolumeName string StorageClassName *string VolumeMode *PersistentVolumeMode DataSource *TypedLocalObjectReference }
In diesem Feld (im Status der Alpha-Version) können Sie es beim Erstellen eines neuen Volumes automatisch mit Daten aus einem vorhandenen Snapshot füllen.
Kubernetes Snapshot-Anforderungen
Bevor Sie Volume-Snapshots in Kubernetes verwenden können, müssen Sie:
- Stellen Sie sicher, dass der CSI-Treiber, der Snapshots implementiert, bereitgestellt wird und auf dem Cluster ausgeführt wird.
- Aktivieren Sie die Kubernetes Volume Snapshotting-Funktion über das neue Feature-Gate (standardmäßig für die Alpha-Version deaktiviert):
- Setzen Sie das folgende Flag für die
--feature-gates=VolumeSnapshotDataSource=true API-Server- --feature-gates=VolumeSnapshotDataSource=true : --feature-gates=VolumeSnapshotDataSource=true
Bevor Sie einen Snapshot erstellen, müssen Sie auch festlegen, welcher CSI-Treiber verwendet werden soll.
VolumeSnapshotClass erstellen Sie ein
VolumeSnapshotClass Objekt und geben den CSI-Treiber im Feld
snapshotter . Im folgenden
VolumeSnapshotClass Beispiel ist dieser Treiber
com.example.csi-driver . Jeder Snapshot-Anbieter benötigt mindestens ein
VolumeSnapshotClass Objekt. Es ist auch möglich, für jeden CSI-Treiber eine Standard-
VolumeSnapshotClass zu definieren. Dies erfolgt durch Festlegen der Annotation
snapshot.storage.kubernetes.io/is-default-class: "true" in der Klassendefinition:
apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: default-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" snapshotter: com.example.csi-driver apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: csi-snapclass snapshotter: com.example.csi-driver parameters: fakeSnapshotOption: foo csiSnapshotterSecretName: csi-secret csiSnapshotterSecretNamespace: csi-namespace
Alle erforderlichen Parameter müssen gemäß der CSI-Treiberdokumentation eingestellt werden. Im obigen Beispiel werden der Parameter
fakeSnapshotOption: foo und alle genannten Geheimnisse beim Erstellen und Entfernen des Snapshots an den CSI-Treiber übergeben.
CSI external-snapshotter speichert standardmäßig die Parameterschlüssel
csiSnapshotterSecretName und
csiSnapshotterSecretNamespace .
Bevor Sie einen Snapshot erstellen, müssen Sie das Volume über den CSI-Treiber erstellen und mit den Daten füllen, die Sie dort anzeigen möchten (Einzelheiten zur Verwendung von CSI-Volumes finden Sie in
dieser Veröffentlichung ).
Erstellen eines neuen Schnappschusses in Kubernetes
Sobald das
VolumeSnapshotClass Objekt definiert ist und das Volume ist, von dem Sie den Snapshot entfernen möchten, können Sie diesen Vorgang ausführen, indem Sie das
VolumeSnapshot Objekt
VolumeSnapshot .
Die Quelle für den Schnappschuss wird durch zwei Parameter bestimmt:
kind - PersistentVolumeClaim hier angezeigt;name - der tatsächliche Name des PVC-Objekts.
Es versteht sich, dass der Namespace des Volumes, für das der Snapshot erstellt wird, durch den Namespace des
VolumeSnapshot Objekts bestimmt wird.
apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: new-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass source: name: mypvc kind: PersistentVolumeClaim
Die
VolumeSnapshot Spezifikation kann eine
VolumeSnapshotClass VolumeSnapshot , die Informationen darüber enthält, welcher CSI-Treiber zum Erstellen des Snapshots verwendet wird. Wie bereits berichtet, werden nach dem Erstellen des
VolumeSnapshot Objekts der Parameter
fakeSnapshotOption: foo und alle genannten
VolumeSnapshotClass Geheimnisse im
CreateSnapshot Aufruf an das CSI-Plugin
com.example.csi-driver CreateSnapshot .
Als Antwort auf eine solche Anforderung erstellt der CSI-Treiber einen Snapshot des Volumes und erstellt dann automatisch ein
VolumeSnapshotContent Objekt, das den neuen Snapshot darstellt, und bindet dieses Objekt an den
VolumeSnapshot , um es einsatzbereit zu machen. Wenn der CSI-Treiber keinen Snapshot erstellen kann und einen Fehler zurückgibt, meldet der Snapshot-Controller diesen Fehler im Status des
VolumeSnapshot Objekts und
unternimmt keine neuen Versuche (dieses Verhalten unterscheidet sich von anderen Controllern in Kubernetes - es wird implementiert, um keinen Snapshot zu unvorhersehbaren Zeiten zu erstellen). .
Wenn die Snapshot-Klasse nicht angegeben ist, versucht der externe Snapshotter, die Standardklasse zu finden und für den erstellten Snapshot zu verwenden. In diesem Fall sollte der CSI-Treiber, auf den der
snapshotter in der Standardklasse verweist, dem CSI-Treiber entsprechen, auf den der
provisioner in der PVC-Speicherklasse verweist.
Bitte beachten Sie, dass die Alpha-Version von Snapshots für Kubernetes keine Garantie für Konsistenz bietet. Um vollständige Daten in einem Snapshot sicherzustellen, muss die Anwendung ordnungsgemäß vorbereitet werden (Anwendung stoppen, Dateisystem einfrieren usw.), bevor sie entfernt wird.
Um zu
VolumeSnapshot ob das
VolumeSnapshot Objekt erstellt und dem
VolumeSnapshotContent , können Sie den
kubectl describe volumesnapshot :
Ready sollte im Status true , um anzuzeigen, dass der Volume-Snapshot zur Verwendung bereit ist.- Das Feld
Creation Time zeigt an, wann der Schnappschuss tatsächlich aufgenommen wurde. - Das Feld
Restore Size ist die minimale Volume-Größe zum Wiederherstellen eines Snapshots. - Das Feld
Snapshot Content Name des Snapshot Content Name in der Spezifikation verweist auf das für diesen Snapshot erstellte VolumeSnapshotContent Objekt.
Importieren Sie einen vorhandenen Snapshot in Kubernetes
Ein vorhandener Snapshot kann in Kubernetes importiert werden, indem manuell ein
VolumeSnapshotContent Objekt erstellt wird, das diesen Snapshot darstellt. Da
VolumeSnapshotContent ein API-Objekt ist, das nicht an einen Namespace gebunden ist, kann nur der Systemadministrator es erstellen.
Wenn das
VolumeSnapshotContent Objekt erstellt wird, kann der Benutzer ein anderes Objekt erstellen -
VolumeSnapshot - das darauf
VolumeSnapshot . Der externe Snapshotter-Controller markiert den Snapshot als bereit, nachdem er das Vorhandensein und die korrekte Verbindung zwischen den
VolumeSnapshotContent VolumeSnapshot und
VolumeSnapshotContent . Ein Snapshot kann in Kubernetes verwendet werden, wenn diese Verbindung hergestellt wird.
Das
VolumeSnapshotContent Objekt muss mit den folgenden Feldern erstellt werden, die den
vorab VolumeSnapshotContent Snapshot darstellen:
csiVolumeSnapshotSource - Informationen zur Identifizierung eines Snapshots:
snapshotHandle - Name / Kennung für den Snapshot. Pflichtfeld;driver - Der CSI-Treiber, mit dem mit diesem Volume gearbeitet wurde. Pflichtfeld. Muss mit dem Namen des snapshotter im Controller (Snapshot-Controller) übereinstimmen.restoreSize und restoreSize - Für vorab restoreSize Volumes sind diese Felder optional. Der externe Snapshotter-Controller aktualisiert sie automatisch, nachdem ein Snapshot erstellt wurde.
volumeSnapshotRef - Zeiger auf das VolumeSnapshot Objekt, an das dieses Objekt (d. VolumeSnapshotContent ) angehängt werden soll:
name und namespace - Name und Namespace des VolumeSnapshot Objekts, dessen Inhalt gebunden ist.UID - optionales Feld (für vorbereitete Volumes). Der externe Snapshotter-Controller aktualisiert dieses Feld nach dem Binden automatisch. Wenn der Benutzer dieses Feld definiert, müssen Sie sicherstellen, dass es mit der UID des Snapshots übereinstimmt, für den die Bindung erfolgt. Wenn es keine solche Entsprechung gibt, wird der Inhalt als irrelevant angesehen (verwaistes Objekt) und daher löscht der Controller sowohl ihn als auch den zugehörigen Snapshot.
snapshotClassName ist ein optionales Feld. Der externe Snapshotter-Controller aktualisiert ihn nach dem Binden automatisch.
apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotContent metadata: name: static-snapshot-content spec: csiVolumeSnapshotSource: driver: com.example.csi-driver snapshotHandle: snapshotcontent-example-id volumeSnapshotRef: kind: VolumeSnapshot name: static-snapshot-demo namespace: demo-namespace
Ein
VolumeSnapshot Objekt muss erstellt werden, damit der Benutzer mit dem Snapshot arbeiten kann. In ihm:
snapshotClassName - Name der Snapshot-Klasse des Volumes. Optionales Feld. Wenn festgelegt, sollte das snapshotter Feld in der Snapshot-Klasse mit dem Namen des Snapshot-Controllers übereinstimmen. Wenn nicht festgelegt, sucht der Controller nach der Standard-Snapshot-Klasse.snapshotContentName - Der Name des Inhalts des Snapshot-Volumes. Pflichtfeld für vorbereitete Bände.
apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: static-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass snapshotContentName: static-snapshot-content
Wenn diese Objekte erstellt werden, bindet der Snapshot-Controller sie. Setzen Sie das Feld
Ready (in
Status ) auf
True , um
True , dass der Snapshot zur Verwendung bereit ist.
Vorbereiten eines neuen Volumes aus dem Snapshot in Kubernetes
Verwenden Sie das neue
dataSource Feld in
PersistentVolumeClaim um ein neues Volume zu erstellen, das mit Daten aus dem Snapshot-Objekt
dataSource ist. Es hat drei Parameter:
name - Name des VolumeSnapshot Objekts, das die Snapshot-Quelle darstellt;kind - sollte als VolumeSnapshot ;apiGroup - sollte snapshot.storage.k8s.io .
Es wird angenommen, dass der Namespace der Quelle - der
VolumeSnapshot - mit dem Namespace des
PersistentVolumeClaim VolumeSnapshot .
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-restore Namespace: demo-namespace spec: storageClassName: csi-storageclass dataSource: name: new-snapshot-demo kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 1Gi
Wenn das
PersistentVolumeClaim Objekt erstellt wird, wird die Bereitstellung des neuen Volumes aufgerufen, das mit Daten aus dem angegebenen Snapshot gefüllt ist.
Wie füge ich meinem CSI-Treiber Snapshot-Unterstützung hinzu, wenn ich Speicherentwickler bin?
Um Snapshots zu unterstützen, sollten dem CSI-Treiber zusätzliche Controller-Funktionen hinzugefügt werden:
CREATE_DELETE_SNAPSHOT und
LIST_SNAPSHOTS sowie zusätzliche RPC-Controller:
CreateSnapshot ,
DeleteSnapshot ,
ListSnapshots . Einzelheiten finden Sie in
der CSI-Spezifikation .
Obwohl Kubernetes die
grundlegendsten Richtlinien zum Packen und Bereitstellen des CSI-Volume-Treibers bietet, gibt es einen
empfohlenen Mechanismus zum Bereitstellen eines beliebigen containerisierten CSI-Treibers in Kubernetes, um diesen Prozess zu vereinfachen.
Als Teil des empfohlenen Bereitstellungsprozesses schlägt das Kubernetes-Team vor, eine Vielzahl von Seitenwagen- (d. H. Hilfs-) Containern zu verwenden, einschließlich eines Seitenwagen-Containers mit einem
externen Snapshotter .
Der erwähnte externe Snapshotter überwacht die
VolumeSnapshot und
VolumeSnapshotContent Objekte auf dem API-Server und ruft die
DeleteSnapshot CreateSnapshot und
DeleteSnapshot für den CSI-Endpunkt auf. Der Beiwagencontainer mit dem
externen CSI
-Provisioner wurde ebenfalls aktualisiert, um die Volumenwiederherstellung aus Snapshots mithilfe des neuen
dataSource PVC
dataSource zu unterstützen.
Um Snapshot-Funktionen zu unterstützen, wird Speicherherstellern empfohlen, Sidecar-Container mit einem externen Snapshotter zusätzlich zu einem externen Provisioner
StatefulSet und den CSI-Treiber in einem
StatefulSet , wie in der folgenden Abbildung dargestellt:
In
diesem Bereitstellungsbeispiel gibt es zwei Sidecar-Container, einen externen Provisioner und einen externen Snapshotter, und die CSI-Treiber werden mit dem CSI-Hostpfad-Plugin im StatefulSet-Pod bereitgestellt. Der CSI-Hostpfad ist ein Beispiel-Plugin, das nicht für die Verwendung in der Produktion vorgesehen ist.
Was sind die Einschränkungen der Alpha-Version?
Die Alpha-Version der Snapshot-Implementierung in Kubernetes weist die folgenden Einschränkungen auf:
- Das Zurücksetzen eines vorhandenen Volumes auf einen vorherigen Status, der durch einen Snapshot dargestellt wird, wird nicht unterstützt (nur die Bereitstellung eines neuen Volumes aus einem Snapshot wird unterstützt).
- Die direkte Wiederherstellung wird für vorhandene
PersistentVolumeClaim aus dem Snapshot nicht unterstützt: d. H. Das Bereitstellen eines neuen Volumes aus dem Snapshot funktioniert, das vorhandene PersistentVolumeClaim wird jedoch nicht aktualisiert, sodass es auf ein neues Volume verweist und das PVC auf einen früheren Status zurückgesetzt wird (es wird nur die Verwendung eines neuen Volumes unterstützt, das aus einem Snapshot über ein neues PV / PVC erstellt wurde). - Garantien für die Konsistenz von Snapshots gehen nicht über die Garantien des Speichersystems hinaus (z. B. Integrität beim Löschen).
Was weiter?
Das Kubernetes-Team plant, die Implementierung von Snapshots für CSI in den Beta-Versionen 1.13 oder 1.14 in die Beta-Version zu bringen, abhängig vom erhaltenen Feedback und der Anpassung der Technologie.
Wie erfahre ich mehr Details?
Weitere Snapshot-Dokumentation finden Sie unter
k8s.io/docs/concepts/storage/volume-snapshots und
kubernetes-csi.imtqy.com/docs .
PS vom Übersetzer
Lesen Sie auch in unserem Blog: