应用通过容器部署由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的容灾解决方案无法做到这一点。

感谢回复，因为双活可以分几层，网络双活、应用双活、数据库双活、存储双活，我想进一步了解下，跨集群应用部署，数据库双活这块在K8S环境下【应用和数据库都容器化了】有哪些经验分享？ 因为K8S设计之初就假定容器/pod是不稳定的，应用部署在跨数据中心的K8S集群组里，怎么保障业务的连续性？

非常赞同之前郭经理的回复，其中概括了很多非常重要的最佳实践逻辑。这里再补充几点。

1、Kubernetes 应用体系的可靠性是靠可重复部署的描述文件来保障的，由于所有的部署都可以通过yaml所描述的完成整过程快速复现，因此Kubernetes体系可以实现快速、灵活的业务部署与分布。这也是为什么很长一段时间以来我们在Kuberenetes平台上都不提及数据的一个主要原因。Kubernetes 设计最初是根本不考虑数据的。而真实业务中我们又无法脱离数据。因此之前我们的可靠性保障理论中、微服务理论中，都是通过高速构建就近数据源，完成快速局部数据供应来实现微服务的数据单元化的。当然这不可能解决所有问题，因此我们后来有了 Stateful set。

2、 Stateful Set 的核心意义就在于将存储与计算容器捆绑统一调度。但Stateful Set保障的是计算与存储的同步，并不保障存储的可用，因此 OpenShift 推出了 OpenShift Container Storage （OCS产品）来协助解决这个问题。软定义存储的多副本、备份恢复等手段可以结合Kubernetes来保障业务的连续性要求。但我们仍然面临核心数据的连续性服务能力要求，因为微服务理论中，每个服务的数据都是整体数据模型的小局部供应模型。最终一致性还在核心数据模型上。

3、因此在今天分享的内容中多处提到了如何实现局部小数据模型如何与核心数据模型的同步与快速供应方案。这部分方案其实就是我们现在关注的数据中台，通过隔离局部数据逻辑与核心数据模型，我们通常要分拆成部分核心数据模型的子集，用于面向部分具有共性数据需求的业务上，这部分能力就是数据中台。数据中台相当于过去中间件的数据库连接池，而差别在于，数据中台具备缓存、同步、传递交易等能力。这部分能力需要借助一些工具来实现。Redhat AMQ Streams （Kafka 中台），Redhat Data Grid（Memcahe/分布式数据网格/NoSQL内存库 中泰），RedHat Data Virtulization（数据视图中台）都是这类工具可以有效隔离业务与数据逻辑，并可以借助一些微服务概念，通过蓝绿部署，金丝雀部署等方式，屏蔽数据底层核心逻辑，实现无感知化化面向应急数据源或灾备数据源的目的。从而强化容器化PaaS平台的必须服务能力。

4、通过Redhat Change Data Capture 这样的技术可以实现复杂/异构/异地/差异逻辑的多数据源同步，从而协助用户实现同城双活、异地双活、异地容灾等需求的实现。但这种方案并不能从逻辑上彻底解决最终数据一致性问题。最终数据一致性仍然需要人为逻辑设定来参与保障。

5、结合另一个问题的回答 “ 在大数据平台容器化基础上如何考虑数据安全？ ” 在这也抛出一个个人观点供大家参考与讨论。随着数据使用平台的容器化、分布化、敏态化，数据的安全性，唯一权威性与最终一致性的保障将变得越来越复杂。区块链的技术在性能上还不成熟，但在溯源与权威性保障上有独到的优势。因此可以考虑通过区块链技术来实现未来全局数据体系的最终一致性保障。当然实现途径仍然有待论证。