1. 程式人生 > >這是一項顛覆性技術 - 容器

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

操作 思維導圖 虛擬機創建 指導 根據 col 雲計 size 申請

我從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. 項目上線周期長

馬上就618、雙11了,到時業務訪問量會很大,得擴容服務器了。
新項目/擴容大致流程:申請資源 -> 資源審批 -> 虛擬機創建 -> 環境部署 -> 代碼測試 -> 上線。
多部門協作,這個流程起碼得一周吧!流程化提高一定生產力也可能帶來一定局限:增加事項落實時間;那如何才能做到業務快速擴展並發能力和縮短上線周期呢?難道這個流程真的不能再優化了嘛?

A:說到彈性伸縮,在雲計算領域數AWS做的好了 - AWS Auto Scaling。AWS Auto Scaling 可以監控您的應用程序並自動調整容量,以便以盡可能低的成本來保持穩定、可預測的性能。使用 AWS Auto Scaling,您可以在幾分鐘內為多項服務中的多個資源輕松設置應用程序擴展,例如EC2(雲主機)。
當使用容器技術後,這種彈性伸縮的單元就是物理機/雲主機之上的容器了。由於Docker容器快速啟動的特性,可以在秒級部署幾十個、上百個容器來提供服務,成倍提高並發能力,縮短上線周期。當業務高峰期下去了,動態銷毀一部分容器,釋放資源,讓業務低成本穩定運行。

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

如何高效學習Docker/Kubernetes?

學習容器技術最大障礙不是網上資源太少,而是網上資源太多。大多數缺章少節的,很難按照教程跑通,並且Kubernetes具備豐富的功能,相對比較復雜,學習成本自然是有的;再說了,很簡單的技術在網上隨便找資料就能學會,也就沒什麽價值了。因此,總結了一些學習DockerKubernetes技術的思維導圖,幫助你快速建立學習體系。

技術分享圖片

技術分享圖片

針對上述學習效率問題,我決定寫DockerKubernetes技術文章專欄,目的是讓學習Kubernetes的朋友少走些彎路,在企業落地容器雲平臺提供一些企業實踐性指導,希望自己所學所思的東西能夠幫助到大家,能夠有所啟發。

此專欄講解上述思維導圖中的80%內容,以最佳實踐為講解導向,確保實用性、實戰性。

技術分享圖片

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

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

記得點進去看看哦。

總結

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

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