這是一項顛覆性技術 - 容器

我從14年開始關注容器技術，15年開始使用容器技術，這些年看到了容器技術爆發式發展、版本的快速迭代，記得當時Docker版本仍是0.7，Kubernetes版本是1.0，到如今Docker CE 18，Kubernetes 11。
一門新技術的產生一定是爲解決某些問題而存在的，一樣也會帶來必定的問題，容器技術是一項顛覆性技術，改變了企業的CI/CD（持續集成/持續交付，部署）環節的方式，開啓了一場革命，咱們一塊兒看看這場革命怎麼實行的！

Docker是什麼？

2013年初，Docker橫空出世，一個懷揣着改變應用程序部署的革命技術，目前看來，顯然它作到了！
Docker是一個開源的應用容器引擎，對應用進程進行封裝隔離，而且獨立於宿主機與其餘進程。Docker理念是將應用及依賴包打包到一個可移植的鏡像中，能夠運行到任意Docker引擎上。具備快速部署、可移植性、環境隔離等特色。

Kubernetes是什麼？

Kubernetes（K8S）是Google開源的容器集羣管理系統，其設計源於Google在容器編排方面積累的豐富經驗，並結合社區創新的最佳實踐。
K8S在Docker容器技術的基礎之上，大大地提升了容器化部署應用簡單高效。而且具有了完整的集羣管理能力，例如服務發現、資源配額、縮容擴容、動態更新、持久化存儲、監控、日誌等，涵蓋項目週期的各個環節。
通過這幾年的快速發展，K8S已經成爲建設容器雲平臺的首選方案。

Docker與Kubernetes有什麼聯繫？

說到這裏，就涉及到容器雲平臺核心組成了。
Docker是一個容器引擎，用於運行容器，Kubernetes是一個容器編排系統，不具有容器引擎功能，相比Docker是一個更高級封裝，而他們在一塊兒堪稱珠聯璧合，一塊兒搞大事！如圖：

聊聊平常運維中的工做痛點

1. 多開發語言，多運行環境

公司發展迅速，業務量蹭蹭的往上漲，同時也會開展其餘業務線，打造本身的生態圈。多業務線維護給運維也帶來必定挑戰，例如多項目、多開發語言，例如開發語言有Java、Go、Python、還有PHP，這就意味着運行環境可能很是複雜，還要要維護多個版本，寫N個腳本、長期積累還會致使環境臃腫、雜亂、故障率高、不易維護等問題，當遷移業務時，這個不敢動，哪一個不敢動！

A：根據不一樣環境構建不一樣的鏡像，例如：

• 基礎鏡像：基本的運行環境，例如Java、PHP
• 項目鏡像：包含項目，可直接部署
  鏡像在鏡像倉庫中管理及維護，經過版本管理應用環境鏡像。

2. 環境不一致引起的爭議

開發人員一般在Mac、Windows系統上開發項目，功能上線，合併代碼到版本倉庫，隨後通知測試部門測試，測試經過後發佈到生產環境，目前大多數互聯網公司都是這種流程。
那麼問題來了，項目可能在測試環境或生產環境就運行不起來...，爲何呢？操做系統、軟件版本、少依賴包、配置忘記修改了等等？從而出現這些神祕的Bug，神祕的配置。有同窗可能說：寫一個參考文檔。一般還會有遺漏，並且這依賴於文檔編寫能力和理解能力。

A：容器消除了線上線下的環境差別，保證了應用生命週期的環境一致性和標準化。開發人員使用鏡像實現標準開發環境的構建，開發完成後封裝項目及依賴環境，測試和運維人員能夠直接用這個鏡像在任何Docker Engine建立容器進行測試和發佈，大大簡化了持續集成、測試和發佈的過程。Docker的可移植性，保持運行狀態一致性，可想而知，是否更容易解決問題呢？

3. 微服務架構帶來的問題

