最近做基於docker技術的管理系統有一段時間了，對Docker技術的理解、部署實施、問題解決也算是有了一定的功力，糾結了好久該不該耗些時間寫點什麼，終於在這個躁動不安的夜晚決定下來，需要為自己的付出留下些痕跡；

說到docker，這個當前大熱的虛擬化技術，業界也有很多聲音，從原始碼解析、到部署管理系統、再到上層應用方案，各種資料都挺多的；對於docker，業界也有很多巨集觀的看法，很多文章都有指導docker可以怎麼用、應該怎麼用，實際有很多文章談的很虛，個人不喜歡在那些虛的東西上浪費口舌，因為沒有真正去做過的人，怎麼說、說什麼都是可以的，只有立場，沒有行動，可做參考，但沒實際意義，只有真正去做了，深入細節挑戰過後，才能煉出精華；

docker本身是基於LXC container技術發展起來的，核心是cgroup、namespace，個人覺得對比LXC的優勢主要體現在整合管理以及更豐富完善的周邊支撐，其實Docker已經是款產品了，但就docker 本身而言，產品形態比較簡單，但是它的產品特性是依附於叢集式部署與流程化管理，需要基於它之上的管理系統支撐，才能很好的鋪開並服務於上層業務，真正的產品化；

首先談談當前開源基於docker比較火的叢集式部署管理系統：Kubernetes(簡稱k8s)，它是基於Docker技術的nat網路模式構建的，個人覺得它有優有劣，從三個角度來說說：

1、部署和管理。-

優勢：以管理者的角度看，因為k8s的叢集環境相較於實際生產環境，算是比較純粹乾淨（特別是業務線比較長的公司），且使用的nat模式，橫向擴充套件可以很方便，可以輕易的擴充套件部署和遷移，結合docker快速上下線的技術特性，使得動態調整部署很方便，是一套比較不錯的高效部署管理系統；

劣勢：k8s架構本身基於三角穩固體系，且中間有巢狀，邏輯比較重，為了連貫整套體系，保證服務質量，架構中間的輔助性支撐節點偏多，使得k8s要維護本身的框架所消耗的資源成本偏高，簡單舉例：k8s架構基於三個基本的管理物件（pod、service、replicationController），典型的三角穩定模型，相互關係類似於我們熟知的執法、立法、司法，其中pod物件也是有自己的架構，也是基於三角模型的管理物件（container、kubelet、proxy），通過這套叢集管理系統接入一個業務，整套流程下來，至少要經過兩趟巢狀式的管理架構，最後才能實現真正的docker container的落地使用，如果業務體系本身的架構比較輕可以支撐，但是一旦業務本身的架構比較重，假設分接入、邏輯和儲存，各層次中間還有均衡容災，用k8s部署管理，會導致這整套體系中間的支撐邏輯會非常重，架構成本會很高；

2、與實際生產環境的相容結合

優勢：純粹乾淨的叢集環境，適合新的業務部署，結合映象的使用方式，可以將開發、釋出、部署封裝成一條龍流程，實現高效快速的開發迭代和釋出部署；

劣勢：相較於大部分公司的業務系統都是基於IP為狀態做的釋出、部署、管理、監控，基於nat無狀態模式運營管理k8s其實很難相容鋪開使用，它更強調依賴底層單純乾淨的叢集資源環境，它有一套自己的釋出、部署、管理、監控的體系，與大部分公司已有的體系比較難融合，如果是小公司還比較好，業務範圍不廣，運營壓力不大，從開發、釋出到運維的整條生產線，直接遷移到nat模式或許可以接受，但是如果公司業務比較多，業務架構比較重，要遷過去或做相容成本是非常大的，甚至可能是顛覆性的改革，而且改革結果是不確定性的，很多公司其實是很難接受的，簡單舉例：假設A公司已有一套基於IP為狀態比較完善的業務系統，上游的釋出工具、中游的資源管理和部署排程系統、下游的監控告警系統，整套流程都比較好用，如果讓k8s支撐這套業務，需要把這套東西都改為支援nat模式，所有的流程中間都必須有一層nat轉換，上層無法得知對映後面具體的IP，就算知道了，IP也是複用不唯一，會導致之前基於以IP為狀態做的管理、排程、監控、告警會全部癱瘓掉，簡直就像武俠小說裡說的欲練此功必先自宮，代價太大；

3、成本

優勢：如果公司打造了一套純粹的基於k8s 叢集部署環境，能快速的批量擴縮容，叢集本身彈性擴充套件比較方便，能很高效的實現運維人員追求的部署流程傻瓜自動化，從人力角度來評價，還是很省成本的，很高效；

劣勢：如果從裝置資源的角度考慮，由於相較於其他模式的管理叢集，對容器的使用方式都一樣，k8s本身不能提供更高階的可智慧學習迭代優化機制，而且也沒基於系統層級對硬體使用做優化策略，所以在容器對資源使用這塊不會有成本優勢，相反，由於nat模式本身就耗裝置效能，如果一臺機器部署幾臺容器，當業務請求都上來的時候，效能下降肯定比線性更嚴重，另外，由於k8s本身架構繁重，為支撐並保證叢集穩定執行，還會耗用一些資源，且叢集越大，成本越高，可拓展性預期比較差；