強推！2019年最火的容器、K8S和DevOps入門都在這了

做者： Pasca

來源：蛋蛋團（公衆號ID：dandan_tuan）

前言

咱們回顧企業IT架構演進的整個歷史，不難看出企業主流形態都是依據馮諾依曼架構形態從計算機高度集中化，再到多用戶多任務的大型機和小型機，簡單歸納這個時期的特徵就是複雜且缺少統一的標準。

直到80年代X86服務器的誕生，企業IT形態走向水平分層：站點層、應用層、中間件層甚至是數據訪問層。 若是用一個詞來形容發展中的互聯網行業演變，我會說：突飛猛進。

傳統IT架構在互聯網急劇膨脹的數據增加下，沒法實現很好的解耦以及有效的分配資源。因而，以雲計算爲驅動的第三次IT架構融合變革浪潮，經過虛擬化與雲調度管理技術，將不一樣廠家彼此孤立的計算、存儲以及網絡設備邏輯上虛擬成一個「資源池」。同時應運而生的，還有容器、K8S、DevOps等技術與理念成爲雲計算產業新熱點。

「天下大勢，合久必分，分久必合！」， 這裏也體如今IT架構，當咱們瞭解了這種趨勢後，從而去根據業務需求選擇部署最適合的架構帶來成本的下降和效率的提高。

「工欲善其事，必先利其器！」，做爲互聯網從業者，不管是否隸屬於架構師職責，瞭解如容器、K8S等技術以及相輔而成的DevOps部署模式，才能更好的「玩轉雲計算」。

思考一個事物，筆者喜歡以2W1H邏輯模型去分析。

是什麼？爲何會出現？出現後會帶來怎樣的價值？本文文章脈絡也是如此。

一、容器是什麼？

容器，見到這個詞，咱們可能腦中就有一個「裝東西」概念。 沒錯，簡單來說，容器就是裝「應用」封裝，而後在任何位置均可以運行。就如同容器的logo，相似於一個集裝箱，容器能夠全部貨物打包，而且互相隔離。

視角移到軟件開發，當咱們在本地電腦上開發時（生產環節），可能本地已經適配好了所需的庫文件、擴展包、開發工具和開發框架等。而後在一個模擬生產環境的機器上進行測試經過後被用於生產環境（測試和上線）。 假設沒有用到容器，這三者的開發環境多是不同的，而後致使一系列的 Bug。

可是容器完美解決了這個問題。

正如 Docker 解釋的，「容器鏡像是軟件的一個輕量的、獨立的、可執行的包，包括了執行它所須要的全部東西：代碼、運行環境、系統工具、系統庫、設置。」

這表明着，一旦一個應用被封裝成容器，那麼它所依賴的下層環境就再也不重要了。它能夠在任何地方運行，甚至在混合雲環境下也能夠。

有數據代表，持續集成和持續部署 (CI/CD) 經過 Docker 加速應用管道自動化和應用部署，交付速度提升至少 13 倍。 固然，這只是容器的一個優勢，由於若是僅僅是這一個，虛擬機也能辦到這個事情。 打包成鏡像而後移交到另一臺虛擬機，可是容器有一個虛擬機沒法媲美的優勢: 輕量。

這裏的輕量指的是相比較於虛擬機動輒分鐘級的啓動時間，容器甚至能夠在毫秒級別啓動，而且相同宿主機，能夠爲容器給成千上百的應用獨立部署。 並且，相比較於虛擬機，容器的性能IO更接近於原生，這也是半死不活的DotCloud公司，當開源了這個公司內部項目後，不管是谷歌仍是微軟，又或者AWS，紛紛看到了容器的前景，加入docker開源社區。DotCloud也所以成爲了業內使人仰慕的公司。

而對於容器，咱們只須要記住三大特性：輕量、標準和獨立。

二、K8S是什麼？

首先，咱們來了解K8S是什麼。

K8S全稱爲Kubernetes，其諧音就是K8S，而後如今通俗講K8S都是指Kubernetes。 上面咱們簡單的介紹了下Docker，其實Docker只是應用容器引擎，也就是建立容器的工具。

Docker技術的三大核心概念，分別是：

• 鏡像（Image）
• 容器（Container）
• 倉庫（Repository）。

前二者咱們很好理解，鏡像是一種輕量級、可執行的獨立軟件包，它包含運行某個軟件所需的全部內容，容器就是承載這個鏡像運行的實例。

