容器 … 伴隨著2013發佈的開源項目Docker，以迅雷不及掩耳盜鈴之勢迅速席捲了整個IT行業，一瞬間每個人都在談論容器，談論Docker，談論Kubernetes。但，這一切都不是一瞬間的事情 … …
為什麼是Docker?
讓我們把時間拉回到1995年，那一年我剛剛進入北京理工大學管理學院，成為了一名大一的新生。雖然是管理學院，但不務正業的自己還是喜歡鼓搗各種電子產品，藉著高三假期在中關村打工的機會認識了一些“業內人士”，也在學校裡面幫人攢機賺點外塊。
當然賺外快就需要關注各種配件行情，所以開始關注各種技術雜誌；這個時候開始，在各種電腦類雜誌上開始頻繁出現一個詞彙，就是 Web Service。當時的我還完全看不懂這裡面的玄機，而容器的發展應該說從那個時候就已經埋下了伏筆。
在1995年，任何一種技術棧所開發出來的軟件都是無法很方便和其他技術棧進行通訊的，除非使用共享內存，文件系統的方式。跨進程訪問是一個阻礙技術發展的巨大難題，而對這個難題最不滿意的其實是企業的管理者們。因為對於管理者而言，一旦購買了某個廠商的某個技術棧的產品，那麼就必須一直“忠實”的與這個廠商合作下去，同時一直使用同樣一個技術棧開發後續的擴展。什麼意思呢，就是說如果你用Java開發一個系統（注意：這只是個例子，1995年的Java還僅限於applet的狀態），你是不可能使用任何其他語言，比如：C#，PHP，Python等，與這個系統進行集成的。這個狀態讓企業管理者感到非常不可接受，因為他們感覺被綁架了，明明市場上有根好的解決方案，有便宜的開發人員，但僅僅因為技術的限制我就必須和這個廠商合作。
這個問題必須解決！
同時，1995年互聯網開始普及，於是科學家們開始研究使用網絡通信的方式來解決跨進程訪問的問題，這樣才出現了Web Service這種藉助標記語言(XML)來抽象不同技術棧的實現方式，統一使用簡單的純文本報文的方式來實現跨進程訪問的技術。這種方式從那個時候一直在持續被改進，並最終演化成了今天的Rest API的標準。這件事情，到2015的時候已經不再是一個障礙了，你現在可以使用任何語言，在任何系統上和其他語言的系統進行自由高效的通訊。在這個過程中，IT系統架構也隨之改變，從原來只能是一個廠商，一個操作系統，一個技術棧的煙囪式架構，逐漸演變成不同廠商，不同技術，不同操作系統的網狀架構 … … 其實這就是我們所說的集中式到分佈式，單體到微服務的整個演化過程。
這個過程中，企業管理者終於自由了，技術人員也終於自由了，大家不再受限於某種單一的技術，可以自由的選擇適合的組件來“拼裝”一個IT系統。這件事情同時也和整個開源運動互相推動。現如今，在一個IT系統中引入某種開源組件，或者與一個第三方系統進行集成都不再是一個技術問題。大家變得隨意，自由，敏捷起來。
但是，任何事情都有它的兩面性。在獲取了自由，敏捷的同時，整個IT架構變得無比複雜，開發人員開始組裝出高度異構化的系統，而運維環境也開始採用更加複雜的分佈式，x86，虛擬化和雲來支撐這類異構的系統。
這個時候，企業管理者的另外一個大麻煩又來了，如何管理這複雜的NxN問題？不僅僅技術變得更加複雜，人員知識結構也成為了一個巨大的瓶頸。原來的IT運維人員只需要掌握一個技術棧的知識，而現在每個服務都使用不同的技術棧運行在不同的硬件或者虛擬化平臺上。
這個問題也必須解決！
於是，聰明的技術人又一次發揮了充分的想象力，利用容器的方式完美的解決了這個問題。Docker通過統一開發人員打包交付代碼的方式，和統一運維人員運行軟件包的方式，讓開發人員做到“一次構建，多次運行”，讓運維人員做到“配置一次，運行任何應用”。
最終，Docker以自己特有的逆向思維模式用最簡單的方式解決了這個問題。具體請參考：Docker，容器，虛擬機和紅燒肉
如果你對運維自動化工具有所瞭解，就一定知曉Ansible, Chef, Puppet以及Vagrant等等這些工具。但，如果把Docker和這些工具做比較，你就會發現他們其實解決了同一個問題，但使用了2種完全不同的思路。Docker是用簡單的辦法解決複雜的問題，而其他那些工具都使用複雜的辦法來解決複雜的問題。
到這裡，我想我已經解答了前面2個問題，為什麼是容器和Docker?
為什麼是Kubernetes？
這個問題我想從《2018全球DevOps現狀調查報告》中針對雲計算發展的這張總結來說明，雲計算所需要具備的五個核心特徵恐怕大家都瞭解。但是即便過去這些年各大企業都在風風火火的建設自己的雲計算，但其實沒有幾個企業的所謂雲計算具備了這些特徵。特別是大多數傳統企業所建設的雲計算，都是打著雲計算的幌子繼續賣傳統數據中心的狗肉。
即便是已經上了公有云的很多企業，也仍然按照老的方式在使用先進的雲計算平臺，生生的把公有云用成了庫房裡面的服務器。
這些問題當然不僅僅是技術問題，還涉及到管理，文化和傳統思維方式的問題。但是拋開這些非技術因素不談，僅僅說技術，如果雲計算僅僅能夠解決IaaS層的問題，對於企業來說確實很難挖掘出真正的價值，最後也就是個虛擬化數據中心而已。企業業務真正需要的是PaaS層面的東西，但因為上述整個IT行業向異構化發展的趨勢，一直沒有一個真正的通用化的，可以被企業自己的數據中心玩得起來的PaaS出現。具體問題，可以看看CloudFoundry的發展現狀就知道了。
這個時候，恰好Docker出現了，那麼對於企業來說，上層對接應用技術棧的問題被完美解決了，還需要一個方案能夠完美解決對接底層IaaS雲計算基礎設施的對接問題。
這個問題也必須被解決。
可以這樣說，有了編排平臺，你可以在一個混合的雲環境上運行任何你想要運行的應用，不用關心技術棧，不用關心操作系統，不用關心哪朵雲，也不用關心應用在哪裡。你完全可以在Azure上放3個節點，在AWS放3個節點，另外在家裡的破舊服務器也放上3個節點來運行你的集群和應用。
編排平臺解決了困擾企業管理者上雲最大的擔憂，就是被廠商綁定，被技術綁定，被操作系統綁定。特別是傳統企業的管理者，終於找到了一個成熟的方案可以盤活自己花費巨資建立的"雲計算"數據中心，讓自己的“雲”成為一朵真的雲，真正為業務為開發者服務。
Kubernetes就是這樣一個技術，它滿足了企業管理者們這“最後一公里”的訴求。
閱讀更多 開源大學習 的文章
