摘要：中暴露服務(wù)訪問(wèn)自己實(shí)現(xiàn)了一個(gè)，它本質(zhì)上是包裝了，在真正創(chuàng)建負(fù)載均衡器上它會(huì)調(diào)用來(lái)創(chuàng)建自身的。

最近的一年，kubernetes的發(fā)展如此閃耀，正被越來(lái)越多的公司采納用于生產(chǎn)環(huán)境的實(shí)踐。同時(shí)，我們可以在最著名的開發(fā)者問(wèn)答社區(qū)StackOverflow上看到k8s的問(wèn)題數(shù)量的增長(zhǎng)曲線（2015.5-2016.5），開發(fā)者是用腳投票的，從這一點(diǎn)看也無(wú)疑證明了k8s的火爆程度。

k8s來(lái)源于Google生產(chǎn)環(huán)境的實(shí)踐，社區(qū)活躍度很高，在github上的Star數(shù)17k+，30k+commits，同時(shí)由Google主導(dǎo)CNCF基金會(huì)也在強(qiáng)力運(yùn)作k8s的社區(qū)發(fā)展，也就在幾個(gè)月前OpenStack社區(qū)宣布全面擁抱k8s，這也宣布了全球第大的開源IAAS云社區(qū)已經(jīng)選擇k8s作為容器的唯一解決方案。

談到k8s，無(wú)論怎樣的議題怎樣的開始，我們都先介紹一個(gè)k8s整體架構(gòu)（如下圖所示）：

etcd 作為配置中心和存儲(chǔ)服務(wù)，保存了所有組件的定義以及狀態(tài)，k8s的多個(gè)組件之間的互相交互也主要通過(guò)etcd；

kube-apiserver 提供和外部交互的接口，提供安全機(jī)制，大多數(shù)接口都是直接讀寫etcd中的數(shù)據(jù)；

kube-scheduler 調(diào)度器，主要干一件事情，監(jiān)聽etcd中的pod目錄變更，然后通過(guò)調(diào)度算法分配node，最后調(diào)用apiserver的bind接口將分配的node和pod進(jìn)行關(guān)聯(lián)；

kube-controller-manager 承擔(dān)了master的主要功能，比如和CloudProvider(IaaS)交互，管理node，pod，replication，service，namespace等。

基本機(jī)制是監(jiān)聽etcd /registry/events下對(duì)應(yīng)的事件，進(jìn)行處理；kubelet 主要包含容器管理，鏡像管理，Volume管理等；kube-proxy 主要用于實(shí)現(xiàn)k8s的service機(jī)制。提供一部分SDN功能以及集群內(nèi)部的智能LoadBalancer。

本文分享的內(nèi)容主要是在minion節(jié)點(diǎn)上的pod和service上，pod是k8s應(yīng)用的具體實(shí)例抽象，而service便是這些抽象的集合。

回到本文的主題，在k8s中暴露Service訪問(wèn)（無(wú)論內(nèi)部還是外部），都要經(jīng)過(guò)kube-proxy，比如下圖中我們定義一個(gè)Service，便可以通過(guò)訪問(wèn)Service的80端口轉(zhuǎn)發(fā)到Pod的9376端口上。

kube-proxy在轉(zhuǎn)發(fā)時(shí)主要有兩種模式Userspace和Iptables。如下圖，左側(cè)是Userspace模式，也是kube-proxy默認(rèn)的方式，所有的轉(zhuǎn)發(fā)都是通過(guò)kube-proxy軟件實(shí)現(xiàn)的；右側(cè)是Iptables模式，所有轉(zhuǎn)發(fā)都是通過(guò)Iptables內(nèi)核模塊實(shí)現(xiàn)，而kube-proxy只負(fù)責(zé)生成相應(yīng)的Iptables規(guī)則。從效率上看，Iptables會(huì)更高一些，但是需要Iptables version >=1.4.11，Iptables模式在k8s1.2版本放出，是否開啟使用還需要具體斟酌。

