如何在Kubernetes中暴露服務訪問

Kubernetes概述

最近的一年，kubernetes的發展如此閃耀，正被愈來愈多的公司採納用於生產環境的實踐。同時，咱們能夠在最著名的開發者問答社區StackOverflow上看到k8s的問題數量的增加曲線（2015.5-2016.5），開發者是用腳投票的，從這一點看也無疑證實了k8s的火爆程度。

k8s來源於Google生產環境的實踐，社區活躍度很高，在github上的Star數17k+，30k+commits，同時由Google主導CNCF基金會也在強力運做k8s的社區發展，也就在幾個月前OpenStack社區宣佈全面擁抱k8s，這也宣佈了全球第大的開源IAAS雲社區已經選擇k8s做爲容器的惟一解決方案。

談到k8s，不管怎樣的議題怎樣的開始，咱們都先介紹一個k8s總體架構（以下圖所示）：

etcd 做爲配置中心和存儲服務，保存了全部組件的定義以及狀態，k8s的多個組件之間的互相交互也主要經過etcd；

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

kube-scheduler 調度器，主要幹一件事情，監聽etcd中的pod目錄變動，而後經過調度算法分配node，最後調用apiserver的bind接口將分配的node和pod進行關聯；

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

基本機制是監聽etcd /registry/events下對應的事件，進行處理；kubelet 主要包含容器管理，鏡像管理，Volume管理等；kube-proxy 主要用於實現k8s的service機制。提供一部分SDN功能以及集羣內部的智能LoadBalancer。

本文分享的內容主要是在minion節點上的pod和service上，pod是k8s應用的具體實例抽象，而service即是這些抽象的集合。

ClusterIP & NodePort & Loadbalancer

回到本文的主題，在k8s中暴露Service訪問（不管內部仍是外部），都要通過kube-proxy，好比下圖中咱們定義一個Service，即可以經過訪問Service的80端口轉發到Pod的9376端口上。

kube-proxy在轉發時主要有兩種模式Userspace和Iptables。以下圖，左側是Userspace模式，也是kube-proxy默認的方式，全部的轉發都是經過kube-proxy軟件實現的；右側是Iptables模式，全部轉發都是經過Iptables內核模塊實現，而kube-proxy只負責生成相應的Iptables規則。從效率上看，Iptables會更高一些，可是須要Iptables version >=1.4.11，Iptables模式在k8s1.2版本放出，是否開啓使用還須要具體斟酌。

從Service自己看，有三種方式來暴露訪問：

• ClusterIP：使用集羣內的私有ip —— 這是默認值

• NodePort：除了使用cluster ip外，也將service的port映射到每一個node的一個指定內部port上，映射的每一個node的內部port都同樣。

• LoadBalancer：使用一個ClusterIP & NodePort，可是會向cloud provider申請映射到service自己的負載均衡。

LoadBalancer Provider主要有aws、azure、openstack、gce等雲平臺提供。相關實現能夠在k8s的源碼中看到，以下圖所示：

Ingress

Ingress也是k8s中單獨定義的對象（以下圖所示），它的做用就是實現對外暴露訪問的負載均衡，那麼它和Service自己LoadBalancer有哪些區別呢？Ingress支持L四、L7負載均衡，LoadBalancer設計上只支持L4；Ingress基於Pod部署，並將Pod網絡設置成external network；Ingress controller支持Nginx、Haproxy、GCE-L7，可以知足企業內部使用。

在實際使用時，Ingress的架構以下圖所示：

可是在實際使用中，pod可能會產生漂移，因爲Ingress Controller也是基於Pod部署，這樣Ingress對外的IP會發生變化。在企業內部都會在防火牆上給Service的訪問IP設定規則，而IP變更對這一機制是致命的，由於企業不可能常常手動修改防火牆規則。

那麼咱們就須要一個VIP功能，同時也要能保證Ingress的HA。咱們能夠考慮在Ingress Controller基礎上增長一個keepalived，能夠利用keepalived＋haproxy的機制來完成VIP的功能。要實現這一機制，能夠參考並改動k8s社區中的contrib-keepalived-vip機制。

除了以上介紹的暴露服務機制，還有Hpcloud-service-loadbalancer ，它實現了支持keepalived+nginx、F五、OpenStack Lbaas這些方式，而且支持L4 & L7負載均衡，可是與k8s社區自己的發展機制並不兼容，因此一直沒有被合併到社區中。另外還有 Contrib-service-loadbalancer ，這個是社區內部正在發展的，它的想法更遠大，考慮會支持Cross-namespace、 Cross-cluster這種級別的負載均衡，同時也是設計了插件機制，目前支持Haproxy，一樣也支持L4 & L7負載均衡。

Rancher K8s中暴露服務訪問

Rancher本身實現了一個rancher-ingress-controller，它本質上是包裝了k8s-ingress-controller，在真正建立負載均衡器上它會調用Rancher Cattle API來建立Rancher自身的LB。

相關代碼也是開源的，https://github.com/rancher/lb...，lb-controller在啓動時候會指定provider爲rancher，對應的實現也可在package provider/rancher中看到。

建立Ingress後，也可在Rancher UI上展示出來。

建立過程，能夠看我錄製這段視頻教程，http://v.youku.com/v_show/id_...