关于cncf:Kubernetes-120Kubernetes卷快照提升到GA

37次阅读

共计 4871 个字符，预计需要花费 13 分钟才能阅读完成。

你填了吗？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/v1
kind: VolumeSnapshotClass
metadata:
 name: test-snapclass
driver: testdriver.csi.k8s.io
deletionPolicy: Delete
parameters:
 csi.storage.k8s.io/snapshotter-secret-name: mysecret
 csi.storage.k8s.io/snapshotter-secret-namespace: mysecretnamespace

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

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
 name: test-snapshot
 namespace: ns1
spec:
 volumeSnapshotClassName: test-snapclass
 source:
 persistentVolumeClaimName: test-pvc

应用 Kubernetes 导入现有卷快照

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

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
 name: test-content
spec:
 deletionPolicy: Delete
 driver: testdriver.csi.k8s.io
 source:
 snapshotHandle: 7bdd0de3-xxx
 volumeSnapshotRef:
 name: test-snapshot
 namespace: default

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

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
 name: test-snapshot
spec:
 source:
 volumeSnapshotContentName: test-content

从快照创立新卷

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-restore
 namespace: demo-namespace
spec:
 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 微信公众号。

正文完
cncf
发表至： cncf
2020-12-11
 0
关于cncf:使用Lens管理多云Kubernetes
关于cncf:KubeVirt深度剖析系列之virtcontroller源码分析
关于cncf:OpenYurt-联手-eKuiper解决-IoT-场景下边缘流数据处理难题
关于cncf:5个Kubernetes成本估算问题和策略