作者： Pasca
來源：蛋蛋團（公眾號ID：dandan_tuan）
前言
我們回顧企業IT架構演進的整個歷史，不難看出企業主流形態都是依據馮諾依曼架構形態從計算機高度集中化，再到多使用者多工的大型機和小型機，簡單概括這個時期的特徵就是複雜且缺乏統一的標準。
直到80年代X86伺服器的誕生，企業IT形態走向水平分層：站點層、應用層、中介軟體層甚至是資料訪問層。 如果用一個詞來形容發展中的網際網路行業演變，我會說：日新月異。
傳統IT架構在網際網路急劇膨脹的資料增長下，無法實現很好的解耦以及有效的分配資源。於是，以雲端計算為驅動的第三次IT架構融合變革浪潮，通過虛擬化與雲排程管理技術，將不同廠家彼此孤立的計算、儲存以及網路裝置邏輯上虛擬成一個“資源池”。同時應運而生的，還有容器、K8S、DevOps等技術與理念成為雲端計算產業新熱點。
“天下大勢，合久必分，分久必合！”， 這裡也體現在IT架構，當我們瞭解了這種趨勢後，從而去根據業務需求選擇部署最適合的架構帶來成本的降低和效率的提升。
“工欲善其事，必先利其器！”，作為網際網路從業者，無論是否隸屬於架構師職責，瞭解如容器、K8S等技術以及相輔而成的DevOps部署模式，才能更好的“玩轉雲端計算”。
思考一個事物，筆者喜歡以2W1H邏輯模型去分析。
是什麼？為什麼會出現？出現後會帶來怎樣的價值？本文文章脈絡也是如此。
1、容器是什麼？
容器，見到這個詞，我們可能腦中就有一個“裝東西”概念。 沒錯，簡單來講，容器就是裝“應用”封裝，然後在任何位置都可以執行。就如同容器的logo，類似於一個集裝箱，容器可以所有貨物打包，並且互相隔離。
視角移到軟體開發，當我們在本地電腦上開發時（生產環節），可能本地已經適配好了所需的庫檔案、擴充套件包、開發工具和開發框架等。然後在一個模擬生產環境的機器上進行測試通過後被用於生產環境（測試和上線）。 假設沒有用到容器，這三者的開發環境可能是不一樣的，然後導致一系列的 Bug。
但是容器完美解決了這個問題。
正如 Docker 解釋的，“容器映象是軟體的一個輕量的、獨立的、可執行的包，包括了執行它所需要的所有東西：程式碼、執行環境、系統工具、系統庫、設定。”
這代表著，一旦一個應用被封裝成容器，那麼它所依賴的下層環境就不再重要了。它可以在任何地方執行，甚至在混合雲環境下也可以。
這裡的輕量指的是相比較於虛擬機器動輒分鐘級的啟動時間，容器甚至可以在毫秒級別啟動，並且相同宿主機，可以為容器給成千上百的應用獨立部署。 而且，相比較於虛擬機器，容器的效能IO更接近於原生，這也是半死不活的DotCloud公司，當開源了這個公司內部專案後，無論是谷歌還是微軟，又或者AWS，紛紛看到了容器的前景，加入docker開源社群。DotCloud也因此成為了業內令人仰慕的公司。
而對於容器，我們只需要記住三大特性：輕量、標準和獨立。
2、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。
這幾個元件的具體功能介紹如下：
- 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，於是我們就有了更多的想象空間。
3、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中文社群文件