本課時，我們就開始正式進入 Kubernetes 的學習，或許你已經聽過或簡單了解過 Kubernetes，它是一款由 Google 開源的容器編排管理工具，而我們想要深入地掌握 Kubernetes 框架，就不得不先了解 Kubernetes 的前世今生，而這一切都要從“云計算”的興起開始講起。

云計算平臺

說來也巧，“云計算”這個概念也是由 Google 提出的，可見這家公司對計算機技術發展的貢獻有多大。自云計算 2006 年被提出后，已經逐漸成為信息技術產業發展的戰略重點，你可能也會切身感受到變化。我們平時在討論技術的時候，經常會被問到諸如“你們公司的業務是否要考慮上云”的問題，而國內相關的云計算大會近幾年也如雨后春筍般地召開，可見其有多么火熱。

而云計算之所以可以這么快地發展起來，主要原因還是可以為企業帶來便利，同時又能降低成本，國內的各大傳統型企業的基礎設施紛紛向云計算轉型，從阿里云、騰訊云每年的發展規模我們就可以看出來云計算市場對人才的需求有多大。

這里，我們可以將經典的云計算架構分為三大服務層：也就是 IaaS（Infrastructure as a Service，基礎設施即服務）、PaaS（Platform as a Service，平臺即服務）和 SaaS（Software as a Service，軟件即服務）。

• IaaS 層通過虛擬化技術提供計算、存儲、網絡等基礎資源，可以在上面部署各種 OS 以及應用程序。開發者可以通過云廠商提供的 API 控制整個基礎架構，無須對其進行物理上的維護和管理。

• PaaS 層提供軟件部署平臺（runtime），抽象掉了硬件和操作系統，可以無縫地擴展（scaling）。開發者只需要關注自己的業務邏輯，不需要關注底層。

• SaaS 層直接為開發者提供軟件服務，將軟件的開發、管理、部署等全部都交給第三方，用戶不需要再關心技術問題，可以拿來即用。

（圖片引自https://www.aalpha.net/blog/the-difference-between-paas-iaas-and-saas/）

這樣解釋起來可能會有點抽象，我們可以想象自己要去一個地方旅行，那么首先就需要解決住的問題，而 IaaS 服務就相當于直接在當地購買了一套商品房，像搭建系統、維護運行環境這種“裝修”的事情就必須由我們自己來，但優點是“裝修風格”可以自己定。

PaaS 則要簡單一點，我們到了一個陌生的城市，可以選擇住民宿或青旅，這樣就不需要考慮裝修和買家具的事情了，系統和環境都是現成的，我們只需要安裝自己的運行程序就可以了。

而 SaaS 就更簡單了，相當于直接住酒店，一切需求都由供應商搞定了，我們只需要選擇自己喜歡的房間風格和戶型就可以了，這時從操作系統到運行的具體軟件都不再需要我們自己操心了。

上面，我們了解了云計算的概念，既然上云可以給我們帶來這么多的便利，那么我們該如何讓系統上云呢？

以前主流的做法就是申請或創建一批云服務（Elastic Compute Service），比如亞馬遜的 AWS EC2、阿里云 ECS 或者 OpenStack 的虛擬機，然后通過 Ansible、Puppet 這類部署工具在機器上部署應用。

但隨著應用的規模變得越來越龐大，邏輯也越來越復雜，迭代更新也越來越頻繁，這時我們就逐漸發現了一些問題，比如：

• 性價比低，資源利用率低

有時候用戶只是希望運行一些簡單的程序而已，比如跑一個小進程，為了不相互影響，就要建立虛擬機。這顯然會浪費不少資源，畢竟 IaaS 層產品都是按照資源進行收費的。同時操作也比較復雜，花費時間也會比較長；

• 遷移成本高

如果想要遷移整個自己的服務程序，就要遷移整個虛擬機。顯然，遷移過程也會很復雜；

• 環境不一致

在進行業務部署發布的過程中，服務之間的各種依賴，比如操作系統、開發語言及其版本、依賴的庫/包等，都給業務開發和升級帶來很大的制約。

如果沒有 Docker 的橫空出世，這些問題解決起來似乎有些困難。

Docker

Docker 這個新的容器管理引擎大大降低了使用容器技術的門檻，輕量、可移植、跨平臺、鏡像一致性保障等優異的特性，一下子解放了生產力。開發者可以根據自己的喜好選擇合適的編程語言和框架，然后通過微服務的方式組合起來。交付同學可以利用容器保證交付版本和交付環境的一致性，也便于各個模塊的單獨升級。測試人員也可以只針對單個功能模塊進行測試，加快測試驗證的速度。

