戳藍(lán)字“CSDN云計算”關(guān)注我們哦！

技術(shù)頭條：干貨、簡潔、多維全面。更多云計算精華知識盡在眼前，get要點、solve難題，統(tǒng)統(tǒng)不在話下！

作者：?Pasca

來源：蛋蛋團(tuán)（ID：dandan_tuan）

前言

我們回顧企業(yè)IT架構(gòu)演進(jìn)的整個歷史，不難看出企業(yè)主流形態(tài)都是依據(jù)馮諾依曼架構(gòu)形態(tài)從計算機(jī)高度集中化，再到多用戶多任務(wù)的大型機(jī)和小型機(jī)，簡單概括這個時期的特征就是復(fù)雜且缺乏統(tǒng)一的標(biāo)準(zhǔn)。

直到80年代X86服務(wù)器的誕生，企業(yè)IT形態(tài)走向水平分層：站點層、應(yīng)用層、中間件層甚至是數(shù)據(jù)訪問層。

如果用一個詞來形容發(fā)展中的互聯(lián)網(wǎng)行業(yè)演變，我會說：日新月異。?

傳統(tǒng)IT架構(gòu)在互聯(lián)網(wǎng)急劇膨脹的數(shù)據(jù)增長下，無法實現(xiàn)很好的解耦以及有效的分配資源。于是，以云計算為驅(qū)動的第三次IT架構(gòu)融合變革浪潮，通過虛擬化與云調(diào)度管理技術(shù)，將不同廠家彼此孤立的計算、存儲以及網(wǎng)絡(luò)設(shè)備邏輯上虛擬成一個“資源池”。同時應(yīng)運而生的，還有容器、K8S、DevOps等技術(shù)與理念成為云計算產(chǎn)業(yè)新熱點。

“天下大勢，合久必分，分久必合！”，這里也體現(xiàn)在IT架構(gòu)，當(dāng)我們了解了這種趨勢后，從而去根據(jù)業(yè)務(wù)需求選擇部署最適合的架構(gòu)帶來成本的降低和效率的提升。

“工欲善其事，必先利其器！”，作為互聯(lián)網(wǎng)從業(yè)者，無論是否隸屬于架構(gòu)師職責(zé)，了解如容器、K8S等技術(shù)以及相輔而成的DevOps部署模式，才能更好的“玩轉(zhuǎn)云計算”。

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

是什么？為什么會出現(xiàn)？出現(xiàn)后會帶來怎樣的價值？本文文章脈絡(luò)也是如此。

1、容器是什么？

容器，見到這個詞，我們可能腦中就有一個“裝東西”概念。?

沒錯，簡單來講，容器就是裝“應(yīng)用”封裝，然后在任何位置都可以運行。就如同容器的logo，類似于一個集裝箱，容器可以所有貨物打包，并且互相隔離。

視角移到軟件開發(fā)，當(dāng)我們在本地電腦上開發(fā)時（生產(chǎn)環(huán)節(jié)），可能本地已經(jīng)適配好了所需的庫文件、擴(kuò)展包、開發(fā)工具和開發(fā)框架等。然后在一個模擬生產(chǎn)環(huán)境的機(jī)器上進(jìn)行測試通過后被用于生產(chǎn)環(huán)境（測試和上線）。?

假設(shè)沒有用到容器，這三者的開發(fā)環(huán)境可能是不一樣的，然后導(dǎo)致一系列的?Bug。

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

正如?Docker?解釋的，“容器鏡像是軟件的一個輕量的、獨立的、可執(zhí)行的包，包括了執(zhí)行它所需要的所有東西：代碼、運行環(huán)境、系統(tǒng)工具、系統(tǒng)庫、設(shè)置。”

這代表著，一旦一個應(yīng)用被封裝成容器，那么它所依賴的下層環(huán)境就不再重要了。它可以在任何地方運行，甚至在混合云環(huán)境下也可以。

有數(shù)據(jù)表明，持續(xù)集成和持續(xù)部署?(CI/CD)?通過?Docker?加速應(yīng)用管道自動化和應(yīng)用部署，交付速度提高至少?13?倍。

當(dāng)然，這只是容器的一個優(yōu)點，因為如果僅僅是這一個，虛擬機(jī)也能辦到這個事情。

