对于两地三中心的数据中心架构,k8s集群建议一套还是各区域搭建各自k8s集群,各自有什么优缺点,对于多集群方案,每个集群3master时候过于冗余。
一般来说,会有几点问题需要我们来思考
1、执行实时备份,其中将写入一个数据中心的数据异步复制到另一个数据中心。
2、 多个数据中心进行应用多活部署,就近原则,来确保更快的性能。
3、如果一个数据中心发生故障,仍然可以从另一数据中心提供业务服务
4、 如果一个数据中心中的几个节点发生故障,其他数据中心的资源任可以被调度
在架构设计过程中,你可以数据中心之间进行解耦,你也可以进行耦合,如果仅仅是备份,那就解耦,如果多活,那就需要耦合
收起建议各个区域搭建各自的k8s集群。
如果搭建一套,区域与区域之间的网络抖动或者延迟有可能造成master节点和node节点失联,业务重新调度等问题。
常规方法都是在各个区域搭建各自的k8s集群,然后用统一的多集群管理或者多云管理平台统一纳管多套k8s集群,集群与集群之间的业务调度、容灾备份等都可以在这个多集群管理或者多云管理平台上实现。
搭建一套的前提有如下两个:
1.master组件的可用性保障。当master任何组件有故障时候影响是全局的,如何进行快速的故障处理和恢复,甚至不影响业务
2.大集群跨区域的网络性能保障。跨区域,存在网络延时,如何进行保障
3.大集群的管理。集群规模的变大,相应参数和优化也要跟上。
1,从数据中心统一安全、基线管理来看,首先要构建统一的docker image hub registry;
2,若分散构建registry,需要规划跨中心定期同步更新基线信息;
3,Kubernetes集群建议分散到各数据中心,用户体验、权限等管理方便些。
跨AZ/DC的双活指的是应用级别的双活,一般用跨AZ/DC的 LB + VIP来实现统一的流量入口。
但是并不等于同一个集群能够跨AZ的弹性扩容。问题在于AZ之间的网络质量如何保证?一般AZ之间是专线或者裸光纤,即使这样,也避免不了网络抖动。集群内部的组件之间的API调用,MQ,时间同步,DNS解析,状态同步,集群心跳之类的都会出现致命故障。分布式系统最怕网络不稳定了,组件之间太依赖网络的延时。
所以我所见到生产系统,都是各区域搭建各自k8s集群,前端LB负载均衡, 后端存储同步。如果要实现跨集群多个k8s联动扩缩容,可以在上面封装一层集群业务管理/编排功能,可能openshift有这样的功能吧,还需要专家确认。
建议各区域搭建各自k8s集群
优点:
1、避免跨机房网络抖动造成的管理端与宿主机连接故障
2、多管理端多控制面模式,可以有效接管某套控制面不可用时的业务容器编排
3、扩充受管端宿主机规模,根据评估,一套K8S管理端可承载宿主机5000个节点
应注意:
1、应考虑受管端的宿主机规模,评估投入有效性
2、同一套应用,建议部署在同一个管理集群内,否则会造成需要发布两次,存在风险
3、人力运维投入多,需要保障两套系统的可用性
4、建议开发制作多集群的统一操作portal
5、建议开发制作跨控制面的迁移工具模块
您的问题,我觉得可以从两个层面来看问题。
1、两地三中心场景
传统的方案是同城双活异地灾备,主要解决的是业务的多重可靠性保障。
如果是以可靠性为目标,建议每个中心都要单独部署集群,以保证其独立运行能力,进而保障业务的可靠性。
2、如何优化提升资源的利用率
为了保障每个集群的可靠性,至少需要3台master节点。当集群较多的时候,资源会比较浪费。
基于提高资源利用率的角度看,我们可以从下面几个方面着手考虑。
a、单中心内跨区域时,只部署node尽量共用master节点,避免每个区域都要部署一套完整的K8s集群。
b、如果一定要部署多个K8s集群时,可以考虑使用虚拟机部署master,只提供够master运行的资源,降低资源浪费。
c、如果在物理机上部署master的时候,可以考虑把master改造,实现master和node运行在同一个节点上。
收起好问题,如果是大企业环境,建议采用各区域各自搭建,统一管理的模式,有以下优点:
1.实现数据的异地灾备,两个数据中心k8s的数据进行异步复制(切记不要同步,否则增加网络带宽压力和业务的压力,甚至造成业务延迟过大);
2.部署区域建议不要跨城;
3.实现业务层面的高可用,尤其是金融类系统;
4.双中心必须建设统一的管控中心,而不是多个孤岛;
一套的这种部署方案适合小型企业,单点故障时最大的问题。
对于类似两地三中心的多活要求,建议还是各数据中心分别搭建K8s集群,尽量保证各数据中心和网络分区的隔离性。
多活就是为了保证部分数据中心瘫痪时其他数据中心的持续可用,如果跨机房建一套K8s集群,master和node间网络抖动和时延带来的风险和不确定因素太多了,搞不好没问题的数据中心node都不可用。
建议实现多活的各数据中心的交叉点尽量收敛,应用层的状态抽离,多活基于上层的DNS、SLB配合下层的存储复制实现,没必要每层都跨机房组集群。
至于多集群带来的运维复杂度,可以通过统一的容器云管理平台比如Rancher,实现多集群纳管,减少一部分运维工作量。
以上为个人见解,欢迎各位同仁交流指正。
收起两地三中心的架构最开始的来源应该是银行业,银行业之所以要搞这样的架构是因为监管部门对某些业务系统是有业务连续性要求的。说白了也是为了保障某些重要交易系统的连续性。
那么K8S平台上的系统,要放什么系统?
核心交易系统?还是其他的一些什么系统?我相信就目前来看,核心交易系统思路还上不了K8S的平台。如果是其他系统,那么好办了。看看系统的业务连续性要求是什么,如果没有硬性监管要求,那么有没有一个客观实际的评估,按照这个标准去评估后续的架构就可以了。
为什么要做跨数据中心的集群?
K8S集群本身是为了提高局部区域计算能力的高可用性。如果为了实现所谓的双活,而舍弃K8S本身的最大适合条件,这个决策评估的是不是有点不太专业。
纯属个人观点,仅供参考!
收起