Remarque perev. : L'article original a été récemment publié sur le blog Kubernetes et a été écrit par des employés de Google et Huawei (Jing Xu, Xing Yang, Saad Ali), dont vous avez certainement vu l'activité active dans le GitHub du projet, si vous avez déjà été intéressé par les fonctionnalités et problèmes de K8 liés à avec stockage de données. Les ingénieurs parlent de l'objectif des instantanés de volume, de leurs capacités actuelles et des bases de leur utilisation. Kubernetes v1.12 a introduit une version alpha de prise en charge des instantanés pour les volumes. Cette fonctionnalité vous permet de créer et de supprimer des instantanés de volumes, ainsi que de créer de nouveaux volumes à partir d'instantanés en utilisant les moyens "natifs" du système - via l'API Kubernetes.
Qu'est-ce qu'un instantané?
De nombreux systèmes de stockage (comme Google Cloud Persistent Disks, Amazon Elastic Block Storage et de nombreux systèmes de stockage sur site) offrent la possibilité de créer un instantané («instantané») pour un volume permanent. Un instantané est une copie d'un volume à un moment donné. Il peut être utilisé pour fournir un nouveau volume (déjà rempli de données à partir d'un instantané) ou restaurer un volume existant à un état précédent (qui est présenté dans un instantané).
Pourquoi ajouter des instantanés à Kubernetes?
Une puissante abstraction est déjà disponible dans le système de plug-in de volume Kubernetes, automatisant l'approvisionnement, la connexion et le montage des stockages de blocs et de fichiers.
Fournir toutes ces fonctionnalités fait partie des objectifs de tolérance de charge de travail de Kubernetes: Kubernetes cherche à créer une couche d'abstraction entre les applications qui fonctionnent comme des systèmes distribués et les clusters sous-jacents afin que les applications soient indépendantes du cluster spécifique sur lequel elles s'exécutent, et le déploiement d'applications ne nécessite pas toute connaissance spécifique au cluster.
Kubernetes Storage SIG a identifié les opérations d'instantanés comme des capacités critiques pour une variété de charges de travail avec état. Par exemple, un administrateur de base de données peut vouloir prendre un instantané de sa base de données avant d'effectuer toute opération sur celle-ci.
En faisant de l'API Kubernetes un moyen standard d'appeler des opérations de snapshot, les utilisateurs de Kubernetes peuvent travailler avec eux sans avoir besoin de solutions de contournement (et d'invocation manuelle d'opérations spécifiques au système de stockage). Au lieu de cela, les utilisateurs ont eu la possibilité d'intégrer des opérations d'instantanés dans leurs outils et politiques, sachant que tout fonctionnera avec tous les clusters Kubernetes, quel que soit le stockage sous-jacent.
En outre, ces primitives Kubernetes fonctionnent comme des blocs de construction de base, ouvrant la voie au développement de fonctionnalités plus avancées au niveau de l'entreprise pour la gestion du stockage - par exemple, pour la protection, la réplication et la migration des données.
Quels plugins de volume prennent en charge les instantanés dans Kubernetes?
Kubernetes prend en charge trois types de plug-ins de volume: dans l'arborescence, Flex et CSI. Consultez la
FAQ du plug-in de volume Kubernetes pour plus
de détails.
Les instantanés ne sont pris en charge que pour les pilotes CSI (ils ne sont pas pris en charge pour l'arborescence ou Flex). Pour tirer parti de cette fonctionnalité, assurez-vous que le pilote CSI qui implémente la prise en charge des instantanés est déployé dans le cluster Kubernetes.
Au moment de la publication de ce blog
(9 octobre 2018 - traduction approximative ) , les instantanés sont pris en charge par les pilotes CSI suivants:
La prise en charge des instantanés pour d'
autres pilotes est en cours de développement et devrait être disponible prochainement. Plus de détails sur CSI et comment déployer les pilotes CSI sont décrits dans la publication «
Container Storage Interface (CSI) for Kubernetes Goes Beta »
(et voir également notre traduction de la note « Understanding Container Storage Interface (in Kubernetes and more) » - environ trad. ) .
API Kubernetes pour les instantanés
Pour gérer les snapshots, Kubernetes Volume Snapshots introduit trois nouveaux objets API de la même manière que dans l'API Kubernetes Persistent Volumes:
VolumeSnapshot
- Créé par l'utilisateur Kubernetes pour demander un instantané pour le volume spécifié. Contient des informations sur l'opération de capture instantanée, telles que l'horodatage pour la suppression de la capture instantanée et sa disponibilité.
- Comme pour l'objet
PersistentVolumeClaim , la création et la suppression de cet objet représentent le souhait de l'utilisateur de créer ou de supprimer une ressource de cluster (instantané).
VolumeSnapshotContent
- Créé par le pilote CSI lorsque l'instantané a été créé avec succès. Contient des informations sur l'instantané, y compris son ID.
- Comme un objet
PersistentVolume , il représente une ressource déjà desservie par le cluster (instantané). - Comme les objets
PersistentVolumeClaim et PersistentVolume , lorsqu'un instantané est créé, l'objet VolumeSnapshotContent attaché au VolumeSnapshot pour lequel il a été créé (un mappage un à un est utilisé).
VolumeSnapshotClass
- Défini par les administrateurs de cluster pour décrire les instantanés pouvant être créés. Comprend des informations sur le pilote, des secrets pour accéder aux instantanés, etc.
Il est important de noter que - contrairement aux principaux objets de volume persistant dans Kubernetes - ces objets instantanés sont définis comme
CustomResourceDefinitions (CRD) . Le projet Kubernetes s'éloigne progressivement des types de ressources prédéfinis dans le serveur API, s'approchant d'un modèle dans lequel le serveur API est indépendant des objets API. Cette approche vous permet de réutiliser le serveur API dans d'autres projets (en plus de Kubernetes), et les consommateurs (comme Kubernetes) peuvent définir les types de ressources dont ils ont besoin en tant que CRD.
Les pilotes CSI qui prennent en charge les instantanés installeront automatiquement les CRD nécessaires. Les utilisateurs finaux de Kubernetes doivent uniquement vérifier que le pilote CSI qui prend en charge les instantanés est déployé dans le cluster.
En plus de ces nouveaux objets, le
PersistentVolumeClaim existant
PersistentVolumeClaim un nouveau champ
DataSource :
type PersistentVolumeClaimSpec struct { AccessModes []PersistentVolumeAccessMode Selector *metav1.LabelSelector Resources ResourceRequirements VolumeName string StorageClassName *string VolumeMode *PersistentVolumeMode DataSource *TypedLocalObjectReference }
Ce champ (dans l'état de la version alpha) vous permet de le remplir automatiquement avec les données d'un instantané existant lors de la création d'un nouveau volume.
Configuration requise pour les instantanés Kubernetes
Avant d'utiliser des instantanés de volume dans Kubernetes, vous devez:
- assurez-vous que le pilote CSI qui implémente les instantanés est déployé et s'exécute sur le cluster;
- activer la fonction Kubernetes Volume Snapshotting via la nouvelle porte des fonctionnalités (désactivée par défaut pour la version alpha):
- définissez l'indicateur suivant pour l'
--feature-gates=VolumeSnapshotDataSource=true serveur API: --feature-gates=VolumeSnapshotDataSource=true
Avant de créer un instantané, vous devez également déterminer le pilote CSI à utiliser, ce qui se fait en créant un objet
VolumeSnapshotClass et en spécifiant le pilote CSI dans le champ de l'
snapshotter . Dans l'exemple de
VolumeSnapshotClass ci-dessous, ce pilote est
com.example.csi-driver . Chaque fournisseur d'instantanés nécessite au moins un objet
VolumeSnapshotClass . Il est également possible de définir une
VolumeSnapshotClass par défaut pour chaque pilote CSI - cela se fait en définissant l'annotation
snapshot.storage.kubernetes.io/is-default-class: "true" dans la définition de classe:
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
Tous les paramètres requis doivent être définis conformément à la documentation du pilote CSI. Dans l'exemple ci-dessus, le paramètre
fakeSnapshotOption: foo et tous les secrets mentionnés seront transmis au pilote CSI lors de la création et de la suppression de l'instantané.
Le snapshotter externe CSI enregistre par défaut les clés de paramètres
csiSnapshotterSecretName et
csiSnapshotterSecretNamespace .
Enfin, avant de créer un instantané, vous devez créer le volume via le pilote CSI et le remplir avec les données que vous souhaitez y voir (voir
cette publication pour plus de détails sur l'utilisation des volumes CSI).
Création d'un nouvel instantané dans Kubernetes
Une fois que l'objet
VolumeSnapshotClass défini et correspond au volume duquel vous souhaitez supprimer l'instantané, vous pouvez effectuer cette opération en créant l'objet
VolumeSnapshot .
La source de l'instantané est déterminée par deux paramètres:
kind - PersistentVolumeClaim indiqué ici;name - le nom réel de l'objet PVC.
Il est entendu que l'espace de noms du volume pour lequel l'instantané est créé est déterminé par l'espace de noms de l'objet
VolumeSnapshot .
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
La spécification
VolumeSnapshot peut
VolumeSnapshot une
VolumeSnapshotClass qui contient des informations sur le pilote CSI qui sera utilisé pour créer l'instantané. Comme indiqué précédemment, après avoir créé l'objet
VolumeSnapshot le paramètre
fakeSnapshotOption: foo et tous les secrets
VolumeSnapshotClass mentionnés sont transmis au plug
com.example.csi-driver in CSI
com.example.csi-driver dans l'appel
CreateSnapshot .
En réponse à une telle demande, le pilote CSI prend un instantané du volume, puis crée automatiquement un objet
VolumeSnapshotContent qui représente le nouvel instantané et lie cet objet au
VolumeSnapshot , le rendant prêt à l'emploi. Si le pilote CSI ne peut pas créer un instantané et renvoie une erreur, le contrôleur d'instantané signale cette erreur dans l'état de l'objet
VolumeSnapshot et
n'effectue pas de nouvelles tentatives (ce comportement est différent des autres contrôleurs de Kubernetes - il est implémenté afin de ne pas créer un instantané à des moments imprévisibles) .
Si la classe d'instantanés n'est pas spécifiée, external-snapshotter essaiera de trouver la classe par défaut et l'utilisera pour l'instantané créé. Dans ce cas, le pilote CSI pointé par le
snapshotter dans la classe par défaut doit correspondre au pilote CSI pointé par le
provisioner dans la classe de stockage PVC.
Veuillez noter que la version alpha des instantanés pour Kubernetes ne fournit aucune garantie de cohérence. Pour garantir des données complètes dans un instantané, il est nécessaire de préparer correctement l'application (arrêter l'application, figer le système de fichiers, etc.) avant de la supprimer.
Pour
VolumeSnapshot que l'objet
VolumeSnapshot a
VolumeSnapshot créé et associé au
VolumeSnapshotContent , vous pouvez utiliser la
kubectl describe volumesnapshot :
Ready doit être true dans Status , ce qui indique que l'instantané de volume est prêt à être utilisé.- Le champ
Creation Time indique quand l'instantané a été réellement pris. - Le champ
Restore Size est la taille de volume minimale pour restaurer un instantané. - Le champ
Snapshot Content Name dans la spécification pointe vers l'objet VolumeSnapshotContent créé pour cet instantané.
Importer un instantané existant dans Kubernetes
Un instantané existant peut être importé dans Kubernetes en créant manuellement un objet
VolumeSnapshotContent qui représentera cet instantané. Étant donné que
VolumeSnapshotContent est un objet API qui n'est pas lié à un espace de noms, seul l'administrateur système a le droit de le créer.
Lorsque l'objet
VolumeSnapshotContent créé, l'utilisateur peut créer un autre objet -
VolumeSnapshot - qui pointera vers lui. Le contrôleur d'instantané externe marquera l'instantané comme prêt après avoir vérifié l'existence et l'exactitude de la connexion entre les
VolumeSnapshotContent VolumeSnapshot et
VolumeSnapshotContent . Un instantané est prêt à être utilisé dans Kubernetes lorsque cette connexion est établie.
L'objet
VolumeSnapshotContent doit être créé avec les champs suivants représentant l'instantané préapprovisionné:
csiVolumeSnapshotSource - informations identifiant un instantané:
snapshotHandle - nom / identifiant pour l'instantané. Champ obligatoire;driver - Le pilote CSI fonctionnait avec ce volume. Champ obligatoire. Doit correspondre au nom de l' snapshotter dans le contrôleur (contrôleur d'instantané);creationTime et restoreSize - Pour les volumes pré-provisionnés, ces champs sont facultatifs. Le contrôleur de snapshotter externe les mettra automatiquement à jour après avoir créé un snapshot.
volumeSnapshotRef - pointeur vers l'objet VolumeSnapshot auquel cet objet (c'est-à-dire VolumeSnapshotContent ) doit être attaché:
name et namespace - le nom et l'espace de noms de l'objet VolumeSnapshot dont le contenu est lié;UID - champ facultatif (pour les volumes pré-préparés). Le contrôleur de snapshotter externe mettra automatiquement à jour ce champ après la liaison. Si l'utilisateur définit ce champ, vous devez vous assurer qu'il correspond à l'UID de l'instantané pour lequel la liaison se produit. S'il n'y a pas une telle correspondance, le contenu est considéré comme non pertinent (objet orphelin) et par conséquent le contrôleur le supprimera à la fois lui et l'instantané associé.
snapshotClassName est un champ facultatif. Le contrôleur de snapshotter externe le mettra automatiquement à jour après la liaison.
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
Un objet
VolumeSnapshot doit être créé afin que l'utilisateur puisse travailler avec l'instantané. Dans ce document:
snapshotClassName - nom de la classe d'instantanés du volume. Champ facultatif. S'il est défini, le champ d'instantané de la classe d'instantanés doit correspondre au nom du contrôleur d'instantanés. S'il n'est pas défini, le contrôleur recherchera la classe d'instantanés par défaut;snapshotContentName - le nom du contenu du volume de snapshot. Champ obligatoire pour les volumes pré-préparés.
apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: static-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass snapshotContentName: static-snapshot-content
Lorsque ces objets sont créés, le contrôleur de snapshot les liera, définissez le champ
Ready (dans
Status ) sur
True , indiquant que le snapshot est prêt à être utilisé.
Préparation d'un nouveau volume à partir d'un instantané dans Kubernetes
Pour créer un nouveau volume prérempli avec des données de l'objet instantané, utilisez le nouveau champ
dataSource dans
PersistentVolumeClaim . Il a trois paramètres:
name - nom de l'objet VolumeSnapshot représentant la source de l'instantané;kind - doit être défini comme VolumeSnapshot ;apiGroup - doit être snapshot.storage.k8s.io .
Il est supposé que l'espace de noms de la source -
VolumeSnapshot - correspond à l'espace de noms de
PersistentVolumeClaim .
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
Lorsque l'objet
PersistentVolumeClaim est créé, il appellera l'approvisionnement du nouveau volume, prérempli avec les données de l'instantané spécifié.
Comment ajouter la prise en charge des instantanés à mon pilote CSI si je suis développeur de stockage?
Pour prendre en charge les instantanés, des capacités de contrôleur supplémentaires doivent être ajoutées au pilote CSI:
CREATE_DELETE_SNAPSHOT et
LIST_SNAPSHOTS , ainsi que des contrôleurs RPC supplémentaires:
CreateSnapshot ,
DeleteSnapshot ,
ListSnapshots . Voir
la spécification CSI pour plus
de détails.
Bien que Kubernetes fournisse les
directives les plus
élémentaires pour l'empaquetage et le déploiement du pilote de volume CSI, il existe un
mécanisme recommandé pour déployer un pilote CSI conteneurisé arbitraire dans Kubernetes pour simplifier ce processus.
Dans le cadre du processus de déploiement recommandé, l'équipe Kubernetes suggère d'utiliser une variété de conteneurs sidecar (c'est-à-dire auxiliaires), y compris un sidecar-container avec un
snapshotter externe .
Le snapshotter externe mentionné surveille les objets
VolumeSnapshot et
VolumeSnapshotContent dans le serveur API, en invoquant les
DeleteSnapshot CreateSnapshot et
DeleteSnapshot pour le point de terminaison CSI. Le conteneur sidecar avec l'
approvisionneur externe CSI
a également été mis à jour pour prendre en charge la récupération de volume à partir d'instantanés à l'aide du nouveau champ PVC
dataSource .
Pour prendre en charge les capacités d'instantanés, il est recommandé aux fabricants de stockage de déployer des conteneurs sidecar avec un instantané externe en plus d'un provisionneur externe et de placer le pilote CSI dans un
StatefulSet , comme illustré dans le diagramme ci-dessous:
Dans
cet exemple de déploiement, il existe deux conteneurs sidecar, un provisionneur externe et un snapshotter externe, et les pilotes CSI sont déployés avec le plug-in de chemin d’hôte CSI dans le module StatefulSet. Le chemin d'hôte CSI est un exemple de plugin qui n'est pas destiné à être utilisé en production.
Quelles sont les limites de la version alpha?
La version alpha de l'implémentation de l'instantané dans Kubernetes présente les limitations suivantes:
- La restauration d'un volume existant vers un état précédent représenté par un instantané n'est pas prise en charge (seul l'approvisionnement d'un nouveau volume à partir d'un instantané est pris en charge).
- La restauration sur place n'est pas prise en charge pour
PersistentVolumeClaim existant à partir d'un instantané: c.-à-d. le provisionnement d'un nouveau volume à partir d'un instantané fonctionne, mais pas la mise à jour du PersistentVolumeClaim existant afin qu'il pointe vers un nouveau volume et que le PVC revienne à un état antérieur (uniquement en utilisant un nouveau volume créé à partir d'un instantané via un nouveau PV / PVC est pris en charge) - Les garanties de cohérence des instantanés ne vont pas au-delà des garanties fournies par le système de stockage (par exemple, l'intégrité lors de la suppression).
Et ensuite?
L'équipe Kubernetes prévoit d'apporter la mise en œuvre d'instantanés pour CSI à la version bêta dans les versions 1.13 ou 1.14, en fonction des commentaires reçus et de l'adaptation de la technologie.
Comment trouver plus de détails?
Voir la documentation supplémentaire sur les instantanés sur
k8s.io/docs/concepts/storage/volume-snapshots et
kubernetes-csi.imtqy.com/docs .
PS du traducteur
Lisez aussi dans notre blog: