对于两地三中心的数据中心架构，k8s集群建议一套还是各区域搭建各自k8s集群？

一般来说，会有几点问题需要我们来思考
1、执行实时备份，其中将写入一个数据中心的数据异步复制到另一个数据中心。
2、 多个数据中心进行应用多活部署，就近原则，来确保更快的性能。
3、如果一个数据中心发生故障，仍然可以从另一数据中心提供业务服务
4、 如果一个数据中心中的几个节点发生故障，其他数据中心的资源任可以被调度

在架构设计过程中，你可以数据中心之间进行解耦，你也可以进行耦合，如果仅仅是备份，那就解耦，如果多活，那就需要耦合

跨AZ/DC的双活指的是应用级别的双活，一般用跨AZ/DC的 LB + VIP来实现统一的流量入口。
但是并不等于同一个集群能够跨AZ的弹性扩容。问题在于AZ之间的网络质量如何保证？一般AZ之间是专线或者裸光纤，即使这样，也避免不了网络抖动。集群内部的组件之间的API调用，MQ，时间同步，DNS解析，状态同步，集群心跳之类的都会出现致命故障。分布式系统最怕网络不稳定了，组件之间太依赖网络的延时。
所以我所见到生产系统，都是各区域搭建各自k8s集群，前端LB负载均衡， 后端存储同步。如果要实现跨集群多个k8s联动扩缩容，可以在上面封装一层集群业务管理/编排功能，可能openshift有这样的功能吧，还需要专家确认。

两地三中心的架构最开始的来源应该是银行业，银行业之所以要搞这样的架构是因为监管部门对某些业务系统是有业务连续性要求的。说白了也是为了保障某些重要交易系统的连续性。

那么K8S平台上的系统，要放什么系统？
核心交易系统？还是其他的一些什么系统？我相信就目前来看，核心交易系统思路还上不了K8S的平台。如果是其他系统，那么好办了。看看系统的业务连续性要求是什么，如果没有硬性监管要求，那么有没有一个客观实际的评估，按照这个标准去评估后续的架构就可以了。

为什么要做跨数据中心的集群？
K8S集群本身是为了提高局部区域计算能力的高可用性。如果为了实现所谓的双活，而舍弃K8S本身的最大适合条件，这个决策评估的是不是有点不太专业。

纯属个人观点，仅供参考！