資訊專欄INFORMATION COLUMN
摘要：?jiǎn)栴}就是這個(gè)作用只在版本及以上版本中可用，但是還沒(méi)有發(fā)布。中的選舉要解決這個(gè)，我們需要做一些分布式協(xié)調(diào)，比如，當(dāng)被執(zhí)行的時(shí)候，如果這個(gè)節(jié)點(diǎn)不是節(jié)點(diǎn)，為運(yùn)行調(diào)度負(fù)責(zé)，我們就只需要傳回信息而且，不要和一起運(yùn)行代碼。
Parkster這個(gè)項(xiàng)目正在從單體應(yīng)用轉(zhuǎn)化到微服務(wù)的過(guò)程中，已經(jīng)使用Kubernetes有一段時(shí)間了，尚未被移動(dòng)到Kubernetes應(yīng)用程序的就是單體應(yīng)用剩下的部分。將單體應(yīng)用完全分裂成微服務(wù)是一個(gè)愿景，在這個(gè)過(guò)程中，我們從kubernetes提供的調(diào)度、服務(wù)發(fā)現(xiàn)、高可用性、日志收集等服務(wù)中受益諸多。要達(dá)到在這種程度還需要做很多工作。在這篇文章中，我們要探索的是周期性單個(gè)開(kāi)啟調(diào)度工作的問(wèn)題。
處理調(diào)度Jobs單一的應(yīng)用程序，就是之前在單個(gè)節(jié)點(diǎn)上運(yùn)行的單個(gè)實(shí)例，包括了很多在數(shù)據(jù)庫(kù)更新?tīng)顟B(tài)的調(diào)度jobs（現(xiàn)在也同樣發(fā)布商務(wù)events）。單體程序創(chuàng)建在java中，并且大量使用Spring，所以job看起來(lái)是這個(gè)樣子的：
Spring之后會(huì)確認(rèn)提到過(guò)的doSomethingEveryMinute方法每分鐘執(zhí)行一次。問(wèn)題是，如果我們目前不在Kubernetes上主持單體程序，并且跟多個(gè)實(shí)例一起運(yùn)行，這個(gè)job就每分鐘會(huì)在每個(gè)實(shí)例上被執(zhí)行一次，而不僅僅只是每分鐘執(zhí)行了一次而已。如果job有類似發(fā)送通知郵件或更新數(shù)據(jù)庫(kù)這樣的副作用的話，這就是一個(gè)問(wèn)題了。所以我們要怎樣避免這個(gè)？當(dāng)然，解決方案還是很多的，顯而易見(jiàn)的選擇就是利用Kubernetes Jobs，讓Kubernetes自己周期性調(diào)度jobs。問(wèn)題就是這個(gè)作用只在Kubernetes1.3版本及以上版本中可用，但是1.3還沒(méi)有發(fā)布。但是即使我們能夠使用這樣一個(gè)功能，從技術(shù)角度來(lái)說(shuō)，這也是不太可行的。我們的jobs被高度耦合到已經(jīng)存在的代碼庫(kù)，并且提取每個(gè)job到它自己的應(yīng)用程序，程序可能會(huì)有錯(cuò)誤，而且如果一次性完成的話會(huì)非常耗費(fèi)時(shí)間。所以我們最初的計(jì)劃是提取所有的調(diào)度jobs到一個(gè)應(yīng)用程序，這個(gè)應(yīng)用程序在Kubernetes中只能作為一個(gè)實(shí)例來(lái)運(yùn)行。但由于現(xiàn)有代碼的本質(zhì)，和高耦合性，即使是這樣也很難實(shí)現(xiàn)。那么，有沒(méi)有一種很輕松的辦法允許我們目前在單體應(yīng)用中保持jobs，并且當(dāng)我們從這個(gè)應(yīng)用中提取功能到獨(dú)立的服務(wù)的時(shí)候，逐漸替代他們呢？其實(shí)還是有的。
Kubernetes中的Leader選舉要解決這個(gè)，我們需要做一些分布式協(xié)調(diào)，比如，當(dāng)jobs被Spring執(zhí)行的時(shí)候，如果這個(gè)節(jié)點(diǎn)不是“l(fā)eader節(jié)點(diǎn)”，為運(yùn)行調(diào)度jobs負(fù)責(zé)，我們就只需要傳回信息（而且，不要和job一起運(yùn)行代碼）。有一些項(xiàng)目能夠幫助我們來(lái)處理諸如zookeeper和hazelcast之類的東西。但是僅僅只是為了決定哪個(gè)節(jié)點(diǎn)執(zhí)行調(diào)度jobs，以此來(lái)設(shè)置、保留zookeeper集群就太勞師動(dòng)眾了。我們需要一些易于管理的東西，假如我們能夠利用Kubernetes會(huì)怎么樣呢？Kubernetes已經(jīng)在cover下（使用RAFT consensus algorithm）處理了leader選舉。結(jié)果證明，這個(gè)功能通過(guò)使用gcr.io/google_containers/leader-elector Docker鏡像已經(jīng)被暴露給了終端用戶。之前已經(jīng)有一個(gè)很棒的博客帖子很細(xì)節(jié)地描述過(guò)這個(gè)是如何運(yùn)行的了，點(diǎn)擊這個(gè)網(wǎng)址查看：這里。所以在這里我就不多加贅述了，但是我會(huì)講一講我們是如何利用鏡像來(lái)解決我們的問(wèn)題的。
解決問(wèn)題我們做的就是帶來(lái)gcr.io/google_containers/leader-elector容器到我們的pod，這樣就可以讓單體應(yīng)用的實(shí)例都運(yùn)行一個(gè)leader選舉的實(shí)例。這是證明Kubernetes pod有用的典型例子。
以下是一個(gè)在我們的配置resource中定義好的pod的摘錄：
我們開(kāi)啟leader選舉以及我們的單體應(yīng)用程序。注意，我們將--election=monolith-jobs當(dāng)作第一個(gè)參數(shù)。這就意味著leader選舉知道容器屬于哪一個(gè)組。所以指定這個(gè)組的容器會(huì)是leader選舉進(jìn)程中的一部分，這個(gè)組之中只有一個(gè)容器會(huì)被選舉為leader。--http=localhost:4040的第二個(gè)參數(shù)同樣是非常重要的。它在4040端口打開(kāi)了一個(gè)網(wǎng)頁(yè)服務(wù)器，在這個(gè)端口，我們可以查詢到目前l(fā)eader的pod名字，然后以這個(gè)格式返回：
這是我們決定要不要運(yùn)行我們的job的一個(gè)小把戲。我們要做的事情就是檢查即將執(zhí)行調(diào)度pod的名字是否跟選舉出來(lái)的leader一致，如果一致，我們就應(yīng)該繼續(xù)執(zhí)行，并且執(zhí)行job，或者其它的我們應(yīng)該返回的東西。比如：
所以我們來(lái)看看ClusterLeaderService是如何被實(shí)施的。首先，我們必須從應(yīng)用程序獲得pod的名字。Kubernetes將pod名字存儲(chǔ)在/etc/hostname，Java將這個(gè)/etc/hostname暴露在HOSTNAME環(huán)境變量，這就是我們將在這個(gè)例子中引用的。另一個(gè)方法就是使用Downward API將pod名字暴露到環(huán)境變量選擇。比如：
從這里，我們可以看到 metadata.name （也就是pod的名字）會(huì)與MY_POD_NAME環(huán)境變量聯(lián)系在一起。但是現(xiàn)在讓我們來(lái)看看 ClusterLeaderService的實(shí)施是看起來(lái)是怎么樣的：
在這里例子中，我們正在從RESTAssured項(xiàng)目使用JsonPath來(lái)查詢選舉者網(wǎng)頁(yè)服務(wù)，并且從回應(yīng)中提取pod的名字。然后我們簡(jiǎn)單地將本地容器的名字跟leader相比較，如果他們是相同的，那么我們就知道這個(gè)實(shí)例就是leader！就是這樣！
結(jié)論事實(shí)證明，上述工作運(yùn)行地很不錯(cuò)！如果leader節(jié)點(diǎn)要掛掉了，那么另一個(gè)就會(huì)自動(dòng)選舉上。但這個(gè)過(guò)程會(huì)花上一點(diǎn)時(shí)間，要一分鐘左右。所以這個(gè)還是要權(quán)衡一下的。假如你的工作中不允許錯(cuò)過(guò)任意一個(gè)job執(zhí)行，那么這個(gè)選擇對(duì)你來(lái)說(shuō)是不合適的。但在我們上述的例子中，中間有那么一分鐘job沒(méi)有被準(zhǔn)確執(zhí)行，對(duì)我們來(lái)說(shuō)無(wú)傷大雅。所以我覺(jué)得這個(gè)方法十分簡(jiǎn)單，而且當(dāng)移植一個(gè)現(xiàn)有的包含調(diào)度jobs的應(yīng)用程序的時(shí)候很有價(jià)值，因?yàn)檎{(diào)度jobs總有各種各樣很難提取的原因。
原文鏈接
（如果需要轉(zhuǎn)載，請(qǐng)聯(lián)系我們哦，尊重知識(shí)產(chǎn)權(quán)人人有責(zé)；）
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/32474.html
摘要：那都是老一套了。已死已經(jīng)沒(méi)有人用了?，F(xiàn)在所有的一切都在容器化，它是未來(lái)。這是確保它可靠的唯一方式。我現(xiàn)在需要一個(gè)是的，為了穩(wěn)定性。我猜是規(guī)模的對(duì)，沒(méi)錯(cuò)。我明白了，好吧，我懂了。那我來(lái)重復(fù)一遍確保我領(lǐng)悟了這些。 這是一篇在國(guó)外社區(qū)非?；鸬奈恼隆Ｓ蒀ircleCI創(chuàng)始人所寫(xiě)，追逐熱點(diǎn)新技術(shù)的程序員與只想做個(gè)簡(jiǎn)單web應(yīng)用的程序員對(duì)話，Docker到底能否解決簡(jiǎn)單小應(yīng)用的問(wèn)題嗎？Herok...
摘要：公司始于名為的平臺(tái)即服務(wù)供應(yīng)商?？缍鄠€(gè)機(jī)器之間協(xié)調(diào)這些容器需要額外的工具，這稱之為容器編排。的核心優(yōu)勢(shì)是為應(yīng)用程序開(kāi)發(fā)人員提供了用于編排無(wú)狀態(tài)容器的強(qiáng)大工具。有無(wú)數(shù)的文章都在討論和比較Docker、Kubernetes 以及Mesos。如果你是初學(xué)者，那么你可能會(huì)認(rèn)為這三個(gè)開(kāi)源項(xiàng)目正為了稱霸容器界而殊死搏斗。雖然這三種技術(shù)都使得使用容器部署、管理和伸縮應(yīng)用成為可能，但實(shí)際上它們各自解決了不同...
摘要：分布式文件系統(tǒng)和數(shù)據(jù)庫(kù)，由于性能和成本，是持久性本地存儲(chǔ)的主要用例。在裸機(jī)上，除了性能之外，本地存儲(chǔ)通常更便宜，并且使用它是配置分布式文件系統(tǒng)的必要條件。 作者：1.14發(fā)布團(tuán)隊(duì) 我們很高興地宣布推出Kubernetes 1.14，這是我們2019年的首次發(fā)布！ showImg(https://segmentfault.com/img/bVbqrJZ?w=300&h=293); Kub...
摘要：分布式文件系統(tǒng)和數(shù)據(jù)庫(kù)，由于性能和成本，是持久性本地存儲(chǔ)的主要用例。在裸機(jī)上，除了性能之外，本地存儲(chǔ)通常更便宜，并且使用它是配置分布式文件系統(tǒng)的必要條件。 作者：1.14發(fā)布團(tuán)隊(duì) 我們很高興地宣布推出Kubernetes 1.14，這是我們2019年的首次發(fā)布！ showImg(https://segmentfault.com/img/bVbqrJZ?w=300&h=293); Kub...
摘要：同時(shí)該版本在安全性和等關(guān)鍵功能上作出了改進(jìn)年月日，發(fā)布。盡管谷歌這些年來(lái)是的主要貢獻(xiàn)者，但現(xiàn)在其他技術(shù)人員在這個(gè)項(xiàng)目上的貢獻(xiàn)量已經(jīng)幾乎和谷歌持平了。這些舉動(dòng)都在表明云計(jì)算市場(chǎng)的戰(zhàn)火將繼續(xù)蔓延，已經(jīng)成為兵家必爭(zhēng)之地。年月日，宣布推出。 Kubernetes 在過(guò)去幾年中一直是云計(jì)算領(lǐng)域最著名的開(kāi)源項(xiàng)目之一。20...
閱讀 852·2021-11-18 10:07
閱讀 2363·2021-10-14 09:42
閱讀 5360·2021-09-22 15:45
閱讀 597·2021-09-03 10:29
閱讀 3477·2021-08-31 14:28
閱讀 1885·2019-08-30 15:56
閱讀 3048·2019-08-30 15:54
閱讀 1003·2019-08-29 11:32
