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

简介：

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)。

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

rancher和k8s的初步对比