你填了吗？2020年CNCF中国云原生问卷

问卷链接（https://www.wjx.cn/jq/9714648...）

作者：Xing Yang, VMware & Xiangqian Yu, Google

Kubernetes卷快照个性当初在Kubernetes v1.20中是GA。它在Kubernetes v1.12中以alpha的模式引入，随后在Kubernetes v1.13中进行了第二次alpha，并在Kubernetes 1.17中降级为beta版本。这篇博客总结了从beta版到GA版的变动。

什么是卷快照？

许多存储系统（如谷歌云长久磁盘、Amazon弹性块存储和许多外部存储系统）都提供了创立长久卷的“快照”的能力。快照示意卷的工夫点正本。快照能够用于从新生成新卷（用快照数据预填充），也能够用于将现有卷复原到以前的状态（由快照示意）。

为什么要向Kubernetes增加卷快照？

Kubernetes的指标是在分布式应用程序和底层集群之间创立一个形象层，以便应用程序能够不晓得它们运行的集群的具体情况，并且应用程序部署不须要“特定于集群的”常识。

Kubernetes Storage SIG将快照操作辨认为许多有状态工作负载的要害性能。例如，数据库管理员可能心愿在启动数据库操作之前快照数据库的卷。

通过提供在Kubernetes中触发卷快照操作的规范办法，该个性容许Kubernetes用户以可移植的形式在任何Kubernetes环境中合并快照操作，而不论底层存储是什么。

此外，这些Kubernetes快照个性/原语（primitive）充当根本构建块，开释了为Kubernetes开发高级企业级存储管理个性（包含应用程序或集群级备份解决方案）的能力。

beta之后有什么新个性吗？

随着卷快照晋升到GA，该个性在规范Kubernetes部署中默认启用，并且不能敞开。

曾经对该个性进行了许多加强，以进步其品质并使其达到生产级。

  • 卷快照API和客户端库被挪动到独自的Go模块。
  • 增加了快照验证webhook来对卷快照对象执行必要的验证。更多细节能够在卷快照验证Webhook Kubernetes加强倡议中找到。
  • 与验证webhook一起，卷快照控制器将开始标记曾经存在的有效快照对象。这容许用户辨认、删除任何有效对象，并纠正他们的工作流。一旦API切换到v1类型，这些有效对象将不能从零碎中删除。
  • 为了更好地理解快照个性是如何执行的，在卷快照控制器中增加了一组初始操作指标。
  • 还有更多（在GCP上运行的）端到端测试，能够在真正的Kubernetes集群中验证该个性。引入了压力测试（基于谷歌长久磁盘和hostPath CSI驱动程序）来测试零碎的健壮性。

除了引入了更严格的验证之外，v1beta1和v1 Kubernetes卷快照API之间没有任何区别。在这个版本中（应用Kubernetes 1.20），提供了v1和v1beta1，而存储的API版本依然是v1beta1。将来的版本将把存储的版本切换到v1，并逐步删除对v1beta1的反对。

哪些CSI驱动程序反对卷快照？

快照只反对CSI驱动程序，不反对树内或FlexVolume驱动程序。确保集群上部署的CSI驱动程序实现了快照接口。无关更多信息，请参见Kubernetes GA的容器存储接口（CSI）。

目前有50多个CSI驱动程序反对卷快照个性。GCE长久磁盘CSI驱动程序曾经通过了从卷快照beta降级到GA的测试。对其余CSI驱动程序的GA级反对应该很快就能够应用了。

谁应用卷快照构建产品？

在本博客公布之时，以下来自Kubernetes数据保护工作组的参与者正在应用Kubernetes卷快照构建产品或曾经构建了产品。

  • Dell-EMC: PowerProtect
  • Druva
  • Kasten K10
  • Pure Storage (Pure Service Orchestrator)
  • Red Hat OpenShift Container Storage
  • TrilioVault for Kubernetes
  • Velero plugin for CSI

如何部署卷快照？

卷快照性能蕴含以下组件：

  • Kubernetes Volume Snapshot CRDs
  • Volume snapshot controller
  • Snapshot validation webhook
  • CSI Driver along with CSI Snapshotter sidecar

强烈建议Kubernetes发行商捆绑并部署卷快照控制器、CRD和验证webhook，作为Kubernetes集群治理过程的一部分（独立于任何CSI驱动程序）。

正告：快照验证webhook在从应用v1beta1平稳过渡到应用v1 API时起着关键作用。如果不装置快照验证webhook，就不可能阻止有效卷快照对象的创立/更新，这反过来会阻止有效卷快照对象在将来的降级中被删除。

如果你的集群没有事后装置正确的组件，你能够手动装置它们。详见CSI Snapshotter README。

如何应用卷快照？

