在容器之前的世界里，备份和恢复解决方案通常是在虚拟机层面实施的，这适用于在传统的本地系统上运行的应用程序。但是，当应用程序被容器化并通过Kubernetes这样的编排器进行远程管理时，原有的解决方案就不适用了。这意味着有效的灾难恢复计划必须为容器化架构而设计，并且理解Kubernetes的运作方式。
根据Gartner的数据，到明年，全球将有超过75%的企业在生产中运行容器化应用——比去年6月不到30%的数据增加了不少。如果容器化应用是企业IT服务的一部分，那么现实是，它应该像其他服务一样受到有效的保护和管理。
现在正在使用容器化应用的组织中，存在着现有灾难恢复准备与容器化应用所需准备之间的差距。随着技术的不断发展，首席信息官需要更多地考虑该领域。
应对灾难恢复挑战
尽管迄今为止从Kubernetes的发展中收获了许多好处，但容器化的应用程序仍然有其局限性。具有讽刺意味的是，使应用开发、生产和部署更容易的基础设施，正给灾难恢复准备方面带来更大的挑战。
容器化架构旨在通过在每个独特的容器上托管最少数量的独立服务来最大程度地降低停机风险。这增加了企业需要的灵活性和可访问性，同时也降低了在面临动荡时失败的可能性。但是，鉴于Kubernetes工作负载可以在单个企业IT 战略中包含数百个容器，这很容易使IT团队不堪重负。这种复杂性带来的最大挑战是备份和恢复，因此Kubernetes应始终包含进灾难恢复计划的核心议题。
灾难有多种形式——从人为错误和网络攻击到自然灾害。虽然数字化有助于最大限度地减少数据丢失的风险，但每个应用程序都仍需要有一个钢铁般坚固的灾难恢复战略，以确保当受到攻击时能够有效的恢复数据。在灾难发生时，有大量的容器需要备份和工作负载需要恢复，这可能将是非常复杂的，所以，在准备灾难恢复计划时一定不能忽视这点。
缩少准备差距
容器化的应用程序不应该使用传统的一刀切的方法进行备份。一个针对容器化环境有效的灾难恢复计划还应有其他基本特征：速度、可重复性和可移植性。确保您的灾难恢复计划在灾难发生前具备这些特性，将在之后为企业节省时间和金钱，避免可用性问题。最重要的是，确保您的IT团队准备充分，以应对数据丢失的威胁。
Kubernetes和容器化应用的好处不仅仅是存储应用数据，还包括保存其他关键任务的业务数据。由于容器化环境中有如此多的组件（如node、pod、容器），想要创建无漏洞的备份几乎是不可能的。为了避免手动开发大量的灾难恢复文档和备份脚本，组织可以投资自动化解决方案，如KastenK10，帮助减轻负担。
一个灾难恢复计划的有效性取决于它的可重复性。企业应该定期进行灾难情况的模拟演习。这将使您的团队（不只是IT团队、还有其他团队）都能评估您的准备工作，学习如何整合自上一次演习以来的任何变化，并定期审查和更新计划。企业需要清楚地了解备份的存储位置和恢复位置。您的组织在容器环境中进行越多的灾难恢复测试，您的员工做的准备就越充分，在处理灾难时就越有信心。
虽然Kubernetes让使用现有服务创建应用程序变得更容易，并提供了一个更简单的迁移过程，但涉及到灾难恢复准备方面，它往往会产生更多的工作。灾难恢复计划应该让您能轻松地整合变化，这样当灾难来临时，恢复才是顺畅的。从一个简单的计划开始，当环境变得更加复杂时，再进行补充。为了最大程度地缩小准备工作的差距，您需要仔细记录对计划做的所有改变以及改变的原因，并采用灵活的自动化，使更新插件变得简单。
为成功做计划
Kubernetes灾难恢复不是一项简单的工作。备份您的容器化工作负载的唯一正确方法是采用应用程序可感知的、云原生备份，这种备份不会妨碍迁移到新的基础设施。第一步是确定您的具体要求，并制定适合容器化应用程序的灾难恢复战略。通过这样做，企业可以扩展Kubernetes最受欢迎的功能——数据移动性。
正如那句老话所说，没有计划就是失败的计划。随着IT基础设施承担着比以往任何时候都更重要的新角色，系统变得更加复杂，容器的灾难恢复计划必须关注高可用性、速度和可访问性。虽然灾难恢复准备计划不是你需要每天更新的东西，但当灾难来临时，它将发挥至关重要的作用。
