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支援L4、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、F5、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-controller，lb-controller在啟動時候會指定provider為rancher，對應的實現也可在package provider/rancher中看到。 建立Ingress後，也可在Rancher UI上展現出來。 建立過程，可以看我錄製這段影片教程，http://v.youku.com/v_show/id_XMTc2MDAzNjQ4OA==.html
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支援L4、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、F5、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-controller，lb-controller在啟動時候會指定provider為rancher，對應的實現也可在package provider/rancher中看到。 建立Ingress後，也可在Rancher UI上展現出來。 建立過程，可以看我錄製這段影片教程，http://v.youku.com/v_show/id_XMTc2MDAzNjQ4OA==.html