說(shuō)到高可用，咱們?cè)谑褂弥鳈C(jī)環(huán)境的時(shí)候（非 k8s），咱做高可用有使用過(guò)這樣的方式：

• 服務(wù)器做主備部署，當(dāng)主節(jié)點(diǎn)和備節(jié)點(diǎn)同時(shí)存活的時(shí)候，只有主節(jié)點(diǎn)對(duì)外提供服務(wù)，備節(jié)點(diǎn)就等著主節(jié)點(diǎn)掛了之后，立刻補(bǔ)位

• 另外為了提供服務(wù)的可用性，做了異地多活，增加服務(wù)的接入節(jié)點(diǎn)，對(duì)流量進(jìn)行分流等

• 對(duì)于數(shù)據(jù)庫(kù)同樣也是做備份，定期同步，熱備或者冷備

那么前面分享了那么多的關(guān)于 k8s 自身組件的原理，咱們可以回過(guò)來(lái)頭看，我們?yōu)槭裁匆x擇 k8s ？

簡(jiǎn)單來(lái)說(shuō)還是因?yàn)?k8s 自身的特性：

• 自身滿(mǎn)足負(fù)載均衡

• 服務(wù)自愈

• 管理的服務(wù)還可橫向擴(kuò)容

• 升級(jí)的時(shí)候，能夠滾動(dòng)升級(jí)，平滑過(guò)渡，整個(gè)升級(jí)過(guò)程能夠做到非常的絲滑，

• 若中間出現(xiàn)升級(jí)異常，還可以一鍵回滾，在回滾過(guò)程中，亦不影響原有服務(wù)

這一切的一切，咱們?cè)谥鳈C(jī)環(huán)境都是需要耗費(fèi)很大的人力成本去做的事情，因而，最終才會(huì)選擇服務(wù)部署在 k8s 上面，可以極大的減少開(kāi)發(fā)和運(yùn)維的心智負(fù)擔(dān)和運(yùn)維成本

那么上述說(shuō)的這么好， k8s 是如何保障高可用的呢？

高可用我們可以從哪些方面思考呢？

從 pod 來(lái)看

從 pod 來(lái)看高可用的話(huà)，前面我們有說(shuō)到 pod 可以通過(guò)使用高級(jí)資源 Deployment 來(lái)進(jìn)行管理，創(chuàng)建，更新，刪除 ?pod ，使用 Deployment 都可以進(jìn)行平滑的升級(jí)和回滾

當(dāng)然默認(rèn)說(shuō)的這種方式是無(wú)狀態(tài)的 pod

如果咱們是的服務(wù)是有狀態(tài)的，運(yùn)行在 pod 中，咱們?nèi)匀豢梢允褂?Deployment ，但是只能有 1 個(gè)副本，否則會(huì)有影響

如果帶有數(shù)據(jù)卷的時(shí)候，咱們也可以使用 StatefulSet 資源來(lái)進(jìn)行管理

但是若咱們的 pod 掛掉，咱們?cè)?pod 重啟到可以對(duì)外提供服務(wù)的過(guò)程中，服務(wù)會(huì)中斷一段時(shí)間

有狀態(tài)服務(wù)，無(wú)法水平擴(kuò)展的高可用方式

有狀態(tài)的服務(wù)，無(wú)法水平擴(kuò)展，咱們也可以像最開(kāi)始我說(shuō)到的使用主備的這種做法來(lái)進(jìn)行處理

類(lèi)似的，我們可以使用領(lǐng)導(dǎo)選舉機(jī)制，來(lái)將多個(gè)同樣的有狀態(tài)服務(wù)中選舉一個(gè)服務(wù)來(lái)對(duì)外處理請(qǐng)求

直到這個(gè)服務(wù)出現(xiàn)異常而宕機(jī)之后，使用同樣的方式，來(lái)在剩下的服務(wù)中選舉出一個(gè)有效的服務(wù)，來(lái)處理外來(lái)請(qǐng)求

具體的算法和 k8s 中的實(shí)現(xiàn)方式，我會(huì)在后面的文章中進(jìn)行分享

從 etcd 來(lái)看

etcd ，咱們是使用主機(jī)環(huán)境的時(shí)候也有使用過(guò) etcd

