共計 2479 個字符，預(yù)計需要花費 7 分鐘才能閱讀完成。

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

處理調(diào)度 Jobs

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

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

Kubernetes 中的 Leader 選舉

要解決這個，我們需要做一些分布式協(xié)調(diào)，比如，當(dāng) jobs 被 Spring 執(zhí)行的時候，如果這個節(jié)點不是“l(fā)eader 節(jié)點”，為運行調(diào)度 jobs 負(fù)責(zé)，我們就只需要傳回信息（而且，不要和 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)有一個很棒的博客帖子很細(xì)節(jié)地描述過這個是如何運行的了，點擊這個網(wǎng)址查看：http://blog.kubernetes.io/2016/01/simple-leader-election-with-Kubernetes.html。所以在這里我就不多加贅述了，但是我會講一講我們是如何利用鏡像來解決我們的問題的。

解決問題

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

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

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

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

所以我們來看看 ClusterLeaderService 是如何被實施的。首先，我們必須從應(yīng)用程序獲得 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)頁服務(wù)，并且從回應(yīng)中提取 pod 的名字。然后我們簡單地將本地容器的名字跟 leader 相比較，如果他們是相同的，那么我們就知道這個實例就是 leader！就是這樣！

結(jié)論

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

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