摘要：但的數(shù)據(jù)存在，而的數(shù)據(jù)存儲暫未了解但肯定是存在內(nèi)存中。測試對比物理機(jī)進(jìn)程。當(dāng)然，使用對容器進(jìn)行編排的時(shí)候，可以指定任何想要的網(wǎng)絡(luò)方式如采用的方式，，。

rancher 自帶了一套網(wǎng)絡(luò)方案，可以實(shí)現(xiàn)跨機(jī)器的docker容器互聯(lián)。其原理大致是：在每個(gè)機(jī)器上通過docker啟動一個(gè)路由容器，將docker容器啟動時(shí)的ip定義為10.42網(wǎng)段，并在iptables中將10.42網(wǎng)段的請求轉(zhuǎn)發(fā)到路由進(jìn)程的監(jiān)聽端口，進(jìn)行udp的封裝和解封。這么看來其原理與flannel一樣都是隧道技術(shù)，都是通過一個(gè)程序進(jìn)行封包解包，并引導(dǎo)docker啟動容器時(shí)指定相應(yīng)的ip。但flannel的數(shù)據(jù)存在etcd，而rancherSDN的數(shù)據(jù)存儲暫未了解（但肯定是存在內(nèi)存中）。下面對rancherSDN的網(wǎng)絡(luò)性能做一次測試。

對比：物理機(jī)進(jìn)程。
場景：

 1.redis部署在物理機(jī)上，markbench部署在另一臺物理機(jī)的docker容器中（hostnetwork）
 2.redis部署在docker上（屬于rancher的sdn），markbench部署在另一臺物理機(jī)的docker中（屬于rancher的sdn）。

測試：

 1.1000個(gè)并發(fā) 1000000個(gè)請求 8byte數(shù)據(jù)包
 2.1000個(gè)并發(fā) 1000000個(gè)請求 1024byte數(shù)據(jù)包

測試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網(wǎng)絡(luò)，性能表現(xiàn)比較差，并且測試過程中由于并發(fā)量太大程序還跑出了不少超時(shí)的異常。雖然benchmark端不是放在同一個(gè)地方進(jìn)行的測試，但是可以明顯看到相比物理機(jī)端的差距(相比之下flannel的損耗情況會改善一些)。當(dāng)然，使用rancher對docker容器進(jìn)行編排的時(shí)候，可以指定任何想要的網(wǎng)絡(luò)方式如：bridge（flannel采用的方式），host，managed（rancher SDN）。

所以拋開sdn，rancher依然是一個(gè)很好的docker編排工具。它已經(jīng)實(shí)現(xiàn)了多套環(huán)境的切換，多種結(jié)構(gòu)的容器編排（按機(jī)器和按項(xiàng)目，k8s的編排思想與之有出入，所以沒有這個(gè)功能），項(xiàng)目容器的伸縮，機(jī)器/容器的監(jiān)控，對容器的啟動參數(shù)也支持得很全面。如果rancherSDN可以做的更好，結(jié)合rancher的loadbalance功能，就可以規(guī)范地給服務(wù)進(jìn)行負(fù)載均衡了。