Kubernetes中擴容和可靠性的示例分析

這篇文章將為大家詳細講解有關Kubernetes中擴容和可靠性的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

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

如果pods是一個單元，部署和services是抽象層，那么誰來追蹤pods的健康狀況呢？

于是RC就這樣出場了。

在pods被部署之后，他們需要擴容，需要被追蹤。RC定義文件有pods數(shù)量的基線配置，這些pods在任何給定的點都是可得的。Kubernetes確保了需要的配置選項一直通過追蹤pods數(shù)量來維護。它會殺死一些pods，又或者是創(chuàng)建一些來滿足基線配置。

RC可以追蹤pods的健康狀況。如果一個pod變得難得到的，那么它就會被殺死，然后一些新的pod會被創(chuàng)建。因為一個RC實質(zhì)上就是繼承了pod的定義，YAML或者JSON清單可能包含重啟策略，容器調(diào)查和健康檢查端點的屬性。

Kubernetes支持基于CPU利用率的pod自動彈性擴容，跟EC2自動擴容或者GCE自動擴容有些相似。在運行的時候，RC可以被操作來自動擴容pods，基于特定的CPU利用率閾值。pods的數(shù)量的最大值和最小值也可以在同樣的命令下規(guī)定。

平網(wǎng)絡：秘密武器

網(wǎng)絡也是容器化過程中面臨的復雜挑戰(zhàn)之一。將一個容器暴露到外部世界的唯一方法就是通過主機的端口轉(zhuǎn)發(fā)。但是擴容容器的時候就會變得復雜。Kubernetes不是將網(wǎng)絡配置和集成留給管理員來做，而是自帶一個網(wǎng)絡模型，這個網(wǎng)絡模型十分易于使用。

每個節(jié)點，service，pod和容器都有一個IP地址。節(jié)點的IP地址由物理路由器分配；結合分配的端口，它會變成端點來訪問面向服務。雖然不是可路由的，但是Kubernetes服務也是可以獲取IP地址的。所有的通信都是在沒有NAT層的基礎上產(chǎn)生的，使得網(wǎng)絡平面化，透明化。

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

• 所有的容器不需要NAT也可以互相通信

• 所有的節(jié)點不需要NAT也可以跟所有的pods和集群中的容器通信

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

關于通過RS來擴容pods最好的一點就是，端口映射是由Kubernetes處理的。所有屬于service的pods都是通過相同的端口暴露到每個節(jié)點上的。即使沒有pod在特定的節(jié)點上調(diào)度，request也會自動轉(zhuǎn)發(fā)到合適的節(jié)點。

這個神奇的功能就是通過kube-proxy，iptables和etcd這些網(wǎng)絡代理的結合來實現(xiàn)的。當前集群的狀態(tài)就是用etcd來維護的，這也就意味著在運行的時候通過kube-proxy查詢。通過操作在每個節(jié)點上的iptables，kube-proxy將request退信到正確的目的地。

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

持久性：將狀態(tài)帶到容器

容器是短暫的。當他們從一個主機轉(zhuǎn)移到另一個主機的時候，他們不包含狀態(tài)。對于產(chǎn)品負載，持久是一個必須條件。任意有用的應用程序都有一個數(shù)據(jù)庫在背后支持它。

默認設置下，pods也是短暫的。他們每次復活的時候都從空白狀態(tài)開始。設置在同一個pod中運行的容器所共享的數(shù)據(jù)卷也是可以的。由emptyDir monilker確認，這個與Docker數(shù)據(jù)卷有點相似，在這里主機文件系統(tǒng)在容器內(nèi)被暴露為一個目錄。emptyDir數(shù)據(jù)卷追蹤pods的生命周期。當pod 被刪除的時候，數(shù)據(jù)卷也會被刪除掉。因為這些數(shù)據(jù)卷只符合主機的，所以他們在其它節(jié)點上不可用。

為了在pods上帶來持久性數(shù)據(jù)，不管他們在哪個節(jié)點上被調(diào)度，Kubernetes都支持PV和PVC requests。PVC和PV共享關系，就如同pod和節(jié)點一樣。當一個pod被創(chuàng)建的時候，它可以通過claim聯(lián)系到特定數(shù)據(jù)卷。PV可以基于各種各樣的插件，比如GCE持久性硬盤，亞馬遜彈性快存儲（EBS），網(wǎng)絡文件系統(tǒng)（NFS），小型計算機系統(tǒng)接口（ISCSI），GlusterFS和RBD。

設置持久化的工作流包括配置底層文件系統(tǒng)或者云數(shù)據(jù)卷，創(chuàng)建持久性數(shù)據(jù)卷，最后，創(chuàng)建claim來將pod跟數(shù)據(jù)卷關聯(lián)起來。這個解耦方法可以將pod和數(shù)據(jù)卷完全分離，或者pod不需要知道確切的文件系統(tǒng)或者支持它的持久性引擎。有些文件系統(tǒng)，比如GlusterFS，也可以被容器化，使得配置更加容易，便捷。

結論

容器已經(jīng)不是一個新型的概念了，谷歌數(shù)十年來都將它大部分網(wǎng)絡規(guī)模的工作負載都放在容器中運行。他們在這個過程中吸取教訓，并將這些教訓融入Kubernetes的建設中，這些經(jīng)驗教訓也可以被移植到其他的編排平臺中，也可以移植到其它的編排工具中。Kubernetes早在十年前就已經(jīng)解決了谷歌SRE面對的難題，這些正在影響著容器編排工具前進的道路。

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

關于“Kubernetes中擴容和可靠性的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。