如何實現(xiàn)分布式協(xié)調(diào)Kubernet

這篇文章將為大家詳細講解有關(guān)如何實現(xiàn)分布式協(xié)調(diào)Kubernet，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

處理調(diào)度Jobs

單一的應用程序，就是之前在單個節(jié)點上運行的單個實例，包括了很多在數(shù)據(jù)庫更新狀態(tài)的調(diào)度jobs（現(xiàn)在也同樣發(fā)布商務events）。單體程序創(chuàng)建在java中，并且大量使用Spring，所以job看起來是這個樣子的：

Spring之后會確認提到過的 doSomethingEveryMinute方法每分鐘執(zhí)行一次。問題是，如果我們目前不在Kubernetes上主持單體程序，并且跟多個實例一起運行，這個job就每分鐘會在每個實例上被執(zhí)行一次，而不僅僅只是每分鐘執(zhí)行了一次而已。如果job有類似發(fā)送通知郵件或更新數(shù)據(jù)庫這樣的副作用的話，這就是一個問題了。所以我們要怎樣避免這個？當然，解決方案還是很多的，顯而易見的選擇就是利用Kubernetes Jobs，讓Kubernetes自己周期性調(diào)度jobs。問題就是這個作用只在Kubernetes1.3版本及以上版本中可用，但是1.3還沒有發(fā)布。但是即使我們能夠使用這樣一個功能，從技術(shù)角度來說，這也是不太可行的。我們的jobs被高度耦合到已經(jīng)存在的代碼庫，并且提取每個job到它自己的應用程序，程序可能會有錯誤，而且如果一次性完成的話會非常耗費時間。所以我們最初的計劃是提取所有的調(diào)度jobs到一個應用程序，這個應用程序在Kubernetes中只能作為一個實例來運行。但由于現(xiàn)有代碼的本質(zhì)，和高耦合性，即使是這樣也很難實現(xiàn)。那么，有沒有一種很輕松的辦法允許我們目前在單體應用中保持jobs，并且當我們從這個應用中提取功能到獨立的服務的時候，逐漸替代他們呢？其實還是有的。

Kubernetes中的Leader選舉

要解決這個，我們需要做一些分布式協(xié)調(diào)，比如，當jobs被Spring執(zhí)行的時候，如果這個節(jié)點不是“l(fā)eader節(jié)點”，為運行調(diào)度jobs負責，我們就只需要傳回信息（而且，不要和job一起運行代碼）。有一些項目能夠幫助我們來處理諸如zookeeper和hazelcast之類的東西。但是僅僅只是為了決定哪個節(jié)點執(zhí)行調(diào)度jobs，以此來設(shè)置、保留zookeeper集群就太勞師動眾了。我們需要一些易于管理的東西，假如我們能夠利用Kubernetes會怎么樣呢？Kubernetes已經(jīng)在cover下（使用 RAFT consensus algorithm）處理了leader選舉。結(jié)果證明，這個功能通過使用gcr.io/google_containers/leader-elector Docker鏡像已經(jīng)被暴露給了終端用戶。之前已經(jīng)有一個很棒的博客帖子很細節(jié)地描述過這個是如何運行的了，點擊這個網(wǎng)址查看：http://blog.kubernetes.io/2016/01/simple-leader-election-with-Kubernetes.html。所以在這里我就不多加贅述了，但是我會講一講我們是如何利用鏡像來解決我們的問題的。

解決問題

我們做的就是帶來gcr.io/google_containers/leader-elector容器到我們的pod，這樣就可以讓單體應用的實例都運行一個leader選舉的實例。這是證明Kubernetes pod有用的典型例子。

以下是一個在我們的配置resource中定義好的pod的摘錄：

我們開啟leader選舉以及我們的單體應用程序。注意，我們將 --election=monolith-jobs當作第一個參數(shù)。這就意味著leader選舉知道容器屬于哪一個組。所以指定這個組的容器會是leader選舉進程中的一部分，這個組之中只有一個容器會被選舉為leader。 --http=localhost:4040的第二個參數(shù)同樣是非常重要的。它在4040端口打開了一個網(wǎng)頁服務器，在這個端口，我們可以查詢到目前l(fā)eader的pod名字，然后以這個格式返回：

這是我們決定要不要運行我們的job的一個小把戲。我們要做的事情就是檢查即將執(zhí)行調(diào)度pod的名字是否跟選舉出來的leader一致，如果一致，我們就應該繼續(xù)執(zhí)行，并且執(zhí)行job，或者其它的我們應該返回的東西。比如：

所以我們來看看ClusterLeaderService是如何被實施的。首先，我們必須從應用程序獲得pod的名字。Kubernetes將pod名字存儲在/etc/hostname ，Java將這個/etc/hostname暴露在HOSTNAME環(huán)境變量，這就是我們將在這個例子中引用的。另一個方法就是使用 Downward API將pod名字暴露到環(huán)境變量選擇。比如：

從這里，我們可以看到 metadata.name （也就是pod的名字）會與 MY_POD_NAME環(huán)境變量聯(lián)系在一起。但是現(xiàn)在讓我們來看看 ClusterLeaderService的實施是看起來是怎么樣的：

在這里例子中，我們正在從 RESTAssured 項目使用 JsonPath來查詢選舉者網(wǎng)頁服務，并且從回應中提取pod的名字。然后我們簡單地將本地容器的名字跟leader相比較，如果他們是相同的，那么我們就知道這個實例就是leader！就是這樣！

結(jié)論

事實證明，上述工作運行地很不錯！如果leader節(jié)點要掛掉了，那么另一個就會自動選舉上。但這個過程會花上一點時間，要一分鐘左右。所以這個還是要權(quán)衡一下的。假如你的工作中不允許錯過任意一個job執(zhí)行，那么這個選擇對你來說是不合適的。但在我們上述的例子中，中間有那么一分鐘job沒有被準確執(zhí)行，對我們來說無傷大雅。所以我覺得這個方法十分簡單，而且當移植一個現(xiàn)有的包含調(diào)度jobs的應用程序的時候很有價值，因為調(diào)度jobs總有各種各樣很難提取的原因。

關(guān)于“如何實現(xiàn)分布式協(xié)調(diào)Kubernet”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。