1,大规模app扩展 软负载与硬负载如何选取?负载能力,维护性,管理性?
2,容器支持有状态的应用数据持久化,当规模较大时,同城容灾数据如何持续保护保护又该如何做?
3,kubernets编排工具 ,针对中小银行如何选取?
1、负载选择
a、容器外,建议使用硬件负载,可以提供更好的性能和调度能力。如:F5
b、容器内,直接使用内部软负载即可,如性能有要求,可以通过横向扩展降低单一负载压力。
2、应用数据持久化
目前,没有成熟的容器化数据库应用。建议使用外部存储来提供数据存储服务。
3、编排工具选择
绝大多数厂家的容器编排方案都是K8s,中小银行建议跟随主流,不建议选择小众工具,试错成本高。
收起以下内容是在使用kubernetes这一基础上展开:
1,大规模app使用硬件负载+软件负载结合,硬件负载作为入口保障安全稳定,软件负载可容器化部署,通过横向扩展满足性能要求。
2,不建议将数据直接落地到容器云平台上,应平台与数据分离,采用传统的存储方案或者分布式存储方案;
3,kubernetes已是当前的主流和事实标准,大多数的选择。
在应用大规模上容器平台后,在应用层面上负载均衡需要满足几个条件:
1、请求接入点可以合理的选择后端POD并将请求转发到处于容器中的应用POD上。
2、可以在没有数据面返回路径汇聚点的情况下进行扩展。
3、不存在跨节点的响应数据包的转发。
4、尽量减少iptables里面的NAT操作。
负载均衡设计方案,需要考虑实际环境中复杂情况:
1、是否需要开发一个基于DNS的服务路由前端。
2、是否需要实现一个kubernetes平台级别的扩展服务。
3、是否需要iptables NAT的支持。
4、是否需要修改kubernetes生的iptables规则。
5、是否需要修改kubernetes节点的内核网络配置。
6、是否需要修改kubernetes/Openshift的代码。
7、是否需要独占的kubernetes节点或者将节点进行分区使用。
博云在多年容器实战中总结出几种负载均衡方案:
1、基于DNS和HTTP 302的转发负载方案。
2、基于博云的CNI产品七层(haproxy)负载方案。
3、基于container host network模式的IPVS负载方案。
4、基于kubernetes nodeport service的IPVS负载方案。
总结:各类方案实施环境根据行方现行环境来考虑采纳哪种负载方案适合解决当前场景。
对于容灾,博云提供解决方案:
1、支持应用多集群发布
2、支持服务在多集群间的差异化配置
3、应用可在单集群或多集群应用间自由切换
4、实现跨集群的统一部署、升级、回滚
容灾多活技术主要从几个方面来实施:
1.应用层-多集群能力:主要完成多数据中心的应用同步部署、多活/主备方式的应用服务提供。
2.中间件层-个性化解决
3.负载均衡层-对接f5:主要完成数据中心之间和数据中心内的流量负载与冗余。
4.数据层:实现数据同步/异步的复制。
5.网络层:主要对上层应用调度、数据同步提供底层能力支持。