上文我們主要介紹了容器和Docker，第五部分我們來講Kubernetes與容器編排之戰。
在單機上運行容器，無法發揮它的最大效能，只有形成集羣，才能最大程度發揮容器的良好隔離、資源分配與編排管理的優勢。所以企業需要一套管理系統，對Docker及容器進行更高級更靈活的管理，按照用戶的意願和整個系統的規則，完全自動化的處理好容器之間的各種關係，這叫做編排（Orchestration）。
Orchestration這個詞來自於音樂領域，是指一種將不同樂器、音色加以合理的編排等手法營造出一個聽感交融、平衡的藝術，它完美地描述了容器編排的含義：爲單個應用程序（樂隊中的每種樂器）提供協同工作的模式。
在IT領域編排可以理解爲一種工作流，它能把整個IT系統都串接起來，然後自動化運作。在雲原生時代，整體式的應用早已成爲過去時，應用一般由單獨容器化的組件即微服務組成，而這些組件需要通過相互間的協同合作，才能使既定的應用按照設計運作。
2014年6月，IT基礎設施領域的領先者Google發佈了Kubernetes（簡寫爲K8S）（https://kubernetes.io）。編排概念並不是由Kubernetes第一個提出的，Kubernetes這個單詞來自於希臘語，含義是舵手或領航員。
Kubernetes是基於Docker的開源容器集羣管理系統，爲容器化的應用提供資源調度、部署運行、服務發現、擴容縮容等整一套功能，因爲容器本身可移植，所以Kubernetes容器集羣能跑在私有云、公有云或者混合雲上。
Kubernetes屬於主從的分佈式集羣架構，包含Master和Nodes。Master作爲控制節點，調度管理整個系統；Nodes是運行節點，負責運行應用。Pod是Kubernetes創建或部署的最小單位。一個Pod封裝一個或多個容器（Container）、存儲資源（Volume）、一個獨立的網絡IP以及管理控制容器運行方式的策略選項。
Kubernetes的主要功能包括：
• 資源調度：資源調度是一套分佈式系統最基本的核心指標
• 資源管理：控制Pod對計算資源、網絡資源、存儲資源的使用
• 服務發現：管理外在的程序或者內部的程序如何訪問Kubernetes裏面的某個Pod
• 健康檢查：監控檢測服務是否正常運行非常重要
• 自動伸縮：因爲涉及到環境的快速遷移和複製，虛擬機時代之前都非常難實現。容器化時代很自然的解決了這個問題，Kubernetes保證了資源的按需擴容
• 更新升級：Kubernetes爲服務的滾動和平滑升級提供了很好的機制
Kubernetes使用案例：滾動發佈
下面我們舉一個Kubernetes的應用場景，幫助大家更好的理解Kubernetes的用途。
應用程序升級面臨最大挑戰是新舊業務切換，將軟件從測試的最後階段帶到生產環境，同時要保證系統不間斷提供服務。長期以來，業務升級漸漸形成了幾個發佈策略：藍綠髮布、灰度發佈（金絲雀發佈）和滾動發佈，目的是儘可能避免因發佈導致的流量丟失或服務不可用問題。
在微服務架構盛行的時代，用戶希望應用程序時時刻刻可用，爲了滿足不斷變化的新業務，需要不斷升級更新應用程序，有時可能需要頻繁的發佈版本。實現"零停機"、“零感知”的持續集成和持續交付/部署應用程序，一直都是軟件升級換代必須面對的難題和追求的理想方式，也是DevOps誕生的目的。
滾動發佈/滾動更新（Rolling Update Deployment）是指每次只升級一個或多個服務，升級完成後加入生產環境，不斷執行這個過程，直到集羣中的全部舊版本升級成爲新版本。在整個滾動發佈期間，保證始終有可用的副本在運行，從而平滑的發佈新版本，實現零停機、用戶零感知，是雲原生時代非常主流的發佈方式。
下圖是滾動發佈的流程示意圖，Load Balance是前端的負載均衡器，橙色是正在運行舊版本服務的節點，紫色是正在更新及更新完畢新版本服務的節點。
可以看到，滾動發佈開始後（Step 2），負載均衡器將服務器A從集羣裏摘除，服務器A進行新版本的發佈，由服務器B和服務器C對外提供版本1.0的服務；Step 3，服務器A更新完畢，部署驗證成功，負載均衡器將其加入集羣，開始和服務器C一起對外提供不同版本的服務，同時服務器B開始發佈；直至服務器ABC全部發布完成（Step 5），服務都更新到最新的2.0版本。
滾動發佈的優點是用戶無感知，平滑過渡，同時不需要冗餘服務器，節省資源。不足是部署時間慢，取決於每階段的更新時間；發佈策略較複雜；同時涉及自動化的更新策略、部署驗證、回滾機制等等，自動化程度比較高，通常需要複雜的發佈工具支撐，而Kubernetes正好可以完美的支持這個任務。
Kubernetes通用的編排模式是控制循環，用僞代碼表示如下：
解釋一下，Kubernetes集羣本身狀態就是實際狀態，而期望狀態來自於用戶提交的配置文件。滾動發佈的時候，Kubernetes將會根據這個控制循環，使用一個叫做Deployment的控制器，通過創建新的集羣（下圖中的v2版本ReplicaSet複製集）將其控制的Pod副本從0個逐漸變成3個，與此同時舊的集羣（下圖中v1版本的ReplicaSet）管理的Pod副本數則從3個逐漸變成0個，以此將一個集羣中正在運行的多個Pod交替的逐一升級，實現滾動發佈的效果。
如果在發佈剛開始的時候，集羣裏只有1個新版本的Pod，這個Pod有問題啓動不起來，那麼滾動發佈就會停止，開發和運維可以及時介入解決問題。而應用本身還有舊版本的集羣和Pod在線，所以服務不會受到任何影響。關於滾動發佈的詳細介紹和互動教程可以閱讀這裏。
下面這張圖展示了使用Kubernetes，配合代碼倉庫GitLab、Docker鏡像倉庫Harbor、構建工具Jenkins，實現自動化的CI/CD流程。
上一部分結束時我們提到，傳統IT架構好比傳統工廠，容器化好比現代化工廠，而Kubernetes則是智能化的無人工廠，讓容器和應用能夠高效自動、井然有序的被控制和管理；Kubernetes還實現了服務的抽象、解耦、高擴展、統一調度與集中化管理，例如用戶可以專注用同樣的方式在不同硬件上的應用，比如GPU節點池和低優先級的CPU節點池。Kubernetes不僅解決了容器的編排問題，讓容器應用進入大規模工業生產，更進一步對雲原生應用提供了定義規範，CNCF整個技術棧都是圍繞Kubernetes建立，所以Kubernetes是雲原生生態最重要的基石，可以說“Kubernetes是雲原生時代的Linux”，即雲原生應用的操作系統。
回到本文第一部分，我們曾經用集裝箱革命比喻雲原生。現在大家已經理解，貨船可以類比操作系統，集裝箱類比容器，裏面裝的貨物則是一個個的微服務，吊臂、吊橋、起重機等自動化操作設備是Kubernetes，而一整套集裝箱的操作方法和流程則是DevOps。所有這些加起來構成了現代PaaS所具備的能力：操作系統、集羣管理、應用編排、應用發佈、持續集成等等。
容器編排之戰
意識到容器編排的重要性，Docker在2014年發佈了Docker Swarm（Swarm是蜂羣的意思），以一個整體來對外提供集羣管理功能，最大的亮點就是全部使用Docker項目原來的容器管理API來完成集羣管理。
同時從2014年底開始，Docker收購了最先提出容器編排概念的Fig項目，並改名爲Compose（Compose是作曲的意思），它可以用來組裝多容器的應用，並在Swarm集羣中部署分佈式應用。
2014年Kubernetes發佈之後，爲了與Swarm競爭，在容器編排地位取得絕對的優勢，Google、RedHat等開源基礎設施公司共同發起了CNCF基金會，希望以Kubernetes爲基礎，建立一個由開源基礎設施領域廠商主導、按照獨立基金會方式運營的平臺社區，來對抗以Docker公司爲核心的容器商業生態。
一方面Kubernetes脫胎於Google內部久負盛名的大規模集羣管理系統Borg，是Google在容器化基礎設施領域十餘年實踐經驗的沉澱和昇華，Google利用Kubernetes的架構和設計思想成功將其所有應用（搜索、地圖、視頻、金融、社交、人工智能）運行在超過100萬臺服務器、超過80個數據中心，每週的20億個容器上，所以Kubernetes是唯一具有超過10年以上大規模容器生產使用的技術經驗和積澱的開源項目。並且Kubernetes採用了非常優雅的軟件工程設計和開源開放的態度，使得用戶可以根據自己的使用場景、通過靈活插拔的方式，採用自定義的網絡、存儲、調度、監控、日誌等模塊，所以在Github上的各項指標一路飆升，將較爲簡單、並且生態自閉的Swarm項目遠遠地甩在了後邊。CNCF社區也迅速增加了一系列容器生態的知名工具和項目，大量的公司和初創團隊將注意力投向CNCF社區而不再是Docker，CNCF本質上成爲了以Kubernetes爲核心的生態系統。
企業服務大廠也紛紛加入Kubernetes平臺戰局，在公有云或者私有PaaS平臺上來發展自己的Kubernetes產品。像微軟直接找來Kubernetes聯合創始人Brendan Burns負責領導Azure容器服務團隊，自身的混合雲產品Azure Stack也大力支持Kubernetes。IBM同樣也靠以Kubernetes爲核心的PaaS軟件IBM Cloud Private來搶佔企業私有云容器平臺市場，尤其是微服務的管理需求。很早就支持Kubernetes的Redhat，在2015年推出的OpenShift 3.0版中，不惜放棄自己的容器調度工具，開始支持Kubernetes，現在更成爲了支持跨多雲、混合雲架構，以及裸機、容器和虛擬機的企業級通用應用管理平臺。而虛擬化龍頭VMware也改爲力推主打通喫多家IaaS和Kubernetes集羣管理的容器服務軟件，甲骨文也在旗下雲端服務支持Kubernetes。
在用戶、社區和大廠的支持中，Kubernetes逐步成爲企業基礎架構的部署標準和新一代的應用服務層。
2016年，面對CNCF的競爭優勢，Docker公司宣佈放棄現有的Swarm項目，將容器編排和集羣管理功能轉到Docker項目當中。然而這種改變帶來的技術複雜度和維護難度，給Docker項目造成了非常不利的局面。不同於Docker，Kubernetes推進的民主化架構從API到容器運行的每一層，都給開發者暴露出了可擴展的插件機制，鼓勵用戶通過代碼的方式介入每一個階段。Kubernetes的變革非常有效，很快在整個容器社區中催生出了大量的、基於Kubernetes API和擴展接口的二次創新產品，例如前文提到的Istio等等。Docker公司在Kubernetes社區崛起和壯大後，敗下陣來。
2017年，Docker公司將容器運行時部分Containerd捐獻給CNCF社區，並在自己主打產品Docker企業版中內置Kubernetes項目，持續了兩年的容器編排之爭終於落下帷幕，Kubernetes成爲了最後的勝利者，而Docker輸掉了最關鍵的一仗，失去了成爲雲原生時代操作系統的機會。
Docker在最重要的容器編排之戰中失敗，帶給我們的教訓包括：
• 開源不等於免費，開源是一種商業模式，一個開源組織和開源項目要想生存下去，最重要的基礎就是普遍被使用，不然很快就會被競爭者替代
• 開源技術終將走向商業，包括Docker，必然面臨企業市場的挑戰
• Docker進入企業級市場，有優勢也有劣勢，優勢是挾Docker的大量開發者，劣勢是沒有做過企業級市場，開發者市場和企業級市場的做法完全不同
• Docker在競爭中失利，看起來是時機和生態構建的問題，但歸根結底是基因和能力問題
此係列文章的前五部分，我們詳細介紹了雲原生的各種理念和技術。在最後一部分，我們將展開總結和思考，分析雲原生時代的機遇與挑戰。
下一期內容爲《雲原生時代（六）：機會與思考》。
參考文檔：
本文的部分內容參考或者引用以下文章，在此表示感謝，如果有涉及知識產權的問題，請聯繫我及時修改。