专栏名称: OSC开源社区
OSChina 开源中国 官方微信账号
目录
相关文章推荐
京东零售技术  ·  行业专家齐聚 | 共探跨端动态化新态势 ·  昨天  
稀土掘金技术社区  ·  优雅!原生Js实现多标签页之间的数据共享如此简单 ·  3 天前  
伯乐在线  ·  苹果 AI 发展受挫!AI 部门负责人或将被降职 ·  2 天前  
伯乐在线  ·  苹果 AI 发展受挫!AI 部门负责人或将被降职 ·  2 天前  
程序员的那些事  ·  神操作!中国工程师拖 4 箱硬盘 80TB ... ·  3 天前  
51好读  ›  专栏  ›  OSC开源社区

PaaS 容器集群优化之路

OSC开源社区  · 公众号  · 程序员  · 2017-05-13 08:29

正文

请到「今天看啥」查看全文


那么,对于这么一个大的、复杂的系统,从方法论的角度来讲,应该怎么去优化呢?基本思路就是做拆分,把一个大的问题分解为多个互相不耦合的维度,进行各个击破。


从大的维度来讲,一个PaaS容器集群,可以分为3个大的子系统。


- 控制子系统 :控制指令的下发和运行(k8s),例如创建pod


- 业务流量子系统 :容器网络(flannel)、负载均衡(ELB/kube-proxy)


- 监控子系统 :监控告警数据的采集(kafka, Hadoop)


这个看起来仅仅是一个架构上的划分,那么如何和具体的业务场景对应起来呢?我们可以考虑如下一个场景,在PaaS平台上大批量的部署应用。


看看在部署应用的过程中,会对各个子系统产生什么压力。


- 应用软件包大小:400M


- 应用模板大小:10M


- 1000个节点,每个节点一个POD,一个实例


- 10种类型的软件包,依赖长度为3,10GB 网络


- 调度及资源管理 3VM


这是一个典型的部署应用的一些规格,那么对于这样的一个输入,我们可以按照架构把压力分解到每个子系统上,这样得出的子系统需要支撑的指标是:


- 控制子系统 : kubernetes调度速度 > 50 pods/s,仓库支持300并发下载,>40M/s


- 数据子系统 :overlay容器网络TCP收发性能损耗


- 监控子系统 :在上面这个场景中不涉及,但可以从别的场景大致告警处理能力100条/秒


这里的业务场景:架构分析:子系统指标,这三者是m:1:n的,也就是说在不同场景下对不同的组件的性能要求不同,最后每个组件需要取自己指标的最大值。


指标决定了后续怎么进行实验测试,而测试是要花较大时间成本的,所以在指标的选取上要求少求精,尽量力图用2-3个指标衡量子系统。


优化测试 & 工具

上面讲的还是偏纸上的推演和分析,接下来进入实战阶段



对于服务器后端的程序来讲,推荐使用Promtheus这个工具来做指标的定义和采集。


Promtheus的基本工作原理是:后端程序引入Promtheus的SDK,自定义所有需要的测量的指标,然后开启一个http的页面,定期刷新数据。


Promtheus服务器会定期抓取这个页面上的数据,并存在内部的时间序列数据库内。








请到「今天看啥」查看全文