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

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

作者：?Pasca

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

前言

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

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

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

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

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

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

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

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

1、容器是什么？

容器，見(jiàn)到這個(gè)詞，我們可能腦中就有一個(gè)“裝東西”概念。?

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

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

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

但是容器完美解決了這個(gè)問(wèn)題。

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

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

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

當(dāng)然，這只是容器的一個(gè)優(yōu)點(diǎn)，因?yàn)槿绻麅H僅是這一個(gè)，虛擬機(jī)也能辦到這個(gè)事情。

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

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

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

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

2、K8S是什么？

首先，我們來(lái)了解K8S是什么。

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

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

? 鏡像（Image）

? 容器（Container）

??倉(cāng)庫(kù)（Repository）。

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

那這個(gè)倉(cāng)庫(kù)又是什么呢？?

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

倉(cāng)庫(kù)，就是提供一個(gè)集中的存儲(chǔ)、分發(fā)鏡像的服務(wù)。而每個(gè)倉(cāng)庫(kù)通過(guò)不同的標(biāo)簽（Tag）對(duì)不同的鏡像分類。

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

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

主要是因?yàn)?#xff0c;K8S本身就是依托于容器而誕生的，兩者密不可分。

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

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

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

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

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

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

? 一個(gè)Master節(jié)點(diǎn)（主節(jié)點(diǎn)）

? 一群Node節(jié)點(diǎn)（計(jì)算節(jié)點(diǎn)）

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

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

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

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

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

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

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

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

其中Node節(jié)點(diǎn)主要包含Pod（沒(méi)錯(cuò)，上面可能聽(tīng)的很迷糊的那個(gè)pod）、kubelet、kube-proxy?、Docker和Fluentd等等。

這幾個(gè)組件的具體功能介紹如下：

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

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

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

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

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

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

因?yàn)槌松鲜鲞@些組件的介紹外，在K8S還有一些概念是必須要理解，這樣才能更好深刻理解整個(gè)系統(tǒng)。

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

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

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

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

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

答案是通過(guò)Service。

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

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

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

3、DevOps是什么？

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

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

參考資料

10分鐘看懂Docker和K8S——來(lái)源：小棗君?

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

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

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

七牛容器云文檔

Docker中國(guó)文檔?

K8S中文社區(qū)文檔

福利

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

推薦閱讀：

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

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

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

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

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

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

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

真香，朕在看了！

總結(jié)

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

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