共計 2253 個字符，預計需要花費 6 分鐘才能閱讀完成。

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

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 目前的角色和作用對于編排工具市場是十分有必要的。

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