在某一段時期內，大家一提到 Docker，就和容器等價起來，認為 Docker 就是容器，容器就是Docker。其實容器是一個相當古老的概念，并不是 Docker發明的，但 Docker 卻為其注入了新的靈魂——Docker 鏡像。

Docker 鏡像解決了環境打包的問題，它直接打包了應用運行所需要的整個“操作系統”，而且不會出現任何兼容性問題，它賦予了本地環境和云端環境無差別的能力，這樣避免了用戶通過“試錯”來匹配不同環境之間差異的痛苦過程， 這便是 Docker 的精髓。

它通過簡單的 Dockerfile 來描述整個環境，使開發者可以隨時隨地構建無差別的鏡像，方便了鏡像的分發和傳播。相較于以往通過光盤、U盤、ISO文件等方式進行環境的拷貝復制，Docker鏡像無疑把開發者體驗提高到了前所未有的高度。這也是 Docker 風靡全球的一個重要原因。

有了 Docker，開發人員可以輕松地將其生產環境復制為可立即運行的容器應用程序，讓工作更有效率。越來越多的機構在容器中運行著生產業務，而且這一使用比例也越來越高。我們來看看CNCF （Cloud Native Computing Foundation，云計算基金會）在2019年做的調研報告。

容器使用數量低于249 個的比例自2018年開始下降了 26%，而使用容器數目高于 250 個的比例增加了 28%。可以預見的是，未來企業應用容器化會越來越常見，使用容器進行交付、生產、部署是大勢所趨，也是企業進行技術改造，業務快速升級的利器。

我們為什么需要容器調度平臺

有了容器，開發人員就只需要考慮如何恰當地擴展、部署，以及管理他們新開發的應用程序。但如果我們大規模地使用容器，就不得不考慮容器調度、部署、跨多節點訪問、自動伸縮等問題。

接下來，我們來看看一個容器編排引擎到底需要哪些能力才能解決上述這些棘手的問題。

一個容器調度系統到底需要什么

如表所示，首先容器調度平臺可以自動生成容器實例，然后是生成的容器可以相鄰或者相隔，幫助提高可用性和性能，還有健康檢查、容錯、可擴展、網絡等功能，它幾乎完美地解決了需求與資源的匹配編排問題。

既然容器調度平臺功能這樣強大，市場競爭必定是風云逐鹿的，其實主流的容器管理調度平臺有三個，分別是Docker Swarm、Mesos Marathon和Kubernetes，它們有各自的特點。但是同時滿足上面所述的八大能力的容器調度平臺，其實非 Kubernetes 莫屬了。

Swarm 是 Docker 公司自己的產品，會直接調度 Docker 容器，并且使用標準的 Docker API 語義，為用戶提供無縫銜接的使用體驗。 Swarm 更多的是面向于開發者，而且對容錯性支持不夠好。

Mesos 是一個分布式資源管理平臺，提供了 Framework 注冊機制。接入的框架必須有一個Framework Scheduler 模塊負責框架內部的任務調度，還有一個 Framework Executor 負責啟動運行框架內的任務。Mesos 采用了雙層調度架構，首先 Mesos 將資源分配給框架，然后每個框架使用自己的調度器將資源分配給內部的各個任務使用，比如 Marathon 就是這樣的一個框架，主要負責為容器工作負載提供擴展、自我修復等功能。

Kubernetes 的目標就是消除編排物理或者虛擬計算、網絡和存儲等基礎設施負擔，讓應用運營商和開發工作者可以專注在以容器為核心的應用上面，同時可以優化集群的資源利用率。Kubernetes 采用了 Pod 和 Label 這樣的概念，把容器組合成一個個相互依賴的邏輯單元，相關容器被組合成 Pod 后被共同部署和調度，就形成了服務，這也是 Kuberentes 和其他兩個調度管理系統最大的區別。

相對來說，Kubernetes 采用這樣的方式簡化了集群范圍內相關容器被共同調度管理的復雜性。換種角度來說，Kubernetes 能夠相對容易的支持更強大、更復雜的容器調度算法。

根據 StackRox 的統計數據表明，Kubernetes 在容器調度領域占據了 86% 的市場份額，雖說Kubernetes 的部署方式千差萬別。以前絕大多數人都是采用自建的方式來管理 Kubernetes 集群的，現在已經逐漸采用公有云的 Kubernetes 服務。可見，Kubernetes 越來越成熟，也越來越受到市場的青睞。

