前言

對(duì)于kubernetes老玩家而言，StatefulSet這種資源類型并不陌生。對(duì)于很多有狀態(tài)服務(wù)而言，都可以使用 StatefulSet 這種資源類型來部署。那么問題來了：挖掘機(jī)技術(shù)哪家強(qiáng)？額，不對(duì)。

如何在 Rainbond 使用 StatefulSet 資源類型來部署服務(wù)呢？

組件部署類型

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

• 組件需要處于關(guān)閉的狀態(tài)；
• 對(duì)于有持久化存儲(chǔ)的服務(wù)組件，切換組件部署類型會(huì)導(dǎo)致存儲(chǔ)掛載的變更，一定要做好數(shù)據(jù)備份；

Rainbond 默認(rèn)提供四種組件部署類型：

• 有狀態(tài)單實(shí)例：使用 StatefulSet 部署服務(wù)，不可以進(jìn)行實(shí)例的橫向伸縮，實(shí)例數(shù)量始終為1；
• 有狀態(tài)多實(shí)例：使用 StatefulSet 部署服務(wù)，實(shí)例數(shù)量可以進(jìn)行橫向伸縮；
• 無狀態(tài)單實(shí)例：使用 Deployment 部署服務(wù)，不可以進(jìn)行實(shí)例的橫向伸縮，實(shí)例數(shù)量始終為1；
• 無狀態(tài)多實(shí)例：使用 Deployment 部署服務(wù)，實(shí)例數(shù)量可以進(jìn)行橫向伸縮；

當(dāng)你在 Rainbond 中將組件部署類型指定為有狀態(tài) （StatefulSet） 之后，服務(wù)組件將體現(xiàn)以下特性：

• 多實(shí)例狀態(tài)下，所有實(shí)例將具備順序性，實(shí)例的命名將類似于 gr6ec114-0 gr6ec114-1 ，這一順序性將體現(xiàn)為全生命周期的層面，順序的啟動(dòng)、更新、重啟、關(guān)閉。
• 上述的主機(jī)名在集群中將可以被解析，同團(tuán)隊(duì)下，嘗試在任意 POD 中執(zhí)行nslookup gr6ec114-0。不同團(tuán)隊(duì)下，需要指定命名空間，可解析地址的完全地址為：gr6ec114-0.gr6ec114.3be96e95700a480c9b37c6ef5daf3566.svc.cluster.local 其中 3be96e95700a480c9b37c6ef5daf3566 為命名空間。
• 多實(shí)例狀態(tài)下，每個(gè)實(shí)例的持久化存儲(chǔ)將被單獨(dú)掛載，這意味著持久化數(shù)據(jù)在實(shí)例之間不再共享。
• 單實(shí)例狀態(tài)下，執(zhí)行更新操作時(shí)，實(shí)例將會(huì)在完全關(guān)閉之后，啟動(dòng)新的實(shí)例，這意味著服務(wù)會(huì)出現(xiàn)中斷。
• 出于對(duì)持久化數(shù)據(jù)一致性的保護(hù)，運(yùn)行了有狀態(tài)服務(wù)的 k8s 節(jié)點(diǎn)一旦失去和管理節(jié)點(diǎn)的聯(lián)絡(luò)，處于 notready 狀態(tài)時(shí)，其有狀態(tài)服務(wù)的實(shí)例不會(huì)自動(dòng)遷移。

整體來看，利用 StatefulSet 資源類型來部署服務(wù)，帶來了新的特性的同時(shí)，會(huì)顯得呆板了一些，但接下來的探討，會(huì)發(fā)現(xiàn)這些限制是有意義的。

細(xì)心如你一定會(huì)發(fā)現(xiàn)，我們將 StatefulSet 這種資源類型和 “有狀態(tài)” 綁定在了一起。那么，一個(gè)新的問題冒了出來：什么是服務(wù)的 “狀態(tài)”。

服務(wù)的“狀態(tài)”

有狀態(tài)（Stateful）服務(wù) = 無狀態(tài)（Stateless）的應(yīng)用程序 + 有狀態(tài)的數(shù)據(jù)

