摘要：官方于月日發(fā)布了其容器部署與管理平臺(tái)的最新版本，。架構(gòu)總覽在版本的整體架構(gòu)圖如下圖所示上，引擎向下深入演化成了基礎(chǔ)設(shè)施引擎，這一點(diǎn)上在時(shí)代也早有體現(xiàn)?；A(chǔ)設(shè)施引擎初次安裝版本，會(huì)發(fā)現(xiàn)多了如下圖所示的明顯標(biāo)識(shí)，默認(rèn)的引擎需要安裝等服務(wù)。

Rancher Labs官方于12月1日發(fā)布了其容器部署與管理平臺(tái)Rancher的最新版本，Rancher v1.2。Rancher v1.2可以說(shuō)是一個(gè)里程碑版本，只要體會(huì)其新版功能，會(huì)發(fā)現(xiàn)漫長(zhǎng)的等待絕對(duì)是值得的。

從架構(gòu)角度看，用兩個(gè)字來(lái)概括就是“解耦”，基礎(chǔ)設(shè)施引擎的分離，agent節(jié)點(diǎn)的服務(wù)粒度更細(xì)；

從產(chǎn)品角度看，給了用戶更多定制的空間，Rancher依然秉持著全部OpenSource的理念；

在開(kāi)發(fā)語(yǔ)言上，之前遺留的通過(guò)shell腳本方式的粗糙實(shí)現(xiàn)也都基于Golang重寫(xiě)，解耦的新服務(wù)也幾乎使用Golang開(kāi)發(fā)，agent節(jié)點(diǎn)全線基于Golang這也為后續(xù)便利地支持ARM埋下伏筆；

在市場(chǎng)選擇上，Rancher依然在kubernetes下面投入了大量精力，引入了萬(wàn)眾期待的CNI plugin管理機(jī)制，堅(jiān)持要做最好用的Kubernetes發(fā)行版。

本文就帶著大家從架構(gòu)角度總覽Rancher v1.2版本的特性。

在v1.2版本的整體架構(gòu)圖（如下圖所示）上，Cattle引擎向下深入演化成了基礎(chǔ)設(shè)施引擎，這一點(diǎn)上在v1.1時(shí)代也早有體現(xiàn)。Cattle更多得作為基礎(chǔ)設(shè)施的管理工具，可以用它來(lái)部署其他服務(wù)和編排引擎，當(dāng)然它本身編排能力還是可以使用的，習(xí)慣了stack-service的朋友仍然可以繼續(xù)使用它，同時(shí)rancher scheduler的引入也大大增強(qiáng)了其調(diào)度能力。Rancher仍然支持Kubernetes、Mesos、Swarm三大編排引擎，Kubernetes可以支持到較新的v1.4.6版本，由于所有的部署過(guò)程的代碼都是開(kāi)放的，用戶依然可以自己定制部署版本。值得一提的是，Rancher支持了新版的Swarm Mode也就是Swarmkit引擎，這也意味著Rancher可以在Docker1.12上部署，不小心裝錯(cuò)Docker版本的朋友這回可以放心了。

在存儲(chǔ)方面，Rancher引入了Kubernetes社區(qū)的flexvol來(lái)做存儲(chǔ)插件的管理，同時(shí)也支持Docker原生的volume plugin機(jī)制，并實(shí)現(xiàn)了對(duì)AWS的EFS&EBS以及標(biāo)準(zhǔn)NFS的支持，先前的Convoy應(yīng)該會(huì)被拋棄，Rancher最終還是選擇參與社區(qū)標(biāo)準(zhǔn)。在網(wǎng)絡(luò)方面，除了CNI插件機(jī)制的引入，用戶還可以使用rancher-net組件提供的vxlan網(wǎng)絡(luò)替代先前的ipsec網(wǎng)絡(luò)。在可定制性方面，還體現(xiàn)在Rancher提供了用戶可以自定義rancher-lb的機(jī)制，如果特殊場(chǎng)景下默認(rèn)的Haproxy不是很給力時(shí)，用戶可以自定義使用nginx、openresty或者traefik等等。下面便做一下詳細(xì)分解。

