Kubernetes 数据保护工作流白皮书解读从备份/恢复缺失构建块到应用级数据保护实践【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文以 Kubernetes Community 仓库中 Data Protection Working Group数据保护工作组发布的《Data Protection Workflows》白皮书为骨架系统梳理 Kubernetes 生态中数据保护的定义、动因与落地路径从为什么要保护 K8s 数据到当前 Kubernetes 已具备哪些能力、还缺哪些构建块Volume Backups、Change Block Tracking、Volume Populator、Quiesce/Unquiesce Hooks、Volume Group、Backup Repository、Application Snapshot再到应用备份与恢复的完整工作流以及 MySQL、NuoDB、Prometheus、InfluxDB、etcd、Kafka、MongoDB 等典型数据库的备份恢复实操。读完本文你将掌握在 Kubernetes 中设计一套端到端数据保护方案所需的全部概念、API 演进脉络与可落地的操作流程。本文全部内容基于仓库文档 wg-data-protection/data-protection-workflows-white-paper.md并结合 wg-data-protection/charter.md、sigs.yaml 中的工作组定义及各年度报告进行佐证与扩展。文中的三张流程图均取自 wg-data-protection/figures 目录。一、什么是 Kubernetes 语境下的数据保护1.1 定义数据保护Data Protection在 Kubernetes 语境下是指保护运行在集群中的应用程序的有价值数据与配置的过程。数据保护的结果通常被称为备份Backup。当意外场景发生——例如故障软件导致的数据损坏、灾难导致的数据丢失——备份可以用来把受保护的工作负载恢复到备份所保存的状态。在 Kubernetes 中一个有状态应用包含两类核心数据一组 Kubernetes 资源即应用配置通常存储在 etcd 中通过 Kubernetes API Server 访问可导出为 JSON 或 YAML 文件。例如经典的 WordPress 应用由两个 Deployment、一个 Secret、若干个 PersistentVolumeClaim 和两个 Service 资源组成这些资源共同构成应用本身。持久卷数据Persistent Volume DataKubernetes 通过 PersistentVolumeClaim API 让用户为工作负载预置持久卷对应 PersistentVolume 资源卷数据由底层存储系统管理。数据保护的目标正是对上述两类数据提供备份与恢复能力。工作组的宪章wg-data-protection/charter.md明确工作组负责定义并推动实现一组 Kubernetes 原生构造native constructs以便在不同层级持久卷层、应用层、集群层启用备份与恢复但不是由工作组去定义特定应用编排的备份/恢复接口与流程——因为不同应用达成应用一致性application consistency的策略与流程千差万别。1.2 为什么需要数据保护有状态的 Kubernetes 应用使用 PersistentVolume 存储数据。PersistentVolume 拥有独立于 Pod/集群的生命周期即便 Pod 或集群消失数据仍可保留在底层存储系统上。但问题在于底层卷因某种原因损坏了怎么办底层存储系统遭遇灾难怎么办一旦发生存储在 PersistentVolume 上的数据同样会丢失。因此必须找到一种方式来保护有状态应用使用的数据。白皮书将需要数据保护的原因归纳为三点云原生应用 vs 传统数据保护有状态 vs 无状态应用IT 中的角色与范围Roles and Scopes in IT二、数据保护的三大动因2.1 云原生应用 vs 传统数据保护应用架构的演变应用架构经历了四个技术阶段阶段架构特征数据管理特点大型机Mainframes应用完全固化在系统内一切相对静态易于跟踪与管理服务器架构Server应用被模块化为独立软件组件组件仍需在操作系统边界内与紧耦合组件一同运行虚拟化Virtualization多操作系统共享底层硬件应用架构与服务器时代相似紧耦合组件在虚拟机内运行云原生Cloud-native拆分为轻量微服务独立运行、各自拥有身份与可能挂载的数据通过定义良好的 API 通信应用整体功能由多个微服务协作完成关键结论应用架构在数十年间发生了巨大变化但数据保护的范式始终如一——而架构服务器、虚拟服务器、容器却变得日益动态化、短命化。从裸金属服务器跃迁到虚拟化只提高了硬件利用率应用架构并未改变应用运行方式的元数据绑定在所在机器上数据卷虽可能映射到独立卷但仍可从同一台机器内访问。而云原生应用架构完全不同数据卷与容器分离连接信息仅存在于独立的声明式元数据文件中。因此必须采用新的数据保护方法来支撑这类架构——数据依然需要被保护以支撑业务连续性。传统技术的局限早期拥抱云原生、采用容器的组织立刻发现了既有方案的短板传统方案聚焦于单体应用全部包含在 OS 边界内以基础设施/存储为中心主要关注数据卷因为元数据与应用二进制总是存在于物理/虚拟服务器中数据保护方案的扩展通常需要 IT 运维的侵入式参与无法无缝伸缩在缺乏端到端云原生数据保护方案时工程师用临时脚本 传统方案拼凑备份能力但脚本高度静态、需频繁更新以适应云原生应用的动态特性组件与元数据随服务需求持续变化带来大量运维开销。结论是能管理云原生应用的云原生解决方案应当是每个想现代化基础设施与应用的组织追求的目标。2.2 有状态 vs 无状态应用有状态应用依赖此前的事务数据无状态应用不依赖此前事务即可执行下一次操作。容器化兴起时有人推测容器应用无需备份因为是瞬态无状态但这一局面已彻底改变——大量有状态应用正运行在 Kubernetes 中应用必须访问和计算数据才能正常运转。白皮书引用的调查显示46% 的受访者已在容器中使用有状态应用93% 视 Kubernetes 为有状态应用的可行平台 [1]另有研究显示数据库是 2019 年容器中的头号用例 [2]。在 Kubernetes/云原生世界中应用由以下逻辑组件构成容器镜像Container Images镜像本质是部署到 Kubernetes 中的模板通常托管在公有或私有镜像仓库中。备份镜像或其宿主数据卷后即可在任何 Kubernetes 环境运行——但应用并非只由镜像组成更多时候还挂载持久数据卷。元数据Metadata描述容器如何运行以及其他容器代码访问所需的非容器对象的 Kubernetes 资源定义。例如secrets保存用户凭据信息service暴露应用/容器。持久卷Persistent Volume容器访问数据的存储卷对象。由此可以看到尽管 web-server 这类组件本身可以无状态只转发请求但它往往与有状态组件数据库交互使整体应用前端/后端呈现有状态特征。那些没有持久卷、却对应用运行不可或缺的内部容器即便无状态其珍贵的元数据信息也必须作为应用的一部分备份——因为仅靠镜像本身价值有限。要在 Kubernetes 中获得成功的数据保护体验必须把应用作为单一单元a single unit来保护。总结备份需求有状态应用假设镜像已备份则需保护声明式 YAML元数据 容器使用的持久卷以便快速恢复容器执行所需的数据及行为无状态应用假设镜像已备份仍需备份容器如何运行的元数据信息声明式 YAML以便在其他环境以相同方式快速恢复上线。2.3 IT 中的角色与范围Kubernetes 通过基于角色的访问控制RBAC连接开发与运维团队运维基于细粒度 RBAC 策略管控基础设施的每个角落namespace集群内的迷你/虚拟集群通常是开发者的专属工作区。如果应用不是云原生/Kubernetes 原生开发者与运维的协同就难以实现因为 RBAC 的责任会落到应用提供方身上可能与环境中其他应用的 RBAC 功能不一致。因此从数据保护角度必须为开发者和运维团队提供一致的体验来保护和管理应用与数据。Kubernetes 环境中的所有解决方案都应遵循这一原则与基础设施需求绑定更紧密的数据保护方案也没有理由特立独行。三、数据保护用例与用户角色3.1 Kubernetes 数据保护中的用户角色应用所有者Application Owners专注在集群上创建、更新、运行应用。希望在修改应用前触发备份出问题时对应用全部或部分进行自助恢复且只有自己才能访问应用的备份。Kubernetes 集群管理员Cluster Administrators专注于让集群本身对应用管理员保持可用关心集群灾难恢复和跨集群应用迁移通常是集群上备份 operator 的守门人。集中运维/备份团队Central Operations / Backup Teams按照企业最佳实践与合规要求保护应用包括 RPO恢复点目标、RTO恢复时间目标、保留期retention period以及备份的异地副本维护通常管理中央备份仓库central backup repository。3.2 应用保护Application Protection应用是 Kubernetes 最主要的保护对象因为应用驱动业务和保护需求。应用保护覆盖以下场景应用定义Application DefinitionKubernetes 没有原生应用对象客户与厂商正创建自定义机制来定义应用。挑战在于应用所有者知道应用由什么组成而中央备份管理员负责设置策略并监督保护流程。自定义应用定义让双方对保护什么达成共识。应用组件包括Kubernetes 资源如 pods、secrets、configmaps 等持久卷非 Kubernetes 卷的外部数据存储——例如 Amazon RDS、集群外的 NAS 共享并非所有应用都包含全部组件也并非所有客户都会把全部资源纳入应用定义例如显式排除某些资源。应用备份定义Application Backup DefinitionKubernetes 没有原生备份对象同样需要自定义机制。备份定义的第一部分是如何执行备份的配方recipe常见关注点包括数据库从简单 quiesce 到日志截断再到副本管理数据库保护必然涉及定制客户可能为一天中不同时段使用不同配方如每天一次应用一致性备份 vs 每天四次崩溃一致性备份一致性组Consistency groups常与数据库相关应用的某些组件在崩溃一致性备份时可能有 I/O 一致性要求快照 vs 备份有时客户想用本地快照有时想把数据复制到备用位置——用标准 CLI 工具如 MySQL 的 mysqldump或备份厂商 agent如定制 tar 拷贝文件系统全部文件如何连接外部数据存储进行保护备份资源的顺序如需要。应用所有者还可以定义备份服务需求如 RPO、RTO、保留期、异地保护厂商可让用户逐项指定或打包成等价于备份类backup class的集合。厂商与用户需要机制来定义、发布、执行这些备份配方含等价于 pre/post 脚本、agent 配置、环境变量的内容也需要机制让应用所有者指定其备份需求。应用灾难恢复Application Disaster Recovery灾难性应用故障时用户期望恢复应用资源与数据但不恢复底层集群或其配置。可恢复到同一集群的同一 namespace同一集群的备用 namespace同一区域的备用集群备用区域/地理位置厂商可假设原应用已不再运行。客户对不同恢复选项会有不同的 RPO/RTO 期望开销与性能也会随 RPO、RTO 与位置而变化。应用回滚Application Rollback应用发生非预期变更配置和/或数据时用户期望回滚到备份创建的时间点。回滚不仅要重建/修改应用资源还要清除备份时点不存在、现在却多出来的资源。客户还期望有不覆盖现有资源的选项并接受回滚期间的应用停机。回滚目标通常是同一集群的同一 namespace。应用迁移Application Migration迁移原因包括成本优化、负载均衡、集群升级。虽然迁移严格说不是保护用例但许多客户借助保护工具完成迁移。与灾难恢复类似可迁移到备用 namespace / 备用集群 / 备用区域。由于迁移可能跨版本或跨厂商客户还需在恢复时修改资源定义的选项存储类、名称、容器定义等。根据迁移流程管理方式源应用可能与迁移后的应用并行运行直到切换cutover发生以最小化风险与停机。应用克隆Application Cloning克隆用于培训、开发、升级测试等场景同样常借用保护工具。克隆目标与迁移类似由于克隆与生产实例并行运行必须确保资源不冲突如资源重命名且数据被复制。客户可能希望保留克隆的来源信息provenance用于跟踪克隆副本或推送新的黄金副本golden copy。应用检索Application Retrieval出于法律案件、项目检索或合规需求客户需要检索旧版本应用。应用检索越来越重要其一允许组织在上下文中查看数据其二随着 AI/ML 可复现性需求的兴起重建完整应用流日益关键。恢复多年前的备份带来额外要求版本向后兼容多年前的资源需要映射到现代集群Kubernetes 集群版本备份与恢复时的集群版本可能不同容器保护与恢复备份团队不完全信任容器仓库会长期保留旧版本镜像因此需要保护容器本身备份容器镜像。资源恢复Resource Recovery出于法律案件、测试子集、只回滚应用的一部分等原因客户需要恢复应用的子集。可恢复到四个目标位置同集群同 namespace / 同集群备 namespace / 同区域备集群 / 备区域。客户需要指定要恢复的资源厂商只实现这些资源的恢复某些情况下厂商必须校验依赖资源已就位以确保恢复成功。3.3 Namespace 保护Namespace Protection由于没有良定义的应用对象许多客户选择保护 namespace有的只保护 namespace有的在应用之外额外保护 namespace还有的排除与应用绑定资源来保护 namespace。需要注意namespace 保护不是保护 namespace 中所有应用的机制——虽然厂商可选择把 namespace 当作选择 namespace 中所有应用来提供 UI/API但白皮书把 namespace 当作实际对象。好处应用所有者无需参与保护策略定义挑战只能使用简单的崩溃一致性保护机制应用所有者难以指定恢复备份团队与应用团队之间缺乏清晰连接。恢复流程与应用恢复流程一致但更强调资源恢复。3.4 集群保护Cluster Protection大部分集群保护超出备份倡议的范围。在备份语境下集群保护不包括重建 Kubernetes 集群单独备份和恢复 etcd 存储。完整集群灾难恢复、etcd DR 与 etcd 回滚虽有价值但不在工作组范围内。集群保护同样不是保护集群中所有 namespace/应用的机制。不过部分客户对集群级对象感兴趣包括 CRD 和未绑定的 PersistentVolume——集群保护会备份这些资源恢复通常在资源级别进行。四、Kubernetes 当前已具备的能力数据保护工作组在不同层级解决数据保护问题持久卷层定义 API使用户能为持久卷创建快照或备份并从卷快照/备份恢复持久卷应用层定义 API用于对组成应用的 Kubernetes 资源分组并对应用 Pod/Container 触发 Quiesce/Unquiesce 操作以获得应用一致性快照/备份。应用层数据保护很可能复用持久卷层的构造。截至白皮书撰写时Kubernetes 已有如下构建块VolumeSnapshot APIGA API允许用户为持久卷创建快照后续可用 VolumeSnapshot 资源重新水合rehydrate一个卷各种工作负载 APIStatefulSet、Deployment、DaemonSet 等Application CRD。五、Kubernetes 缺失的构建块工作组识别出以下缺失的构建块Volume backups卷备份Backup repositories备份仓库Volume populator卷填充器Quiesce and unquiesce hooks暂停/恢复钩子Change Block Tracking / CBT变更块跟踪Volume group and group consistent snapshot卷组与组一致性快照Application snapshots and backups应用快照与备份下图展示了结合现有与缺失构建块的备份工作流图 1备份工作流含缺失构建块。图中以不同颜色区分 Process流程、Existing K8s Component现有组件绿色、WIP K8s Component开发中组件黄色如 ContainerNotifier、COS与 Missing K8s Component缺失组件橙色如 Application Backup、Backup Repository、VolumeBackup。备份流程从 Application Backup 出发分为 K8s Resource Backup资源备份由 Workload APIs / Sig-Apps 支撑与 Data Backup数据备份两条分支数据备份经决策节点分流为 Native Data Dump原生数据导出与 Controller Coordinated控制器协调含 Quiesce → Volume Snapshot or Backup → UnQuiesce 序列最终统一 Export Backup 到 Backup Repository。图 2恢复工作流含缺失构建块。从 Application Restore 出发K8s Resource Restore 分支处理资源恢复其中 PVC/PV Restore 需要特殊处理PVC/PV Restore needs special handling数据恢复分支从 Backup Repository依赖 COSImport Backup经决策分流为 Restore from native data dump 或 Rehydrate PVC from VolumeSnapshot/VolumeBackup。5.1 Volume Backups卷备份动机现有卷快照能力无法让用户把备份存储到不同位置、设备或存储介质对应标准3-2-1 备份规则。白皮书明确区分两个术语snapshot快照数据的时间点记录backup备份可存储在与来源集群不同位置、生命周期独立于来源集群的快照。部分快照实现尤其是第一代云厂商实现可能本身就是备份或可通过 VolumeSnapshotClass 中的魔法参数变成备份但没有可移植的方式来显式执行备份这使得在 Kubernetes 中制定可移植的数据保护策略成为不可能。本项工作的目标是产出 Kubernetes 卷备份设计它与卷快照不同但应具备类似的用户 API例如对卷执行备份、预置卷并从备份填充。卷备份的理想特征为简洁下文 snapshot 指卷快照backup 指卷备份。时间点捕获与快照一样备份应代表卷数据的时间点捕获至少应能从一个卷创建备份并能从备份恢复卷预置新卷、用先前备份填充。独立生命周期与快照不同备份的生命周期应完全独立于尽管可控于其来源卷和集群——尤其是备份应能在集群、存储池甚至数据中心整体毁灭后存活且能将备份恢复到不同集群。这不意味着对恢复目标的存储池毫无约束如可能有技术约束——同类型存储但不应有身份约束如同实例。真实的数据副本 增量传输为满足生命周期特征备份必须实际存储卷数据的副本。与快照一样备份会按计划定期执行以最小化故障时的 RPO由于卷与备份间的地理距离是理想属性主卷与备份站点间的数据传输速率应主要随数据变化率而非卷大小伸缩。首次备份通常是全量拷贝但大多数后续备份应当是增量的。透明共享同一卷存储在同一位置的备份很可能共享数据这是预期的但共享对用户透明删除一个备份不应使其他备份失效。支持 3-2-1 规则应能使用备份实现 3-2-1 数据保护规则的全部组成部分——备份通常应存储在不同物理设备设备损坏不影响备份、不同设备类型主存储的 bug 或可利用安全漏洞不危及备份且实现应支持异地存储异地应视为典型场景。可信赖的完整性作为数据保护策略的关键支点用户必须信任备份完整性这意味着极高持久性存储可能依赖复制、防故意篡改如禁止对既有备份的写访问、严格控制删除访问、一定程度的签名和/或加密。部分方面适合在 Kubernetes 内暴露如加密用安全密钥等。职责分离备份架构应允许主存储与备份职责分离支持以下模式备份模式① 由主存储系统执行② 由第三方组件执行——依赖获取卷的静止副本通常通过快照或卷克隆并提供带外out-of-band计算最新卷与上次备份差异的方法③ 由第三方组件执行——依赖主存储实现的尚未完全定义的自上次快照/备份以来变更的块特性。恢复模式① 主存储从用户视角在一个逻辑操作中完成卷预置与从备份填充类似现有快照模型② 用户体验同上但主存储只负责卷预置第三方组件提供卷填充。适度标准化可尝试标准化备份的通用属性如对象存储桶、备份存储区域、每个备份的副本数等但对深度标准化的热情应有所克制——要为竞争性产品留出创新与差异化空间。5.2 Change Block Tracking变更块跟踪 / CBT动机高效备份卷数据是备份系统的重要特性。两次备份之间并非卷内所有数据都会变化因此只备份已变更的数据是理想选择。许多存储系统会跟踪自上次时间点快照以来的变更并暴露给备份应用Kubernetes Snapshot 特性提供了快照持久卷的标准 API但没有标准方式获知自某个快照以来哪些数据发生了变化。Differential Snapshots差分快照描述特定卷上任意两个快照之间的变更。理想的Differential Snapshots Service差分快照服务应提供快速、轻松识别变更数据以用于备份的信息同时处理块卷与文件系统卷的变更提供任意两个卷快照之间变更的信息当请求针对已删除快照的变更时服务应返回特定值由调用方采取相应行动对块卷支持不同块大小变更的最小粒度为单个设备块对文件系统卷处理共享卷并在多个层级文件系统卷、目录、文件、文件内块提供差异。Incremental snapshots增量快照描述自上次快照以来的变更因此是差分快照的特例。注意描述这些术语时实现与计费之间可能存在区别。使用差分快照服务的示例备份工作流图 3使用差分快照服务的备份工作流。应用 Pod 通过 PVC/PV 挂载块磁盘Backend Storage 先后生成 Snapshot 1基础快照与 Snapshot 2后续快照DifferentialSnapshot Service 计算两者差异Data Mover Pod 借助临时 PVC2 仅把变化数据迁移到 Backup Storage图中右侧标注 Only backup changes。示例工作流一利用差分快照服务提升备份效率为待备份的 PVC 创建 VolumeSnapshot以该 VolumeSnapshot 为数据源创建新 PVCPVC2查询差分快照服务获取两个快照之间的变更列表——对块设备是两快照间的变更块列表Changed Blocks, CBT对文件系统卷是两快照间的变更文件列表Changed Files List基于该列表只从 PVC2 备份变更数据若无法获得变更列表则备份整个卷同时可保存额外元数据用于从备份数据合成完整 PV。示例工作流二备份方案可直接访问存储设备时无需从快照创建 PVC为待备份的 PVC 创建 VolumeSnapshot查询差分快照服务获取变更列表格式同上基于该列表与后端存储通信只获取并备份列表中的变更数据无法获取变更列表时备份整个卷。后续进展佐证根据 wg-data-protection/annual-report-2025.md 与 wg-data-protection/annual-report-2024.mdCSI Changed Block Tracking 的 KEPkubernetes/enhancements 3314已合并并持续推进实现配套有 kubernetes-csi/external-snapshot-metadata 项目与 CSI 规范 PRcontainer-storage-interface/spec#551可见白皮书中的设想正在社区落地。5.3 Volume Populator卷填充器动机卷填充器的目的是创建一种机制让用户能创建由任意 CR拥有对应 populator定义数据内容的 PVC。该机制是从备份恢复卷工作流的关键部分从 API 视角看恢复只是创建一个 PVC其 datasource 指向一个备份 CR而备份 CR 的populator负责执行恢复。状态卷填充器是 Kubernetes v1.23 起的alpha 特性相对更早的 alpha 版本重新设计。新 API 设计KEP 1495依赖 PVC spec 中的dataSourceRef字段。一个集群中可以共存无限数量的卷填充器既服务于备份/恢复之外的用例也支持多种备份/恢复实现。由于 Kubernetes 尚无统一的备份 API不同实现很可能用实现特定的 CRD 表示备份对象卷填充器设计正好为此提供便利。长期来看可能出现共享实现的通用格式甚至 SIG Storage 支持的官方备份 API。无论哪种方式在恢复工作流中使用 populator API 都将带来无缝的用户体验。后续进展佐证据 wg-data-protection/annual-report-2025.mdVolume PopulatorsKEP 1495已于 v1.33 转为 GAsig-storage/annual-report-2025.md 也确认该特性允许从任意数据源填充卷数据。5.4 Quiesce and Unquiesce Hooks暂停/恢复钩子动机如前所述客户希望保护并恢复应用。许多有状态应用使用数据库与高级数据服务这些服务建议或要求在拍摄快照前使用其自身机制将服务带入一致状态。因此需要一种机制让厂商和客户能为数据库及高级数据服务创建应用一致性数据副本。背景高级数据服务如数据库的一致性备份通常采用以下一种或多种方式应用一致性逻辑备份备份流由数据服务自身生成是数据流而非快照因此需要触发、传输并存储数据副本崩溃一致性快照备份服务不连接数据库直接拍摄快照依赖数据服务能从任意时间点快照恢复——数据库厂商通常不推荐这种方式应用一致性快照备份服务连接数据库触发其 quiesce 功能如热备模式让数据库进入一致状态拍摄快照再让数据库回到标准模式——这是数据库厂商偏爱的方式。客户期望三种方法都被支持。崩溃一致性快照由标准 CSI 快照解决无需数据库特定命令而要在 Kubernetes 环境中交付应用一致性快照备份服务必须能执行数据库特定命令通常是数据库的 quiesce/unquiesce 功能。要访问 quiesce 功能就需要 quiesce/unquiesce 钩子。数据库 quiesce 命令通常通过客户端二进制或 SDK 提供因此可打包进容器镜像很多情况下客户端二进制就在服务镜像内。在 Kubernetes 中可通过 pod/exec 子资源直接在服务的 pod 中执行命令因此我们需要标准钩子来访问这些命令。Container Notifier容器通知器一个名为Container Notifier的 Kubernetes Enhancement Proposal 正在评审中kubernetes/enhancements PR 1995。该提案引入一种机制通知选定的 Pod 集合执行预置在 Pod spec 中的命令允许 Pod 作者定义可在容器内执行的命令集。该机制可用于实现数据库特定的 quiesce/unquiesce 钩子。例如数据库 Pod spec 的作者可在ContainerNotifierHandler字段中定义刷新数据库表到磁盘的命令数据库用户可通过提议的核心 APIPodNotification触发该命令。5.5 Volume Group and Group Snapshot卷组与组快照动机尽管已有 KEPkubernetes/enhancements PR 1051尝试引入应用快照、备份、恢复 API仍有其他用例未被覆盖用例 1VolumeGroup 允许用户把属于同一应用的多个卷放在一起管理非常通用。例如可用于把同一 StatefulSet 中的所有卷分组用例 2某些存储系统总是按组管理卷。对这些系统若要在 Kubernetes 中实现创建卷功能就不得不为单个卷创建组。提供 VolumeGroup API 将非常方便用例 3与其逐个拍摄快照不如用 VolumeGroup 作为数据源对组内所有卷一次性拍摄快照。若存储系统支持这可能是存储级别的组一致性快照无论如何与 quiesce 钩子结合时组快照可以是应用一致性的。为此引入另一个 CRDVolumeGroupSnapshot用例 4若存储系统支持VolumeGroup 可用于管理组复制或一致性组复制。注意复制超出本提案范围仅作为潜在未来用例提及用例 5VolumeGroup 可用于管理卷放置——跨存储池分散卷或在同一存储池堆叠卷。相关 KEPstorage pool 概念PR 1353、PR 1347。此用例可能未必需要 VolumeGroupStoragePool 可能就足够——待定用例 6VolumeGroup 可与应用快照一起使用作为 ApplicationSnapshot CRD 管理的资源用例 7部分应用不使用 Kubernetes 工作负载 APIStatefulSet、Deployment 等而是自研 operator此时用 VolumeGroup 管理这些应用使用的持久卷更便捷。目标为支持卷组与组快照需要新增以下 API一个把多个卷作为组管理的 API一个支持快照一致性组、确保组内所有卷跨卷崩溃一致性的 API一个对一组卷拍摄快照、但不保证崩溃一致性的 API。组 API 应通用且可扩展以便未来支持其他特性。状态存在正在评审的增强提案kubernetes/enhancements PR 1551。后续进展佐证据 wg-data-protection/annual-report-2025.mdVolume Group SnapshotKEP 3476已演进至 v1.34 的 v1beta2sig-storage/annual-report-2025.md 亦确认其引入 VolumeGroupSnapshot API 以一次拍摄多个卷的快照。5.6 Backup Repositories备份仓库为什么需要备份仓库备份仓库Backup Repository是应用备份的目标存储位置。当站点计算、网络、存储完全宕机时备份仓库用于集中保存数据。快照之所以不是真正的备份正因快照通常与主存储存放在同一系统上形成单点故障。如今数据以指数级速度产生存储空间、备份频率与备份总数持续增长因此备份仓库必须在空间处理、扩展性与读写性能效率方面足够智能高效。动机/目标本节旨在为数据保护厂商提供目标仓库target repository的高层指引为目标仓库提供需求这些需求应被 Kubernetes 支持的 API 所利用提供目标类型选择的高层指引。预期大多数客户会把备份仓库托管在公有云也有部分客户因已有设备而继续托管在本地。下表总结了备份仓库的关键特征、原因、对现有 API 的建议改进与注意事项特征为什么需要对现有 API 的建议改进/变化备注多协议① 对象存储Object Storage用于可扩展性——对象命名简洁② 文件存储File Storage用于迁移lift and shift视角/性能不引入环境中的新存储类型③ Data Domain 类设备④ EBS作为目标而非源也许用于迁移COSI/CSI 改进不同对象存储有不同大小限制需处理变更目标时需考虑迁移用例或许中间翻译层会有帮助多位置/多类型本地与云端Azure Blob、AWS S3、Google Cloud Storage由 COSI API 支持开始使用 API 以了解差距与投资领域冗余地理可用性——基于区域云设置 HA 的能力与云 API 服务集成同上长期归档把数据迁移到低成本存储的能力例如 S3 → Glacier与存储 API 服务集成今天由 BU 厂商处理明天应通过 API 在目标层处理权限通过单一接口处理目标权限的能力COSI 有一套用于 bucket 访问的 API—加密设置加密并选择加密算法的能力静态加密源、静态加密目标、传输中加密备份技术/网络存储加密备份/用户数据的密钥管理挑战与用户密钥管理系统集成备份速度可能受加密影响*BU 访问被加密的明文用户数据去重/压缩启用/禁用去重/压缩的能力今天由 BU 厂商处理明天应通过 API 在目标层处理智能去重可加快备份传输速度今天由 BU 厂商处理明天应通过 API 在目标层处理多集群目标管理多集群访问同一目标时需要所有权与委托控制的机制未来需要更长讨论与实现—5.7 Application Snapshots and Backups应用快照与备份动机VolumeSnapshot API 的加入使持久卷具备快照与恢复能力但应用快照与恢复语义需要考虑的远不止卷快照应用快照同时捕获应用的配置与持久数据。关键在于应用快照必须包含足够信息能从零完整创建一个特定时间点捕获的有状态应用实例。具体来说应用快照包含两部分应用组成资源的定义副本 应用所用持久卷的快照。特别是卷快照必须以应用一致性方式在同一时刻拍摄。为保证应用一致性可能需要在卷快照前 quiesce 应用、成功后 unquiesce 应用。ContainerNotifier 提案正是让用户在应用容器中请求执行任意钩子命令的通用机制适用于应用暂停/恢复等用例。有了 VolumeSnapshot API 与 ContainerNotifier API我们便具备了执行应用级快照与恢复的部分必要构建块。但应用级数据管理操作需要更高级的工作流与自动化——例如拍摄应用快照是多步骤工作流不只是编排卷快照和请求 ContainerNotifier 执行。因此需要一个新的 Kubernetes API以应用一致性方式支持应用级的快照、备份、恢复与克隆语义。目标提出一个用于有状态应用数据管理的 Kubernetes API支持应用级快照、备份、恢复与克隆语义。状态该 KEPkubernetes/enhancements PR 1051提出 Kubernetes Stateful Application Data Management API由一组 CustomResourceDefinitionsCRD组成共同定义有状态应用即维护持久状态的应用的概念以及快照、备份、恢复、克隆等数据管理语义。有状态应用快照被定义为以应用一致性方式拍摄的应用状态时间点捕获同时捕获应用配置组成应用的 Kubernetes 资源定义如 StatefulSets、Services、ConfigMaps、Secrets 等与应用包含的持久数据通过持久卷。六、应用备份与恢复工作流由于应用备份/恢复有两种通用方法——逻辑导出logical-dump与PVC 快照PVC-snapshot——工作流也分为两种类型。6.1 应用备份工作流应用备份工作流由Data Protection Controller数据保护控制器推动控制器监听 Kubernetes API Server 上的 Backup 对象创建事件执行备份工作流来备份应用。工作流可能涉及一个名为data-mover pod的组件它能连接备份设备备份仓库备份应用的持久卷数据。应用备份工作流可能包含以下步骤备份组成应用的 Kubernetes 资源StatefulSet、Secrets 等应用级动作例如在备份数据前执行禁用负载均衡器命令。ContainerNotifier 可用于选择执行该命令的 pod。并非所有应用都需要此步骤备份应用数据根据应用类型执行以下动作组之一逻辑导出如 mysqldump客户端命令连接应用服务器 pod/service把整个应用数据导出到本地备份文件或作为文件流导出到远程备份仓库。若生成了本地备份文件还需额外步骤把备份文件移动到备份仓库快照动作对每个应用 pod 按以下顺序执行部分应用要求特定执行顺序如 secondary pod 需先于 primary pod执行pre-hook 命令通常把应用数据刷盘flush并 quiesce 应用使其暂时冻结快照该 pod 使用的全部/选定 PVC执行post-hook 命令如 unquiesce把 PVC 快照备份到备份仓库。此步骤通常在全部卷快照创建完成后进行以缩短应用冻结时间。一种潜在的快照备份方式Controller 以快照为数据源创建新 PVCController 创建新的 contenteditable="false">【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 数据保护工作流白皮书解读：从备份/恢复缺失构建块到应用级数据保护实践
Kubernetes 数据保护工作流白皮书解读从备份/恢复缺失构建块到应用级数据保护实践【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文以 Kubernetes Community 仓库中 Data Protection Working Group数据保护工作组发布的《Data Protection Workflows》白皮书为骨架系统梳理 Kubernetes 生态中数据保护的定义、动因与落地路径从为什么要保护 K8s 数据到当前 Kubernetes 已具备哪些能力、还缺哪些构建块Volume Backups、Change Block Tracking、Volume Populator、Quiesce/Unquiesce Hooks、Volume Group、Backup Repository、Application Snapshot再到应用备份与恢复的完整工作流以及 MySQL、NuoDB、Prometheus、InfluxDB、etcd、Kafka、MongoDB 等典型数据库的备份恢复实操。读完本文你将掌握在 Kubernetes 中设计一套端到端数据保护方案所需的全部概念、API 演进脉络与可落地的操作流程。本文全部内容基于仓库文档 wg-data-protection/data-protection-workflows-white-paper.md并结合 wg-data-protection/charter.md、sigs.yaml 中的工作组定义及各年度报告进行佐证与扩展。文中的三张流程图均取自 wg-data-protection/figures 目录。一、什么是 Kubernetes 语境下的数据保护1.1 定义数据保护Data Protection在 Kubernetes 语境下是指保护运行在集群中的应用程序的有价值数据与配置的过程。数据保护的结果通常被称为备份Backup。当意外场景发生——例如故障软件导致的数据损坏、灾难导致的数据丢失——备份可以用来把受保护的工作负载恢复到备份所保存的状态。在 Kubernetes 中一个有状态应用包含两类核心数据一组 Kubernetes 资源即应用配置通常存储在 etcd 中通过 Kubernetes API Server 访问可导出为 JSON 或 YAML 文件。例如经典的 WordPress 应用由两个 Deployment、一个 Secret、若干个 PersistentVolumeClaim 和两个 Service 资源组成这些资源共同构成应用本身。持久卷数据Persistent Volume DataKubernetes 通过 PersistentVolumeClaim API 让用户为工作负载预置持久卷对应 PersistentVolume 资源卷数据由底层存储系统管理。数据保护的目标正是对上述两类数据提供备份与恢复能力。工作组的宪章wg-data-protection/charter.md明确工作组负责定义并推动实现一组 Kubernetes 原生构造native constructs以便在不同层级持久卷层、应用层、集群层启用备份与恢复但不是由工作组去定义特定应用编排的备份/恢复接口与流程——因为不同应用达成应用一致性application consistency的策略与流程千差万别。1.2 为什么需要数据保护有状态的 Kubernetes 应用使用 PersistentVolume 存储数据。PersistentVolume 拥有独立于 Pod/集群的生命周期即便 Pod 或集群消失数据仍可保留在底层存储系统上。但问题在于底层卷因某种原因损坏了怎么办底层存储系统遭遇灾难怎么办一旦发生存储在 PersistentVolume 上的数据同样会丢失。因此必须找到一种方式来保护有状态应用使用的数据。白皮书将需要数据保护的原因归纳为三点云原生应用 vs 传统数据保护有状态 vs 无状态应用IT 中的角色与范围Roles and Scopes in IT二、数据保护的三大动因2.1 云原生应用 vs 传统数据保护应用架构的演变应用架构经历了四个技术阶段阶段架构特征数据管理特点大型机Mainframes应用完全固化在系统内一切相对静态易于跟踪与管理服务器架构Server应用被模块化为独立软件组件组件仍需在操作系统边界内与紧耦合组件一同运行虚拟化Virtualization多操作系统共享底层硬件应用架构与服务器时代相似紧耦合组件在虚拟机内运行云原生Cloud-native拆分为轻量微服务独立运行、各自拥有身份与可能挂载的数据通过定义良好的 API 通信应用整体功能由多个微服务协作完成关键结论应用架构在数十年间发生了巨大变化但数据保护的范式始终如一——而架构服务器、虚拟服务器、容器却变得日益动态化、短命化。从裸金属服务器跃迁到虚拟化只提高了硬件利用率应用架构并未改变应用运行方式的元数据绑定在所在机器上数据卷虽可能映射到独立卷但仍可从同一台机器内访问。而云原生应用架构完全不同数据卷与容器分离连接信息仅存在于独立的声明式元数据文件中。因此必须采用新的数据保护方法来支撑这类架构——数据依然需要被保护以支撑业务连续性。传统技术的局限早期拥抱云原生、采用容器的组织立刻发现了既有方案的短板传统方案聚焦于单体应用全部包含在 OS 边界内以基础设施/存储为中心主要关注数据卷因为元数据与应用二进制总是存在于物理/虚拟服务器中数据保护方案的扩展通常需要 IT 运维的侵入式参与无法无缝伸缩在缺乏端到端云原生数据保护方案时工程师用临时脚本 传统方案拼凑备份能力但脚本高度静态、需频繁更新以适应云原生应用的动态特性组件与元数据随服务需求持续变化带来大量运维开销。结论是能管理云原生应用的云原生解决方案应当是每个想现代化基础设施与应用的组织追求的目标。2.2 有状态 vs 无状态应用有状态应用依赖此前的事务数据无状态应用不依赖此前事务即可执行下一次操作。容器化兴起时有人推测容器应用无需备份因为是瞬态无状态但这一局面已彻底改变——大量有状态应用正运行在 Kubernetes 中应用必须访问和计算数据才能正常运转。白皮书引用的调查显示46% 的受访者已在容器中使用有状态应用93% 视 Kubernetes 为有状态应用的可行平台 [1]另有研究显示数据库是 2019 年容器中的头号用例 [2]。在 Kubernetes/云原生世界中应用由以下逻辑组件构成容器镜像Container Images镜像本质是部署到 Kubernetes 中的模板通常托管在公有或私有镜像仓库中。备份镜像或其宿主数据卷后即可在任何 Kubernetes 环境运行——但应用并非只由镜像组成更多时候还挂载持久数据卷。元数据Metadata描述容器如何运行以及其他容器代码访问所需的非容器对象的 Kubernetes 资源定义。例如secrets保存用户凭据信息service暴露应用/容器。持久卷Persistent Volume容器访问数据的存储卷对象。由此可以看到尽管 web-server 这类组件本身可以无状态只转发请求但它往往与有状态组件数据库交互使整体应用前端/后端呈现有状态特征。那些没有持久卷、却对应用运行不可或缺的内部容器即便无状态其珍贵的元数据信息也必须作为应用的一部分备份——因为仅靠镜像本身价值有限。要在 Kubernetes 中获得成功的数据保护体验必须把应用作为单一单元a single unit来保护。总结备份需求有状态应用假设镜像已备份则需保护声明式 YAML元数据 容器使用的持久卷以便快速恢复容器执行所需的数据及行为无状态应用假设镜像已备份仍需备份容器如何运行的元数据信息声明式 YAML以便在其他环境以相同方式快速恢复上线。2.3 IT 中的角色与范围Kubernetes 通过基于角色的访问控制RBAC连接开发与运维团队运维基于细粒度 RBAC 策略管控基础设施的每个角落namespace集群内的迷你/虚拟集群通常是开发者的专属工作区。如果应用不是云原生/Kubernetes 原生开发者与运维的协同就难以实现因为 RBAC 的责任会落到应用提供方身上可能与环境中其他应用的 RBAC 功能不一致。因此从数据保护角度必须为开发者和运维团队提供一致的体验来保护和管理应用与数据。Kubernetes 环境中的所有解决方案都应遵循这一原则与基础设施需求绑定更紧密的数据保护方案也没有理由特立独行。三、数据保护用例与用户角色3.1 Kubernetes 数据保护中的用户角色应用所有者Application Owners专注在集群上创建、更新、运行应用。希望在修改应用前触发备份出问题时对应用全部或部分进行自助恢复且只有自己才能访问应用的备份。Kubernetes 集群管理员Cluster Administrators专注于让集群本身对应用管理员保持可用关心集群灾难恢复和跨集群应用迁移通常是集群上备份 operator 的守门人。集中运维/备份团队Central Operations / Backup Teams按照企业最佳实践与合规要求保护应用包括 RPO恢复点目标、RTO恢复时间目标、保留期retention period以及备份的异地副本维护通常管理中央备份仓库central backup repository。3.2 应用保护Application Protection应用是 Kubernetes 最主要的保护对象因为应用驱动业务和保护需求。应用保护覆盖以下场景应用定义Application DefinitionKubernetes 没有原生应用对象客户与厂商正创建自定义机制来定义应用。挑战在于应用所有者知道应用由什么组成而中央备份管理员负责设置策略并监督保护流程。自定义应用定义让双方对保护什么达成共识。应用组件包括Kubernetes 资源如 pods、secrets、configmaps 等持久卷非 Kubernetes 卷的外部数据存储——例如 Amazon RDS、集群外的 NAS 共享并非所有应用都包含全部组件也并非所有客户都会把全部资源纳入应用定义例如显式排除某些资源。应用备份定义Application Backup DefinitionKubernetes 没有原生备份对象同样需要自定义机制。备份定义的第一部分是如何执行备份的配方recipe常见关注点包括数据库从简单 quiesce 到日志截断再到副本管理数据库保护必然涉及定制客户可能为一天中不同时段使用不同配方如每天一次应用一致性备份 vs 每天四次崩溃一致性备份一致性组Consistency groups常与数据库相关应用的某些组件在崩溃一致性备份时可能有 I/O 一致性要求快照 vs 备份有时客户想用本地快照有时想把数据复制到备用位置——用标准 CLI 工具如 MySQL 的 mysqldump或备份厂商 agent如定制 tar 拷贝文件系统全部文件如何连接外部数据存储进行保护备份资源的顺序如需要。应用所有者还可以定义备份服务需求如 RPO、RTO、保留期、异地保护厂商可让用户逐项指定或打包成等价于备份类backup class的集合。厂商与用户需要机制来定义、发布、执行这些备份配方含等价于 pre/post 脚本、agent 配置、环境变量的内容也需要机制让应用所有者指定其备份需求。应用灾难恢复Application Disaster Recovery灾难性应用故障时用户期望恢复应用资源与数据但不恢复底层集群或其配置。可恢复到同一集群的同一 namespace同一集群的备用 namespace同一区域的备用集群备用区域/地理位置厂商可假设原应用已不再运行。客户对不同恢复选项会有不同的 RPO/RTO 期望开销与性能也会随 RPO、RTO 与位置而变化。应用回滚Application Rollback应用发生非预期变更配置和/或数据时用户期望回滚到备份创建的时间点。回滚不仅要重建/修改应用资源还要清除备份时点不存在、现在却多出来的资源。客户还期望有不覆盖现有资源的选项并接受回滚期间的应用停机。回滚目标通常是同一集群的同一 namespace。应用迁移Application Migration迁移原因包括成本优化、负载均衡、集群升级。虽然迁移严格说不是保护用例但许多客户借助保护工具完成迁移。与灾难恢复类似可迁移到备用 namespace / 备用集群 / 备用区域。由于迁移可能跨版本或跨厂商客户还需在恢复时修改资源定义的选项存储类、名称、容器定义等。根据迁移流程管理方式源应用可能与迁移后的应用并行运行直到切换cutover发生以最小化风险与停机。应用克隆Application Cloning克隆用于培训、开发、升级测试等场景同样常借用保护工具。克隆目标与迁移类似由于克隆与生产实例并行运行必须确保资源不冲突如资源重命名且数据被复制。客户可能希望保留克隆的来源信息provenance用于跟踪克隆副本或推送新的黄金副本golden copy。应用检索Application Retrieval出于法律案件、项目检索或合规需求客户需要检索旧版本应用。应用检索越来越重要其一允许组织在上下文中查看数据其二随着 AI/ML 可复现性需求的兴起重建完整应用流日益关键。恢复多年前的备份带来额外要求版本向后兼容多年前的资源需要映射到现代集群Kubernetes 集群版本备份与恢复时的集群版本可能不同容器保护与恢复备份团队不完全信任容器仓库会长期保留旧版本镜像因此需要保护容器本身备份容器镜像。资源恢复Resource Recovery出于法律案件、测试子集、只回滚应用的一部分等原因客户需要恢复应用的子集。可恢复到四个目标位置同集群同 namespace / 同集群备 namespace / 同区域备集群 / 备区域。客户需要指定要恢复的资源厂商只实现这些资源的恢复某些情况下厂商必须校验依赖资源已就位以确保恢复成功。3.3 Namespace 保护Namespace Protection由于没有良定义的应用对象许多客户选择保护 namespace有的只保护 namespace有的在应用之外额外保护 namespace还有的排除与应用绑定资源来保护 namespace。需要注意namespace 保护不是保护 namespace 中所有应用的机制——虽然厂商可选择把 namespace 当作选择 namespace 中所有应用来提供 UI/API但白皮书把 namespace 当作实际对象。好处应用所有者无需参与保护策略定义挑战只能使用简单的崩溃一致性保护机制应用所有者难以指定恢复备份团队与应用团队之间缺乏清晰连接。恢复流程与应用恢复流程一致但更强调资源恢复。3.4 集群保护Cluster Protection大部分集群保护超出备份倡议的范围。在备份语境下集群保护不包括重建 Kubernetes 集群单独备份和恢复 etcd 存储。完整集群灾难恢复、etcd DR 与 etcd 回滚虽有价值但不在工作组范围内。集群保护同样不是保护集群中所有 namespace/应用的机制。不过部分客户对集群级对象感兴趣包括 CRD 和未绑定的 PersistentVolume——集群保护会备份这些资源恢复通常在资源级别进行。四、Kubernetes 当前已具备的能力数据保护工作组在不同层级解决数据保护问题持久卷层定义 API使用户能为持久卷创建快照或备份并从卷快照/备份恢复持久卷应用层定义 API用于对组成应用的 Kubernetes 资源分组并对应用 Pod/Container 触发 Quiesce/Unquiesce 操作以获得应用一致性快照/备份。应用层数据保护很可能复用持久卷层的构造。截至白皮书撰写时Kubernetes 已有如下构建块VolumeSnapshot APIGA API允许用户为持久卷创建快照后续可用 VolumeSnapshot 资源重新水合rehydrate一个卷各种工作负载 APIStatefulSet、Deployment、DaemonSet 等Application CRD。五、Kubernetes 缺失的构建块工作组识别出以下缺失的构建块Volume backups卷备份Backup repositories备份仓库Volume populator卷填充器Quiesce and unquiesce hooks暂停/恢复钩子Change Block Tracking / CBT变更块跟踪Volume group and group consistent snapshot卷组与组一致性快照Application snapshots and backups应用快照与备份下图展示了结合现有与缺失构建块的备份工作流图 1备份工作流含缺失构建块。图中以不同颜色区分 Process流程、Existing K8s Component现有组件绿色、WIP K8s Component开发中组件黄色如 ContainerNotifier、COS与 Missing K8s Component缺失组件橙色如 Application Backup、Backup Repository、VolumeBackup。备份流程从 Application Backup 出发分为 K8s Resource Backup资源备份由 Workload APIs / Sig-Apps 支撑与 Data Backup数据备份两条分支数据备份经决策节点分流为 Native Data Dump原生数据导出与 Controller Coordinated控制器协调含 Quiesce → Volume Snapshot or Backup → UnQuiesce 序列最终统一 Export Backup 到 Backup Repository。图 2恢复工作流含缺失构建块。从 Application Restore 出发K8s Resource Restore 分支处理资源恢复其中 PVC/PV Restore 需要特殊处理PVC/PV Restore needs special handling数据恢复分支从 Backup Repository依赖 COSImport Backup经决策分流为 Restore from native data dump 或 Rehydrate PVC from VolumeSnapshot/VolumeBackup。5.1 Volume Backups卷备份动机现有卷快照能力无法让用户把备份存储到不同位置、设备或存储介质对应标准3-2-1 备份规则。白皮书明确区分两个术语snapshot快照数据的时间点记录backup备份可存储在与来源集群不同位置、生命周期独立于来源集群的快照。部分快照实现尤其是第一代云厂商实现可能本身就是备份或可通过 VolumeSnapshotClass 中的魔法参数变成备份但没有可移植的方式来显式执行备份这使得在 Kubernetes 中制定可移植的数据保护策略成为不可能。本项工作的目标是产出 Kubernetes 卷备份设计它与卷快照不同但应具备类似的用户 API例如对卷执行备份、预置卷并从备份填充。卷备份的理想特征为简洁下文 snapshot 指卷快照backup 指卷备份。时间点捕获与快照一样备份应代表卷数据的时间点捕获至少应能从一个卷创建备份并能从备份恢复卷预置新卷、用先前备份填充。独立生命周期与快照不同备份的生命周期应完全独立于尽管可控于其来源卷和集群——尤其是备份应能在集群、存储池甚至数据中心整体毁灭后存活且能将备份恢复到不同集群。这不意味着对恢复目标的存储池毫无约束如可能有技术约束——同类型存储但不应有身份约束如同实例。真实的数据副本 增量传输为满足生命周期特征备份必须实际存储卷数据的副本。与快照一样备份会按计划定期执行以最小化故障时的 RPO由于卷与备份间的地理距离是理想属性主卷与备份站点间的数据传输速率应主要随数据变化率而非卷大小伸缩。首次备份通常是全量拷贝但大多数后续备份应当是增量的。透明共享同一卷存储在同一位置的备份很可能共享数据这是预期的但共享对用户透明删除一个备份不应使其他备份失效。支持 3-2-1 规则应能使用备份实现 3-2-1 数据保护规则的全部组成部分——备份通常应存储在不同物理设备设备损坏不影响备份、不同设备类型主存储的 bug 或可利用安全漏洞不危及备份且实现应支持异地存储异地应视为典型场景。可信赖的完整性作为数据保护策略的关键支点用户必须信任备份完整性这意味着极高持久性存储可能依赖复制、防故意篡改如禁止对既有备份的写访问、严格控制删除访问、一定程度的签名和/或加密。部分方面适合在 Kubernetes 内暴露如加密用安全密钥等。职责分离备份架构应允许主存储与备份职责分离支持以下模式备份模式① 由主存储系统执行② 由第三方组件执行——依赖获取卷的静止副本通常通过快照或卷克隆并提供带外out-of-band计算最新卷与上次备份差异的方法③ 由第三方组件执行——依赖主存储实现的尚未完全定义的自上次快照/备份以来变更的块特性。恢复模式① 主存储从用户视角在一个逻辑操作中完成卷预置与从备份填充类似现有快照模型② 用户体验同上但主存储只负责卷预置第三方组件提供卷填充。适度标准化可尝试标准化备份的通用属性如对象存储桶、备份存储区域、每个备份的副本数等但对深度标准化的热情应有所克制——要为竞争性产品留出创新与差异化空间。5.2 Change Block Tracking变更块跟踪 / CBT动机高效备份卷数据是备份系统的重要特性。两次备份之间并非卷内所有数据都会变化因此只备份已变更的数据是理想选择。许多存储系统会跟踪自上次时间点快照以来的变更并暴露给备份应用Kubernetes Snapshot 特性提供了快照持久卷的标准 API但没有标准方式获知自某个快照以来哪些数据发生了变化。Differential Snapshots差分快照描述特定卷上任意两个快照之间的变更。理想的Differential Snapshots Service差分快照服务应提供快速、轻松识别变更数据以用于备份的信息同时处理块卷与文件系统卷的变更提供任意两个卷快照之间变更的信息当请求针对已删除快照的变更时服务应返回特定值由调用方采取相应行动对块卷支持不同块大小变更的最小粒度为单个设备块对文件系统卷处理共享卷并在多个层级文件系统卷、目录、文件、文件内块提供差异。Incremental snapshots增量快照描述自上次快照以来的变更因此是差分快照的特例。注意描述这些术语时实现与计费之间可能存在区别。使用差分快照服务的示例备份工作流图 3使用差分快照服务的备份工作流。应用 Pod 通过 PVC/PV 挂载块磁盘Backend Storage 先后生成 Snapshot 1基础快照与 Snapshot 2后续快照DifferentialSnapshot Service 计算两者差异Data Mover Pod 借助临时 PVC2 仅把变化数据迁移到 Backup Storage图中右侧标注 Only backup changes。示例工作流一利用差分快照服务提升备份效率为待备份的 PVC 创建 VolumeSnapshot以该 VolumeSnapshot 为数据源创建新 PVCPVC2查询差分快照服务获取两个快照之间的变更列表——对块设备是两快照间的变更块列表Changed Blocks, CBT对文件系统卷是两快照间的变更文件列表Changed Files List基于该列表只从 PVC2 备份变更数据若无法获得变更列表则备份整个卷同时可保存额外元数据用于从备份数据合成完整 PV。示例工作流二备份方案可直接访问存储设备时无需从快照创建 PVC为待备份的 PVC 创建 VolumeSnapshot查询差分快照服务获取变更列表格式同上基于该列表与后端存储通信只获取并备份列表中的变更数据无法获取变更列表时备份整个卷。后续进展佐证根据 wg-data-protection/annual-report-2025.md 与 wg-data-protection/annual-report-2024.mdCSI Changed Block Tracking 的 KEPkubernetes/enhancements 3314已合并并持续推进实现配套有 kubernetes-csi/external-snapshot-metadata 项目与 CSI 规范 PRcontainer-storage-interface/spec#551可见白皮书中的设想正在社区落地。5.3 Volume Populator卷填充器动机卷填充器的目的是创建一种机制让用户能创建由任意 CR拥有对应 populator定义数据内容的 PVC。该机制是从备份恢复卷工作流的关键部分从 API 视角看恢复只是创建一个 PVC其 datasource 指向一个备份 CR而备份 CR 的populator负责执行恢复。状态卷填充器是 Kubernetes v1.23 起的alpha 特性相对更早的 alpha 版本重新设计。新 API 设计KEP 1495依赖 PVC spec 中的dataSourceRef字段。一个集群中可以共存无限数量的卷填充器既服务于备份/恢复之外的用例也支持多种备份/恢复实现。由于 Kubernetes 尚无统一的备份 API不同实现很可能用实现特定的 CRD 表示备份对象卷填充器设计正好为此提供便利。长期来看可能出现共享实现的通用格式甚至 SIG Storage 支持的官方备份 API。无论哪种方式在恢复工作流中使用 populator API 都将带来无缝的用户体验。后续进展佐证据 wg-data-protection/annual-report-2025.mdVolume PopulatorsKEP 1495已于 v1.33 转为 GAsig-storage/annual-report-2025.md 也确认该特性允许从任意数据源填充卷数据。5.4 Quiesce and Unquiesce Hooks暂停/恢复钩子动机如前所述客户希望保护并恢复应用。许多有状态应用使用数据库与高级数据服务这些服务建议或要求在拍摄快照前使用其自身机制将服务带入一致状态。因此需要一种机制让厂商和客户能为数据库及高级数据服务创建应用一致性数据副本。背景高级数据服务如数据库的一致性备份通常采用以下一种或多种方式应用一致性逻辑备份备份流由数据服务自身生成是数据流而非快照因此需要触发、传输并存储数据副本崩溃一致性快照备份服务不连接数据库直接拍摄快照依赖数据服务能从任意时间点快照恢复——数据库厂商通常不推荐这种方式应用一致性快照备份服务连接数据库触发其 quiesce 功能如热备模式让数据库进入一致状态拍摄快照再让数据库回到标准模式——这是数据库厂商偏爱的方式。客户期望三种方法都被支持。崩溃一致性快照由标准 CSI 快照解决无需数据库特定命令而要在 Kubernetes 环境中交付应用一致性快照备份服务必须能执行数据库特定命令通常是数据库的 quiesce/unquiesce 功能。要访问 quiesce 功能就需要 quiesce/unquiesce 钩子。数据库 quiesce 命令通常通过客户端二进制或 SDK 提供因此可打包进容器镜像很多情况下客户端二进制就在服务镜像内。在 Kubernetes 中可通过 pod/exec 子资源直接在服务的 pod 中执行命令因此我们需要标准钩子来访问这些命令。Container Notifier容器通知器一个名为Container Notifier的 Kubernetes Enhancement Proposal 正在评审中kubernetes/enhancements PR 1995。该提案引入一种机制通知选定的 Pod 集合执行预置在 Pod spec 中的命令允许 Pod 作者定义可在容器内执行的命令集。该机制可用于实现数据库特定的 quiesce/unquiesce 钩子。例如数据库 Pod spec 的作者可在ContainerNotifierHandler字段中定义刷新数据库表到磁盘的命令数据库用户可通过提议的核心 APIPodNotification触发该命令。5.5 Volume Group and Group Snapshot卷组与组快照动机尽管已有 KEPkubernetes/enhancements PR 1051尝试引入应用快照、备份、恢复 API仍有其他用例未被覆盖用例 1VolumeGroup 允许用户把属于同一应用的多个卷放在一起管理非常通用。例如可用于把同一 StatefulSet 中的所有卷分组用例 2某些存储系统总是按组管理卷。对这些系统若要在 Kubernetes 中实现创建卷功能就不得不为单个卷创建组。提供 VolumeGroup API 将非常方便用例 3与其逐个拍摄快照不如用 VolumeGroup 作为数据源对组内所有卷一次性拍摄快照。若存储系统支持这可能是存储级别的组一致性快照无论如何与 quiesce 钩子结合时组快照可以是应用一致性的。为此引入另一个 CRDVolumeGroupSnapshot用例 4若存储系统支持VolumeGroup 可用于管理组复制或一致性组复制。注意复制超出本提案范围仅作为潜在未来用例提及用例 5VolumeGroup 可用于管理卷放置——跨存储池分散卷或在同一存储池堆叠卷。相关 KEPstorage pool 概念PR 1353、PR 1347。此用例可能未必需要 VolumeGroupStoragePool 可能就足够——待定用例 6VolumeGroup 可与应用快照一起使用作为 ApplicationSnapshot CRD 管理的资源用例 7部分应用不使用 Kubernetes 工作负载 APIStatefulSet、Deployment 等而是自研 operator此时用 VolumeGroup 管理这些应用使用的持久卷更便捷。目标为支持卷组与组快照需要新增以下 API一个把多个卷作为组管理的 API一个支持快照一致性组、确保组内所有卷跨卷崩溃一致性的 API一个对一组卷拍摄快照、但不保证崩溃一致性的 API。组 API 应通用且可扩展以便未来支持其他特性。状态存在正在评审的增强提案kubernetes/enhancements PR 1551。后续进展佐证据 wg-data-protection/annual-report-2025.mdVolume Group SnapshotKEP 3476已演进至 v1.34 的 v1beta2sig-storage/annual-report-2025.md 亦确认其引入 VolumeGroupSnapshot API 以一次拍摄多个卷的快照。5.6 Backup Repositories备份仓库为什么需要备份仓库备份仓库Backup Repository是应用备份的目标存储位置。当站点计算、网络、存储完全宕机时备份仓库用于集中保存数据。快照之所以不是真正的备份正因快照通常与主存储存放在同一系统上形成单点故障。如今数据以指数级速度产生存储空间、备份频率与备份总数持续增长因此备份仓库必须在空间处理、扩展性与读写性能效率方面足够智能高效。动机/目标本节旨在为数据保护厂商提供目标仓库target repository的高层指引为目标仓库提供需求这些需求应被 Kubernetes 支持的 API 所利用提供目标类型选择的高层指引。预期大多数客户会把备份仓库托管在公有云也有部分客户因已有设备而继续托管在本地。下表总结了备份仓库的关键特征、原因、对现有 API 的建议改进与注意事项特征为什么需要对现有 API 的建议改进/变化备注多协议① 对象存储Object Storage用于可扩展性——对象命名简洁② 文件存储File Storage用于迁移lift and shift视角/性能不引入环境中的新存储类型③ Data Domain 类设备④ EBS作为目标而非源也许用于迁移COSI/CSI 改进不同对象存储有不同大小限制需处理变更目标时需考虑迁移用例或许中间翻译层会有帮助多位置/多类型本地与云端Azure Blob、AWS S3、Google Cloud Storage由 COSI API 支持开始使用 API 以了解差距与投资领域冗余地理可用性——基于区域云设置 HA 的能力与云 API 服务集成同上长期归档把数据迁移到低成本存储的能力例如 S3 → Glacier与存储 API 服务集成今天由 BU 厂商处理明天应通过 API 在目标层处理权限通过单一接口处理目标权限的能力COSI 有一套用于 bucket 访问的 API—加密设置加密并选择加密算法的能力静态加密源、静态加密目标、传输中加密备份技术/网络存储加密备份/用户数据的密钥管理挑战与用户密钥管理系统集成备份速度可能受加密影响*BU 访问被加密的明文用户数据去重/压缩启用/禁用去重/压缩的能力今天由 BU 厂商处理明天应通过 API 在目标层处理智能去重可加快备份传输速度今天由 BU 厂商处理明天应通过 API 在目标层处理多集群目标管理多集群访问同一目标时需要所有权与委托控制的机制未来需要更长讨论与实现—5.7 Application Snapshots and Backups应用快照与备份动机VolumeSnapshot API 的加入使持久卷具备快照与恢复能力但应用快照与恢复语义需要考虑的远不止卷快照应用快照同时捕获应用的配置与持久数据。关键在于应用快照必须包含足够信息能从零完整创建一个特定时间点捕获的有状态应用实例。具体来说应用快照包含两部分应用组成资源的定义副本 应用所用持久卷的快照。特别是卷快照必须以应用一致性方式在同一时刻拍摄。为保证应用一致性可能需要在卷快照前 quiesce 应用、成功后 unquiesce 应用。ContainerNotifier 提案正是让用户在应用容器中请求执行任意钩子命令的通用机制适用于应用暂停/恢复等用例。有了 VolumeSnapshot API 与 ContainerNotifier API我们便具备了执行应用级快照与恢复的部分必要构建块。但应用级数据管理操作需要更高级的工作流与自动化——例如拍摄应用快照是多步骤工作流不只是编排卷快照和请求 ContainerNotifier 执行。因此需要一个新的 Kubernetes API以应用一致性方式支持应用级的快照、备份、恢复与克隆语义。目标提出一个用于有状态应用数据管理的 Kubernetes API支持应用级快照、备份、恢复与克隆语义。状态该 KEPkubernetes/enhancements PR 1051提出 Kubernetes Stateful Application Data Management API由一组 CustomResourceDefinitionsCRD组成共同定义有状态应用即维护持久状态的应用的概念以及快照、备份、恢复、克隆等数据管理语义。有状态应用快照被定义为以应用一致性方式拍摄的应用状态时间点捕获同时捕获应用配置组成应用的 Kubernetes 资源定义如 StatefulSets、Services、ConfigMaps、Secrets 等与应用包含的持久数据通过持久卷。六、应用备份与恢复工作流由于应用备份/恢复有两种通用方法——逻辑导出logical-dump与PVC 快照PVC-snapshot——工作流也分为两种类型。6.1 应用备份工作流应用备份工作流由Data Protection Controller数据保护控制器推动控制器监听 Kubernetes API Server 上的 Backup 对象创建事件执行备份工作流来备份应用。工作流可能涉及一个名为data-mover pod的组件它能连接备份设备备份仓库备份应用的持久卷数据。应用备份工作流可能包含以下步骤备份组成应用的 Kubernetes 资源StatefulSet、Secrets 等应用级动作例如在备份数据前执行禁用负载均衡器命令。ContainerNotifier 可用于选择执行该命令的 pod。并非所有应用都需要此步骤备份应用数据根据应用类型执行以下动作组之一逻辑导出如 mysqldump客户端命令连接应用服务器 pod/service把整个应用数据导出到本地备份文件或作为文件流导出到远程备份仓库。若生成了本地备份文件还需额外步骤把备份文件移动到备份仓库快照动作对每个应用 pod 按以下顺序执行部分应用要求特定执行顺序如 secondary pod 需先于 primary pod执行pre-hook 命令通常把应用数据刷盘flush并 quiesce 应用使其暂时冻结快照该 pod 使用的全部/选定 PVC执行post-hook 命令如 unquiesce把 PVC 快照备份到备份仓库。此步骤通常在全部卷快照创建完成后进行以缩短应用冻结时间。一种潜在的快照备份方式Controller 以快照为数据源创建新 PVCController 创建新的 contenteditable="false">【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考