[[283629]]

[[283630]]

kubernetes介紹[[283631]]

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

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

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

[[283632]]

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

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

[[283634]]

kubernetes優勢[[283631]]

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

自動擴容[[283631]]

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

簡化部署流程[[283631]]

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

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

提高服務器資源的利用率[[283631]]

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

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

自動修復[[283631]]

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

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

一致的運行環境[[283631]]

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

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

kubernetes要求開發人員對容器技術和網絡知識有一定了解，所以是否采用kubernetes要根據團隊的綜合技能和項目斟酌使用，并不是所有項目采用kubernetes都有利。