要說清楚Kubernetes解決了哪些問題，首先要知道容器是怎么回事，為什么要用容器。而要說容器，又要了解下微服務(wù)是怎么回事。要說微服務(wù)，又要說下微服務(wù)之前云部署是怎么回事，依次回溯。
這里我看下是否能簡單扒一扒軟件的運維部署歷史，然后看容器給運維人員帶來了什么問題，而這些問題，就是k8s要解決的了！如果大家覺得費時的，可以直接從第二點看是往下看。
第一，容器出現(xiàn)前的運維簡史
記得還是在讀初中的時候吧，那時候電腦基本上是沒有聯(lián)網(wǎng)的。所以那個時候一個軟件的所有功能基本上都是包含在一個安裝包上面的，也就是所謂的單機版軟件。
因為不同的操作系統(tǒng)環(huán)境，有時候軟件安裝上去了因為缺少了某些庫，會運行不了。所以一旦軟件出了問題，往往就會找電腦城那些人看下應(yīng)該怎么弄。
而這個時期企業(yè)軟件往往也是需要專門的人員進行部署安裝，一旦出問題了就會找對應(yīng)的軟件生產(chǎn)商派人來維護。
那個時候?qū)浖壊渴鹚枰年P(guān)機時間也沒有什么大的要求，畢竟大家都習(xí)慣了，下班時候找人來升級，第二天繼續(xù)開機工作就好了。
后來到了2000年前后吧，也就是互聯(lián)網(wǎng)開始爆發(fā)甚至都引起了.com泡沫的年代吧。經(jīng)過多年的發(fā)展，軟件，特別是企業(yè)軟件，已經(jīng)發(fā)展得越來越復(fù)雜和臃腫，UI和后端都綁定在一起，動不動就出問題，且難以維護。
這時大家就想要不把前后端分離吧，不要把一整套軟件整在一起了，也就是所謂的C/S的概念就出來了，后來又進一步延伸出B/S的模式，也就是所謂的Web App的概念了。
記得那個時候基于網(wǎng)絡(luò)進行通訊的RPC技術(shù)可謂多種多樣，很多估計年青一代的都沒有聽過，比如CORBA,SOAP，COM/DCOM等。當(dāng)時大家其實挺看好SOAP等，誰知道后來Restful異軍突起一統(tǒng)江山了。
雖然前后端分離進一步的將軟件進行解耦，但是后端的部署和運維還是很重。比如有些大型軟件需要專門的機房，然后增加寫功能后負載不夠又要添加硬件設(shè)備等。
為了解決這個問題，后來云服務(wù)就開始被提出來了。與其自己去維護一堆硬件設(shè)備，倒不如按需購買人家已經(jīng)提供好的云服務(wù)，直接部署到人家云端算了。所以這里阿里云的ECS這些Iaas就應(yīng)運而生了。
第二，容器和微服務(wù)的出現(xiàn)帶來的機會和問題
過了一段時間，大家發(fā)現(xiàn)部署在云端雖好，但是還是沒有辦法解決這個后端越來越復(fù)雜的問題，所有的服務(wù)都在一個服務(wù)器上跑，一個模塊出問題了就整個服務(wù)器掛了，運維又得通宵了。況且升級一個模塊就要整個后端升級，這也太麻煩了吧。
這時微服務(wù)和容器的概念就開始被提出來了。既然把所有模塊打包到一起不好維護和部署，那就把不同的模塊分開吧，每個模塊放到一個容器里面作為微服務(wù)，然后容器之前進行rpc通訊，這樣一個模塊要升級的時候就升級這個模塊，一個模塊掛了也不至于影響整個后端。
這種模式好是好，但是運維工程師眉頭一皺，感覺這個也沒有減少我運維的工作量呀，很多東西都需要我手動去做，感覺工作量反而更大了。主要體現(xiàn)在以下幾個方面：
首先，容器之間的通信和互相發(fā)現(xiàn)，我還是需要手動的去通過docker命令等搭建起來。你說一兩個容器還好，但是你現(xiàn)在幾十上百的，每個容器所處的網(wǎng)絡(luò)可能還不一樣。
其次，有時我們需要多個相同的容器來做負載均衡和水平擴展，那現(xiàn)在我還需要自己編碼去監(jiān)控什么時候你一個容器負載過大，然后起一個新的相同的容器來分擔(dān)一部分流量，等流量沒有這么高了，我又要去掉一個備份以節(jié)省資源
然后，我還要去檢測你一個容器什么時候因為我們開發(fā)人員寫的代碼引發(fā)的crash，而需要去決定是否要重新初始化一個新的容器來取代crash掉的。
再次，你一個新版本出來了，我還要一個個容器去升級，出問題了我還要一個個容器去降級。還是那句話，一兩個容器我么有問題，但是你這里往往是幾十上百的容器呀
最后，因為容器支持在不同機器上部署，然后共同提供后端的功能，不同的容器因為不同的功能需求，可能需要掛載的存儲設(shè)備也不一樣，比如有需要本地不同格式文件系統(tǒng)磁盤的，還有有需要NFS網(wǎng)盤的，你讓我一個個容器去配，配完了我估計都可以申請拿養(yǎng)老金了。
第三，Kubernetes來救駕
作為運維人員，碰到這么多東西需要自己手工去做，我當(dāng)然是非常不樂意了。這時我就會想，如果有一個軟件能幫我把這些東西自動化管理起來，我只需要敲幾個命令，將其配置下就好了。
這時容器編排服務(wù)就在運維的歡呼聲中登上歷史的舞臺了。而在眾多選手的競爭角逐中，Kubernetes笑到了最后。
那么Kubernetes又帶來什么問題呢？這就有點超出范疇了。簡要說下的話，就是懶惰不僅是程序員也是運維人員的美德！在命令行上敲命令寫配置文件，我們還是嫌太麻煩了，能不能整個好用的UI出來，底層用的是K8s？
這時Rancher 2.0等就出來了。注意這里特意說的是2.0，因為那之間Kubernetes還沒有完全在角逐中勝出，所以那個時候Rancher是既支持K8s也支持Swarm等的。后來一看K8s基本勝局已定，Rancher 2.0立刻拋棄所有，投入到K8s的懷抱中去。