假如所有必须的组件（包含CSI驱动程序）曾经部署并运行在集群上，你能够应用VolumeSnapshot API对象创立卷快照，或者通过在PVC上指定VolumeSnapshot数据源，应用现有的VolumeSnapshot来复原PVC。无关更多细节，请参阅卷快照文档。

留神：Kubernetes Snapshot API不提供任何应用程序一致性保障。在手动或应用更高级别的API/控制器进行快照之前，你必须筹备好你的应用程序（暂停应用程序，解冻文件系统等等）。

动态创建卷快照

要动态创建卷快照，首先创立一个VolumeSnapshotClass API对象。

apiVersion: snapshot.storage.k8s.io/v1kind: VolumeSnapshotClassmetadata: name: test-snapclassdriver: testdriver.csi.k8s.iodeletionPolicy: Deleteparameters: csi.storage.k8s.io/snapshotter-secret-name: mysecret csi.storage.k8s.io/snapshotter-secret-namespace: mysecretnamespace

而后通过指定卷快照类从PVC创立一个VolumeSnapshot API对象。

apiVersion: snapshot.storage.k8s.io/v1kind: VolumeSnapshotmetadata: name: test-snapshot namespace: ns1spec: volumeSnapshotClassName: test-snapclass source: persistentVolumeClaimName: test-pvc

应用Kubernetes导入现有卷快照

要将事后存在的卷快照导入Kubernetes，请首先手动创立一个VolumeSnapshotContent对象。

apiVersion: snapshot.storage.k8s.io/v1kind: VolumeSnapshotContentmetadata: name: test-contentspec: deletionPolicy: Delete driver: testdriver.csi.k8s.io source: snapshotHandle: 7bdd0de3-xxx volumeSnapshotRef: name: test-snapshot namespace: default

而后创立一个指向VolumeSnapshotContent对象的VolumeSnapshot对象。

apiVersion: snapshot.storage.k8s.io/v1kind: VolumeSnapshotmetadata: name: test-snapshotspec: source: volumeSnapshotContentName: test-content

从快照创立新卷

绑定并准备就绪的VolumeSnapshot对象可用于通过快照数据事后填充的数据创立新卷，如下所示：

apiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-restore namespace: demo-namespacespec: storageClassName: test-storageclass dataSource: name: test-snapshot kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 1Gi

如何在CSI驱动程序中增加对快照的反对？

无关如何在CSI驱动程序中实现快照个性的更多细节，请参阅CSI标准和Kubernetes-CSI驱动程序开发指南。

有什么限度？

Kubernetes卷快照的GA实现有以下限度：

  • 不反对将现有PVC复原到快照所示意的晚期状态（只反对从快照中创立新卷）。

如何学习更多？

快照API和控制器的代码存储库在这里：
https://github.com/kubernetes...

查看快照个性的其余文档：
http://k8s.io/docs/concepts/s...
https://kubernetes-csi.github...

如何参加？

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

咱们对在过来的几个季度里帮忙GA实现该项目标贡献者示意非常感谢。咱们要感激Saad Ali、Michelle Au、Tim Hockin和Jordan Liggitt对设计的粗浅见解和透彻思考；感激Andi Li在减少快照验证Webhook的反对方面所做的工作；感激Grant Griffiths对施行指标反对 在快照控制器中并在验证Webhook中解决明码轮换；感激Chris Henzie、Raunak Shah和Manohar Reddy编写了要害的e2e测试以满足降级的可伸缩性和稳定性要求；感激Kartik Sharma将快照API和客户端库迁徙到了 独自的go模块；并感激Raunak Shah和Prafull Ladha在从Beta到GA的降级测试中所提供的帮忙。

还有很多人帮忙将快照性能从beta版本晋升到GA版本。咱们要感激为这一致力作出贡献的每一个人：

  • Andi Li
  • Ben Swartzlander
  • Chris Henzie
  • Christian Huffman
  • Grant Griffiths
  • Humble Devassy Chirammal
  • Jan Šafránek
  • Jiawei Wang
  • Jing Xu
  • Jordan Liggitt
  • Kartik Sharma
  • Madhu Rajanna
  • Manohar Reddy
  • Michelle Au
  • Patrick Ohly
  • Prafull Ladha
  • Prateek Pandey
  • Raunak Shah
  • Saad Ali
  • Saikat Roychowdhury
  • Tim Hockin
  • Xiangqian Yu
  • Xing Yang
  • Zhu Can

对于那些有趣味参加CSI或Kubernetes存储系统的任何局部的设计和开发的人，退出Kubernetes存储特地趣味组（SIG）。咱们正在疾速倒退，欢送新的贡献者。

咱们亦定期举办保障材料工作小组会议。欢送新参会者退出探讨。

点击浏览网站原文。

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。