初次安裝v1.2版本，會(huì)發(fā)現(xiàn)多了Infrastructure（如下圖所示）的明顯標(biāo)識(shí)，默認(rèn)的Cattle引擎需要安裝healthcheck、ipsec、network-services、scheduler等服務(wù)。這個(gè)是有rancher-catalog來(lái)定義的，https://github.com/rancher/ra...，新分離出來(lái)了infra-templates和project-templates：infra-templates就是Rancher定義的各種基礎(chǔ)設(shè)施服務(wù)，包括基礎(chǔ)服務(wù)和編排引擎；project-templates對(duì)應(yīng)的是Env初始化時(shí)默認(rèn)安裝的服務(wù)，它可以針對(duì)不同的編排引擎進(jìn)行配置。

以Cattle引擎為例，可以在project-templates的Cattle目錄中找到相應(yīng)的配置文件，當(dāng)ENV創(chuàng)建初始化時(shí)會(huì)創(chuàng)建這里面定義的服務(wù)，這樣一個(gè)機(jī)制就可以讓我們可以做更深入的定制，讓ENV初始化時(shí)創(chuàng)建我們需要的服務(wù)：

在Cattle引擎調(diào)度方面，Rancher實(shí)現(xiàn)了rancher-scheduler，https://github.com/rancher/sc...。它實(shí)現(xiàn)了允許用戶按計(jì)算資源調(diào)度，目前支持memory、cpu的Reservation。其實(shí)現(xiàn)原理是，內(nèi)部有一個(gè)resource watcher，通過(guò)監(jiān)聽(tīng)rancher metadata的獲取Host的使用資源數(shù)據(jù)變化，進(jìn)而得到ENV內(nèi)所有Host資源匯總信息。與此同時(shí)，監(jiān)聽(tīng)rancher events的scheduler.prioritize、scheduler.reserve、scheduler.release等各種事件，通過(guò)排序過(guò)濾可用主機(jī)后發(fā)送回執(zhí)信息，Rancher Server就有了可以選擇的Host列表。如下圖所示：

需要注意的是，rancher-scheduler并沒(méi)有和rancher-server部署在一起，而是在你添加Host時(shí)候部署在agent節(jié)點(diǎn)上，當(dāng)然rancher-scheduler在一個(gè)ENV內(nèi)只會(huì)部署一個(gè)。

agent節(jié)點(diǎn)一個(gè)最大的變化就是，agent-instance容器沒(méi)有了，它被拆分成多個(gè)容器服務(wù)，包括rancher-metadata、network-manager、rancher-net、rancher-dns、healthcheck等。

metadata服務(wù)是老朋友了，它在每個(gè)agent節(jié)點(diǎn)上保存了host、stack、service、container等的信息，可以非常方便的在本地調(diào)用取得，https://github.com/rancher/ra...，在新的體系中它扮演了重要角色，幾乎所有agent節(jié)點(diǎn)上的服務(wù)均依賴它。在先前的體系中，metadata的answer file的更新是通過(guò)事件驅(qū)動(dòng)shell腳本來(lái)執(zhí)行下載，比較簡(jiǎn)單粗暴。v1.2開(kāi)始使用監(jiān)聽(tīng)rancher events方式來(lái)reload metadata的answer file，但是answer file還需要到rancher server端下載，總的來(lái)說(shuō)效率還是有一定提升的。

