vlambda博客
学习文章列表

来自twt社区同行交流，欢迎更多同行参与交流

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

对于两地三中心的数据中心架构，k8s集群建议一套还是各区域搭建各自k8s集群，各自有什么优缺点，对于多集群方案，每个集群3master时候过于冗余。

@menglunyang 中国银行系统工程师

@顾黄亮 苏宁消费金融有限公司 技术总监：

一般来说，会有几点问题需要我们来思考：

1、执行实时备份，其中将写入一个数据中心的数据异步复制到另一个数据中心。

2、 多个数据中心进行应用多活部署，就近原则，来确保更快的性能。

3、如果一个数据中心发生故障，仍然可以从另一数据中心提供业务服务。

4、 如果一个数据中心中的几个节点发生故障，其他数据中心的资源任可以被调度。

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

@nameless 某云计算厂商 技术总监：

建议各个区域搭建各自的k8s集群。

如果搭建一套，区域与区域之间的网络抖动或者延迟有可能造成master节点和node节点失联，业务重新调度等问题。

常规方法都是在各个区域搭建各自的k8s集群，然后用统一的多集群管理或者多云管理平台统一纳管多套k8s集群，集群与集群之间的业务调度、容灾备份等都可以在这个多集群管理或者多云管理平台上实现。

@chinesezzqiang  信息技术经理：

好问题，如果是大企业环境，建议采用各区域各自搭建，统一管理的模式，有以下优点：

1.实现数据的异地灾备，两个数据中心k8s的数据进行异步复制（切记不要同步，否则增加网络带宽压力和业务的压力，甚至造成业务延迟过大）；

2.部署区域建议不要跨城；

3.实现业务层面的高可用，尤其是金融类系统；

4.双中心必须建设统一的管控中心，而不是多个孤岛；

一套的这种部署方案适合小型企业，单点故障时最大的问题。

@海燕 陆金所 系统工程师：

搭建一套的前提有如下两个：

1.master组件的可用性保障。当master任何组件有故障时候影响是全局的，如何进行快速的故障处理和恢复，甚至不影响业务。

2.大集群跨区域的网络性能保障。跨区域，存在网络延时，如何进行保障。

3.大集群的管理。集群规模的变大，相应参数和优化也要跟上。

@eximbank 某金融企业 系统架构师：

1、从数据中心统一安全、基线管理来看，首先要构建统一的docker image hub registry；

2、若分散构建registry，需要规划跨中心定期同步更新基线信息；

3、Kubernetes集群建议分散到各数据中心，用户体验、权限等管理方便些。

@mileskuo 平安科技 金融云架构师：

跨AZ/DC的双活指的是应用级别的双活，一般用跨AZ/DC的 LB + VIP来实现统一的流量入口。

所以我所见到生产系统，都是各区域搭建各自k8s集群，前端LB负载均衡， 后端存储同步。如果要实现跨集群多个k8s联动扩缩容，可以在上面封装一层集群业务管理/编排功能，可能openshift有这样的功能吧，还需要专家确认。

@mtming333 某电子支付 系统架构师：

建议各区域搭建各自k8s集群。

优点：

1、避免跨机房网络抖动造成的管理端与宿主机连接故障

2、多管理端多控制面模式，可以有效接管某套控制面不可用时的业务容器编排

3、扩充受管端宿主机规模，根据评估，一套K8S管理端可承载宿主机5000个节点

应注意：

1、应考虑受管端的宿主机规模，评估投入有效性

2、同一套应用，建议部署在同一个管理集群内，否则会造成需要发布两次，存在风险

3、人力运维投入多，需要保障两套系统的可用性

4、建议开发制作多集群的统一操作portal

5、建议开发制作跨控制面的迁移工具模块

@赵海  技术经理：

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

那么K8S平台上的系统，要放什么系统？

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

为什么要做跨数据中心的集群？

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

个人观点，仅供参考！

@NamingException 阳光财产保险股份有限公司 系统架构师：

对于类似两地三中心的多活要求，建议还是各数据中心分别搭建K8s集群，尽量保证各数据中心和网络分区的隔离性。

多活就是为了保证部分数据中心瘫痪时其他数据中心的持续可用，如果跨机房建一套K8s集群，master和node间网络抖动和时延带来的风险和不确定因素太多了，搞不好没问题的数据中心node都不可用。

建议实现多活的各数据中心的交叉点尽量收敛，应用层的状态抽离，多活基于上层的DNS、SLB配合下层的存储复制实现，没必要每层都跨机房组集群。

至于多集群带来的运维复杂度，可以通过统一的容器云管理平台，实现多集群纳管，减少一部分运维工作量。

以上为个人见解，欢迎各位同仁交流指正。

@sergio1899 平安集团 系统运维工程师：

建议分散风险，一中心多套比较稳。

@abcwayne DTC 系统运维工程师：

各自一套，使用公共组件代理。

欢迎点击文末阅读原文到社区阅读和讨论交流，发表您的看法

觉得本文有用，请转发、点赞或点击在看，让更多同行看到