從有狀態(tài)服務(wù)的名字就可以看出， 它和 StatefulSet 這種資源類型是有關(guān)聯(lián)的。

單純說概念，可能很難理解什么是有狀態(tài)服務(wù)。讓我來舉幾個(gè)例子：

• 最常見的有狀態(tài)服務(wù)，就是DB類的數(shù)據(jù)庫(kù)中間件。

對(duì)于常見數(shù)據(jù)庫(kù) Mysql 而言，同一份數(shù)據(jù)，在同一時(shí)刻只可以被一個(gè) Mysql 程序使用。Mysql 在啟動(dòng)后，會(huì)在自己的數(shù)據(jù)目錄下生成唯一的鎖文件，并把這個(gè)文件“鎖死”。這樣一來，其他想要使用這份數(shù)據(jù)的 Mysql 程序，會(huì)因?yàn)榘l(fā)現(xiàn)這個(gè)鎖文件被“鎖死”，而中斷啟動(dòng)的過程。這樣做的好處，是保證了數(shù)據(jù)的強(qiáng)一致性，因?yàn)橥环輸?shù)據(jù)在同一時(shí)刻，絕對(duì)只會(huì)被同一個(gè) Mysql 應(yīng)用程序所讀寫。

請(qǐng)回憶下 StatefulSet 資源類型帶來的特性之一就是每個(gè)實(shí)例都會(huì)掛載獨(dú)立的持久化存儲(chǔ)，這樣可以確保 Mysql 服務(wù)可以被擴(kuò)展成多個(gè)實(shí)例運(yùn)行起來，不會(huì)因?yàn)殒i文件的原因被終止啟動(dòng)，但是因?yàn)楸舜酥g數(shù)據(jù)不共享，所以本質(zhì)上實(shí)例之間沒有什么關(guān)系。使用有狀態(tài)單實(shí)例的方式運(yùn)行 Mysql 看起來是最正確的選擇。

情況類似的常見數(shù)據(jù)庫(kù)中間件還有 Mongo、Postgresql、Redis、Etcd等。

• 另一種常見的有狀態(tài)服務(wù)場(chǎng)景，是 Web 類的服務(wù)提供的粘性 Session。

這種粘性 Session 在某些情況下會(huì)保存在內(nèi)存中，用來提供會(huì)話保持，本身也是一種數(shù)據(jù)。一旦將這種服務(wù)擴(kuò)展多個(gè)實(shí)例，一旦訪問到不正確的實(shí)例，那么就會(huì)因?yàn)檎也坏?nbsp;Session 而丟失登陸態(tài)。在負(fù)載均衡中使用 IP Hash 算法進(jìn)行流量的分發(fā)可以在某種程度上解決這個(gè)問題，來自同個(gè) IP 的流量會(huì)被分發(fā)到指定的實(shí)例。但是我們更希望流量的分發(fā)是輪詢的，這樣可以確保每個(gè)實(shí)例的負(fù)載都是相近的，不會(huì)出現(xiàn)某個(gè)實(shí)例負(fù)載過高，而其他實(shí)例無所事事的情況。

這兩種有狀態(tài)服務(wù)場(chǎng)景，都向我們指出，對(duì)有狀態(tài)服務(wù)而言，不同實(shí)例的數(shù)據(jù)是相互獨(dú)立的。數(shù)據(jù)即“狀態(tài)”。

相比較而言，無狀態(tài)的服務(wù)就靈活很多。它們沒有持久化數(shù)據(jù)，或者持久化數(shù)據(jù)支持共享。對(duì)于客戶端而言，請(qǐng)求哪一個(gè)實(shí)例獲得的返回都是一致的。這樣的特性意味著可以隨意擴(kuò)展無狀態(tài)服務(wù)的實(shí)例數(shù)量，靈活的應(yīng)對(duì)流量。

使用云服務(wù)最大的好處之一，就是它提供的彈性和靈活性，在業(yè)務(wù)遭遇流量高峰時(shí)，可以快速擴(kuò)展實(shí)例進(jìn)行應(yīng)對(duì)。從這個(gè)角度出發(fā)，我們希望服務(wù)都是 “無狀態(tài)” 的。那么，一個(gè)新的問題冒了出來：我們可以去掉服務(wù)的 “狀態(tài)”，使之變成無狀態(tài)服務(wù)么？

