資訊專欄INFORMATION COLUMN
摘要：官方于月日發布了其容器部署與管理平臺的最新版本，。架構總覽在版本的整體架構圖如下圖所示上，引擎向下深入演化成了基礎設施引擎，這一點上在時代也早有體現。基礎設施引擎初次安裝版本，會發現多了如下圖所示的明顯標識，默認的引擎需要安裝等服務。
Rancher Labs官方于12月1日發布了其容器部署與管理平臺Rancher的最新版本，Rancher v1.2。Rancher v1.2可以說是一個里程碑版本，只要體會其新版功能，會發現漫長的等待絕對是值得的。
從架構角度看，用兩個字來概括就是“解耦”，基礎設施引擎的分離，agent節點的服務粒度更細；
從產品角度看，給了用戶更多定制的空間，Rancher依然秉持著全部OpenSource的理念；
在開發語言上，之前遺留的通過shell腳本方式的粗糙實現也都基于Golang重寫，解耦的新服務也幾乎使用Golang開發，agent節點全線基于Golang這也為后續便利地支持ARM埋下伏筆；
在市場選擇上，Rancher依然在kubernetes下面投入了大量精力，引入了萬眾期待的CNI plugin管理機制，堅持要做最好用的Kubernetes發行版。
本文就帶著大家從架構角度總覽Rancher v1.2版本的特性。
架構總覽在v1.2版本的整體架構圖（如下圖所示）上，Cattle引擎向下深入演化成了基礎設施引擎，這一點上在v1.1時代也早有體現。Cattle更多得作為基礎設施的管理工具，可以用它來部署其他服務和編排引擎，當然它本身編排能力還是可以使用的，習慣了stack-service的朋友仍然可以繼續使用它，同時rancher scheduler的引入也大大增強了其調度能力。Rancher仍然支持Kubernetes、Mesos、Swarm三大編排引擎，Kubernetes可以支持到較新的v1.4.6版本，由于所有的部署過程的代碼都是開放的，用戶依然可以自己定制部署版本。值得一提的是，Rancher支持了新版的Swarm Mode也就是Swarmkit引擎，這也意味著Rancher可以在Docker1.12上部署，不小心裝錯Docker版本的朋友這回可以放心了。
在存儲方面，Rancher引入了Kubernetes社區的flexvol來做存儲插件的管理，同時也支持Docker原生的volume plugin機制，并實現了對AWS的EFS&EBS以及標準NFS的支持，先前的Convoy應該會被拋棄，Rancher最終還是選擇參與社區標準。在網絡方面，除了CNI插件機制的引入，用戶還可以使用rancher-net組件提供的vxlan網絡替代先前的ipsec網絡。在可定制性方面，還體現在Rancher提供了用戶可以自定義rancher-lb的機制，如果特殊場景下默認的Haproxy不是很給力時，用戶可以自定義使用nginx、openresty或者traefik等等。下面便做一下詳細分解。
基礎設施引擎初次安裝v1.2版本，會發現多了Infrastructure（如下圖所示）的明顯標識，默認的Cattle引擎需要安裝healthcheck、ipsec、network-services、scheduler等服務。這個是有rancher-catalog來定義的，https://github.com/rancher/ra...，新分離出來了infra-templates和project-templates：infra-templates就是Rancher定義的各種基礎設施服務，包括基礎服務和編排引擎；project-templates對應的是Env初始化時默認安裝的服務，它可以針對不同的編排引擎進行配置。
以Cattle引擎為例，可以在project-templates的Cattle目錄中找到相應的配置文件，當ENV創建初始化時會創建這里面定義的服務，這樣一個機制就可以讓我們可以做更深入的定制，讓ENV初始化時創建我們需要的服務：
在Cattle引擎調度方面，Rancher實現了rancher-scheduler，https://github.com/rancher/sc...。它實現了允許用戶按計算資源調度，目前支持memory、cpu的Reservation。其實現原理是，內部有一個resource watcher，通過監聽rancher metadata的獲取Host的使用資源數據變化，進而得到ENV內所有Host資源匯總信息。與此同時，監聽rancher events的scheduler.prioritize、scheduler.reserve、scheduler.release等各種事件，通過排序過濾可用主機后發送回執信息，Rancher Server就有了可以選擇的Host列表。如下圖所示：
需要注意的是，rancher-scheduler并沒有和rancher-server部署在一起，而是在你添加Host時候部署在agent節點上，當然rancher-scheduler在一個ENV內只會部署一個。
Agent節點服務解耦agent節點一個最大的變化就是，agent-instance容器沒有了，它被拆分成多個容器服務，包括rancher-metadata、network-manager、rancher-net、rancher-dns、healthcheck等。
metadata服務是老朋友了，它在每個agent節點上保存了host、stack、service、container等的信息，可以非常方便的在本地調用取得，https://github.com/rancher/ra...，在新的體系中它扮演了重要角色，幾乎所有agent節點上的服務均依賴它。在先前的體系中，metadata的answer file的更新是通過事件驅動shell腳本來執行下載，比較簡單粗暴。v1.2開始使用監聽rancher events方式來reload metadata的answer file，但是answer file還需要到rancher server端下載，總的來說效率還是有一定提升的。
dns在新的體系中仍然承擔著服務發現的功能，https://github.com/rancher/ra...。除了拆分成多帶帶容器之外，它也在效率上做了改進，它與rancher-metadata容器共享網絡，以metadata的結果生成dns的answer file。與之前的架構相比，省去了dns answer file下載的過程。需要注意的是，rancher-dns的TTL默認是600秒，如果出于各種原因覺得dns作為服務發現不是很可靠，那么可以使用etc-host-updater和rancher-metadata的組合，etc-host-updater（https://github.com/rancher/et...）會根據metadata數據動態生成hosts文件并寫入容器內，這樣通過服務名訪問時，其實已經在本地轉換成了IP，無需經過dns，如下圖所示：
rancher-net作出了比較重大的革新，https://github.com/rancher/ra...，除了繼續支持原有的ipsec外，還支持了vxlan。這個支持是原生支持，只要內核有vxlan的支持模塊就可以。vxlan并不是Cattle的默認網絡，使用時可以在infra-catalog中重新選擇它來部署，其實現以及部署方式后續會在專門的文章中進行探討：
network-manager的引入為Rancher v1.2帶來了一個重要特性就是CNI插件管理，在之前的版本中很多用戶都提到rancher-net本身的網絡無法滿足業務需求。容器網絡之爭，無非就是CNM與CNI，Rancher選擇站隊CNI，這也是為了更好與Kubernetes融合。而CNI的插件很多種，Calico、Weave等之流，每個插件的部署方式都不一樣。Rancher為了簡化管理提出了network-manager，https://github.com/rancher/pl...，它可以做到兼容主流的CNI插件，它實際上定義了一個部署框架，讓CNI插件在框架內部署。network-manager是以容器方式部署，由于每種插件在初始化時可能需要暴露端口或加入一些NAT規則，所以network-manager能夠動態設置不同插件的初始化規則，它的做法是以metadata作為 host port和host nat規則的數據源，然后獲取數據后生成相應的Iptables規則加入的Host中。而對于真正的CNI插件，需要在network-manager容器內/opt/cni目錄下部署對應cni插件的執行程序（calico/weave），/etc/cni目錄下部署cni插件的配置，這兩個目錄映射了docker卷rancher-cni-driver，也就是Host上的/var/lib/docker/volumes/rancher-cni-driver目錄下。
關于healthcheck，先前是通過agent-instance鏡像實現，里面內置了Haproxy，事件驅動shell腳本來下載healchcheck配置并reload。新的架構中，Rancher實現了多帶帶的healthcheck，https://github.com/rancher/he...，采用Golang微服務的方式，數據源是metadata。當然healthcheck的最終檢查仍然是通過與Haproxy sock通信來查看相應member的健康狀態（原理如下圖），healthcheck的實現主要是為了將其從agent-instance中解耦出來。
總結Rancher v1.2的新特性非常多，基礎設施引擎的變化是一切特性的基礎，在這篇開篇之作之后，我們后續會持續為大家帶來Kubernetes與Swarmkit的支持、自定義rancher-lb、vxlan的支持、各種CNI插件的集成以及各種存儲接入的實踐操作指南等等。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11756.html
摘要：官方于月日發布了其容器部署與管理平臺的最新版本，。架構總覽在版本的整體架構圖如下圖所示上，引擎向下深入演化成了基礎設施引擎，這一點上在時代也早有體現。基礎設施引擎初次安裝版本，會發現多了如下圖所示的明顯標識，默認的引擎需要安裝等服務。 Rancher Labs官方于12月1日發布了其容器部署與管理平臺Rancher的最新版本，Rancher v1.2。Rancher v1.2可以說是一...
摘要：在之前的版本上，用戶時常抱怨的網絡只有，沒有其他選擇。而容器社區的發展是十分迅猛的，各種容器網絡插件風起云涌，欲在江湖中一爭高下。同樣是基于，使用提供的，網絡配置信息以方式注入。 在之前的Rancher版本上，用戶時常抱怨Rancher的網絡只有IPsec，沒有其他選擇。而容器社區的發展是十分迅猛的，各種容器網絡插件風起云涌，欲在江湖中一爭高下。Rancher v1.2版本中與時俱進，...
摘要：在之前的版本上，用戶時常抱怨的網絡只有，沒有其他選擇。而容器社區的發展是十分迅猛的，各種容器網絡插件風起云涌，欲在江湖中一爭高下。同樣是基于，使用提供的，網絡配置信息以方式注入。 在之前的Rancher版本上，用戶時常抱怨Rancher的網絡只有IPsec，沒有其他選擇。而容器社區的發展是十分迅猛的，各種容器網絡插件風起云涌，欲在江湖中一爭高下。Rancher v1.2版本中與時俱進，...
摘要：模版用戶可以選擇不同的基礎設施服務組成模版同時還是有默認的主要模版，用戶可以快速創建用戶也可以把的項目放到模版中，來管理和部署增強已經大大簡化了管理和配置，在多節點部署中和已經被去掉了。請保持關注，和一起走上偉岸光明的容器之路 開篇第一句，先為Rancher v1.2曾經的跳票深深抱歉（鞠躬）。我們補償的方式，就是在此日、此刻，用新版功能向你證明Rancher v1.2值得你的等待。R...
摘要：組件會給每個分配一個，則替代了的來實現服務發現，在的容器內部依然可以訪問服務來獲取元數據信息。的需要在中實現一個，目前只有，而則維護了自己的版本在其中提供了。 在Rancher 1.0版本開始，Rancher逐步增加了Kubernetes、Swarm、Mesos等多編排引擎的支持，很多朋友就此產生了疑惑，諸如Cattle引擎和這幾個之間到底什么關系？每種引擎是如何支持的？自家的業務環境...
閱讀 1448·2021-09-02 19:23
閱讀 1600·2021-08-11 11:19
閱讀 645·2019-08-30 15:55
閱讀 1655·2019-08-30 12:50
閱讀 2245·2019-08-30 11:23
閱讀 2187·2019-08-29 13:13
閱讀 1507·2019-08-28 18:13
閱讀 3347·2019-08-26 11:53
