简  介

在前Kubernetes和前容器时代，备份和恢复的解决方案往往在虚拟机层级实现。这种方法适用于传统应用程序，特别是当一个应用程序运行在单一虚拟机上时。但是当应用程序已经容器化并且由诸如Kubernetes等容器编排系统来管理，那么这个备份恢复系统就会崩塌。这意味着Kubernetes的有效灾难恢复(DR)计划必须为容器化架构设计，并可以理解Kubernetes的功能。

Rancher提供了一个自动化配置etcd数据库的循环备份机制，无论是对于Rancher管理的集群(RMC)还是下游Kubernetes集群该机制均生效。万一出现灾难，你可以使用这些备份(或称之为snapshots)来恢复Kubernetes备份和Rancher数据库以及状态。以这种方法，Rancher可以帮助你确保你的集群得到保护并且在灾难情况下有可能恢复。

正如你可以想象的那样，在DR场景中完全恢复用户工作负载还需要许多其他步骤。在这篇文章中，我们将指出DR场景的主要组件，以及如何在Kubernetes环境中安全地实现它们。

根据各种不同因素，DR准备有不同的级别。这些因素包括基础设施的自动化程度、应用程序结构和部署流程、存储、网络、云原生应用和微服务的专业知识以及Kubernetes管理经验。然而，一个成功的DR策略中最关键的组成部分是尽可能频繁地测试和记录你的操作流程。就像没有测试恢复程序的备份是没有用的一样，没有扎实的记录文档和反复验证的DR计划也是没有用的。

一个成功的灾难恢复场景所需组件

在一个DR场景中，需要考虑以下组件列表。在DR情况下如何处理这些组件决定了企业应对快速危机恢复的准备程度。我们的目标是尽可能地使更多组件拥有自动化流程。

1、 备份

• etcd(集群数据库)

• statefile(集群配置)

• 集群配置文件(集群配置)

• 证书(集群配置)

• 持久化存储(有状态应用程序)

• 容器(由应用程序使用的镜像)

2、 基础设施

• 集群节点

• 负载均衡器

• 备份

  - etcd

  - statefile

  - 集群配置

3、 应用程序

• 容器镜像(镜像仓库)

• manifest(Helm或Kubernetes)

4、 DNS

• 需要对你的域进行控制

这不是一个全面的清单。针对你的特定环境，你可能有更多(或更少)的组件类型需要考虑。企业IT团队已经管理了其中的一些组件，这进一步推动了DevOps概念和方法所倡导的协作工作环境的理念。

灾难恢复准备级别

许多公司正处于数字化转型时期，而Kubernetes是这一历程中不可或缺的一部分。每个企业都有一个独特的环境，具有特定的能力和专业知识，这意味着他们有不同的DR准备水平。这些技能和能力的范围包括从基础设施自动化状态到CI/CD流程，从源控制管理到备份策略等。好消息是，你的企业开发的这些能力越多，你的准备级别就越高。这样一来，DR就变成了一个几乎平淡无奇的事情，你的企业可以在最小的人为干预下进行快速处理。

Level 1：手动重新部署

• 备份：自动循环

• 程序：经过测试和记录的流程

• 基础设施：备用基础设施

• DNS：手动故障切换

• Apps：手动恢复应用程序

这是最常见的情况之一。自动循环备份用于将集群状态恢复到灾难恢复(DR)站点的备用基础设施。这些过程都有很好的记录并定期测试。一个好的恢复测试是可以让你的团队最新成员能够直接按照记录文档来实现一个功能齐全的DR环境。

这种级别的灾难恢复准备对大多数企业来说是足够的，因为它创造了一个可重复的、有据可查的过程。它可能会被认为比其他流程慢，因为大多数活动都是手动的，并且必须遵循一个非常严格的时间表。在这个层面上，你还需要考虑人的因素。我们都知道，由于不可预测的实施错误，手动操作会在一些流程中引入风险。这就是为什么需要通过使用脚本和自动化来进行优化。

Level 2：脚本重新部署

• 备份：自动循环

• 程序：测试和记录步骤

• 基础设施：脚本部署

• DNS：使用脚本进行故障切换

