Kubernetes方法論：擴容和可靠性

在第一篇文章裏，咱們探索了在Kubernetes中pods和services的概念。如今，咱們來理解一下如何用RC來完成彈性擴容以及可靠性。咱們也會討論一下如何將持久化帶入佈置在Kubernetes上的雲本地應用程序。

RC：彈性擴容和管理微服務

若是pods是一個單元，部署和services是抽象層，那麼誰來追蹤pods的健康情況呢？
因而RC就這樣出場了。

在pods被部署以後，他們須要擴容，須要被追蹤。RC定義文件有pods數量的基線配置，這些pods在任何給定的點都是可得的。Kubernetes確保了須要的配置選項一直經過追蹤pods數量來維護。它會殺死一些pods，又或者是建立一些來知足基線配置。

RC能夠追蹤pods的健康情況。若是一個pod變得可貴到的，那麼它就會被殺死，而後一些新的pod會被建立。由於一個RC實質上就是繼承了pod的定義，YAML或者JSON清單可能包含重啓策略，容器調查和健康檢查端點的屬性。

Kubernetes支持基於CPU利用率的pod自動彈性擴容，跟EC2自動擴容或者GCE自動擴容有些類似。在運行的時候，RC能夠被操做來自動擴容pods，基於特定的CPU利用率閾值。pods的數量的最大值和最小值也能夠在一樣的命令下規定。

平網絡：祕密武器

網絡也是容器化過程當中面臨的複雜挑戰之一。將一個容器暴露到外部世界的惟一方法就是經過主機的端口轉發。可是擴容容器的時候就會變得複雜。Kubernetes不是將網絡配置和集成留給管理員來作，而是自帶一個網絡模型，這個網絡模型十分易於使用。

每一個節點，service，pod和容器都有一個IP地址。節點的IP地址由物理路由器分配；結合分配的端口，它會變成端點來訪問面向服務。雖然不是可路由的，可是Kubernetes服務也是能夠獲取IP地址的。全部的通訊都是在沒有NAT層的基礎上產生的，使得網絡平面化，透明化。

這個模型會帶來一些好處：

• 全部的容器不須要NAT也能夠互相通訊

• 全部的節點不須要NAT也能夠跟全部的pods和集羣中的容器通訊

• 每一個容器跟其餘容器同樣看到的都是相同的IP地址

關於經過RS來擴容pods最好的一點就是，端口映射是由Kubernetes處理的。全部屬於service的pods都是經過相同的端口暴露到每一個節點上的。即便沒有pod在特定的節點上調度，request也會自動轉發到合適的節點。

這個神奇的功能就是經過kube-proxy，iptables和etcd這些網絡代理的結合來實現的。當前集羣的狀態就是用etcd來維護的，這也就意味着在運行的時候經過kube-proxy查詢。經過操做在每一個節點上的iptables，kube-proxy將request退信到正確的目的地。

Kube-proxy一樣也處理services的基礎負載均衡。Service端點也是用Docker links經過環境變量來管理。這些變量分解到端口，端口經過service暴露到外面。Kubernetes1.1包括了一個來使用本地iptables的選項，這個選項會帶來80%的延遲。這個設計消除了CPU開銷，所以提高了效率，也提高了可拓展性。

持久性：將狀態帶到容器

容器是短暫的。當他們從一個主機轉移到另外一個主機的時候，他們不包含狀態。對於產品負載，持久是一個必須條件。任意有用的應用程序都有一個數據庫在背後支持它。
默認設置下，pods也是短暫的。他們每次復活的時候都從空白狀態開始。設置在同一個pod中運行的容器所共享的數據卷也是能夠的。由emptyDir monilker確認，這個與Docker數據卷有點類似，在這裏主機文件系統在容器內被暴露爲一個目錄。emptyDir數據卷追蹤pods的生命週期。當pod 被刪除的時候，數據卷也會被刪除掉。由於這些數據卷只符合主機的，因此他們在其它節點上不可用。

爲了在pods上帶來持久性數據，無論他們在哪一個節點上被調度，Kubernetes都支持PV和PVC requests。PVC和PV共享關係，就如同pod和節點同樣。當一個pod被建立的時候，它能夠經過claim聯繫到特定數據卷。PV能夠基於各類各樣的插件，好比GCE持久性硬盤，亞馬遜彈性快存儲（EBS），網絡文件系統（NFS），小型計算機系統接口（ISCSI），GlusterFS和RBD。

設置持久化的工做流包括配置底層文件系統或者雲數據卷，建立持久性數據卷，最後，建立claim來將pod跟數據卷關聯起來。這個解耦方法能夠將pod和數據卷徹底分離，或者pod不須要知道確切的文件系統或者支持它的持久性引擎。有些文件系統，好比GlusterFS，也能夠被容器化，使得配置更加容易，便捷。

結論

容器已經不是一個新型的概念了，谷歌數十年來都將它大部分網絡規模的工做負載都放在容器中運行。他們在這個過程當中吸收教訓，並將這些教訓融入Kubernetes的建設中，這些經驗教訓也能夠被移植到其餘的編排平臺中，也能夠移植到其它的編排工具中。Kubernetes早在十年前就已經解決了谷歌SRE面對的難題，這些正在影響着容器編排工具前進的道路。

最重要的是，Kubernetes在容器生態圈已是一個焦點，對於其它相關服務，它的存在就好像是一個有價值的開源平臺。理解Kubernetes目前的角色和做用對於編排工具市場是十分有必要的。