dns在新的體系中仍然承擔(dān)著服務(wù)發(fā)現(xiàn)的功能，https://github.com/rancher/ra...。除了拆分成多帶帶容器之外，它也在效率上做了改進(jìn)，它與rancher-metadata容器共享網(wǎng)絡(luò)，以metadata的結(jié)果生成dns的answer file。與之前的架構(gòu)相比，省去了dns answer file下載的過(guò)程。需要注意的是，rancher-dns的TTL默認(rèn)是600秒，如果出于各種原因覺(jué)得dns作為服務(wù)發(fā)現(xiàn)不是很可靠，那么可以使用etc-host-updater和rancher-metadata的組合，etc-host-updater（https://github.com/rancher/et...）會(huì)根據(jù)metadata數(shù)據(jù)動(dòng)態(tài)生成hosts文件并寫(xiě)入容器內(nèi)，這樣通過(guò)服務(wù)名訪問(wèn)時(shí)，其實(shí)已經(jīng)在本地轉(zhuǎn)換成了IP，無(wú)需經(jīng)過(guò)dns，如下圖所示：

rancher-net作出了比較重大的革新，https://github.com/rancher/ra...，除了繼續(xù)支持原有的ipsec外，還支持了vxlan。這個(gè)支持是原生支持，只要內(nèi)核有vxlan的支持模塊就可以。vxlan并不是Cattle的默認(rèn)網(wǎng)絡(luò)，使用時(shí)可以在infra-catalog中重新選擇它來(lái)部署，其實(shí)現(xiàn)以及部署方式后續(xù)會(huì)在專門的文章中進(jìn)行探討：

network-manager的引入為Rancher v1.2帶來(lái)了一個(gè)重要特性就是CNI插件管理，在之前的版本中很多用戶都提到rancher-net本身的網(wǎng)絡(luò)無(wú)法滿足業(yè)務(wù)需求。容器網(wǎng)絡(luò)之爭(zhēng)，無(wú)非就是CNM與CNI，Rancher選擇站隊(duì)CNI，這也是為了更好與Kubernetes融合。而CNI的插件很多種，Calico、Weave等之流，每個(gè)插件的部署方式都不一樣。Rancher為了簡(jiǎn)化管理提出了network-manager，https://github.com/rancher/pl...，它可以做到兼容主流的CNI插件，它實(shí)際上定義了一個(gè)部署框架，讓CNI插件在框架內(nèi)部署。network-manager是以容器方式部署，由于每種插件在初始化時(shí)可能需要暴露端口或加入一些NAT規(guī)則，所以network-manager能夠動(dòng)態(tài)設(shè)置不同插件的初始化規(guī)則，它的做法是以metadata作為 host port和host nat規(guī)則的數(shù)據(jù)源，然后獲取數(shù)據(jù)后生成相應(yīng)的Iptables規(guī)則加入的Host中。而對(duì)于真正的CNI插件，需要在network-manager容器內(nèi)/opt/cni目錄下部署對(duì)應(yīng)cni插件的執(zhí)行程序（calico/weave），/etc/cni目錄下部署cni插件的配置，這兩個(gè)目錄映射了docker卷rancher-cni-driver，也就是Host上的/var/lib/docker/volumes/rancher-cni-driver目錄下。

關(guān)于healthcheck，先前是通過(guò)agent-instance鏡像實(shí)現(xiàn)，里面內(nèi)置了Haproxy，事件驅(qū)動(dòng)shell腳本來(lái)下載healchcheck配置并reload。新的架構(gòu)中，Rancher實(shí)現(xiàn)了多帶帶的healthcheck，https://github.com/rancher/he...，采用Golang微服務(wù)的方式，數(shù)據(jù)源是metadata。當(dāng)然healthcheck的最終檢查仍然是通過(guò)與Haproxy sock通信來(lái)查看相應(yīng)member的健康狀態(tài)（原理如下圖），healthcheck的實(shí)現(xiàn)主要是為了將其從agent-instance中解耦出來(lái)。

Rancher v1.2的新特性非常多，基礎(chǔ)設(shè)施引擎的變化是一切特性的基礎(chǔ)，在這篇開(kāi)篇之作之后，我們后續(xù)會(huì)持續(xù)為大家?guī)?lái)Kubernetes與Swarmkit的支持、自定義rancher-lb、vxlan的支持、各種CNI插件的集成以及各種存儲(chǔ)接入的實(shí)踐操作指南等等。