Rainbond中怎么使用StatefulSet部署應用

這期內容當中小編將會給大家帶來有關Rainbond中怎么使用StatefulSet部署應用，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

組件部署類型

通過在服務組件的其他設置中，更改 組件部署類型 即可選擇使用 StatefulSet 資源類型部署服務，操作之前要注意以下幾點：

• 組件需要處于關閉的狀態；

• 對于有持久化存儲的服務組件，切換組件部署類型會導致存儲掛載的變更，一定要做好數據備份；

Rainbond 默認提供四種組件部署類型：

• 有狀態單實例：使用 StatefulSet 部署服務，不可以進行實例的橫向伸縮，實例數量始終為1；

• 有狀態多實例：使用 StatefulSet 部署服務，實例數量可以進行橫向伸縮；

• 無狀態單實例：使用 Deployment 部署服務，不可以進行實例的橫向伸縮，實例數量始終為1；

• 無狀態多實例：使用 Deployment 部署服務，實例數量可以進行橫向伸縮；

當你在 Rainbond 中將組件部署類型指定為有狀態 （StatefulSet） 之后，服務組件將體現以下特性：

• 多實例狀態下，所有實例將具備順序性，實例的命名將類似于 gr6ec114-0 gr6ec114-1 ，這一順序性將體現為全生命周期的層面，順序的啟動、更新、重啟、關閉。

• 上述的主機名在集群中將可以被解析，同團隊下，嘗試在任意 POD 中執行nslookup gr6ec114-0。不同團隊下，需要指定命名空間，可解析地址的完全地址為：gr6ec114-0.gr6ec114.3be96e95700a480c9b37c6ef5daf3566.svc.cluster.local 其中 3be96e95700a480c9b37c6ef5daf3566 為命名空間。

• 多實例狀態下，每個實例的持久化存儲將被單獨掛載，這意味著持久化數據在實例之間不再共享。

• 單實例狀態下，執行更新操作時，實例將會在完全關閉之后，啟動新的實例，這意味著服務會出現中斷。

• 出于對持久化數據一致性的保護，運行了有狀態服務的 k8s 節點一旦失去和管理節點的聯絡，處于 notready 狀態時，其有狀態服務的實例不會自動遷移。

整體來看，利用 StatefulSet 資源類型來部署服務，帶來了新的特性的同時，會顯得呆板了一些，但接下來的探討，會發現這些限制是有意義的。

細心如你一定會發現，我們將 StatefulSet 這種資源類型和 “有狀態” 綁定在了一起。那么，一個新的問題冒了出來：什么是服務的 “狀態”。

服務的“狀態”

有狀態（Stateful）服務 = 無狀態（Stateless）的應用程序 + 有狀態的數據

從有狀態服務的名字就可以看出， 它和 StatefulSet 這種資源類型是有關聯的。

單純說概念，可能很難理解什么是有狀態服務。讓我來舉幾個例子：

• 最常見的有狀態服務，就是DB類的數據庫中間件。

對于常見數據庫 Mysql 而言，同一份數據，在同一時刻只可以被一個 Mysql 程序使用。Mysql 在啟動后，會在自己的數據目錄下生成唯一的鎖文件，并把這個文件“鎖死”。這樣一來，其他想要使用這份數據的 Mysql 程序，會因為發現這個鎖文件被“鎖死”，而中斷啟動的過程。這樣做的好處，是保證了數據的強一致性，因為同一份數據在同一時刻，絕對只會被同一個 Mysql 應用程序所讀寫。

請回憶下 StatefulSet 資源類型帶來的特性之一就是每個實例都會掛載獨立的持久化存儲，這樣可以確保 Mysql 服務可以被擴展成多個實例運行起來，不會因為鎖文件的原因被終止啟動，但是因為彼此之間數據不共享，所以本質上實例之間沒有什么關系。使用有狀態單實例的方式運行 Mysql 看起來是最正確的選擇。

情況類似的常見數據庫中間件還有 Mongo、Postgresql、Redis、Etcd等。

• 另一種常見的有狀態服務場景，是 Web 類的服務提供的粘性 Session。