打包成鏡像然后移交到另外一臺虛擬機(jī)，但是容器有一個虛擬機(jī)無法媲美的優(yōu)點:輕量。

這里的輕量指的是相比較于虛擬機(jī)動輒分鐘級的啟動時間，容器甚至可以在毫秒級別啟動，并且相同宿主機(jī)，可以為容器給成千上百的應(yīng)用獨立部署。

而且，相比較于虛擬機(jī)，容器的性能IO更接近于原生，這也是半死不活的DotCloud公司，當(dāng)開源了這個公司內(nèi)部項目后，無論是谷歌還是微軟，又或者AWS，紛紛看到了容器的前景，加入docker開源社區(qū)。DotCloud也因此成為了業(yè)內(nèi)令人仰慕的公司。

而對于容器，我們只需要記住三大特性：輕量、標(biāo)準(zhǔn)和獨立。

2、K8S是什么？

首先，我們來了解K8S是什么。

K8S全稱為Kubernetes，其諧音就是K8S，然后現(xiàn)在通俗講K8S都是指Kubernetes。?上面我們簡單的介紹了下Docker，其實Docker只是應(yīng)用容器引擎，也就是創(chuàng)建容器的工具。?

Docker技術(shù)的三大核心概念，分別是：

? 鏡像（Image）

? 容器（Container）

??倉庫（Repository）。

前兩者我們很好理解，鏡像是一種輕量級、可執(zhí)行的獨立軟件包，它包含運行某個軟件所需的所有內(nèi)容，容器就是承載這個鏡像運行的實例。?

那這個倉庫又是什么呢？?

我們先來思考下，有了鏡像后，可以放到容器中去執(zhí)行。但是從開發(fā)到測試，再到正式上線，這些鏡像是怎么流轉(zhuǎn)的呢？?

倉庫，就是提供一個集中的存儲、分發(fā)鏡像的服務(wù)。而每個倉庫通過不同的標(biāo)簽（Tag）對不同的鏡像分類。

一般而言，一個倉庫會包含同一個軟件不同版本的鏡像，而標(biāo)簽就常用于對應(yīng)該軟件的各個版本。

在K8S的章節(jié)里講了如此多關(guān)于容器知識，為啥不寫進(jìn)前文呢？?

主要是因為，K8S本身就是依托于容器而誕生的，兩者密不可分。

K8S是一個開源的用于多個主機(jī)虛擬成一個云平臺后進(jìn)行容器資源管理和應(yīng)用編排引擎，致力于讓部署容器化應(yīng)用簡單并且高效，提供了應(yīng)用的全生命周期管理，如應(yīng)用部署，規(guī)劃，更新，維護(hù)等機(jī)制。?

這里有兩個關(guān)鍵詞需要重點mark下：多個主機(jī)、容器化應(yīng)用。

K8S為什么出現(xiàn)？就是因為有了K8S，我們可以將整個大規(guī)模的服務(wù)器對計算資源抽象化通過一個個容器進(jìn)行自動化且細(xì)致化管理，將最終的應(yīng)用服務(wù)交給用戶。?

盡管谷歌是開源的K8S，但在谷歌內(nèi)部已經(jīng)大量使用了容器承載數(shù)據(jù)中心不同類型的應(yīng)用負(fù)載，如谷歌搜索、大數(shù)據(jù)還是還是谷歌地圖等。當(dāng)K8S發(fā)布后，眾多的的互聯(lián)網(wǎng)企業(yè)可以享受到連接眾多計算機(jī)成為集群資源池的好處。

也是因為K8S管理著不同的數(shù)據(jù)中心，每個數(shù)據(jù)中心都由成千上萬的服務(wù)器聯(lián)接組成。所以一般來說，一個K8S系統(tǒng)也叫做K8S集群。

而這個集群，通常由兩個核心組件組成：

? 一個Master節(jié)點（主節(jié)點）

? 一群Node節(jié)點（計算節(jié)點）

Master主節(jié)點主要負(fù)責(zé)集群管理和控制Node節(jié)點，Node節(jié)點是物理機(jī)或虛擬機(jī)的主機(jī)節(jié)點，每個Node節(jié)點提供Pod運行的必要服務(wù)，由Master主節(jié)點統(tǒng)一管理。?

其中Master主節(jié)點提供了4個組件，具體功能如下：

• apiserver：資源操作唯一入口，符合Restful規(guī)范。

