Kubernetes 卷快照 Alpha 更新

Kubernetes v1.12 引入了存储卷快照支持作为一项 Alpha 功能。在 Kubernetes v1.13 中，它仍然是一项 Alpha 功能，但增加了一些增强功能并进行了一些重大更改。本文总结了这些更改。

重大更改

CSI 规范 v1.0 对存储卷快照功能引入了一些重大更改。CSI 驱动程序维护者在将其驱动程序升级到支持 v1.0 时应注意这些更改。

SnapshotStatus 已替换为布尔值 ReadyToUse

CSI v0.3.0 在 CreateSnapshotResponse 中定义了一个 SnapshotStatus 枚举，它指示快照是否为 READY、UPLOADING 或 ERROR_UPLOADING。在 CSI v1.0 中，SnapshotStatus 已从 CreateSnapshotResponse 中删除，并替换为 boolean ReadyToUse。ReadyToUse 值为 true 表示快照后处理（例如上传）已完成，并且快照已准备好用作创建存储卷的源。

需要进行快照后处理（例如快照拍摄后上传）的存储系统应在快照拍摄完成后立即返回成功的 CreateSnapshotResponse，并将 ReadyToUse 字段设置为 false。这表明容器编排系统（CO）可以恢复为拍摄快照而暂停的任何工作负载。然后，CO 可以重复调用 CreateSnapshot，直到 ReadyToUse 字段设置为 true，或者调用返回指示处理问题的错误。CSI ListSnapshot 调用可以与 snapshot_id 过滤一起使用以确定快照是否准备就绪，但不建议这样做，因为它无法检测处理过程中的错误（ReadyToUse 字段只是无限期地保持 false）。

CSI external-snapshotter Sidecar 容器的 v1.x.x 版本已经通过调用 CreateSnapshot 而不是 ListSnapshots 来检查快照是否准备就绪来处理此更改。在将驱动程序升级到 CSI 1.0 时，驱动程序维护者应使用相应的 1.0 兼容 Sidecar 容器。

为了与 CSI 规范中的更改保持一致，VolumeSnapshot API 对象中的 Ready 字段已重命名为 ReadyToUse。当运行 kubectl describe volumesnapshot 查看快照详细信息时，用户可以看到此更改。

时间戳数据类型

快照的创建时间作为 VolumeSnapshotContent API 对象的一部分可供 Kubernetes 管理员使用。此字段使用 CSI CreateSnapshotResponse 中的 creation_time 字段填充。在 CSI v1.0 中，此 creation_time 字段类型已更改为 .google.protobuf.Timestamp 而不是 int64。在将驱动程序升级到 CSI 1.0 时，驱动程序维护者必须相应地进行更改。CSI external-snapshotter Sidecar 容器的 v1.x.x 版本已更新以处理此更改。

废弃

以下 VolumeSnapshotClass 参数已废弃，并将在未来的版本中删除。它们将被下面“替换”部分中列出的参数替换。

已废弃的替换项 csiSnapshotterSecretName csi.storage.k8s.io/snapshotter-secret-name csiSnapshotterSecretNameSpace csi.storage.k8s.io/snapshotter-secret-namespace

新功能

SnapshotContent 删除/保留策略

正如宣布快照 Alpha 版的最初博客文章中所述，Kubernetes 快照 API 与 PV/PVC API 类似：就像存储卷由绑定的 PVC 和 PV 对表示一样，快照由绑定的 VolumeSnapshot 和 VolumeSnapshotContent 对表示。

对于 PV/PVC 对，当用户完成使用存储卷后，他们可以删除 PVC。PV 上的回收策略决定了 PV 的处理方式（是也被删除还是保留）。