那這個倉庫又是什麼呢？

咱們先來思考下，有了鏡像後，能夠放到容器中去執行。可是從開發到測試，再到正式上線，這些鏡像是怎麼流轉的呢？

倉庫，就是提供一個集中的存儲、分發鏡像的服務。而每一個倉庫經過不一樣的標籤（Tag）對不一樣的鏡像分類。

通常而言，一個倉庫會包含同一個軟件不一樣版本的鏡像，而標籤就經常使用於對應該軟件的各個版本。

在K8S的章節裏講了如此多關於容器知識，爲啥不寫進前文呢？

主要是由於，K8S自己就是依託於容器而誕生的，二者密不可分。

K8S是一個開源的用於多個主機虛擬成一個雲平臺後進行容器資源管理和應用編排引擎，致力於讓部署容器化應用簡單而且高效，提供了應用的全生命週期管理，如應用部署，規劃，更新，維護等機制。

這裏有兩個關鍵詞須要重點mark下：多個主機、容器化應用。

K8S爲何出現？就是由於有了K8S，咱們能夠將整個大規模的服務器對計算資源抽象化經過一個個容器進行自動化且細緻化管理，將最終的應用服務交給用戶。

儘管谷歌是開源的K8S，但在谷歌內部已經大量使用了容器承載數據中心不一樣類型的應用負載，如谷歌搜索、大數據仍是仍是谷歌地圖等。當K8S發佈後，衆多的的互聯網企業能夠享受到鏈接衆多計算機成爲集羣資源池的好處。

也是由於K8S管理着不一樣的數據中心，每一個數據中心都由成千上萬的服務器聯接組成。因此通常來講，一個K8S系統也叫作K8S集羣。 而這個集羣，一般由兩個核心組件組成： • 一個Master節點（主節點） • 一羣Node節點（計算節點）

Master主節點主要負責集羣管理和控制Node節點，Node節點是物理機或虛擬機的主機節點，每一個Node節點提供Pod運行的必要服務，由Master主節點統一管理。

其中Master主節點提供了4個組件，具體功能以下：

• apiserver：資源操做惟一入口，符合Restful規範。
• controller-manager：全部資源的自動化管理控制中心，管理着一堆其餘控制器。
• scheduler：負責Pods在各個Node節點上的分配和調度，並提供多種Pod調度策略（預選和優選策略）。
• etcd：共享配置和服務發現的分佈式KV鍵值對存儲集羣，主要負責存儲持久性狀態。

除了這些，還有一個很重要的副本控制器（Replication Controller，RC）的概念。

設定RC爲3，經過controller-manager監控到不可用（即Pod少於3）時，會自動複製建立一個新的Pod。

其中Node節點主要包含Pod（沒錯，上面可能聽的很迷糊的那個pod）、kubelet、kube-proxy 、Docker和Fluentd等等。

這幾個組件的具體功能介紹以下：

• Pod：K8S部署的最小對象，內含1~n個容器和存儲卷，全部容器都是一個業務。重點：Pod是短暫的，不是持續性實體。
• kubelet：負責管理Pod的生命週期以及Pod的容器、鏡像、卷等。以及同步Master主節點本機註冊信息。
• kube-proxy：提供Pod之間的網絡代理通信和負載均衡。
• Docker：容器應用引擎。
• Fluentd ：主要負責日誌收集、存儲與查詢。

閱讀到這裏，也許你看完上文，對於K8S仍是迷迷糊糊，不要緊，很正常。

由於除了上述這些組件的介紹外，在K8S還有一些概念是必需要理解，這樣才能更好深入理解整個系統。 命名空間（Namespace）：爲K8S集羣提供虛擬的隔離做用，同一個Pod的容器確定在一個命名空間裏。 服務（Service）：Pod是短暫的，不是持續性實體。持久化容器數據是經過使用持久化的卷類型存在，一個服務後面都有不少對應的容器來提供支持，對外表現爲一個單一訪問域名。 標籤（labels）：用來更好讓你分類，是與一個資源關聯的鍵值對，這個資源大到集羣，小到Pod，皆可。 存儲卷（Volume）：每一個 Pod 中聲明的存儲卷由 Pod 中的全部容器共享，同時，卷的生命週期和Pod一致，一個Volume只是一個目錄，不過一個Pod支持多個Volume。

