程序員修神之路--Kubernetes是微服務(wù)發(fā)展的必然產(chǎn)物

作者：菜v菜 2019-11-26 09:24:19
云計算 在很多項目的發(fā)展初期，都是小型或者大型的單體項目，部署在單臺或者多臺服務(wù)器上，以單個進程的方式來運行。這些項目隨著需求的遞增，發(fā)布周期逐漸增長，迭代速度明顯下降。

kubernetes介紹[[283631]]

在很多項目的發(fā)展初期，都是小型或者大型的單體項目，部署在單臺或者多臺服務(wù)器上，以單個進程的方式來運行。這些項目隨著需求的遞增，發(fā)布周期逐漸增長，迭代速度明顯下降。傳統(tǒng)的發(fā)布方式是：開發(fā)人員將項目打包發(fā)給運維人員，運維人員進行部署、資源分配等操作。

隨著軟件行業(yè)架構(gòu)方式的改變，這些大型的單體應用按照業(yè)務(wù)或者其他維度逐漸被分解為可獨立運行的組件，我們稱之為微服務(wù)。微服務(wù)彼此之間被獨立開發(fā)、部署、升級、擴容，真正實現(xiàn)了大型應用的解耦工作。

軟件開發(fā)行業(yè)就是這樣奇葩，每一個問題被解決之后總是伴隨著另外的問題出現(xiàn)，就像程序員改bug，為什么總有改不完的bug，真的很令人頭大!!!

微服務(wù)雖然解決了一些問題，但是隨著微服務(wù)數(shù)量的增多，配置、管理、擴容、高可用等要求的實現(xiàn)變的越來越困難，包括運維團隊如何更好的利用硬件資源并降低服務(wù)器成本，以及部署的自動化和故障處理等問題變得原來越棘手。

以上問題正是kubernetes要解決并且擅長的領(lǐng)域，它可以讓開發(fā)者自主部署應用，自主控制迭代的頻率，完全解放運維團隊。而運維團隊的工作重心從以往的服務(wù)器資源管理轉(zhuǎn)移到了kubernetes的資源管理。kubernetes最厲害之處是對硬件基礎(chǔ)設(shè)施進行了封裝和抽象，使得開發(fā)人員完全不用去了解硬件的基礎(chǔ)原理，不用去關(guān)注底層服務(wù)器。kubernetes內(nèi)部把設(shè)置的服務(wù)器抽象為資源池，在部署應用的時候，它會自動給應用分配合適合理的服務(wù)器資源，并且能夠保證這些應用能正常的和其他應用進行通信。一個kubernetes集群的大體結(jié)構(gòu)如下：

[[283633]]

kubernetes優(yōu)勢[[283631]]

微服務(wù)雖好，但是數(shù)量多了就會有量帶來的問題。隨著系統(tǒng)組件的不斷增長，這些組件的管理問題逐漸浮出水面。首先我們要明白kubernetes是一個軟件系統(tǒng)，它依賴于linux容器的特性來管理組件(kubernetes和容器并非一個概念，請不要混淆)。通過kubernetes部署應用程序時候，你的集群無論包含多少個節(jié)點，對于kubernetes來說不會有什么差異，這完全得益于它對底層基礎(chǔ)設(shè)置的抽象，使得數(shù)個節(jié)點運行的時候表現(xiàn)的好像一個節(jié)點一樣。

自動擴容[[283631]]

在kubernetes系統(tǒng)中，它可以對每個應用進行實時的監(jiān)控，并能根據(jù)策略來應對突發(fā)的流量做出反應。例如：在流量高峰期間，kubernetes可以根據(jù)各個節(jié)點的資源利用情況，進行自動的增加節(jié)點或者減少節(jié)點操作，這在以前的傳統(tǒng)應用部署方式中是不容易做到的。

簡化部署流程[[283631]]

以往的傳統(tǒng)應用發(fā)布的時候，需要開發(fā)人員把項目打包，并檢查項目的配置文件是否正確，然后發(fā)給運維人員，運維人員然后把線上的應用版本備份，然后停止服務(wù)進行更新。在kubernetes中，我們多數(shù)情況下只需要一條指令或者點擊一個按鈕，就可以把應用升級到最新版本，而且升級的過程中還可做做到不間斷服務(wù)。當然整個的流程還涉及到容器的操作，本次這里不再做過多介紹。