在最初的 Alpha 版本中，快照不支持指定回收策略。相反，当快照对象被删除时，它总是导致快照被删除。在 Kubernetes v1.13 中，添加了快照内容 DeletionPolicy。它使管理员能够配置在绑定的 VolumeSnapshot 对象被删除后，VolumeSnapshotContent 将如何处理。卷快照的 DeletionPolicy 可以是 Retain 或 Delete。如果未指定值，则默认值取决于 SnapshotContent 对象是通过静态绑定还是动态配置创建的。

保留

Retain 策略允许手动回收资源。如果 VolumeSnapshotContent 是静态创建并绑定的，则默认的 DeletionPolicy 是 Retain。当 VolumeSnapshot 被删除时，VolumeSnapshotContent 将继续存在，并且 VolumeSnapshotContent 被视为“已释放”。但它不能用于绑定到其他 VolumeSnapshot 对象，因为它包含数据。由管理员决定如何处理剩余的 API 对象和资源清理。

删除

Delete 策略支持从 Kubernetes 自动删除绑定的 VolumeSnapshotContent 对象以及外部基础设施中相关的存储资产（例如 AWS EBS 快照或 GCE PD 快照等）。动态配置的快照继承其 VolumeSnapshotClass 的删除策略，默认为 Delete。管理员应使用所需的保留策略配置 VolumeSnapshotClass。创建后，可以通过修补对象来更改单个 VolumeSnapshotContent 的策略。

以下示例演示了如何检查动态配置的 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: Delete
  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: Retain
  persistentVolumeRef:
    apiVersion: v1
    kind: PersistentVolume
    name: pvc-853622a4-f28b-11e8-8be6-42010a800002
...

快照对象使用保护

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

1. 如果卷快照正在被持久卷声明主动用作创建卷的源。
2. 如果 VolumeSnapshotContent API 对象绑定到 VolumeSnapshot API 对象，则内容对象被视为正在使用。

如果用户删除被 PVC 主动使用的 VolumeSnapshot API 对象，则 VolumeSnapshot 对象不会立即删除。相反，VolumeSnapshot 对象的删除将被推迟，直到 VolumeSnapshot 不再被任何 PVC 主动使用。同样，如果管理员删除绑定到 VolumeSnapshot 的 VolumeSnapshotContent，则 VolumeSnapshotContent 不会立即删除。相反，VolumeSnapshotContent 的删除将被推迟，直到 VolumeSnapshotContent 未绑定到 VolumeSnapshot 对象。

哪些卷插件支持 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 CSI (Container Storage Interface) GA”博客文章，了解有关 CSI 以及如何部署 CSI 驱动程序的更多信息。

下一步是什么？

根据反馈和采用情况，Kubernetes 团队计划在 1.15 或 1.16 版本中将 CSI 快照实现推向 Beta 版。我们感兴趣支持的一些功能包括一致性组、应用程序一致性快照、工作负载静默、原地恢复等。

我如何了解更多信息？

快照 API 和控制器的代码仓库在这里：https://github.com/kubernetes-csi/external-snapshotter

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

我如何参与？

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

特别感谢所有为本次版本中添加 CSI v1.0 支持和改进快照功能做出贡献的贡献者，包括 Saad Ali (saadali)、Michelle Au (msau42)、Deep Debroy (ddebroy)、James DeFelice (jdef)、John Griffith (j-griffith)、Julian Hjortshoj (julian-hj)、Tim Hockin (thockin)、Patrick Ohly (pohly)、Luis Pabon (lpabon)、Cheng Xing (verult)、Jing Xu (jingxu97)、Shiwei Xu (wackxu)、Xing Yang (xing-yang)、Jie Yu (jieyu)、David Zhu (davidz627)。

有兴趣参与 CSI 或 Kubernetes 存储系统任何部分的设计和开发的人员，请加入 Kubernetes 存储特别兴趣小组 (SIG)。我们正在快速发展，并始终欢迎新的贡献者。

我们还定期举行SIG-Storage 快照工作组会议。欢迎新成员加入设计和开发讨论。

• ←上一篇
• 下一篇→