k8s in Rancher架構(gòu)分析

在Rancher 1.0版本開始，Rancher逐步增加了Kubernetes、Swarm、Mesos等多編排引擎的支持，很多朋友就此產(chǎn)生了疑惑，諸如Cattle引擎和這幾個(gè)之間到底什么關(guān)系？每種引擎是如何支持的？自家的業(yè)務(wù)環(huán)境如何選型？我們將逐步揭開這些神秘面紗，了解基礎(chǔ)架構(gòu)才能在遇到問(wèn)題時(shí)進(jìn)行有效的分析，進(jìn)而準(zhǔn)確的定位問(wèn)題并解決問(wèn)題，因?yàn)闆](méi)有一種生產(chǎn)環(huán)境是完全可靠的?；谶@個(gè)背景下，這次我們首先向大家介紹kubernetes in Rancher的架構(gòu)。

從現(xiàn)在Rancher的發(fā)展節(jié)奏來(lái)看，Cattle引擎已經(jīng)被定義成Rancher的基礎(chǔ)設(shè)施引擎，而Rancher的基礎(chǔ)設(shè)施服務(wù)都包括哪些呢？如下：

• Networking，Rancher的統(tǒng)一網(wǎng)絡(luò)服務(wù)，由rancher-net組件提供

• Load Balancer，Rancher的負(fù)載均衡服務(wù)，目前來(lái)看套路基本上是基于Haproxy來(lái)構(gòu)建

• DNS Service，Rancher的DNS服務(wù)，主要是為了提供服務(wù)發(fā)現(xiàn)能力，由Rancher-DNS組件來(lái)提供

• Metadata Service，Rancher的元數(shù)據(jù)服務(wù)，Metadata是我們通過(guò)compose編排應(yīng)用時(shí)的利器，可以很靈活的像service中注入特定信息

• Persistent Storage Service，持久化存儲(chǔ)服務(wù)目前是由convoy來(lái)提供，而對(duì)于真正的后端存儲(chǔ)的實(shí)現(xiàn)Rancher還有l(wèi)onghorn沒(méi)有完全放出

• Audit Logging，審計(jì)日志服務(wù)是企業(yè)場(chǎng)景中比較重要的一個(gè)屬性，目前是集成在Cattle內(nèi)部沒(méi)有被完全分離出來(lái)

所以Rancher在接入任何一種編排引擎，最終都會(huì)把基礎(chǔ)設(shè)施服務(wù)整合到該引擎中，Kubernetes in Rancher的做法正是如此。

Kubernetes各個(gè)組件的角色可以歸為三類即Master、Minion、Etcd，Master主要是kube-apiserver、kube-scheduler、kube-controller-manager，Minion主要是kubelet和kube-proxy。Rancher為了融合k8s的管控功能，又在Master中添加了kuberctrld、ingress-controller、kubernetes-agent三個(gè)服務(wù)來(lái)打通Rancher和K8s，同時(shí)每個(gè)node上都會(huì)依賴Rancher提供的Rancher-DNS、Rancher-metadata、Rancher-net這些基礎(chǔ)設(shè)施服務(wù)。

由于K8s是基于Cattle引擎來(lái)部署，所以在K8s在部署完成之后，我們可以通過(guò)Link Graph來(lái)很清晰的看到整體的部署情況。

整個(gè)服務(wù)基于Cattle引擎的Rancher-compose構(gòu)建，新增節(jié)點(diǎn)后自動(dòng)添加kubelet和kube-proxy服務(wù)（此處利用了Global Label的特性），各個(gè)組件都添加了health-check機(jī)制，保證一定程度的高可用。考慮到etcd最低1個(gè)最多3個(gè)節(jié)點(diǎn)，單臺(tái)agent host就可以部署K8s，三節(jié)點(diǎn)agent host則更合理些。

