定义恢复点目标 (RPO) 和恢复时间目标 (RTO) 容限至关重要，但更重要的是构建一个能够支持您最严格 SLA 的环境。
译自 Defining Low Data Loss, Downtime Tolerances in Kubernetes，作者 Janet Wi。
客户比以往任何时候都更希望获得无缝的体验。他们期望应用程序高性能且始终可用，体验流畅无摩擦。这并非易事，尤其是在Kubernetes应用程序不仅成为常态，而且成为运行关键任务应用程序的首选编排器的情况下。
随着在Kubernetes上构建的应用程序类型的增长，维护业务连续性以确保用户（无论是内部开发团队还是外部客户）不会遇到中断也变得越来越重要。
灾难恢复和业务连续性策略有助于为这些关键应用程序提供可用性和恢复程序，从而防止长时间停机或数据丢失，这两者都可能对大型企业造成灾难性后果。
IT团队需要为其应用程序确定恢复点目标 (RPO) 和恢复时间目标 (RTO) 容限。RPO定义了灾难发生时可接受的数据丢失量。对于关键任务应用程序（例如视频流），零数据丢失是可以接受的。对于不太关键的应用程序，RPO可以从几分钟到几小时，甚至几天不等。RTO定义了应用程序可承受停机时间的可接受量。
RPO和RTO的确定取决于许多因素，包括应用程序的关键性、服务级别协议 (SLA) 或法规要求。随着Kubernetes应用程序规模的增长以及关键任务Kubernetes应用程序规模的增长，保持较低的RPO和RTO变得越来越重要。在Portworx的“Kubernetes专家报告2024”中，超过50%的受访者表示，他们的云原生平台将受益于增加的高可用性和灾难恢复功能。
在开发关键的Kubernetes应用程序时，务必为其提供能够满足低RPO和RTO要求的环境。丢失关键应用程序数据或经历长时间停机可能会导致收入损失、品牌声誉受损甚至受到监管处罚。组织必须能够维持业务连续性，即使在意外灾难中也能保持运营。但是，Kubernetes环境可能会带来许多复杂性。
在同一项调查中，86%的受访者表示他们正在混合和多云环境中构建应用程序，通过在公共云和私有云等各种环境中部署应用程序，利用Kubernetes的动态基础设施。这使开发人员能够灵活地在选择的环境中部署应用程序，从而优化性能和成本。
在Kubernetes之前，您只需要在两个站点之间使用相同的存储硬件即可提供同步和异步复制。但是，跨多个环境部署Kubernetes应用程序会使复制变得更加困难。您可能无法在所有环境中访问相同的硬件。
一些组织可能会转向提供Kubernetes原生备份和恢复的数据保护解决方案，但仅仅是备份操作不足以提供足够低的RPO或RTO来满足关键应用程序的需求。为了满足要求几乎没有数据丢失的严格RPO要求，您需要一个能够复制数据无论其位于何处的公共存储层。
除了复制数据之外，存储管理层还必须能够复制Kubernetes数据以维持业务连续性。容器化应用程序与虚拟机的构建方式不同。Kubernetes灾难恢复解决方案必须能够恢复应用程序数据以及底层元数据（如应用程序配置和对象），以便快速恢复。否则，工程团队会浪费宝贵的时间分别恢复应用程序组件或参考文档来引导他们完成恢复步骤。
实现Kubernetes应用程序的低RPO需要自动化。您希望能够快速有效地恢复应用程序及其所有相关组件，特别是对于那些几乎无法容忍数据丢失和停机的关键任务应用程序。
您需要寻找——或构建——一个提供灵活的灾难恢复策略的解决方案，该策略可以支持：
- 同步灾难恢复 (DR) 将主副本的精确副本复制到辅助副本，以便对主副本所做的任何更改都反映在辅助副本中。同步 DR 解决方案通常要求集群保持在同一都市区域内以限制延迟。
- 异步 DR 根据预定的时间表（通常由 RPO 要求确定）在副本之间复制数据。由于数据不是自动复制的，因此主副本和辅助副本之间将存在差异。
总之，在 Kubernetes 上构建应用程序时，不仅要定义应用程序所有层级的 RTO 和 RPO 容限，还要构建一个能够支持您最严格 SLA 的环境。Kubernetes 环境可能会带来许多复杂性，包括跨越本地和公共云环境的各种基础设施，以及应用程序结构。灾难恢复解决方案必须准备好为相关应用程序提供同步和异步恢复。
要了解有关“2024 年 Kubernetes 专家之声报告”的更多信息，请立即下载副本。要了解有关 Portworx 的更多信息以及我们如何为您的任何 Kubernetes 应用程序提供灵活的灾难恢复策略，请访问我们的网站了解更多信息 或阅读有关灾难恢复的更多信息。