rancher的使用感受以及与k8s的对比

fzu_huang

简介:

rancher 自带了一套网络方案,可以实现跨机器的docker容器互联。其原理大致是:在每个机器上通过docker启动一个路由容器,将docker容器启动时的ip定义为10.42网段,并在iptables中将10.42网段的请求转发到路由进程的监听端口,进行udp的封装和解封。这么看来其原理与flannel一样都是隧道技术,都是通过一个程序进行封包解包,并引导docker启动容器时指定相应的ip。但flannel的数据存在etcd,而rancherSDN的数据存储暂未了解(但肯定是存在内存中)。下面对rancherSDN的网络性能做一次测试。

测试:

对比:物理机进程。
场景:

 1.redis部署在物理机上,markbench部署在另一台物理机的docker容器中(hostnetwork)
 2.redis部署在docker上(属于rancher的sdn),markbench部署在另一台物理机的docker中(属于rancher的sdn)。

测试:

 1.1000个并发 1000000个请求 8byte数据包
 2.1000个并发 1000000个请求 1024byte数据包

测试1
场景1:

Concurrency Level:     1000--???
Time taken for tests:     14738.712 ms--????
Complete Requests:     1000000--??????
Failed Requests:     0--????
Requests per second:     70381.16--QPS
Time per request:     14.208348 ms--????
Time per request:     0.014208348 ms (across all concurrent requests)--???????????
Shortest request:     0.210504 ms--????
Percentage of the requests served within a certain time (ms)
  50%     11.902441--50% ????0.005703????
  66%     12.081795
  75%     12.233685
  80%     12.335639
  90%     12.679234
  95%     13.357562
  98%     14.547652
  99%     17.011213
 100%     3390.3135 (longest request)--?????```

场景2:

Concurrency Level:     1000--???
Time taken for tests:     41545.566 ms--????
Complete Requests:     1000000--??????
Failed Requests:     0--????
Requests per second:     37853.703--QPS
Time per request:     26.417492 ms--????
Time per request:     0.026417492 ms (across all concurrent requests)--???????????
Shortest request:     0.263888 ms--????
Percentage of the requests served within a certain time (ms)
  50%     20.311712--50% ????0.005703????
  66%     21.991657
  75%     22.531752
  80%     22.833311
  90%     23.901358
  95%     26.956127
  98%     35.04501
  99%     219.7134
100%     22636.861 (longest request)--????? 

测试2:
场景1:

Concurrency Level:     1000--???
Time taken for tests:     15144.447 ms--????
Complete Requests:     1000000--??????
Failed Requests:     0--????
Requests per second:     67796.72--QPS
Time per request:     14.749976 ms--????
Time per request:     0.014749976 ms (across all concurrent requests)--???????????
Shortest request:     0.239347 ms--????
Percentage of the requests served within a certain time (ms)
  50%     13.554401--50% ????0.005703????
  66%     13.735824
  75%     13.886956
  80%     13.990395
  90%     14.687311
  95%     15.511463
  98%     18.912176
  99%     21.210245
100%     702.1307 (longest request)--?????     

场景2:

Concurrency Level:     1000--???
Time taken for tests:     35280.426 ms--????
Complete Requests:     1000000--??????
Failed Requests:     0--????
Requests per second:     32202.309--QPS
Time per request:     31.053675 ms--????
Time per request:     0.031053673 ms (across all concurrent requests)--???????????
Shortest request:     0.314267 ms--????
Percentage of the requests served within a certain time (ms)
  50%     25.674334--50% ????0.005703????
  66%     27.830894
  75%     29.81296
  80%     30.791946
  90%     33.643417
  95%     39.105713
  98%     54.156647
  99%     236.9922
100%     20131.455 (longest request)--????? 
 

总结:

使用rancher的sdn网络,性能表现比较差,并且测试过程中由于并发量太大程序还跑出了不少超时的异常。虽然benchmark端不是放在同一个地方进行的测试,但是可以明显看到相比物理机端的差距(相比之下flannel的损耗情况会改善一些)。当然,使用rancher对docker容器进行编排的时候,可以指定任何想要的网络方式如:bridge(flannel采用的方式),host,managed(rancher SDN)。

clipboard.png

所以抛开sdn,rancher依然是一个很好的docker编排工具。它已经实现了多套环境的切换,多种结构的容器编排(按机器和按项目,k8s的编排思想与之有出入,所以没有这个功能),项目容器的伸缩,机器/容器的监控,对容器的启动参数也支持得很全面。如果rancherSDN可以做的更好,结合rancher的loadbalance功能,就可以规范地给服务进行负载均衡了。

rancher和k8s的初步对比

clipboard.png

阅读 52.6k

kubernetes_docker集群管理
我学到的关于k8s和docker的种种。 仅作学习笔记用,不会发布在别的地方
272 声望
105 粉丝
0 条评论
你知道吗?

272 声望
105 粉丝
文章目录
宣传栏