• Apps：使用脚本恢复应用程序

这是一种更高级的方案，在这种方案中，你的集群的还原是在按需部署的基础设施上完成的。 仍然需要备份来提供还原源。 这些步骤都有完善的记录文档并定期测试。灾难恢复站点的基础设施使用脚本方法部署，每次测试或执行灾难恢复计划时，都会提供一个相同的环境。 脚本方法也可以应用于DNS更改和应用程序部署的实施。

这种级别的DR准备非常有效，因为它消除了DR过程结果的随机性。虽然它需要更多的配置工作和内部专业知识来维护，但其结果是更好地保护你的企业免受任何灾难情况的影响。此外，这种方案还能大幅缩短恢复时间，这对于在这方面有强制要求的企业来说是一个很大的优势。

Level 3：全自动重新部署

• 备份：自动循环。持久化数据由企业管理，自动复制到DR站点。

• 程序：DR程序的自动化定期测试

• 基础设施：基础设施的全自动化重新部署

• Apps：全自动化重新部署Apps

• DNS：自动化故障切换

这是最高级的级别，在这个级别中，所有的事情都是自动化的，可以 "一触即发 "地重新部署。在这种情况下，不会执行还原(restore)。

你会在某个集群的同一站点恢复的情况下使用循环备份。基础设施、Rancher管理集群和下游集群都是按需部署的。DNS变化也是使用全局流量管理(GTM)工具自动进行故障转移。应用程序的部署是完全自动化的。

如果这个级别听起来有些梦幻和理想，那是因为它很难实现。它需要围绕执行DR计划所涉及的所有组件有深入的专业知识。当然，它也需要更长的时间来配置，但结果是值得的。在某种程度上，这是微服务架构的最终目标：能够在几分钟内重新部署整个环境，从基础设施到应用程序，而无需任何人工干预。

自动化Rancher管理集群的灾难恢复

• 备份：自动循环

• 程序：DR步骤的定期测试

• 基础设施：备用Rancher管理集群

• DNS：手动/使用脚本进行故障切换

这个方案只适用于Rancher管理集群，你会发现在企业中，需要一个覆盖每个应用的DR计划。DR站点的基础设施已经被构建为恢复操作的备用目标。对主站点(Rancher)进行监控，如果满足DR条件，则宣布故障转移，并使用脚本方式将Rancher管理集群恢复到备用集群。DNS被手动或通过企业解决方案(如BIG-IP的全球流量管理(GTM))重定向。一旦Rancher集群恢复，下游Kubernetes集群会在几分钟内自动重新连接到新的Rancher server。请注意，这个场景假设下游集群没有受到灾难的影响(即在云端运行)。

总  结

我们不能低估灾难恢复计划的重要性。只有通过强大的规划、测试和文档记录，企业才能确保快速恢复，且不会造成重大数据损失。你应该定期(比如，每季度一次)测试你的DR计划和程序。

Rancher管理着Kubernetes集群，Kubernetes集群首先是一个高可用的分布式系统。这些系统由于其预期高可用性和零停机时间的本质，对企业来说极为重要。在Kubernetes的世界里，将恢复时间减少到最低限度，并在几分钟内恢复应用功能是非常重要的。你可以通过自动化、脚本和定期测试你的DR计划和程序来实现这一点。

推荐阅读

减少80%的集群部署时间，育碧携手Rancher推动游戏创新

误删节点或集群怎么办？这里有一颗后悔药

如何简洁优雅地部署PostgreSQL和Pgweb？

About Rancher Labs

Rancher Labs由CloudStack之父梁胜创建。旗舰产品Rancher是一个开源的企业级Kubernetes管理平台，实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理。Rancher一向因操作体验的直观、极简备受用户青睐，被Forrester评为2018年全球容器管理平台领导厂商，被Gartner评为2017年全球最酷的云基础设施供应商。

目前Rancher在全球拥有超过三亿的核心镜像下载量，并拥有包括中国联通、中国平安、中国人寿、上汽集团、三星、西门子、WWK保险集团、澳电讯公司、德国铁路、厦门航空、新东方等全球著名企业在内的共40000家企业客户。