• controller-manager：所有資源的自動化管理控制中心，管理著一堆其他控制器。

• scheduler：負(fù)責(zé)Pods在各個Node節(jié)點上的分配和調(diào)度，并提供多種Pod調(diào)度策略（預(yù)選和優(yōu)選策略）。

• etcd：共享配置和服務(wù)發(fā)現(xiàn)的分布式KV鍵值對存儲集群，主要負(fù)責(zé)存儲持久性狀態(tài)。

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

設(shè)定RC為3，通過controller-manager監(jiān)控到不可用（即Pod少于3）時，會自動復(fù)制創(chuàng)建一個新的Pod。

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

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

• Pod：K8S部署的最小對象，內(nèi)含1~n個容器和存儲卷，所有容器都是一個業(yè)務(wù)。重點：Pod是短暫的，不是持續(xù)性實體。

• kubelet：負(fù)責(zé)管理Pod的生命周期以及Pod的容器、鏡像、卷等。以及同步Master主節(jié)點本機(jī)注冊信息。

• kube-proxy：提供Pod之間的網(wǎng)絡(luò)代理通訊和負(fù)載均衡。

• Docker：容器應(yīng)用引擎。

• ?Fluentd?：主要負(fù)責(zé)日志收集、存儲與查詢。

閱讀到這里，也許你看完上文，對于K8S還是迷迷糊糊，沒關(guān)系，很正常。

因為除了上述這些組件的介紹外，在K8S還有一些概念是必須要理解，這樣才能更好深刻理解整個系統(tǒng)。

• 命名空間（Namespace）：為K8S集群提供虛擬的隔離作用，同一個Pod的容器肯定在一個命名空間里。

• 服務(wù)（Service）：Pod是短暫的，不是持續(xù)性實體。持久化容器數(shù)據(jù)是通過使用持久化的卷類型存在，一個服務(wù)后面都有很多對應(yīng)的容器來提供支持，對外表現(xiàn)為一個單一訪問域名。

• 標(biāo)簽（labels）：用來更好讓你分類，是與一個資源關(guān)聯(lián)的鍵值對，這個資源大到集群，小到Pod，皆可。

• 存儲卷（Volume）：每個?Pod?中聲明的存儲卷由?Pod?中的所有容器共享，同時，卷的生命周期和Pod一致，一個Volume只是一個目錄，不過一個Pod支持多個Volume。

前面提到，Pod是短暫的、甚至可以說是游離的。那Pod重啟后，IP地址可能改變，怎么前端容器正確可靠地指向后臺容器呢？

答案是通過Service。

Service是K8S的基本操作單元，是真實應(yīng)用服務(wù)或者稱之為一組Pod的抽象。通過?Kube-Proxy?的?port?和服務(wù)?selector?決定服務(wù)請求傳遞給后端的容器，外部無需關(guān)注后端如何運行，只要知道服務(wù)單一訪問域名即可。

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

比如，DevOps持續(xù)交付、微服務(wù)架構(gòu)甚至是混合云部署。本文暫且不提微服務(wù)和混合云的部署，下面來簡單的講講DevOps是什么。

3、DevOps是什么？

近幾年，這個詞很火，特別是K8S和容器發(fā)展起來后，幾乎個個企業(yè)都喊著向DevOps前進(jìn)。?

那么,DevOps到底是什么呢？?

其實我們講解容器的時候已經(jīng)了解了一個持續(xù)集成和持續(xù)部署?(CI/CD)的概念，其實這就是一個實施DevOps的重要成果。最終以實現(xiàn)迅捷、高質(zhì)量的服務(wù)交付為目標(biāo)，為企業(yè)提升業(yè)務(wù)價值和響應(yīng)能力。?

簡單來講，DevOps一詞的來自于Development和Operations的組合，突出重視軟件開發(fā)人員和運維人員的溝通合作，通過自動化流程來使得軟件構(gòu)建、測試、發(fā)布更加快捷、頻繁和可靠。

在DevOps之前，企業(yè)開發(fā)軟件一般采用瀑布流模式，看到瀑布兩個詞，你可能就對這種模式有個大概的了解了。從產(chǎn)品需求的提出，到最終的落地，它的開發(fā)模式是如下圖流程。?