處理服務(wù)的 “狀態(tài)”

利用粘性 Session 保持登陸態(tài)的這類 Web 服務(wù)，其狀態(tài)是可以被去掉的。

原理比較簡(jiǎn)單，把 Session 和 Web 應(yīng)用程序剝離，存儲(chǔ)到其他中間件中去即可，比如保存到Mysql、 Redis、Memcached等數(shù)據(jù)庫(kù)中間件中去。市面上常見的 Web 框架都會(huì)支持這種功能，甚至把這種處理方式作為默認(rèn)選項(xiàng)，因?yàn)檫@實(shí)在太棒了！

處理完的 Web 服務(wù)，就變成了無狀態(tài)服務(wù)，可以任意擴(kuò)展實(shí)例數(shù)量了。來自客戶端的請(qǐng)求無論被分配到哪一個(gè)實(shí)例，其登陸態(tài)都到后端數(shù)據(jù)庫(kù)中調(diào)取，返回正確的登陸態(tài)。在部署時(shí)，可以選擇無狀態(tài)多實(shí)例進(jìn)行部署，即使用 Deployment 這種資源類型。

但是對(duì)于DB類的數(shù)據(jù)庫(kù)中間件而言，其狀態(tài)是不可以被隨意去除的。

原因在于這類數(shù)據(jù)庫(kù)中間件使用自己的機(jī)制來確保數(shù)據(jù)強(qiáng)一致性，就比如 Mysql 的鎖文件機(jī)制，指定的實(shí)例只能去讀寫對(duì)應(yīng)自己的那一份數(shù)據(jù)。對(duì)這一類有狀態(tài)服務(wù)而言，每個(gè)實(shí)例獨(dú)享一份持久化數(shù)據(jù)可以算作是必須的條件。并且隨意擴(kuò)展實(shí)例數(shù)量，會(huì)遭遇很多致命的問題：比如數(shù)據(jù)不一致，或者程序運(yùn)行失敗等等。這一類的有狀態(tài)服務(wù)只能單點(diǎn)部署嗎？

這些數(shù)據(jù)庫(kù)中間件的出品廠商或者社區(qū)，也都很關(guān)注如何實(shí)現(xiàn)高可用方案，來解決上述的問題。甚至近些年推出的數(shù)據(jù)庫(kù)中間件，在設(shè)計(jì)階段就會(huì)被設(shè)計(jì)成分布式架構(gòu)。比如 Etcd 對(duì)自己的定義就是：可靠的強(qiáng)一致性分布式鍵值數(shù)據(jù)庫(kù)。其內(nèi)部使用 Raft 協(xié)議進(jìn)行實(shí)例間選舉來明確統(tǒng)一的leader。而對(duì)于 Mysql 這樣比較老牌的數(shù)據(jù)庫(kù)中間件，也具備基于 Binlog 復(fù)制實(shí)現(xiàn)的主從集群方案。

所以針對(duì)這一類無法去除狀態(tài)的服務(wù)而言，我們的思路與宗旨，就是遵循其自身支持的集群方案，來實(shí)現(xiàn)高可用以及實(shí)例數(shù)量擴(kuò)展。

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

• 每個(gè)實(shí)例掛載單獨(dú)的持久化數(shù)據(jù)；
• 實(shí)例間需要獲取彼此的通信地址，來進(jìn)行選舉或者數(shù)據(jù)同步等動(dòng)作，比如可解析的主機(jī)名或域名。獲取地址時(shí)一定要使用主機(jī)名或域名而非實(shí)例 IP，因?yàn)殡S著實(shí)例的重啟，主機(jī)名或域名不會(huì)改變，但是IP可能會(huì)改變，這很重要；
• 實(shí)例數(shù)量是有要求的，一般情況下選擇 3、5、7··· 等奇數(shù)，來保證集群不會(huì)出現(xiàn)腦裂；

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

以上就是Rainbond部署組件Statefulset的使用官方文檔的詳細(xì)內(nèi)容，更多關(guān)于Rainbond部署組件Statefulse官方文檔的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論