這種粘性 Session 在某些情況下會保存在內存中，用來提供會話保持，本身也是一種數據。一旦將這種服務擴展多個實例，一旦訪問到不正確的實例，那么就會因為找不到 Session 而丟失登陸態。在負載均衡中使用 IP Hash 算法進行流量的分發可以在某種程度上解決這個問題，來自同個 IP 的流量會被分發到指定的實例。但是我們更希望流量的分發是輪詢的，這樣可以確保每個實例的負載都是相近的，不會出現某個實例負載過高，而其他實例無所事事的情況。

這兩種有狀態服務場景，都向我們指出，對有狀態服務而言，不同實例的數據是相互獨立的。數據即“狀態”。

相比較而言，無狀態的服務就靈活很多。它們沒有持久化數據，或者持久化數據支持共享。對于客戶端而言，請求哪一個實例獲得的返回都是一致的。這樣的特性意味著可以隨意擴展無狀態服務的實例數量，靈活的應對流量。

使用云服務最大的好處之一，就是它提供的彈性和靈活性，在業務遭遇流量高峰時，可以快速擴展實例進行應對。從這個角度出發，我們希望服務都是 “無狀態” 的。那么，一個新的問題冒了出來：我們可以去掉服務的 “狀態”，使之變成無狀態服務么？

處理服務的 “狀態”

利用粘性 Session 保持登陸態的這類 Web 服務，其狀態是可以被去掉的。

原理比較簡單，把 Session 和 Web 應用程序剝離，存儲到其他中間件中去即可，比如保存到Mysql、 Redis、Memcached等數據庫中間件中去。市面上常見的 Web 框架都會支持這種功能，甚至把這種處理方式作為默認選項，因為這實在太棒了！

處理完的 Web 服務，就變成了無狀態服務，可以任意擴展實例數量了。來自客戶端的請求無論被分配到哪一個實例，其登陸態都到后端數據庫中調取，返回正確的登陸態。在部署時，可以選擇無狀態多實例進行部署，即使用 Deployment 這種資源類型。

但是對于DB類的數據庫中間件而言，其狀態是不可以被隨意去除的。

原因在于這類數據庫中間件使用自己的機制來確保數據強一致性，就比如 Mysql 的鎖文件機制，指定的實例只能去讀寫對應自己的那一份數據。對這一類有狀態服務而言，每個實例獨享一份持久化數據可以算作是必須的條件。并且隨意擴展實例數量，會遭遇很多致命的問題：比如數據不一致，或者程序運行失敗等等。這一類的有狀態服務只能單點部署嗎？

這些數據庫中間件的出品廠商或者社區，也都很關注如何實現高可用方案，來解決上述的問題。甚至近些年推出的數據庫中間件，在設計階段就會被設計成分布式架構。比如 Etcd 對自己的定義就是：可靠的強一致性分布式鍵值數據庫。其內部使用 Raft 協議進行實例間選舉來明確統一的leader。而對于 Mysql 這樣比較老牌的數據庫中間件，也具備基于 Binlog 復制實現的主從集群方案。

所以針對這一類無法去除狀態的服務而言，我們的思路與宗旨，就是遵循其自身支持的集群方案，來實現高可用以及實例數量擴展。

實際部署這些集群方案時，可以總結出，大多數集群方案需要滿足以下條件：

• 每個實例掛載單獨的持久化數據；

• 實例間需要獲取彼此的通信地址，來進行選舉或者數據同步等動作，比如可解析的主機名或域名。獲取地址時一定要使用主機名或域名而非實例 IP，因為隨著實例的重啟，主機名或域名不會改變，但是IP可能會改變，這很重要；

• 實例數量是有要求的，一般情況下選擇 3、5、7··· 等奇數，來保證集群不會出現腦裂；

回想一下 StatefulSet 資源類型的特性，它可以滿足上述的所有條件，就是為了有狀態服務而生的。所以這一類有狀態服務，其組件部署類型無論如何要使用有狀態單/多實例。

Rainbond 云原生應用管理平臺，實現微服務架構不用改代碼，管理 Kubernetes 不用學容器，幫企業實現應用上云，一站式將任何企業應用持續交付到 Kubernetes 集群、混合云、多云等基礎設施。是 Rainstore 云原生應用商店的支撐平臺。

1. Rainbond 官網

2. Rainbond 安裝使用

3. Rainbond 參考手冊全集

上述就是小編為大家分享的Rainbond中怎么使用StatefulSet部署應用了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。