即，上述任何一個階段，都必須在前者全部完成才能進(jìn)行下一步。而且，傳統(tǒng)軟件架構(gòu)將系統(tǒng)分為多個模塊，并不注重接口的契約化，瀑布流方式集成周期長暫且不說，集成一個模塊出現(xiàn)問題那么其他團(tuán)隊也需要等待。?

為了解決這個問題，早在09年，DevOps就因傳統(tǒng)瀑布流開發(fā)模無法滿足快速迭代交付的需求而誕生，持續(xù)集成（CI）和持續(xù)部署（CD）方式，即小步快跑模式。但是這種模式也是因為近幾年容器和K8S等技術(shù)的成熟，才真正走進(jìn)大小企業(yè)的殿堂。

于是，有了DevOps的開發(fā)模式變成了如下流程。

根據(jù)2018年度的DevOps報告數(shù)據(jù)表明，2014?年時，只有16%的調(diào)查參與者表示自己在?DevOps?團(tuán)隊。而在?2018，這個數(shù)字已經(jīng)增長到?27%。同時“DevOps”一詞的?Google?Trends?以及?2019?年的預(yù)計增長假設(shè)。

?

全文《2018全球DevOps現(xiàn)狀報告》關(guān)鍵點如下：

• SDO效能解鎖競爭優(yōu)勢：提升盈利能力、生產(chǎn)力、市場份額、客戶滿意度，以及實現(xiàn)組織目標(biāo)和使命的能力

• 如何實施云基礎(chǔ)設(shè)施很關(guān)鍵：云提高了軟件交付的效能。具備云計算所有核心特征的團(tuán)隊，其屬于高效能組織的可能性要高出23倍

• 開源軟件可以提高效能：高效能組織廣泛應(yīng)用開源軟件的頻率比其他組織要高1.75倍，并且在未來擴(kuò)展開源軟件使用范圍的可能性是其他團(tuán)隊的1.5倍

• 精英效能團(tuán)隊幾乎不采用職能外包：因為這會有損于效能 通常外包可以節(jié)省成本并提供靈活的人力資源池，然而低效能組織將測試或運維等職能全部外包的比例，至少是高效能組織的4倍

• 關(guān)鍵技術(shù)實踐驅(qū)動高效能?：這些實踐包括監(jiān)控與可觀察性、持續(xù)測試、數(shù)據(jù)庫變更管理，以及盡早在軟件開發(fā)過程中集成安全性

• 實現(xiàn)軟件交付的高效能與行業(yè)無關(guān)：我們發(fā)現(xiàn)在強(qiáng)監(jiān)管行業(yè)和弱監(jiān)管行業(yè)中，都存在著在軟件交付方面實現(xiàn)了高效能的組織

最后，DevOps盡管有如此之多的優(yōu)點，但是并不是所有的企業(yè)都能夠完美的去實踐。

因為DevOps一定程度上，并不僅僅是IT開發(fā)模式的改變，還是企業(yè)公司組織的重構(gòu)。而相比前者，后者更難。

2019年，DevOps是否會如預(yù)期中覆蓋更廣，為更多企業(yè)帶來真正的效率開發(fā)，我們拭目以待。

參考資料

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

2018全球DevOps現(xiàn)狀報告——來源：DevOps社區(qū)

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

《云計算架構(gòu)技術(shù)與實踐》——作者：顧炯炯

七牛容器云文檔

Docker中國文檔?

K8S中文社區(qū)文檔

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學(xué)習(xí)交流群】，和志同道合的朋友們共同打卡學(xué)習(xí)！

推薦閱讀：

• 漫畫：圖的?“最短路徑”?問題?|?技術(shù)頭條

• 一張“黑洞”照片需半噸重硬盤？更逆天的操作還有這些……

• Python的10個“秘籍”，這些技術(shù)專家全都告訴你了

• 12?歲開始自學(xué)?Web?開發(fā)，他竟說初學(xué)者別搭理大牛？！

• 從?0?到管理?200?人，這位程序員是如何做到的？?|?程序員有話說

• 4000萬假幣流入波場, 發(fā)生在凌晨的BTT假幣攻擊事件始末及細(xì)節(jié)披露

• 馬云再談?996：真正的?996?與被剝削無關(guān)
  

真香，朕在看了！

總結(jié)

以上是生活随笔為你收集整理的强推！2019年最火的容器、K8S和DevOps入门都在这了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。