（https://www.stackrox.com/kubernetes-adoption-and-security-trends-and-market-share-for-containers/）

依據 Google Trends 收集的數據，自 Kubernetes出現以后，便呈黑馬態勢一路開掛，迅速并牢牢占據頭把交椅位置，最終成為容器調度的事實標準。

Kubernetes 成為事實標準

2014 年 6 月 7 日的第一個 commit 拉開了 Kubernetes 的序幕。它基于 Google 內部超過 15 年歷史的大規模集群管理系統 Borg ，集結其精華，可以對容器進行編排管理、自動部署、彈性伸縮等操作，它于 2015 年 7 月 21 日正式對外發布第一版本，走進了大眾視線。

其實，Kubernetes 這個詞由 Joe Beda，Brendan Burns和 Craig McLuckie 所創建，源于希臘語的“舵手”或者“領航員”，簡稱“K8s”，用 8 代替 8 個字符“ubernete”而成的縮寫。

經過 6 年的時間，Kubernetes 成為云廠商的“寵兒”，而且國內的諸多大廠已經在生產環境中大規模使用 Kubernetes，用于運行自己的核心業務系統，無數中小企業也都在進行業務容器化探索以及云原生化改造，比如阿里的螞蟻金服已經有線上業務在使用了。

各大云廠商對Kubernetes的支持力度

（圖片來自https://www.datadoghq.com/container-report/）

我們來看看 Kubernetes 是如何憑借自身的優勢走紅的。

首先，Kubernetes 的成功離不開 Borg。目前Google 內部依然大規模運行著 Borg，上面跑著我們熟悉的 Google 搜索、Gmail、Youtube 等業務。正是因為從 Borg 當中借鑒了相當多優秀的設計經驗，并改進了很多不合理的設計。這些無疑都是促成 Kubernetes 邁向成功的先決條件。Kubernetes 提供了很多方便使用的抽象定義幫助我們對容器進行一些操作，同時可擴展能力強，便于用戶定制開發。我們將在后面的課程里慢慢了解到 Kubernetes 這些設計理念和實現方式。

其次，Kubernetes 并不會跟任何平臺綁定，它可以跑在任何環境里，包括公有云、私有云、物理機，甚至筆記本和樹莓派都可以運行，避免了用戶對于廠商鎖定 (vendor-lockin) 的擔憂。

接著，Kubernetes 的上手門檻很低。通過 minikube 這類工具，就可以在你的筆記本上快速搭建一套 Kubernetes 集群出來。我會在后面的課程里，教你更多集群的搭建方法，畢竟搭建生產使用的集群還是需要花費一些功夫的。這相比較于 mesos + marathon 方便了很多，你可以更快更直接地上手 Kubernetes。

再次，Kubernetes 使用了聲明式API，這也是從 Borg 中借鑒來的設計。所謂聲明式，就是指你只需要提交一個定義好的?API?對象來聲明你所期望的對象是什么樣子即可，而無須過多關注如何達到最終的狀態。Kubernetes 可以在無外界干預的情況下，完成對實際狀態和期望狀態的調和（Reconcile）工作。

在Kubernetes中，你可以直接通過 YAML 或者 JSON 進行聲明，然后通過?PATCH?的方式就可以完成對?API?對象的多次修改，而無須關心原始?YAML 或 JSON?文件的內容。可以說聲明式?API 也是?Kubernetes?項目能夠成為事實標準的一個核心所在。

最后，圍繞著 Kubernetes 的相關生態異常活躍，它有自己的開發者社區，為開發者提供了交流各種方案的平臺，社區開放包容，而且協作程度高。目前 CNCF 也吸引著諸多孵化中的新項目。

可以預見的是，未來Kubernetes的使用會更加普遍，圍繞著Kubernetes構建的生態也會越來越好。

寫在最后

Kubernetes 是為數不多的能夠成長為基礎技術的技術之一，就像 Linux、OS 虛擬化和 Git一樣成為各自領域的佼佼者。簡單來說，Kubernetes是如今所有云應用程序開發機構能做出的最安全的投資，如果運用得當，它可以幫助大幅提升開發和交付的速度以及質量。

下節課，我們一起來了解 Kubernetes 的架構。如果你有什么想法或疑問，歡迎你在留言區留言，我們一起討論。

---

總結

以上是生活随笔為你收集整理的01-前世今生：Kubernete 是如何火起来的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。