强推！2019年最火的容器、K8S和DevOps入门都在这了
戳藍字“CSDN云計算”關注我們哦！
技術頭條：干貨、簡潔、多維全面。更多云計算精華知識盡在眼前，get要點、solve難題，統統不在話下！
作者：?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全稱為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是什么。
近幾年，這個詞很火，特別是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中文社區文檔
福利
掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！
推薦閱讀：
漫畫：圖的?“最短路徑”?問題?|?技術頭條
一張“黑洞”照片需半噸重硬盤？更逆天的操作還有這些……
Python的10個“秘籍”，這些技術專家全都告訴你了
12?歲開始自學?Web?開發，他竟說初學者別搭理大牛？！
從?0?到管理?200?人，這位程序員是如何做到的？?|?程序員有話說
4000萬假幣流入波場, 發生在凌晨的BTT假幣攻擊事件始末及細節披露
馬云再談?996：真正的?996?與被剝削無關
真香，朕在看了！
總結
以上是生活随笔為你收集整理的强推！2019年最火的容器、K8S和DevOps入门都在这了的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 鞋店的利润有多大 简单给各位介绍下
- 下一篇： Boost：自定义双端队列的测试程序