微服務架構是當下最流行的一種業務架構開發模式，目的是讓臃腫的業務系統拆分紅多個微服務，一個微服務完成某個特定的功能，如電商的購物車、支付、用戶後臺、消息等等。每個微服務都是微型六角形應用，都有本身的業務邏輯和適配器，微服務部署在多臺服務器上，每次項目升級都要java -jar啓動服務，維護幾十臺這樣的服務器，簡直苦不堪言，感受要吐血了。

A：
微服務特色：組件化、鬆耦合、去中心、靈活獨立。
容器特色：沙箱機制、隔離性、可移植性、快速部署。
是否是恰到好處呢？容器的特色在微服務下能更好發揮優點，是部署的理想選擇。

4. 項目上線週期長

立刻就61八、雙11了，到時業務訪問量會很大，得擴容服務器了。
新項目/擴容大體流程：申請資源 -> 資源審批 -> 虛擬機建立 -> 環境部署 -> 代碼測試 -> 上線。
多部門協做，這個流程起碼得一週吧！流程化提升必定生產力也可能帶來必定侷限：增長事項落實時間；那如何才能作到業務快速擴展併發能力和縮短上線週期呢？難道這個流程真的不能再優化了嘛？

A：說到彈性伸縮，在雲計算領域數AWS作的好了 - AWS Auto Scaling。AWS Auto Scaling 能夠監控您的應用程序並自動調整容量，以便以儘量低的成原本保持穩定、可預測的性能。使用 AWS Auto Scaling，您能夠在幾分鐘內爲多項服務中的多個資源輕鬆設置應用程序擴展，例如EC2（雲主機）。
當使用容器技術後，這種彈性伸縮的單元就是物理機/雲主機之上的容器了。因爲Docker容器快速啓動的特性，能夠在秒級部署幾十個、上百個容器來提供服務，成倍提升併發能力，縮短上線週期。當業務高峯期下去了，動態銷燬一部分容器，釋放資源，讓業務低成本穩定運行。

上述問題你有遇到過嗎？在容器技術未出現以前可能很難解決這些問題，但容器技術的出現針對這些痛點交出一份滿意的答卷，能幫助企業IT基礎架構解決或者改善現狀！

如何高效學習Docker/Kubernetes？

學習容器技術最大障礙不是網上資源太少，而是網上資源太多。大多數缺章少節的，很難按照教程跑通，而且Kubernetes具有豐富的功能，相對比較複雜，學習成本天然是有的；再說了，很簡單的技術在網上隨便找資料就能學會，也就沒什麼價值了。所以，決定寫Docker和Kubernetes技術文章專欄，目的是讓學習Kubernetes的朋友少走些彎路，在企業落地容器雲平臺提供一些企業實踐性指導，但願本身所學所思的東西可以幫助到你們，可以有所啓發。

此專欄以最佳實踐爲講解導向，確保實用性、實戰性。

專欄地址：基於Kubernetes企業容器雲平臺落地與實踐

若你在容器運維中，遇到Kubernetes方面的問題，請給我留言。一樣，若發現有任何紕漏，還請隨時指正，相互學習，共同進步！

記得點進去看看哦。

總結

1. 首先，咱們要明確企業上容器雲的目的，容器是爲業務服務的，任何技術都是爲了更好的服務業務，這是咱們的出發點。其次，看看業務特色是否是適合容器化，業務是否是具備版本迭代快、訪問波動大、業務量增加快等特色。
2. 容器平臺目的是能爲應用帶來部署靈活、彈性伸縮、節省資源等優點。這些要求最好具有微服務架構、無狀態化等特色，這些優點能更好的發揮。但不適合容器化的應用也不能勉強，不然建設後，不能帶來預期的價值，不只浪費了大量企業投入，還使得容器平臺的價值得不到承認，這都不肯意看到的結果。
3. 企業是一個大團隊，要想體現我的價值，管好本身的一畝三分地是不行的，咱們須要從一個全局角度看事情，發現其中的痛點去解決它；而且你們要創建一個統一的目標，共同圍繞這個方向使勁，向本身的客戶或用戶交付最大化價值及最高質量的成果；團隊以項目爲導向，而不是職責！
   這種文化也是DevOps所倡導的，頻發的交付帶來更迅速的反饋，更高效的CI/CD流程可間接帶來效益。