云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读本文以 Longhorn 仓库中的设计文档 enhancements/20200904-csi-snapshot-support.md 为骨架系统讲解如何通过 Kubernetes 标准的 CSI Snapshot 机制VolumeSnapshot/VolumeSnapshotContent/VolumeSnapshotClass资源对 Longhorn 卷进行程序化的备份创建、备份删除与卷恢复。读完本文你将掌握如何为 Longhorn 部署 CSI Snapshotter 前置组件、如何配置VolumeSnapshotClass、如何创建/删除备份、如何从 CSI 快照恢复新卷以及如何将备份存储中已存在的 Longhorn 备份预置为可恢复的 CSI 快照。背景与动机在引入 CSI Snapshot 支持之前Longhorn 用户只能通过 UI、CLI 或直接调用 Longhorn API 与备份系统交互缺乏标准化的程序化访问途径。该设计文档提出在 Longhorn CSI 驱动中增加对 CSI Snapshot 机制的支持使既有 Kubernetes 生态工具可以直接创建VolumeSnapshotAPI 资源并由 CSI 插件响应这些资源从而完成备份的创建、删除与基于备份的卷恢复。相关需求来自 Longhorn issue #304、#610、#1127设计参照了 Kubernetes 社区的 CSI Snapshot 设计提案。其核心目标非常聚焦为 Longhorn CSI 驱动添加 CSI Snapshot 支持Goals不涉及VolumeBackupCRD 重构、不改动 Longhorn 备份核心代码Non-goals。CSI Snapshot 工作机制概览CSI Snapshot 体系由三层 Kubernetes 资源构成三者协作完成快照即备份的映射资源作用由谁创建VolumeSnapshot用户请求创建快照的入口声明数据源PVC 或既有VolumeSnapshotContent用户VolumeSnapshotContent已供应快照的实例承载 CSI 返回的snapshotHandle外部 snapshotter自动或用户预置既有备份VolumeSnapshotClass声明使用的 CSI driver 与删除策略用户/管理员工作流上用户创建VolumeSnapshot后集群中的 snapshot controller 会调用 external-snapshotter后者通过 CSI gRPC 接口调用 Longhorn CSI 插件插件侧完成 Longhorn 快照 备份后返回一个snapshotHandlesnapshotter 将其写入自动生成的VolumeSnapshotContent。前置条件与集群要求原设计文档明确指出CSI Snapshot 支持依赖 Kubernetes 集群侧具备 snapshot 能力而 CRD 与 snapshot controller 的安装责任属于 Kubernetes 发行版而非 Longhorn 本身。部署前需要确认Kubernetes 版本原设计文档要求集群版本至少为 1.17当前仓库的 Longhorn 部署清单已演进为更现代的组件版本见下文镜像说明生产环境请以所用 Longhorn 版本的官方文档要求为准。CRD 安装集群中必须存在snapshot.storage.k8s.io相关 CRDVolumeSnapshot、VolumeSnapshotContent、VolumeSnapshotClass该设计文档特别提醒 rancher rke 默认未部署这些 CRD需手动安装 external-snapshotter 的client/config/crd清单。Snapshot Controller集群中必须运行 snapshot controllerexternal-snapshotter 的deploy/kubernetes/snapshot-controller清单rancher rke 同样默认未部署。CSI 组件镜像在 airgap离线等需要手动固定 CSI 镜像的环境中需要手动提供以下镜像原设计文档版本longhornio/csi-provisioner:v1.6.0longhornio/csi-snapshotter:v2.1.1原文档同时说明csi-provisioner 从 1.4 升级到 1.6但仍以 Kubernetes 1.13 为最低支持版本。当前仓库中的 CSI 镜像版本对照当前仓库的 deploy/longhorn.yamlLonghorn 部署清单中的 CSI 相关镜像已经随项目演进升级csi-attacher:v4.12.0csi-provisioner:v6.3.0csi-node-driver-registrar:v2.17.0csi-resizer:v2.2.1csi-snapshotter:v8.6.0livenessprobe:v2.19.0这些镜像统一以CSI_*_IMAGE环境变量注入 Longhorn CSI Driver 的 Deployment便于离线环境替换为私有仓库地址。Helm 部署方式下可通过 chart/values.yaml 的image.csi.*配置项定制镜像仓库与 tag对应模板见 chart/templates/deployment-driver.yaml。另外当前部署清单中还预留了 CSI VolumeGroupSnapshot 开关CSI_VOLUME_GROUP_SNAPSHOT_ENABLED注释中明确提示启用它需要先安装groupsnapshot.storage.k8s.ioCRD否则 CSI Snapshotter 会停止服务常规卷快照普通用户无需开启。配置 VolumeSnapshotClass由于无法假设用户集群的发行版默认包含 snapshotter 支持用户必须自行创建VolumeSnapshotClass才能使用 CSI Snapshot。原设计文档给出的示例为snapshot.storage.k8s.io/v1beta1版本当前仓库的示例文件 examples/snapshot/snapshotclass.yaml 已使用稳定的v1API 版本kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: name: longhorn driver: driver.longhorn.io deletionPolicy: Delete #parameters: # csi.storage.k8s.io/snapshotter-secret-name: mysecret # csi.storage.k8s.io/snapshotter-secret-namespace: mysecretnamespace要点说明driver必须固定为 Longhorn 的 CSI 驱动标识driver.longhorn.io这是 external-snapshotter 与 Longhorn CSI 插件对接的依据。deletionPolicy决定删除VolumeSnapshot时底层备份的处置方式详见下文备份删除一节。注释掉的parameters字段用于配置 snapshotter 访问凭证 secret使用带认证的备份存储时可参考启用。用户操作场景详解以下四种场景全部来自原设计文档的 User Experience In Detail 部分并已对照仓库 examples/snapshot 目录下的示例清单做了版本同步v1beta1→v1。场景一通过 VolumeSnapshot 创建备份用户创建 KubernetesVolumeSnapshot对象即可触发对指定 PVC 的备份。例如对名为test-vol的卷请求备份apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: test-snapshot-pvc spec: volumeSnapshotClassName: longhorn source: persistentVolumeClaimName: test-vol对应仓库示例examples/snapshot/snapshot_pvc.yaml。底层流程创建VolumeSnapshot资源后snapshot controller 与 external-snapshotter 会调用 Longhorn CSI 插件的CreateSnapshot接口。插件先创建 Longhorn 快照再通过 Longhorn 备份机制将快照备份到用户定义的备份存储S3、NFS、Azure Blob 等。备份未完成期间CSI 快照会被标记为 not ready to use用户应等待VolumeSnapshot进入 Ready 状态后再使用。场景二通过 VolumeSnapshot 恢复新卷用户创建引用VolumeSnapshot作为dataSource的 PVC即可从既有备份恢复出全新卷。例如基于test-snapshot-pvc恢复名为test-restore-snapshot-pvc的卷apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-restore-snapshot-pvc namespace: default spec: storageClassName: longhorn dataSource: name: test-snapshot-pvc kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 2Gi对应仓库示例examples/snapshot/restore_pvc_snapshot.yaml。注意storageClassName必须为 Longhorn StorageClass且 PVC 容量与备份来源卷容量保持一致示例为 2Gi。场景三恢复备份存储中已存在的 Longhorn 备份预置对于不是通过 CSI 层创建的既有 Longhorn 备份用户需要手工创建一对VolumeSnapshotContentVolumeSnapshot对象将备份预置为 CSI 快照。核心是让VolumeSnapshotContent.spec.source.snapshotHandle指向备份存储中的既有备份格式为bs://backupVolume/backupNameapiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotContent metadata: name: test-existing-backup spec: volumeSnapshotClassName: longhorn driver: driver.longhorn.io deletionPolicy: Delete source: # NOTE: change this to point to an existing backup on the backupstore snapshotHandle: bs://test-vol/backup-625159fb469e492e volumeSnapshotRef: name: test-snapshot-existing-backup namespace: defaultapiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: test-snapshot-existing-backup spec: volumeSnapshotClassName: longhorn source: volumeSnapshotContentName: test-existing-backupapiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-restore-existing-backup namespace: default spec: storageClassName: longhorn dataSource: name: test-snapshot-existing-backup kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 2Gi三个清单分别对应仓库示例 examples/snapshot/existing_backup.yaml、examples/snapshot/snapshot_existing.yaml 和 examples/snapshot/restore_existing_backup.yaml。snapshotHandle中的bs://test-vol/backup-625159fb469e492e为占位示例实际使用时需替换为备份存储中真实存在的备份标识。场景四通过删除 VolumeSnapshot 删除备份删除操作遵循VolumeSnapshotClass的deletionPolicyDelete默认删除VolumeSnapshot对象后snapshotter 会调用 CSIDeleteSnapshot接口底层 Longhorn 备份会连同VolumeSnapshotContent一起被删除。Retain底层 Longhorn 备份与VolumeSnapshotContent均保留仅移除 Kubernetes 侧的引用关系。命令行操作为kubectl delete volumesnapshots test-snapshot-pvc若希望保留 Longhorn 备份请创建deletionPolicy: Retain的VolumeSnapshotClass并在VolumeSnapshot中引用它。实现设计CSI 调用背后的 Longhorn 映射机制原设计文档对本增强的实现方案做了清晰拆解理解这些机制有助于排查快照不可用备份找不到等问题。CreateSnapshot从 CSI 请求名到备份的持久映射请求名的由来CSI snapshotter 依据配置的前缀 VolumeSnapshot.uuid生成 CSI snapshot request name并据此生成VolumeSnapshotContent.name snapcontent-uuid。必须复用同名对同一个VolumeSnapshot对象csi-snapshotter 会以相同的CSI snapshot 请求名反复调用 Longhorn CSI 插件备份大卷耗时很长。因此 Longhorn 必须使用该请求名来命名 Longhorn 快照否则每次调用都会生成新快照——这显然不是期望行为。原设计文档也提出了另一条备选路径引入VolumeBackupCRD 来持久关联 csiSnapshot ↔ longhornSnapshot ↔ longhornBackup但该 CRD 重构被列为 Non-goal未在本增强中实现。snapshotID 编码为让后续DeleteSnapshot或CreateVolume调用能回查到对应备份插件将backupVolume与backupName编码进CreateSnapshot返回的 snapshotID 中格式为type://backupVolume/backupName其中默认type为bs直接引用 Longhorn 备份。该 snapshotID 会被 Kubernetes 写入自动创建的VolumeSnapshotContent.spec.snapshotHandle。设计上保留type前缀是为了将来可以改为引用自定义 Kubernetes 资源用于备份元数据的持久化。恢复复用既有路径基于 CSI 快照创建卷时解码 snapshotID 即可在备份存储中查到备份获得backupURL并填入 Longhorn Volume 资源的fromBackup字段。由于 Longhorn 早已支持通过 StorageClass 参数fromBackup恢复备份这里复用同一机制无需维护多套卷恢复代码路径。DeleteSnapshot解码即删除备份删除的实现非常简洁解码 snapshotID然后通过 Longhorn API 触发底层备份删除调用。端到端验证测试方案原设计文档给出了四组可复现的验证流程每组都围绕数据写入 → 快照操作 → 备份核对 → 数据校验闭环展开创建测试Creation test创建卷向卷写入数据创建VolumeSnapshot对象等待VolumeSnapshot变为 ready to use检查备份存储中是否存在对应备份。删除测试Deletion test创建卷并写入数据创建VolumeSnapshot等待 ready to use确认备份存储中存在备份删除VolumeSnapshot对象等待备份从备份存储中移除。恢复 CSI 快照测试Restore csi snapshot test创建卷并写入数据创建VolumeSnapshot等待 ready to use确认备份存在创建dataSource指向该VolumeSnapshot的 PVC等待卷恢复完成校验恢复后的卷数据与写入前的数据一致。恢复既有 Longhorn 备份测试Restore existing longhorn backup test创建卷并写入数据创建 Longhorn 备份并确认其存在于备份存储创建指向该备份的VolumeSnapshotContent创建指向该VolumeSnapshotContent的VolumeSnapshot创建dataSource指向该VolumeSnapshot的 PVC等待卷恢复并校验数据一致性。所需的全部 YAML 清单见上文用户操作场景详解及 examples/snapshot 目录。与后续增强的衔接CSI Snapshot 支持落地后Longhorn 围绕快照/备份的 CSI 生态仍在持续演进仓库中可看到两条直接相关的后续设计enhancements/20220110-extend-csi-snapshot-to-support-longhorn-snapshot.md将 CSI Snapshot 扩展支持到 Longhorn 本地快照enhancements/20230417-extend-csi-snapshot-to-support-backingimage.md将 CSI Snapshot 扩展支持到 Backing Image。这说明本文所述的type://backupVolume/backupName可扩展 snapshotID 设计确实为后续资源类型如自定义 CR 引用预留了空间。读者可按需阅读上述文档了解后续能力边界。常见问题与注意事项快照一直 not ready to use备份未完成时快照不会进入 Ready 状态大卷备份耗时较长请耐心等待并检查备份存储可达性。集群缺少 CRD/controllerVolumeSnapshot相关 CRD 与 snapshot controller 属于集群发行版职责Longhorn 安装不会代为部署。若kubectl get volumesnapshots报资源不存在请先补齐 external-snapshotter 的 CRD 与 controller。离线环境镜像固定airgap 环境务必手动提供 CSI 镜像原文档为csi-provisioner:v1.6.0与csi-snapshotter:v2.1.1当前版本请参考 deploy/longhorn.yaml 中的CSI_*_IMAGE变量。预置备份的 snapshotHandlebs://backupVolume/backupName必须指向备份存储中真实存在的备份否则恢复 PVC 会失败。删除策略默认deletionPolicy: Delete会连带删除底层备份需保留备份时改用Retain的VolumeSnapshotClass。总结通过本增强Longhorn 将标准的 Kubernetes CSI Snapshot 机制与自身快照/备份体系打通用户可以用统一的VolumeSnapshot资源完成备份创建、删除与卷恢复也能将备份存储中已有的 Longhorn 备份预置为 CSI 快照进行恢复而无需改变底层备份核心代码。其关键实现——用 CSI snapshotter 生成的请求名持久映射快照与备份、以bs://backupVolume/backupName编码 snapshotID、复用fromBackup恢复路径——保证了多次重试幂等与恢复路径的唯一性。部署时请务必确认集群具备 snapshot CRD 与 controller并按需创建VolumeSnapshotClass参考 examples/snapshot/snapshotclass.yaml。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Longhorn 扩展 CSI Snapshot 管理 BackingImage基于 VolumeSnapshot 的镜像创建、删除与恢复实战指南Longhorn 扩展 CSI Snapshot 管理 BackingImage基于 VolumeSnapshot 的镜像创建、删除与恢复实战指南 导读 本指云原生存储高可用容器编排Velero CSI 快照支持基于 Kubernetes CSI VolumeSnapshot API 的持久卷备份与恢复Velero CSI 快照支持基于 Kubernetes CSI VolumeSnapshot API 的持久卷备份与恢复 Velero当前仓库为 vmwa云原生灾备存储后端Velero CSI 快照支持借助 Kubernetes CSI Snapshot API 实现 CSI 卷的备份与恢复Velero CSI 快照支持借助 Kubernetes CSI Snapshot API 实现 CSI 卷的备份与恢复 导读 本文基于 Velero 官方文云原生灾备存储后端上一篇三步完成Windows与Office永久激活KMS_VL_ALL_AIO技术指南下一篇PaddleNLP 小样本多标签文本分类实战基于 ERNIE 3.0 的提示学习Prompt Learning全流程指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考