主要是用來(lái)存放服務(wù)配置，和用來(lái)做服務(wù)發(fā)現(xiàn)的，key 值是服務(wù)的目錄或者帶有 / 的字符串， value 的話(huà)，則是服務(wù)的 ip 和 端口

etcd 本身就被設(shè)計(jì)成一個(gè)分布式的系統(tǒng)，本身就可以運(yùn)行多個(gè) etcd 實(shí)例，天生做高可用就是很容易的事情

一般做集群，咱們會(huì)部署 3 個(gè)，5個(gè) 或者是 7 個(gè)，原因的話(huà)，可以嘗試去看看 redis 集群部署一章的分享

可以看這個(gè)簡(jiǎn)圖：

多 master ，多 worker 的簡(jiǎn)圖

從 ApiServer 來(lái)看

從 ApiServer 來(lái)看的話(huà)，那就更簡(jiǎn)單的

這個(gè)組件本身無(wú)狀態(tài)，且不緩存數(shù)據(jù)，他會(huì)直接和 自己獨(dú)立的 etcd 進(jìn)行通信，對(duì)于節(jié)點(diǎn)里面的組件，請(qǐng)求給到哪一個(gè) master 里面的 ApiServer 都是可以的

因?yàn)?ApiServer 后面的 etcd 組件是分布式的，他們的數(shù)據(jù)是會(huì)跨實(shí)例復(fù)制數(shù)據(jù)的

在多 master 的時(shí)候，worker 和主節(jié)點(diǎn)通信的時(shí)候，是要經(jīng)過(guò)一個(gè)負(fù)載均衡器的，這可以讓多個(gè)節(jié)點(diǎn)的流量進(jìn)行分流，同時(shí)還可以保證 worker 的請(qǐng)求可以正確的打到健康的 ApiServer 上

從 調(diào)度器 scheduler 和控制器管理器 controller manager 來(lái)看

對(duì)于 scheduler 和控制器管理器相對(duì)就沒(méi)有 ApiServer 那么簡(jiǎn)單和方便，因?yàn)樗麄儠?huì)涉及資源管理的沖突

對(duì)于他們來(lái)說(shuō)，他們大部分都是在做監(jiān)聽(tīng)工作，當(dāng)有多個(gè)控制器監(jiān)聽(tīng)了到 ApiServer 的中的資源變化

那么，例如 3 個(gè) ReplicaSet 控制器，都監(jiān)聽(tīng)了 ApiServer 將其對(duì)應(yīng)的副本數(shù)增加 2 個(gè)

這個(gè)時(shí)候，3 個(gè) ReplicaSet 控制器 都監(jiān)聽(tīng)了，為了滿(mǎn)足期望，他們便會(huì)做滿(mǎn)足期望的事情，最終，環(huán)境里面會(huì)新產(chǎn)生 6 個(gè) pod

自然，這是我們所不期待的，這樣搞豈不是亂套了，浪費(fèi)資源

因此 對(duì)于控制器管理器和調(diào)度器和他們都會(huì)積極的監(jiān)聽(tīng)集群的狀態(tài)，為了避免不良競(jìng)爭(zhēng)，還是要選用上述的類(lèi)似主備的思想

給他們使用 --leader-elert 選項(xiàng) ， 默認(rèn)會(huì)進(jìn)行選主，誰(shuí)是主，誰(shuí)就做實(shí)際的動(dòng)作，做監(jiān)聽(tīng)之后需要做的事情，其他的就等著這個(gè)主 壽終正寢

好了，今天就是這樣

今天就到這里，學(xué)習(xí)所得，若有偏差，還請(qǐng)斧正

歡迎點(diǎn)贊，關(guān)注，收藏

朋友們，你的支持和鼓勵(lì)，是我堅(jiān)持分享，提高質(zhì)量的動(dòng)力

好了，本次就到這里

技術(shù)是開(kāi)放的，我們的心態(tài)，更應(yīng)是開(kāi)放的。擁抱變化，向陽(yáng)而生，努力向前行。

我是阿兵云原生，歡迎點(diǎn)贊關(guān)注收藏，下次見(jiàn)~