本文整理自2024云栖大会苏雅诗演讲
K8s集群业务为什么需要灾备？
集群与业务自身的的高可用配置是集群稳定性的基石，能保证业务在基础设施突发故障的时候应用仍能稳定运行。
然而，在业务的快速迭代与集群的日常运维中，也可能出现人为误操作，比如集群资源的误删除。对于重要的业务，建议做周期性的灾备，并在业务迭代、回滚以及集群的高危操作前做单次的灾备，来降低相关故障发生时恢复的RTO和RPO。
因此，有效的灾备手段是业务稳定性的最后一道防线。
业务容器化后的灾备特性与新需求是什么？
对K8s集群中运行的业务，灾备的对象和目标都发生变化：
由于K8s已经对业务进行了编排，灾备的对象应该是以工作负载（也就是容器组）为核心的集群资源以及关联的云资源信息。对于有状态应用，还需要额外考虑存储卷内数据的灾备。
容器化后的恢复更关注业务的连贯性，目标为工作负载重新拉起，相关配置保持不变，对外服务恢复。恢复既可能是原地（备份集群与恢复集群为相同集群），也可能是跨集群的（不为相同集群）。
备份中心：
Container Native
的应用维度的K8s灾备方案
针对新的灾备特性与需求，ACK推出备份中心一站式灾备方案。
备份中心概述：
集群的运维人员可以在控制台一键为业务创建周期性的备份计划或单次的应用备份。与ETCD备份相比，备份中心支持命名空间、标签、资源类型等维度，选择需要备份的应用；对于有状态应用，支持同时备份业务挂载的存储卷数据。
而对于有完善gitops流程的企业，也可以通过备份中心的数据保护功能做仅针对存储卷数据的灾备。
在恢复之前，可以简单通过配置实现命名空间、镜像地址仓库映射等资源调整。
对于更复杂、高级的调整需求，也可以通过ConfigMap配置调整策略，实现按需切流、副本数调整、配置文件修改等灵活配置。
在需要恢复时，对目标备份，支持恢复完整或部分的应用与存储卷。除了预先配置的调整策略，备份中心在恢复时也会自动调整资源的恢复顺序与部分配置（如跨云场景的存储driver切换等等），兼容ACK系统组件与阿里云生态。
备份中心控制台展示
在集群的应用备份控制台有相关的使用流程指引。
创建用于存放备份的OSS bucket与关联的备份仓库之后，就可以在控制台创建备份计划或立即备份。
备份的状态和详情展示在备份记录列表中。
需要备份时，对目标备份点击立即恢复即可。若无高级配置需求，在单个控制台即可实现应用数据的备份恢复。
接下来，以MySQL有状态应用为例，讨论为实现业务连贯恢复目标，面临了哪些挑战。
Container Native集群资源灾备
的难点与备份中心解决方案
K8s日益迭代，提供的官方资源类型越来越多，再加上资源的不同版本与用户自定义的资源类型，备份和恢复涉及的资源数也在增加。
以MySQL为例，部署时，可能需要使用Secret存储账密、使用ConfigMap存储启动配置、使用PVC, PV记录存储底层信息、使用Service, Ingress存储端口、网络资源信息等等。
如此多的资源类型，第一个挑战，就是如何保证备份的完备性，任何一个资源的缺失都可能导致恢复时应用无法正常拉起。
-备份中心根据K8s的资源定义，根据资源间的依赖关系，备份时将自动追加依赖的资源。比如，若MySQL使用某个自定义资源，在备份时将自动追加相关的CRD，保证在新的集群中也能成功部署相关自定义资源。
完备的备份是否就能保证完备的恢复呢？实际上，恢复顺序不当也可能会导致业务运行状态的丢失。比如恢复时，若先恢复了MySQL的StatefulSet (STS)，K8s的STS Controller将根据STS的副本数及template自动创建副本（即Pod）。此前备份的Pod资源上，运行期间Patch的配置信息相当于被复写导致丢失。
-备份中心默认维护了K8s官方资源的恢复顺序，优先部署控制器动态创建的资源。
最后，如果尝试使用kubectl get -oyaml获取过运行期间的资源配置，会发现使用这个配置文件apply之前，还需要手动清理或调整大量的字段。比如调度完成后Controller追加的nodeName字段，在恢复时若保留，则会跳过调度阶段，进而导致在新的集群中无法拉起。
-类似地，备份中心兼容K8s生态，对资源进行默认的调整。若用户有特殊调整需求，也可以通过配置调整策略定制化订正。
以上备份和恢复的自动调整都强依赖于K8s的版本，备份中心在兼容老版本K8s集群的基础上也会一直随社区迭代。
Container Natice存储卷数据灾备
的难点与备份中心解决方案
MySQL在部署时，可能需要云盘存储实际DB中的数据，以及NAS, OSS等存储日志等运行信息。
不同存储底层原生的灾备手段各异，比如云盘的快照、NAS的回收站等等。
-备份中心将各种类型的存储卷抽象为块存储与文件系统存储，对用户屏蔽底层存储备份的实现方式。用户备份存储卷数据时不需要关注底层存储类型并逐一配置。所有数据卷存储的备份策略一致。
即使实现了存储源的备份与恢复，应用也无法直接使用恢复出的云盘等存储源。这是因为应用与存储底层间还需要有PVC与PV资源作为桥梁。在K8s集群中，应用声明挂载信息时指定的是PVC，PVC与PV为一一绑定关系，并由PV记录实际的存储源信息如云盘实例ID。
-备份中心在备份存储卷数据时，备份恢复的对象都为PVC。即在备份时同时备份PVC、PV配置，恢复时调整PV的存储信息，并同时恢复PV、PVC，供应用无感复用。
对于使用过已废弃的FlexVolume存储驱动的ACK老用户，或从IDC、三方云迁移至ACK的用户，还会面临K8s集群的存储驱动不一致的挑战。
-针对ACK集群，备份中心支持备份ACK FlexVolume、NFS,Ceph等K8s树外驱动、及主流云厂商CSI等数据并恢复至ACK CSI，在恢复期间字段转译PV上的volumeSourceACK维护的CSI。
备份中心原理及组成概述
以上介绍了容器化业务灾备的特性、挑战以及备份中心是如何解决的，但我们可能还会有以下疑问：
我的备份数据实际存储在哪里？由哪个云产品保证备份数据的SLA？
如果使用定时备份，比如每天凌晨备份一次，数据量和开销岂不是很大？
等等，这些也是用户在意的问题。
实际上，每次的备份（恢复同理）任务，最多可能会被分解成3个子任务，分别为集群资源、块存储数据以及文件系统存储数据的备份子任务，三个子任务的备份策略，如TTL、周期、目标应用等都是一致的。
集群资源备份：基于开源Velero社区开发，并通过内源的Plugin兼容阿里云生态与ACK系统组件，用户备份时只需关注业务本身。所有的集群资源（多APIVersion版本）都将被备份并存储于备份仓库中。备份仓库实际关联的是用户自己提供的OSS Bucket中。
块存储数据保护：基于阿里云云盘快照功能，特点是备份时间快且保证单盘的数据一致性（对一致性快照组，为多盘数据一致，排期中）。对于广泛使用的ESSD云盘，默认开启极速快照功能，备份恢复秒级可用。此外，快照本身是增量的。
文件系统数据保护：基于阿里云云备份服务，对文件系统的备份提供增量、压缩、去重、加密等能力，为备份恢复流程提速。文件系统备份的数据可以通过备份中心的存储类转换功能转换成其他文件系统类型（如以ext4挂载的云盘，NAS等）。
备份中心在混合云场景的应用
原地灾备
云上的灾备能力同样能助力云下K8s集群。
将线下IDC集群或其他云厂商的K8s集群接入ACK One的注册集群，部署备份中心组件后，即可轻松实现云端灾备。与云上ACK集群一致，集群资源将备份在阿里云OSS，存储卷数据则备份在阿里云云备份服务中。
云端迁移
通过在注册集群中备份，在线上ACK集群恢复的方式，轻松实现集群上云。
对有状态应用的存储卷，也可以通过存储类转换功能实现数据上云。
ACK One注册集群概述：
https://help.aliyun.com/zh/ack/overview-9?spm=a2c4g.11186623.0.0.1c416218Ugyqe5
更多使用场景与用户关注的能力
备份中心发布后，越来越多的用户通过备份中心实现集群跨大版本无缝迁移、集群跨VPC迁移、IDC上云等复杂需求。这里也简单总结了一些用户比较关注的能力：
存储类型转换：
文件系统数据备份后可通过存储类转换变更存储介质，已经提过这里不做过多赘述。
API Version随集群版本切换：
K8s本身具有API Version的Convert功能，Velero社区基于该功能，以在1.16集群备份Deployment，在1.30集群恢复为例：
备份时备份资源的所有API Version版本，如Deployment将备份extensions v1, apps v1beta1, apps v1beta2, apps v1。
恢复时优先切换成恢复集群的推荐版本，即apps v1。
若恢复集群推荐版本在备份中不存在，则恢复备份中被恢复集群兼容的版本。
1.16版本中，大部分重要group如core, apps, network.k8s.io, storage.k8s.io中的资源都已v1，但仍有部分资源如Ingress无法在1.22+集群版本中恢复。在社区的基础上，备份中心对该类资源做了进一步的兼容，实现自动切换（也可由客户手动创建）。
对外服务切流：
不同的恢复场景可能会对Service的恢复有不同要求，如是否复用端口、是否复用负载均衡实力、是否开启强制监听等。这些要求都可以通过配置调整策略实现。对于集群业务迁移场景，该功能可以保证业务正常拉起并由业务检查后再手动切流，不影响对外服务。
恢复时资源已存在的处理策略：
默认为更安全的同名资源跳过逻辑，对于有升级变更需求的场景，也可尝试以K8s JsonMergedPatch的方式更新已有资源。
Demo：
1.16集群业务备份恢复至1.30集群
通过视频Demo展示上述提到的功能，备份与恢复集群的配置与业务需求如下同所示：
在demo中：
首先，展示1.16集群的组件安装情况，以及部署的MySQL应用，着重检查LoadBalancer类型Service的负载均衡id，以及存储卷类型及模拟的DB数据。（流程省略了通过对MySQL应用打标排除OSS存储卷数据备份的操作）
在备份中心进行备份，检查备份的存储卷及集群资源情况。
然后，展示1.30集群的组件安装情况，在备份中心确认备份已同步至当前集群并恢复（某些场景下对Service切流配置需要预先创建相关ConfigMap）。
检查存储卷的存储类转换情况，并检查恢复后的应用，着重检查LoadBalancer类型Service的负载均衡id不变，模拟的DB数据恢复。
此处为语雀视频卡片，点击链接查看：云栖demo.mov
一图总结K8s
集群业务的灾备特性与解决方案
