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

隨著軟體行業架構方式的改變，這些大型的單體應用按照業務或者其他維度逐漸被分解為可獨立執行的元件，我們稱之為微服務。微服務彼此之間被獨立開發、部署、升級、擴容，真正實現了大型應用的解耦工作。關於微服務的介紹，大家可以去擼一下菜菜之前的文章：

https://mp.weixin.qq.com/s/b7Bd8giwWVNF1CtkaDaVpw

https://mp.weixin.qq.com/s/BixgyGFrlwZ7wpgDdrmU_g

軟體開發行業就是這樣奇葩，每一個問題被解決之後總是伴隨著另外的問題出現，就像程式設計師改bug，為什麼總有改不完的bug，真的很令人頭大！！!

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

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

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

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

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

但是這裡有一個意外情況，如果kubernetes叢集中存在不同架構CPU的伺服器，而你的應用程式是針對特定CPU架構的軟體，可能需要在kubernetes中指定節點去執行你的應用程

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

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

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

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

而kubernetes採用的容器技術，在把應用打包的時候，執行環境也一起被打入包中，這就保證了相同版本的容器包（映象）在任何伺服器上都有相同的執行環境