K8s集群完成部署后，我們就可以在其中添加各種應(yīng)用服務(wù)，目前Rancher支持管理K8s的service、pod、replication-controller等，我們可以用一張圖來(lái)形象得描述一下應(yīng)用視圖結(jié)構(gòu)。

rancher-net組件會(huì)給每個(gè)pod分配一個(gè)IP，Rancher-DNS則替代了K8s的Skydns來(lái)實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，在pod的容器內(nèi)部依然可以訪問(wèn)Rancher-metadata服務(wù)來(lái)獲取元數(shù)據(jù)信息。除了這三個(gè)基礎(chǔ)服務(wù)外，我們之前提到的kuberctrld、ingress-controller、kubernetes-agent也在其中扮演者重要角色。

無(wú)論是K8s還是Rancher，其中一些抽象對(duì)象（如Rancher的stack/service，或者K8s的serivice/pod）在屬性更新時(shí)都會(huì)有events產(chǎn)生，在任何服務(wù)入口來(lái)更改這些抽象對(duì)象都會(huì)有events產(chǎn)生，所以要保證Rancher和k8s能夠互相感知各自對(duì)象的更新，那么kubernetes-agent就應(yīng)運(yùn)而生了。

諸如K8s的namespaces、services、replicationcontrollers、pods等對(duì)象的信息變更會(huì)及時(shí)通知給Rancher，而Cattle管理的Host資源出現(xiàn)信息變更（諸如host label的變動(dòng)）也會(huì)通知給K8s。

簡(jiǎn)單得說(shuō)kubernetes-agent是為了維護(hù)Rancher和K8s之間的對(duì)象一致性，而真正要通過(guò)Rancher來(lái)創(chuàng)建K8s中的service或者pod之類的對(duì)象，還需要另外一個(gè)服務(wù)來(lái)實(shí)現(xiàn)，它就是kubectrld，直觀的講它就是包裝了kubectrl，實(shí)現(xiàn)了其中kubectl create/apply/get 等功能。

所有的K8s對(duì)象創(chuàng)建請(qǐng)求都會(huì)走cattle引擎，cattle會(huì)把請(qǐng)求代理到kubectrld啟動(dòng)的一個(gè)api服務(wù)。除此之外，還會(huì)監(jiān)聽Rancher events來(lái)輔助實(shí)現(xiàn)相關(guān)對(duì)象的CRUD。

K8s上創(chuàng)建的service如需對(duì)外暴露訪問(wèn)，那么必然會(huì)用到LoadBalancer Type和Ingress kind，注意K8s概念下的LoadBalancer和Ingress略有不同，LoadBalancer的功能主要關(guān)注在L4支持http/tcp，而Ingrees則是要實(shí)現(xiàn)L7的負(fù)載均衡且只能支持http。K8s 的LoadBalancer需要在K8s中實(shí)現(xiàn)一個(gè)Cloud Provider，目前只有GCE，而Rancher則維護(hù)了自己的K8s版本在其中提供了Rancher Cloud Provider。對(duì)于Ingress則是提供了Ingress-controller組件，它實(shí)現(xiàn)了K8s的ingress框架，可以獲取ingress的創(chuàng)建信息并執(zhí)行相應(yīng)的接口。當(dāng)然最終這兩者都會(huì)調(diào)用Cattle api來(lái)創(chuàng)建Rancher的負(fù)載均衡，且都是通過(guò)Haproxy完成負(fù)責(zé)均衡功能。

以目前K8s社區(qū)的火熱勢(shì)頭，Rancher應(yīng)該會(huì)持續(xù)跟進(jìn)并不斷更新功能優(yōu)化架構(gòu)，待到Rancher1.2發(fā)布之后，CNI的支持會(huì)是一個(gè)里程碑，到那時(shí)Kubernetes in Rancher也會(huì)更加成熟，一起向著最好用Kubernetes發(fā)行版大踏步的前進(jìn)。

原文來(lái)源：Rancher Labs