Kubernetes的卷快照Alpha更新

作者： 徐静（Google），兴阳（华为），萨阿德（Google）

卷快照支持是Kubernetes v1.12中的一项Alpha功能。在Kubernetes v1.13中，它仍然是alpha功能，但是增加了一些增强功能并进行了一些重大更改。这篇文章总结了这些变化。

重大变化

CSI规范v1.0 对卷快照功能进行了一些重大更改。 CSI驱动程序维护人员在升级驱动程序以支持v1.0时应注意这些更改。

SnapshotStatus替换为布尔型ReadyToUse

CSI v0.3.0, defined a SnapshotStatus enum in CreateSnapshotResponse which indicates whether the snapshot is READY, UPLOADING, or ERROR_UPLOADING. In CSI v1.0, SnapshotStatus has been removed from CreateSnapshotResponse 和 replaced with a boolean ReadyToUse. A ReadyToUse value of true indicates that post snapshot processing (such as uploading) is complete 和 the snapshot is ready to be used as a source to create a volume.

Storage systems that need to do post snapshot processing (such as uploading after the snapshot is cut) should return a successful CreateSnapshotResponse with the ReadyToUse field set to false as soon as the snapshot has been taken. This indicates that the Container Orchestration System (CO) can resume any workload that was quiesced for the snapshot to be taken. 的 CO can then repeatedly call CreateSnapshot until the ReadyToUse field is set to true or the call returns an error indicating a problem in processing. 的 CSI ListSnapshot call could be used along with snapshot_id filtering to determine if the snapshot is ready to use, but is not recommended because it provides no way to detect errors during processing (the ReadyToUse field simply remains false indefinitely).

的 v1.x.x版本 of the CSI external-snapshotter sidecar container already handle this change by calling CreateSnapshot instead of ListSnapshots to check if a snapshot is ready to use. When upgrading their 司机 to CSI 1.0, driver maintainers should use the appropriate 1.0 compatible sidecar container.

To be consistent with the change in the CSI spec, the Ready field in the VolumeSnapshot API object has been renamed to ReadyToUse. This change is visible to the user when running kubectl describe volumesnapshot to view the details of a snapshot.

时间戳数据类型

的 creation time of a snapshot is available to Kubernetes admins as part of the VolumeSnapshotContent API object. This field is populated using the creation_time field in the CSI CreateSnapshotResponse. In CSI v1.0, this creation_time field type was changed to .google.protobuf.Timestamp instead of int64. When upgrading 司机 to CSI 1.0, driver maintainers must make changes accordingly. 的 v1.x.x版本 CSI external-snapshotter sidecar容器的容器已更新，可以处理此更改。

弃用

的 following VolumeSnapshotClass parameters are deprecated 和 will be removed in a future release. 的y will be replaced with parameters listed in the 替代 section below.

不推荐使用 Replacement csiSnapshotterSecretName csi.storage.k8s.io/snapshotter-secret-name csiSnapshotterSecretNameSpace csi.storage.k8s.io/snapshotter-secret-namespace

新的功能

SnapshotContent删除/保留策略

如中所述 最初的博客文章宣布快照alpha, the Kubernetes snapshot APIs are similar to the PV/PVC APIs: just like a volume is represented by a bound PVC 和 PV pair, a snapshot is represented by a bound VolumeSnapshot 和 VolumeSnapshotContent pair.

使用PV / PVC对时，当用户完成一个卷时，他们可以删除PVC。 PV上的回收策略决定了PV发生了什么（无论它是否被删除或保留）。

In the initial alpha release, snapshots did not support the ability to specify a reclaim policy. Instead when a snapshot object was deleted it always resulted in the snapshot being deleted. In Kubernetes v1.13, a snapshot content DeletionPolicy was added. It enables an admin to configure what what happens to a VolumeSnapshotContent after the VolumeSnapshot object it is bound to is deleted. 的 DeletionPolicy of a volume snapshot can either be 保留 or 删除. If the value is not specified, the default depends on whether the SnapshotContent object was created via static binding or dynamic provisioning.

保留

的 保留 policy allows for manual reclamation of the resource. If a VolumeSnapshotContent is statically created 和 bound, the default DeletionPolicy is 保留. When the VolumeSnapshot is deleted, the VolumeSnapshotContent continues to exist 和 the VolumeSnapshotContent is considered “released”. But it is not available for binding to other VolumeSnapshot objects because it contains data. It is up to an administrator to decide how to handle the remaining API object 和 resource cleanup.

删除

A 删除 policy enables automatic deletion of the bound VolumeSnapshotContent object from Kubernetes 和 the associated storage asset in the external infrastructure (such as an AWS EBS snapshot or GCE PD snapshot, etc.). Snapshots that are dynamically provisioned inherit the deletion policy of their VolumeSnapshotClass, which defaults to 删除. 的 administrator should configure the VolumeSnapshotClass with the desired retention policy. 的 policy may be changed for individual VolumeSnapshotContent after it is created by patching the object.

的 following example demonstrates how to check the deletion policy of a dynamically provisioned VolumeSnapshotContent.

