k8s in Rancher架構分析

在Rancher 1.0版本開始，Rancher逐步增加了Kubernetes、Swarm、Mesos等多編排引擎的支持，很多朋友就此產生了疑惑，諸如Cattle引擎和這幾個之間到底什么關系？每種引擎是如何支持的？自家的業務環境如何選型？我們將逐步揭開這些神秘面紗，了解基礎架構才能在遇到問題時進行有效的分析，進而準確的定位問題并解決問題，因為沒有一種生產環境是完全可靠的。基于這個背景下，這次我們首先向大家介紹kubernetes in Rancher的架構。

從現在Rancher的發展節奏來看，Cattle引擎已經被定義成Rancher的基礎設施引擎，而Rancher的基礎設施服務都包括哪些呢？如下：

• Networking，Rancher的統一網絡服務，由rancher-net組件提供
• Load Balancer，Rancher的負載均衡服務，目前來看套路基本上是基于Haproxy來構建
• DNS Service，Rancher的DNS服務，主要是為了提供服務發現能力，由Rancher-DNS組件來提供
• Metadata Service，Rancher的元數據服務，Metadata是我們通過- compose編排應用時的利器，可以很靈活的像service中注入特定信息
• Persistent Storage Service，持久化存儲服務目前是由convoy來提供，而對于真正的后端存儲的實現Rancher還有longhorn沒有完全放出
• Audit Logging，審計日志服務是企業場景中比較重要的一個屬性，目前是集成在Cattle內部沒有被完全分離出來

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

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

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

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

K8s集群完成部署后，我們就可以在其中添加各種應用服務，目前Rancher支持管理K8s的service、pod、replication-controller等，我們可以用一張圖來形象得描述一下應用視圖結構。

rancher-net組件會給每個pod分配一個IP，Rancher-DNS則替代了K8s的Skydns來實現服務發現，在pod的容器內部依然可以訪問Rancher-metadata服務來獲取元數據信息。除了這三個基礎服務外，我們之前提到的kuberctrld、ingress-controller、kubernetes-agent也在其中扮演者重要角色。

無論是K8s還是Rancher，其中一些抽象對象（如Rancher的stack/service，或者K8s的serivice/pod）在屬性更新時都會有events產生，在任何服務入口來更改這些抽象對象都會有events產生，所以要保證Rancher和k8s能夠互相感知各自對象的更新，那么kubernetes-agent就應運而生了。

諸如K8s的namespaces、services、replicationcontrollers、pods等對象的信息變更會及時通知給Rancher，而Cattle管理的Host資源出現信息變更（諸如host label的變動）也會通知給K8s。

簡單得說kubernetes-agent是為了維護Rancher和K8s之間的對象一致性，而真正要通過Rancher來創建K8s中的service或者pod之類的對象，還需要另外一個服務來實現，它就是kubectrld，直觀的講它就是包裝了kubectrl，實現了其中kubectl create/apply/get 等功能。

所有的K8s對象創建請求都會走cattle引擎，cattle會把請求代理到kubectrld啟動的一個api服務。除此之外，還會監聽Rancher events來輔助實現相關對象的CRUD。

K8s上創建的service如需對外暴露訪問，那么必然會用到LoadBalancer Type和Ingress kind，注意K8s概念下的LoadBalancer和Ingress略有不同，LoadBalancer的功能主要關注在L4支持http/tcp，而Ingrees則是要實現L7的負載均衡且只能支持http。K8s 的LoadBalancer需要在K8s中實現一個Cloud Provider，目前只有GCE，而Rancher則維護了自己的K8s版本在其中提供了Rancher Cloud Provider。對于Ingress則是提供了Ingress-controller組件，它實現了K8s的ingress框架，可以獲取ingress的創建信息并執行相應的接口。當然最終這兩者都會調用Cattle api來創建Rancher的負載均衡，且都是通過Haproxy完成負責均衡功能。

以目前K8s社區的火熱勢頭，Rancher應該會持續跟進并不斷更新功能優化架構，待到Rancher1.2發布之后，CNI的支持會是一個里程碑，到那時Kubernetes in Rancher也會更加成熟，一起向著最好用Kubernetes發行版大踏步的前進。

來自：http://dockone.io/article/2006