应用通过容器部署由K8S调度，对于此类应用的业务连续性要求实现同城双活，异地容灾，需要考虑哪些方面？

容灾恢复是绝大多数企业级应用的基本要求
在没有Kubernetes也没有容器的时候，备份和恢复解决方案通常在虚拟机（VM）级别上实现。当应用程序在单个VM上运行时，容灾系统适用于这样的传统应用程序。但是，当使用Kubernetes对应用程序进行容器化管理时，这样的容灾系统就无法使用了。**有效的Kubernetes容灾恢复方案必须针对容器化架构进行重新设计，并按Kubernetes的原生方式来运行。
传统的基于VM的备份和恢复解决方案，使用快照来收集数据，但这些数据对于某个具体容器化应用并不足够。因为任何一个特定的VM都将包含来自多个应用的数据。如果您尝试通过VM快照来备份APP 1，将会同时获取其他应用的多余数据。但这些数据从容器角度来看又不够：APP 1可能还会将数据存储在其他VM上。**因此通过对某个单独VM的快照无法捕获所有APP1的数据。
基于分布式体系结构的现代应用需要的容灾方案，需要能够找到特定应用的所有相关数据和配置信息，并能够以零RPO（Recovery Point Objective，复原点目标）和接近零RTO（Recovery Time Object，复原时间目标）的方式进行恢复。
一个有效的Kubernetes容灾解决方案需要具备：

• 容器粒度的控制
• 能够备份数据和配置
• Kubernetes命名空间感知
• 针对多云和混合云架构的优化
• 保持应用的一致性
  容灾解决方案必须满足以上五个标准，才能确保Kubernetes上运行的含大量数据的应用程序在容灾恢复的时候，满足服务水平协议（SLA）或相关法律要求。
  当主站点和备份站点之间的往返延迟通常在10毫秒以下时，可以实现允许RTO和RPO为零的同步复制。这种情况通常是当主集群和备份群集所在数据中心地理相距较近。
  在某些情况下，企业希望主站点和备份站点之间的地理距离远一些。在这种情况下，RTO仍可以为零或接近零。但是延迟的增加，同步复制数据会产生比较大的性能问题。如果应用能够接受15分钟或1小时的RPO，则也是可接受的容灾方案。
  Kubernetes的企业级容灾恢复方案，应为用户提供适用于多云或混合云架构的，同步复制或异步复制的选择。 这样可以使用户能够基于自己的数据中心架构和业务需求情况，来选择不同的容灾恢复方案。
  当企业将关键业务应用迁移至Kubernetes时，重新思考和设计容灾恢复的方案非常重要。实际上可以做到在满足与容灾相关的SLA的同时，在Kubernetes上运行应用。
  但它需要采用专为Kubernetes设计的容灾方法，与Kubernetes的工作方式深入结合。传统的基于VM的容灾解决方案无法做到这一点。