$ kubectl create -f ./examples/kubernetes/demo-defaultsnapshotclass.yaml
$ kubectl create -f ./examples/kubernetes/demo-snapshot.yaml
$ kubectl get volumesnapshots demo-snapshot-podpvc -o yaml
apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshot
metadata:
  creationTimestamp: "2018-11-27T23:57:09Z"
...
spec:
  snapshotClassName: default-snapshot-class
  snapshotContentName: snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002
  source:
    apiGroup: null
    kind: PersistentVolumeClaim
    name: podpvc
status:
…
$ kubectl get volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -o yaml
apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotContent
…
spec:
  csiVolumeSnapshotSource:
    creationTime: 1546469777852000000
    driver: pd.csi.storage.gke.io
    restoreSize: 6442450944
    snapshotHandle: projects/jing-k8s-dev/global/snapshots/snapshot-26cd0db3-f2a0-11e8-8be6-42010a800002
  deletionPolicy: 删除
  persistentVolumeRef:
    apiVersion: v1
    kind: PersistentVolume
    name: pvc-853622a4-f28b-11e8-8be6-42010a800002
    resourceVersion: "21117"
    uid: ae400e9f-f28b-11e8-8be6-42010a800002
  snapshotClassName: default-snapshot-class
  volumeSnapshotRef:
    apiVersion: snapshot.storage.k8s.io/v1alpha1
    kind: VolumeSnapshot
    name: demo-snapshot-podpvc
    namespace: default
    resourceVersion: "6948065"
    uid: 26cd0db3-f2a0-11e8-8be6-42010a800002

用户可以使用补丁程序更改删除策略：

$ kubectl patch volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -p '{"spec":{"deletionPolicy":"Retain"}}' --type=merge

$ kubectl get volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -o yaml
apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotContent
...
spec:
  csiVolumeSnapshotSource:
...
  deletionPolicy: 保留
  persistentVolumeRef:
    apiVersion: v1
    kind: PersistentVolume
    name: pvc-853622a4-f28b-11e8-8be6-42010a800002
...

快照对象使用保护

使用中的快照对象保护功能的目的是确保不会从系统中删除使用中的快照API对象（因为这可能会导致数据丢失）。有两种情况需要“使用中”保护：

1. 如果持久化卷声明正在使用卷快照作为创建卷的源。
2. If a VolumeSnapshotContent API object is bound to a VolumeSnapshot API object, the content object is considered in use.

If a user deletes a VolumeSnapshot API object in active use by a PVC, the VolumeSnapshot object is not removed immediately. Instead, removal of the VolumeSnapshot object is postponed until the VolumeSnapshot is no longer actively used by any PVCs. Similarly, if an admin deletes a VolumeSnapshotContent that is bound to a VolumeSnapshot, the VolumeSnapshotContent is not removed immediately. Instead, the VolumeSnapshotContent removal is postponed until the VolumeSnapshotContent is not bound to the VolumeSnapshot object.

哪些卷插件支持Kubernetes快照？

仅CSI驱动程序支持快照（树内或FlexVolume不支持）。要使用Kubernetes快照功能，请确保在群集上部署了实现快照的CSI驱动程序。

在发布此博客文章时，以下CSI驱动程序支持快照：

• GCE永久磁盘CSI驱动程序
• OpenSDS CSI驱动程序
• Ceph RBD CSI驱动程序
• Portworx CSI驱动程序
• GlusterFS CSI驱动程序
• DigitalOcean CSI驱动程序
• Ember CSI驱动程序
• Cinder CSI驱动程序
• Datera CSI驱动程序
• NexentaStor CSI驱动程序

快照支持其他 司机 尚待处理，应尽快推出。阅读“用于Kubernetes GA的容器存储接口（CSI）”博客文章，以了解有关CSI以及如何部署CSI驱动程序的更多信息。

下一步是什么？

根据反馈和采用情况，Kubernetes团队计划将CSI Snapshot实施推至beta版本1.15或1.16。我们希望支持的某些功能包括一致性组，应用程序一致性快照，工作负载静默，就地还原等。

我该如何学习？

快照API和控制器的代码存储库位于： //github.com/kubernetes-csi/external-snapshotter

在此处查看有关快照功能的其他文档： http://k8s.io/docs/concepts/storage/volume-snapshots 和 //kubernetes-csi.github.io/docs/

我该如何参与？

与所有Kubernetes一样，该项目是来自不同背景的许多贡献者共同努力的结果。

特别感谢所有贡献者，包括Saad Ali（萨达里），欧锦绣（msau42），深德布罗（（德布罗伊），詹姆斯·德费利斯（杰德夫），约翰·格里菲斯（John Griffith（格里菲斯），朱利安（Julian Hjortshoj）（朱利安），蒂姆·霍金（ock），帕特里克·奥赫利（h地），路易斯·潘本（pa），程兴（真实的），徐静（静许97），徐世伟（ack），杨兴（ing阳），洁玉（界宇），朱大卫（davidz627）。

那些有兴趣参与CSI或Kubernetes Storage System的任何部分的设计和开发的人，请加入 Kubernetes存储特别兴趣小组 （SIG）。我们正在迅速发展，并随时欢迎新的贡献者。

我们也定期举办 SIG-存储快照工作组会议。欢迎新的参与者参加设计和开发讨论。

• ← 以前
下一页 →