但是這里有一個意外情況，如果kubernetes集群中存在不同架構(gòu)CPU的服務(wù)器，而你的應用程序是針對特定CPU架構(gòu)的軟件，可能需要在kubernetes中指定節(jié)點去運行你的應用程

提高服務(wù)器資源的利用率[[283631]]

傳統(tǒng)應用部署的時候，多數(shù)情況下總會把資源留有一定的比例來作為資源的緩沖，來應對流量的峰值，很少有人把單個服務(wù)器資源利用率提高到90%以上，從服務(wù)器故障的概率來說，服務(wù)器資源使用率在90%要比50%高很多，而且服務(wù)器一旦出現(xiàn)故障，都是運維人員來解決問題和背鍋，所以傳統(tǒng)的物理機或者虛擬機部署應用的方式，硬件的資源利用率相比較來說是比較低的。

而kubernetes對集群的管理由于抽象了底層硬件設(shè)施，所以已經(jīng)將應用程序和基礎(chǔ)設(shè)施分離開來。當你告訴kubernetes運行你 應用程序時，它會根據(jù)程序的資源需求和集群內(nèi)每隔節(jié)點的可用資源情況選擇合適的節(jié)點來運行。而且通過容器的技術(shù)，可以讓應用程序在任何時間遷移到集群中的任何機器上。而對于服務(wù)器選擇的最優(yōu)的組合，kubernetes比人工做的更好，它會根據(jù)集群中每臺服務(wù)器的負載情況來把硬件利用率提高到最高。

自動修復[[283631]]

在傳統(tǒng)的應用架構(gòu)中，如果一臺服務(wù)器發(fā)生故障，那么這臺服務(wù)器上的應用將會全部down掉，多數(shù)情況下需要運維人員去處理，這也是為什么運維人員需要7*24小時隨時待命的一個重要原因。相信你也曾看到過因為半夜故障運維人員罵娘的情景。在kubernetes中，它監(jiān)視并管理著所有的節(jié)點和應用，在節(jié)點出現(xiàn)故障的時候，kubernetes可以自動將該節(jié)點上的應用遷移到其他健康節(jié)點，并將故障節(jié)點在資源池中排除。如果你的kubernetes集群基礎(chǔ)設(shè)施有足夠的備用資源來支撐系統(tǒng)的正常運行，運維人員完全可以拖延到正常的工作時間再處理故障，讓程序員和運維人員過一下965的工作節(jié)奏。[[283635]]

這點有點像Actor模型的設(shè)計理論，提倡的是任其崩潰原理。

一致的運行環(huán)境[[283631]]

無論你是開發(fā)還是運維人員，在傳統(tǒng)的部署方案中，總會有運行環(huán)境差異性的煩惱，這樣的差異性大到每個服務(wù)器的差異，小到開發(fā)環(huán)境、仿真環(huán)境、生產(chǎn)環(huán)境，而且每個環(huán)境的服務(wù)器都會隨著時間的推移而變化。我相信你一定遇到過開發(fā)環(huán)境程序運行正常，生產(chǎn)環(huán)境卻異常的情況。這種差異性不僅僅是因為生產(chǎn)環(huán)境由運維團隊管理，開發(fā)環(huán)境由開發(fā)者管理，更重要的這兩組人對系統(tǒng)的要求是不同的，運維團隊會對線上生產(chǎn)環(huán)境定時的打補丁，做安全監(jiān)測等操作，而開發(fā)者可能根本就不會吊這些問題。除此之外，應用系統(tǒng)依賴的第三方庫可能在開發(fā)、仿真、生產(chǎn)環(huán)境中版本不同，這樣的問題反正我是遇到過。

而kubernetes采用的容器技術(shù)，在把應用打包的時候，運行環(huán)境也一起被打入包中，這就保證了相同版本的容器包(鏡像)在任何服務(wù)器上都有相同的運行環(huán)境

kubernetes要求開發(fā)人員對容器技術(shù)和網(wǎng)絡(luò)知識有一定了解，所以是否采用kubernetes要根據(jù)團隊的綜合技能和項目斟酌使用，并不是所有項目采用kubernetes都有利。

當前文章：程序員修神之路--Kubernetes是微服務(wù)發(fā)展的必然產(chǎn)物
當前網(wǎng)址：http://fisionsoft.com.cn/article/coocspp.html