從Service本身看，有三種方式來(lái)暴露訪問(wèn)：

ClusterIP：使用集群內(nèi)的私有ip —— 這是默認(rèn)值

NodePort：除了使用cluster ip外，也將service的port映射到每個(gè)node的一個(gè)指定內(nèi)部port上，映射的每個(gè)node的內(nèi)部port都一樣。

LoadBalancer：使用一個(gè)ClusterIP & NodePort，但是會(huì)向cloud provider申請(qǐng)映射到service本身的負(fù)載均衡。

LoadBalancer Provider主要有aws、azure、openstack、gce等云平臺(tái)提供。相關(guān)實(shí)現(xiàn)可以在k8s的源碼中看到，如下圖所示：

Ingress也是k8s中多帶帶定義的對(duì)象（如下圖所示），它的作用就是實(shí)現(xiàn)對(duì)外暴露訪問(wèn)的負(fù)載均衡，那么它和Service本身LoadBalancer有哪些區(qū)別呢？Ingress支持L4、L7負(fù)載均衡，LoadBalancer設(shè)計(jì)上只支持L4；Ingress基于Pod部署，并將Pod網(wǎng)絡(luò)設(shè)置成external network；Ingress controller支持Nginx、Haproxy、GCE-L7，能夠滿足企業(yè)內(nèi)部使用。

在實(shí)際使用時(shí)，Ingress的架構(gòu)如下圖所示：

但是在實(shí)際使用中，pod可能會(huì)產(chǎn)生漂移，由于Ingress Controller也是基于Pod部署，這樣Ingress對(duì)外的IP會(huì)發(fā)生變化。在企業(yè)內(nèi)部都會(huì)在防火墻上給Service的訪問(wèn)IP設(shè)定規(guī)則，而IP變動(dòng)對(duì)這一機(jī)制是致命的，因?yàn)槠髽I(yè)不可能經(jīng)常手動(dòng)修改防火墻規(guī)則。

那么我們就需要一個(gè)VIP功能，同時(shí)也要能保證Ingress的HA。我們可以考慮在Ingress Controller基礎(chǔ)上增加一個(gè)keepalived，可以利用keepalived＋haproxy的機(jī)制來(lái)完成VIP的功能。要實(shí)現(xiàn)這一機(jī)制，可以參考并改動(dòng)k8s社區(qū)中的contrib-keepalived-vip機(jī)制。

除了以上介紹的暴露服務(wù)機(jī)制，還有Hpcloud-service-loadbalancer ，它實(shí)現(xiàn)了支持keepalived+nginx、F5、OpenStack Lbaas這些方式，并且支持L4 & L7負(fù)載均衡，但是與k8s社區(qū)本身的發(fā)展機(jī)制并不兼容，所以一直沒有被合并到社區(qū)中。另外還有 Contrib-service-loadbalancer ，這個(gè)是社區(qū)內(nèi)部正在發(fā)展的，它的想法更遠(yuǎn)大，考慮會(huì)支持Cross-namespace、 Cross-cluster這種級(jí)別的負(fù)載均衡，同時(shí)也是設(shè)計(jì)了插件機(jī)制，目前支持Haproxy，同樣也支持L4 & L7負(fù)載均衡。

Rancher自己實(shí)現(xiàn)了一個(gè)rancher-ingress-controller，它本質(zhì)上是包裝了k8s-ingress-controller，在真正創(chuàng)建負(fù)載均衡器上它會(huì)調(diào)用Rancher Cattle API來(lái)創(chuàng)建Rancher自身的LB。

相關(guān)代碼也是開源的，https://github.com/rancher/lb...，lb-controller在啟動(dòng)時(shí)候會(huì)指定provider為rancher，對(duì)應(yīng)的實(shí)現(xiàn)也可在package provider/rancher中看到。

創(chuàng)建Ingress后，也可在Rancher UI上展現(xiàn)出來(lái)。

創(chuàng)建過(guò)程，可以看我錄制這段視頻教程，http://v.youku.com/v_show/id_...