前面提到，Pod是短暫的、甚至能夠說是遊離的。那Pod重啓後，IP地址可能改變，怎麼前端容器正確可靠地指向後臺容器呢？

答案是經過Service。

Service是K8S的基本操做單元，是真實應用服務或者稱之爲一組Pod的抽象。經過 Kube-Proxy 的 port 和服務 selector 決定服務請求傳遞給後端的容器，外部無需關注後端如何運行，只要知道服務單一訪問域名便可。

下述GIF簡略的演示了部分的Service通訊功能，其中LoadBalancer是一個特殊類型的Service，也就是外部負載均衡。有容器，有了K8S，因而咱們就有了更多的想象空間。

好比，DevOps持續交付、微服務架構甚至是混合雲部署。本文暫且不提微服務和混合雲的部署，下面來簡單的講講DevOps是什麼。

三、DevOps是什麼？

近幾年，這個詞很火，特別是K8S和容器發展起來後，幾乎個個企業都喊着向DevOps前進。

那麼,DevOps究竟是什麼呢？

其實咱們講解容器的時候已經瞭解了一個持續集成和持續部署 (CI/CD)的概念，其實這就是一個實施DevOps的重要成果。最終以實現迅捷、高質量的服務交付爲目標，爲企業提高業務價值和響應能力。

簡單來說，DevOps一詞的來自於Development和Operations的組合，突出重視軟件開發人員和運維人員的溝通合做，經過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。

在DevOps以前，企業開發軟件通常採用瀑布流模式，看到瀑布兩個詞，你可能就對這種模式有個大概的瞭解了。從產品需求的提出，到最終的落地，它的開發模式是以下圖流程。

即，上述任何一個階段，都必須在前者所有完成才能進行下一步。並且，傳統軟件架構將系統分爲多個模塊，並不注重接口的契約化，瀑布流方式集成周期長暫且不說，集成一個模塊出現問題那麼其餘團隊也須要等待。

爲了解決這個問題，早在09年，DevOps就因傳統瀑布流開發模沒法知足快速迭代交付的需求而誕生，持續集成（CI）和持續部署（CD）方式，即小步快跑模式。可是這種模式也是由於近幾年容器和K8S等技術的成熟，才真正走進大小企業的殿堂。

因而，有了DevOps的開發模式變成了以下流程。

根據2018年度的DevOps報告數據代表，2014 年時，只有16%的調查參與者表示本身在 DevOps 團隊。而在 2018，這個數字已經增加到 27%。同時「DevOps」一詞的 Google Trends 以及 2019 年的預計增加假設。

全文《2018全球DevOps現狀報告》關鍵點以下：

• SDO效能解鎖競爭優點：提高盈利能力、生產力、市場份額、客戶滿意度，以及實現組織目標和使命的能力
• 如何實施雲基礎設施很關鍵：雲提升了軟件交付的效能。具有云計算全部核心特徵的團隊，其屬於高效能組織的可能性要高出23倍
• 開源軟件能夠提升效能：高效能組織普遍應用開源軟件的頻率比其餘組織要高1.75倍，而且在將來擴展開源軟件使用範圍的可能性是其餘團隊的1.5倍
• 精英效能團隊幾乎不採用職能外包：由於這會有損於效能 一般外包能夠節省成本並提供靈活的人力資源池，然而低效能組織將測試或運維等職能所有外包的比例，至少是高效能組織的4倍
• 關鍵技術實踐驅動高效能 ：這些實踐包括監控與可觀察性、持續測試、數據庫變動管理，以及儘早在軟件開發過程當中集成安全性
• 實現軟件交付的高效能與行業無關：咱們發如今強監管行業和弱監管行業中，都存在着在軟件交付方面實現了高效能的組織

最後，DevOps儘管有如此之多的優勢，可是並非全部的企業都可以完美的去實踐。

由於DevOps必定程度上，並不只僅是IT開發模式的改變，仍是企業公司組織的重構。而相比前者，後者更難。

2019年，DevOps是否會如預期中覆蓋更廣，爲更多企業帶來真正的效率開發，咱們拭目以待。

參考資料

10分鐘看懂Docker和K8S——來源：小棗君

2018全球DevOps現狀報告——來源：DevOps社區

Learn the Kubernetes Key Concepts in 10 Minutes——做者：Omer Dawelbeit

《雲計算架構技術與實踐》——做者：顧炯炯

七牛容器雲文檔

Docker中國文檔

K8S中文社區文檔