Kubernetes 已在容器編排之戰(zhàn)中取勝，未來很可能會(huì)成為“多云”之上的標(biāo)準(zhǔn)層，進(jìn)而為分布式系統(tǒng)的分發(fā)和運(yùn)行帶來根本性的改變，而其自身則會(huì)慢慢變得像 Linux Kernel 一樣，成為一種系統(tǒng)底層的支撐，不再引人注目。

本文金句：

• 通過 Kubernetes，分布式系統(tǒng)工具將擁有網(wǎng)絡(luò)效應(yīng)。每當(dāng)人們?yōu)?Kubernetes 制作出的新的工具，都會(huì)讓所有其他工具更完善。因此，這進(jìn)一步鞏固了 Kubernetes 的標(biāo)準(zhǔn)地位。
• 云提供商并非可替換的商品。不同的云提供的服務(wù)會(huì)變得越來越獨(dú)特和不同。如果可以訪問不同的云提供商提供的不同服務(wù)，那么企業(yè)將因此受益。
• 當(dāng)多節(jié)點(diǎn)應(yīng)用與單節(jié)點(diǎn)應(yīng)用一樣可靠時(shí)，我們將看到定價(jià)模型的變化。
• 這就是為什么我會(huì)被 Kubernetes 洗腦的原因，它是跨越異構(gòu)系統(tǒng)的一個(gè)標(biāo)準(zhǔn)層。
• 將來，我們會(huì)像討論編譯器和操作系統(tǒng)內(nèi)核一樣討論 Kubernetes。 Kubernetes 將會(huì)是低層級的管路系統(tǒng)，而不在普通應(yīng)用開發(fā)人員的視野之內(nèi)。

Kubernetes 已成為部署分布式應(yīng)用的標(biāo)準(zhǔn)方式。在不遠(yuǎn)的將來，任何新成立的互聯(lián)網(wǎng)公司都將用到 Kubernetes，無論其是否意識(shí)到這點(diǎn)。許多舊應(yīng)用也正在遷移到 Kubernetes。

在 Kubernetes 之前，特定的分布式系統(tǒng)平臺(tái)還沒有一個(gè)標(biāo)準(zhǔn)。正如 Linux 是針對單個(gè)節(jié)點(diǎn)的標(biāo)準(zhǔn)的服務(wù)器側(cè)操作系統(tǒng)那樣，Kubernetes 已成為編排應(yīng)用節(jié)點(diǎn)的標(biāo)準(zhǔn)方式。

通過 Kubernetes，分布式系統(tǒng)工具將擁有網(wǎng)絡(luò)效應(yīng)。每當(dāng)人們?yōu)?Kubernetes 制作出新的工具，都會(huì)讓所有其他工具更完善。因此，這進(jìn)一步鞏固了 Kubernetes 的標(biāo)準(zhǔn)地位。

谷歌、微軟、亞馬遜和 IBM 都有自己的 Kubernetes 即服務(wù)產(chǎn)品，這讓我們在大型云提供商之間切換基礎(chǔ)設(shè)施變得更加簡單。

我們將很有可能看到 Digital Ocean、Heroku 和其他長尾型云提供商開始提供受管理的和托管 Kubernetes 服務(wù)。

在這邊文章中，我將探討以下問題：

• 為什么正在發(fā)生這種情況？
• 對于開發(fā)者來說這意味著什么?
• 云提供商將受到什么影響？
• 在 Kubernetes 標(biāo)準(zhǔn)化的世界中，有哪些新的業(yè)務(wù)模型將會(huì)出現(xiàn)？

軟件標(biāo)準(zhǔn)

標(biāo)準(zhǔn)化的軟件平臺(tái)有利有弊。

標(biāo)準(zhǔn)讓開發(fā)者可以對軟件的運(yùn)行方式抱有一定的預(yù)期。如果一個(gè)開發(fā)者為某個(gè)標(biāo)準(zhǔn)化平臺(tái)構(gòu)建了某個(gè)產(chǎn)品，他可以評估出該軟件的目標(biāo)市場總規(guī)模。

如果你用 JavaScript 寫了一個(gè)程序，你會(huì)知道它將會(huì)在所有人的瀏覽器中運(yùn)行。如果你給 iOS 創(chuàng)作了一個(gè)游戲，你會(huì)知道每個(gè)有 iPhone 的人都可以下載它。

如果你構(gòu)建了一個(gè)工具來分析 .NET 中的垃圾收集，你會(huì)知道大量的 Windows 開發(fā)者會(huì)遇到內(nèi)存問題，所以他們會(huì)購買你的軟件。

標(biāo)準(zhǔn)化的專有平臺(tái)可以給平臺(tái)提供者創(chuàng)造大量的利潤。1995 年，Windows 這個(gè)很好的平臺(tái)讓微軟能夠以 100 美元的價(jià)格售出一個(gè)只是紙盒子裝著的光盤。

2018 年，iPhone 這個(gè)很好的平臺(tái)讓蘋果能夠從平臺(tái)所有的應(yīng)用銷售額中拿走 30%。

但是專有的標(biāo)準(zhǔn)會(huì)導(dǎo)致分裂。

比如，你的 iPhone 應(yīng)用無法在 Kindle Fire 上運(yùn)行。我不能在 Facebook Messenger（臉書信使）上使用你的 Snapchat 增強(qiáng)現(xiàn)實(shí)貼紙。

我最喜歡的數(shù)字音頻工作站[1]只能在 Windows 上使用，所以我不得不使用 Windows 電腦來制作音樂。

當(dāng)開發(fā)者們見到這種分裂時(shí)，他們會(huì)抱怨。他們會(huì)聯(lián)想到貪婪的資本家，這些資本家為了賺錢，不惜犧牲軟件的質(zhì)量。

開發(fā)者們會(huì)想：“為什么人們不能和諧共處？”為什么我們不能讓所有東西開放和免費(fèi)？開發(fā)者們還會(huì)想：“我們不需要專有標(biāo)準(zhǔn)。我們可以擁有開放標(biāo)準(zhǔn)。”

Apache 的增長，Apache 是 LAMP (Linux、 Apache、MySQL 和 PHP)堆棧的一部分，Linux 就曾發(fā)生過這樣的事。

現(xiàn)在，大多數(shù)新的服務(wù)側(cè)應(yīng)用都在使用 Linux。但曾經(jīng)有一段時(shí)間，人們對此有爭議。見上圖的左側(cè)遠(yuǎn)端部分。

最近，我們還看到了一個(gè)更新的開放標(biāo)準(zhǔn)：Docker。Docker 給了我們一個(gè)開放、標(biāo)準(zhǔn)化的打包、部署和分布單個(gè)節(jié)點(diǎn)的方法。

這極其有價(jià)值！但在 Docker 解決的所有大問題之中，有個(gè)新的問題非常突出，那就是我們應(yīng)該如何將這些節(jié)點(diǎn)編排到一起？

畢竟，你的應(yīng)用肯定不只是單個(gè)節(jié)點(diǎn)。你知道自己希望部署一個(gè) Docker 容器，但是容器應(yīng)該如何相互通信呢？你如何向上擴(kuò)展容器實(shí)例呢？你如何在容器實(shí)例之間路由流量呢?

容器編排

在 Docker 流行之后，一大批開源項(xiàng)目和專有平臺(tái)紛紛出現(xiàn)，以解決容器編排的問題。

Mesos、Docker Swarm 和 Kubernetes 均提供了不同的抽象來管理容器。Amazon ECS 提供了一個(gè)專有的受管的服務(wù)，它可以為 AWS 用戶提供 Docker 容器的安裝和擴(kuò)展服務(wù)。

有些開發(fā)者并未采用任何編排平臺(tái)，而是使用 BASH、Puppet、Chef 和其他工具來為他們的部署編寫腳本。

無論一個(gè)開發(fā)者是否使用編排平臺(tái)或者腳本來部署容器，Docker 都可以加快開發(fā)，并且讓開發(fā)者和運(yùn)營之間更加和諧。

隨著愈來愈多的開發(fā)者使用 Docker 來部署容器，編排平臺(tái)的重要性日益突出。容器對于分布式系統(tǒng)的重要性就如同對象對于面向?qū)ο蟪绦虻闹匾阅菢覽2]。

所有人都希望使用容器平臺(tái)，但是眾多平臺(tái)之間存在著競爭，很難看出哪個(gè)平臺(tái)會(huì)最終勝出，所以這可能會(huì)是持續(xù)十多年的競爭，就如 iOS 和安卓的競爭那樣。

這樣的競爭正在制造分裂。這并不是因?yàn)榱餍械木幣趴蚣苁菍Ｓ械模⊿warm、Kubernetes 和 Mesos 都是開源的），而是因?yàn)槊總€(gè)容器編排社區(qū)都已經(jīng)在自己的系統(tǒng)上投入了太多資金。

所以，從 2013 到 2016 年，Docker 用戶一直有種隱憂。選擇容器編排框架就像一次豪賭，如果你選擇了錯(cuò)誤的編排系統(tǒng)，這就好像你開了一家影像店，卻選擇了高清 DVD，而不是藍(lán)光光碟[3]。

[[222273]]

集裝箱（container）船傾覆的圖片從不過時(shí)。

正如在所有戰(zhàn)爭中那樣，總是有一層霧，讓我們很難看透彼此。在我報(bào)道容器編排之戰(zhàn)時(shí)，我曾用一條條播客記錄我和容器編排專家的談話，其中，我會(huì)問到這樣的問題，”那么，哪一個(gè)容器編排系統(tǒng)會(huì)贏？“

我一直這么做，直到某個(gè)我十分景仰之人告訴我問這樣的問題一點(diǎn)也沒有意思，還不如評估一下不同編排商之間的技術(shù)權(quán)衡。

回首過去，我后悔自己被不同容器編排商之間的戰(zhàn)爭的故事所吸引。

當(dāng)有關(guān)容器編排商的辯論如火如荼時(shí)，甚至是我這樣的記者也被這樣的情緒激發(fā)，并且認(rèn)為這將是一場與派系斗爭有關(guān)的故事時(shí)，那些最聰明的人大多數(shù)卻正在進(jìn)行著平靜和科學(xué)的談?wù)摗?/p>

容器編排之戰(zhàn)并非是一場派系斗爭，而更多的是觀點(diǎn)和開發(fā)者工程學(xué)之間的差異。

[[222274]]

好吧，或許容器編排之戰(zhàn)并不只是觀點(diǎn)之間的差異。因?yàn)檫@個(gè)領(lǐng)域?qū)?huì)創(chuàng)造大量財(cái)富。我們現(xiàn)在談?wù)摰氖桥c數(shù)十億市值的老組織如銀行、電信公司和保險(xiǎn)公司之間的合同，這些組織正在逐步向云遷移。

如果你正在幫助電信公司遷移到正確的平臺(tái)，那么你的業(yè)務(wù)會(huì)很好。但如果你擁護(hù)了錯(cuò)誤的平臺(tái)，最終你只會(huì)得到一倉庫的高清 DVD。

沖突最嚴(yán)重的時(shí)間大約是 2016 年底，那時(shí)有關(guān)于 Docker 可能出現(xiàn)分歧的傳言，原因是因?yàn)?Docker 公司想改變 Docker 標(biāo)準(zhǔn)，以更好地適配其容器編排系統(tǒng) Docker Swarm[4]。但即使在那時(shí)，做一個(gè)樂觀者仍然是明智的。

具有毀滅性的創(chuàng)新會(huì)帶來痛苦，但它是一個(gè)進(jìn)步的標(biāo)志。在爭取容器編排統(tǒng)治地位的斗爭中，出現(xiàn)了許許多多的毀滅性創(chuàng)新。

但在 2016 底迷霧消散之后，Kubernetes 成了明顯的獲勝者。

今天，隨著 Kubernetes 成為保險(xiǎn)的選擇，CIO 們對在企業(yè)中采用容器編排感到更安全了，這也讓廠商更愿意投入到 Kubernetes 專用的工具中，并且把這些工具銷售給這些 CIO。

讓我們來看看現(xiàn)狀：

• 開源開發(fā)者正在朝同樣的方向前進(jìn)，并且為他們能構(gòu)建的東西感到興奮。
• 大公司（無論是新還是老）都在逐漸采用 Kubernetes。
• 大型云提供商也準(zhǔn)備好迎接低成本的 Kubernetes 即服務(wù)。
• 監(jiān)控、日志記錄、安全和合規(guī)軟件廠商也極為激動(dòng)，因?yàn)樗麄兡芨尤菀椎仡A(yù)測自己要集成的底層軟件堆棧了。

走向多云化

今天，盈利最多的專有后端開發(fā)者基礎(chǔ)設(shè)施提供商就是亞馬遜 AWS 云服務(wù)。開發(fā)者并不憎恨 AWS，因?yàn)?AWS 是創(chuàng)新和具備使能性的，并且便宜。如果你在 AWS 花了很多錢，那說明你的生意很好。

通過 AWS，開發(fā)者不會(huì)感到 90 年代時(shí)的主導(dǎo)專有平臺(tái)所給人的那種被鎖定的感覺。

但仍然有一些鎖定感。一旦你深深地扎根于 AWS 的生態(tài)系統(tǒng)中，并使用如 DynamoDB、Amazon Elastic Container Service（彈性容器服務(wù)）、或 Amazon Kinesis 服務(wù)時(shí)，你會(huì)發(fā)現(xiàn)你很難再脫離亞馬遜。

然而，由于 Kubernetes 為基礎(chǔ)設(shè)施創(chuàng)造的是一個(gè)開放、共有的層，所以理論上，將你的 Kubernetes 集群從一個(gè)云提供商處”遷移到“另一個(gè)提供商那里是可行的。

如果你決定遷移你的應(yīng)用，你需要重寫應(yīng)用的部分組件來停止使用亞馬遜特定的服務(wù)（如亞馬遜 S3）。

例如，如果你想要一個(gè)可以在任何云上運(yùn)行的 S3 替代品，你可以配置一個(gè)帶 Rook[5] 的 Kubernetes 集群，并使用與你在 S3 上使用的相同 API 來存儲(chǔ)對象到 Rook 上。

這是一個(gè)很好的選項(xiàng)，但是我還從未聽說過誰真正地將他們的應(yīng)用從云中遷走，除了 Dropbox[6] 之外，但他們的遷移是如此宏大，以至于耗費(fèi)了 2 年半的時(shí)間[7]。

當(dāng)然，除了 Dropbox 之外，肯定還有其他人也在亞馬遜 S3 上投入了很多錢，雖然他們也想創(chuàng)造自己的對象存儲(chǔ)，但是遷移會(huì)非常費(fèi)力。

（Kubernetes 可以被用于遷移應(yīng)用，但更可能會(huì)用于在不同的云之中提供相似的操作層）

在不遠(yuǎn)的將來，Kubernetes 或許不會(huì)成為一個(gè)廣泛用于應(yīng)用遷移的工具。更可能的情況是 Kubernetes 將會(huì)成為一個(gè)無所不在的控制平面，企業(yè)可以在多個(gè)云上使用它。

NodeJS 便是一個(gè)有用的類比。為什么人們喜歡 NodeJS 的服務(wù)器側(cè)應(yīng)用？這并不一定是因?yàn)?NodeJS 是最快的 Web 服務(wù)器，而是因?yàn)槿藗兿矚g在客戶端和服務(wù)器上使用相同的語言。

NodeJS 可以讓你在客戶端和服務(wù)器節(jié)點(diǎn)切換，而無需切換語言，同樣，Kubernetes 也能讓你在不同的云之間切換，而無需改變運(yùn)營方式。

在每個(gè)云上，你都會(huì)有一些定制的應(yīng)用代碼，它們由 Kubernetes 運(yùn)行，并且與那個(gè)云提供的受管服務(wù)進(jìn)行交互。

企業(yè)希望多云化，部分是因?yàn)槿轂?zāi)的考慮，但還因?yàn)樵L問不同云上的受管服務(wù)有實(shí)際的好處。

一個(gè)新出現(xiàn)的模式是將基礎(chǔ)設(shè)施分布于 AWS（用于用戶流量）和 Google Cloud（用于數(shù)據(jù)工程）上。Thumbtack[8] 公司正在使用此模式。

在 Thumbtack，位于 AWS 的生產(chǎn)基礎(chǔ)設(shè)施負(fù)責(zé)處理用戶請求。事務(wù)日志將從 AWS 推送到 Google Cloud，并在那里進(jìn)行數(shù)據(jù)工程。

在 Google Cloud 上，事務(wù)記錄在 Cloud PubSub 中排隊(duì)。Cloud PubSub 是一個(gè)信息隊(duì)列服務(wù)。這些事務(wù)會(huì)從隊(duì)列里被抽出，并存儲(chǔ)在 BigQuery 中，BigQuery 是一個(gè)存儲(chǔ)和查詢大量數(shù)據(jù)的系統(tǒng)。

BigQuery 充當(dāng)編排機(jī)器學(xué)習(xí)任務(wù)時(shí)的數(shù)據(jù)池，以便人們從中抽取數(shù)據(jù)。這些機(jī)器學(xué)習(xí)任務(wù)是在 Cloud Dataproc 中運(yùn)行的，Cloud Dataproc 是一個(gè)運(yùn)行 Apache Spark 的服務(wù)。

在 Google Cloud 上訓(xùn)練好一個(gè)模型之后，這個(gè)模型會(huì)被部署到 AWS 側(cè)，然后處理用戶流量。在 Google Cloud 側(cè)，這些不同的受管服務(wù)的編排是由Apache Airflow完成的。

Apache Airflow 是一個(gè)開源工具。Thumbtack 在 Google Cloud 上管理自己時(shí)，需要 Apache Airflow。

今天，Thumbtack 用 AWS 來處理用戶請求，并用 Google Cloud 來進(jìn)行 PubSub 中的數(shù)據(jù)工程和排隊(duì)。Thumbtack 在谷歌中訓(xùn)練其機(jī)器學(xué)習(xí)模型，并將它們部署到 AWS 中。

這就是今天我們常見的現(xiàn)象。Thumbtack 最終或許還會(huì)將 Google Cloud 用于面向用戶的服務(wù)。

某家日本公司采用的多云化的數(shù)據(jù)工程流水線

越來越多的公司將逐漸遷移至多個(gè)云，而且它們當(dāng)中的某些公司會(huì)在每個(gè)云上管理獨(dú)立的 Kubernetes 集群。

你可能在谷歌上有一個(gè) GKE Kubernetes 集群來編排 BigQuery、Cloud PubSub 和 Google Cloud ML 之間的負(fù)載。

而且你可能會(huì)有一個(gè) Amazon EKS 集群來編排 DynamoDB、 Amazon Aurora 和你的生產(chǎn) NodeJS 應(yīng)用之間的負(fù)載。

云提供商并非可替換的商品。不同的云提供的服務(wù)會(huì)變得越來越獨(dú)特和不同。如果可以訪問不同的云提供商提供的不同服務(wù)，那么企業(yè)將因此受益。

分布式系統(tǒng)分發(fā)

Google BigQuery 等 AWS Redshift 服務(wù)十分流行，因?yàn)樗鼈兘o了你強(qiáng)大、可擴(kuò)展和多節(jié)點(diǎn)的工具，而且 API 還簡單。開發(fā)者經(jīng)常選擇這些受管服務(wù)，因?yàn)樗鼈兪侨绱撕糜谩?/p>

針對單個(gè)節(jié)點(diǎn)的付費(fèi)工具并不常見。我不需要給 NodeJS、React 或 Ruby on Rails 付費(fèi)。

針對單個(gè)節(jié)點(diǎn)的工具比針對分布式系統(tǒng)的工具用起來更容易。相比于在我的筆記本上運(yùn)行 Ruby on Rails 應(yīng)用來說，在許多服務(wù)器上部署 Hadoop 難多了。然而，有了 Kubernetes 后，這一切都將改變。

如果你正在使用 Kubernetes，你可以使用一個(gè)名叫 Helm 的分布式系統(tǒng)包管理器。它就好比是用于 Kubernetes 應(yīng)用的 npm。

如果你正在使用 Kubernetes，無論你使用的是哪個(gè)云提供商，你都可以用 Helm 來輕松安裝一個(gè)復(fù)雜的多節(jié)點(diǎn)應(yīng)用。

下面是對 Helm 的描述：

Helm 幫助你管理 Kubernetes 應(yīng)用。Helm Charts 幫助你定義、安裝和升級 Kubernetes 應(yīng)用，無論它們有多復(fù)雜。Charts 很容易創(chuàng)建、進(jìn)行版本控制、共享和發(fā)布，所以請開始使用 Helm 吧，停止復(fù)制-粘貼的瘋狂舉動(dòng)。

一個(gè)用于分布式系統(tǒng)的包管理器。不可思議！讓我們看看我們能安裝的東西。

未列出的還有 WordPress、Jenkins 和 Kafka。

分布式系統(tǒng)配置很難，不信就去問問配置過 Kafka 集群的人。Helm 將使安裝 Kafka 像在你的 MacBook 上安裝新版 Photoshop 那樣簡單。 而且你可以在任何云上這么做。

在 Helm 之前，最接近分布式系統(tǒng)軟件包管理器（就我所知道的）的東西是 AWS[9] 或 Azure[10] 或 Google Cloud Launcher[11] 上的應(yīng)用市場。

在這里，我們再次看到了專有軟件如何導(dǎo)致分裂。在 Helm 之前，沒有任何一個(gè)標(biāo)準(zhǔn)的、與平臺(tái)無關(guān)的一鍵安裝 Kafka 的方法。

你可以在 AWS、Google 或 Azure 上找到一鍵安裝 Kafka 的方法。 但是，這些安裝中的每個(gè)都必須獨(dú)立編寫，以供每個(gè)特定的云提供商使用。 而要在 Digital Ocean 上安裝 Kafka，則需要遵循這個(gè) 10 步教程[12]。

Helm 是一個(gè)在任何 Kubernetes 實(shí)例上分布多節(jié)點(diǎn)軟件的跨平臺(tái)系統(tǒng)。你可以在任何云提供商那里或你自己的硬件上使用已安裝有 Helm 的應(yīng)用。

你可以輕松安裝 Apache Spark 或 Cassandra 系統(tǒng)。眾所周知，它們都是難以設(shè)置和操作的。

Helm 是 Kubernetes 的包管理器，但它看起來也像是 Kubernetes 應(yīng)用商店的雛形。有了應(yīng)用商店，你就可以出售用于 Kubernetes 的軟件。

你可以賣什么樣的軟件？

你可以銷售 Cloudera Hadoop，Databricks Spark 和 Confluent Kafka 等分布式系統(tǒng)平臺(tái)的企業(yè)版。 或者難以安裝的 Prometheus 等新型監(jiān)控系統(tǒng)和 Cassandra 等多節(jié)點(diǎn)數(shù)據(jù)庫。

也許你甚至可以銷售像 Zendesk 這樣的更高級的消費(fèi)級軟件。

自主托管 Zendesk 的想法聽起來很瘋狂，但是有人的確可以構(gòu)建它，并以專有二進(jìn)制文件的形式出售，以固定費(fèi)用而不是訂閱進(jìn)行收費(fèi)。

如果我向你出售價(jià)值 99 美元的 Zendesk-for-Kubernetes，并且你可以在 AWS 上的 Kubernetes 集群上輕松運(yùn)行它，那么你將在工單軟件上節(jié)省大量支持費(fèi)用。

企業(yè)經(jīng)常運(yùn)行自己的 WordPress 來管理公司的博客。 Zendesk 的軟件比 WordPress 更復(fù)雜嗎？ 我不這么認(rèn)為，但比起管理自己的博客軟件，企業(yè)更害怕管理自己的 Help Desk 軟件。

我經(jīng)營了一家非常小的公司，但我訂閱了很多不同的軟件即服務(wù)工具。包括一個(gè)昂貴的 WordPress 主機(jī)，一個(gè)用于廣告銷售的昂貴的 CRM 軟件，和用于通訊簡報(bào)的 MailChimp。

我支付這些服務(wù)是因?yàn)樗鼈兂壙煽亢桶踩宜鼈円彩菑?fù)雜的多節(jié)點(diǎn)應(yīng)用。我不想在自己的機(jī)房里運(yùn)行它們。我也不想自己管理它們。當(dāng)我的簡報(bào)發(fā)送失敗時(shí)，我不想自己排除技術(shù)故障。我不想運(yùn)行太多的軟件[13]。

相比之下，我并不擔(dān)心我的單機(jī)軟件出錯(cuò)。

我在單機(jī)軟件上的開銷往往要便宜得多，因?yàn)槲也恍枰阉鼈冏鳛榉?wù)購買。我用來寫音樂的軟件有一次性的固定成本。

Photoshop 有一次性固定成本。我支付電費(fèi)來運(yùn)行我的電腦，但除此之外，我不需要持續(xù)的資本支出才能運(yùn)行 Photoshop。

當(dāng)多節(jié)點(diǎn)應(yīng)用與單節(jié)點(diǎn)應(yīng)用一樣可靠時(shí)，我們將看到定價(jià)模型的變化。

也許有一天我可以購買 Zendesk-for-Kubernetes。Zendesk-for-Kubernetes 將會(huì)給我提供我需要的所有東西。

它將啟動(dòng)一個(gè)電子郵件服務(wù)器，它會(huì)給我一個(gè)網(wǎng)絡(luò)前端來管理工單。 如果出現(xiàn)任何問題，我可以在需要支持時(shí)支付費(fèi)用。

Zendesk 是一個(gè)非常棒的服務(wù)，但如果它有一個(gè)固定的定價(jià)模式，那將會(huì)更好。

Metaparticle

借助 Kubernetes，部署和管理分布式應(yīng)用程序變得更加容易。借助 Helm，將這些應(yīng)用程序分發(fā)給其他用戶變得更加容易。但是開發(fā)分布式系統(tǒng)還是相當(dāng)困難的。

這是 Brendan Burns 最近所作的一篇 CloudNative Con / KubeCon 主題演講的焦點(diǎn)，那個(gè)演講的題目為“構(gòu)建新工具、模式和范例來讓分布式系統(tǒng)開發(fā)更加大眾化的工作實(shí)在太難了[14]”。

Brendan 在發(fā)言中提出了一個(gè)名為 Metaparticle 的項(xiàng)目。Metaparticle 是云原生開發(fā)的標(biāo)準(zhǔn)庫，其目標(biāo)是實(shí)現(xiàn)分布式系統(tǒng)的大眾化。Brendan 在對 Metaparticle 的介紹[15]中寫道：

云原生開發(fā)是定制且復(fù)雜的，而且僅限于少數(shù)專家開發(fā)人員。Metaparticle 通過在熟悉的編程語言中引入一系列實(shí)用程序來改變這種狀況，這些實(shí)用程序符合開發(fā)人員當(dāng)前的處境，并使他們能夠使用熟悉的語言開始開發(fā)云原生系統(tǒng)。

Metaparticle 建立在 Kubernetes 原語的基礎(chǔ)上，而且它使分布式協(xié)調(diào)更容易。Metaparticle 提供獨(dú)立于語言的模塊，用于鎖定和主選舉，并把這些模塊作為熟悉的編程語言中易于使用的抽象。

經(jīng)過幾十年的分布式系統(tǒng)研究和應(yīng)用，我們?nèi)绾螛?gòu)建這些系統(tǒng)的模式已經(jīng)顯現(xiàn)。我們需要一種方法來鎖定一個(gè)變量，這樣兩個(gè)節(jié)點(diǎn)便不能以非確定性的方式寫入該變量。

我們需要一種方法來做主選舉，以便在主節(jié)點(diǎn)死亡時(shí)，其他節(jié)點(diǎn)可以選擇一個(gè)新節(jié)點(diǎn)來編排系統(tǒng)。

今天，我們使用 etcd 和 Zookeeper 這樣的工具來幫助我們進(jìn)行主選舉和鎖定，而這些工具都有接入成本。

Brendan 用 Zookeeper 的例子來說明這一點(diǎn)。Hadoop 和 Kafka 都使用 Zookeeper 來做主選舉。

你需要花費(fèi)大量的時(shí)間和精力來學(xué)習(xí)如何操作 Zookeeper。在構(gòu)建 Hadoop 和 Kafka 的過程中，這些項(xiàng)目的創(chuàng)始工程師設(shè)計(jì)的系統(tǒng)可以與 Zookeeper 協(xié)作，共同來維護(hù)一個(gè)主節(jié)點(diǎn)。

如果我正在編寫一個(gè)系統(tǒng)來執(zhí)行分布式 MapReduce，我希望不考慮節(jié)點(diǎn)故障和競爭條件。Brendan 的想法是將這些問題推到一個(gè)標(biāo)準(zhǔn)的庫中，從而讓下一個(gè)開發(fā)人員為多節(jié)點(diǎn)應(yīng)用程序提出新想法更加容易。

重要的元點(diǎn)：使用 Metaparticle 的前提是使用 Kubernetes。Metaparticle 是一個(gè)語言層級的抽象，它是建立在對底層（分布式）操作系統(tǒng)的假設(shè)之上的。這再一次使我們回到了標(biāo)準(zhǔn)這一話題。 

如果每個(gè)人都在同一個(gè)分布式操作系統(tǒng)上，我們可以對我們項(xiàng)目的下游用戶做出更大的假設(shè)。

這就是為什么我會(huì)被 Kubernetes 洗腦的原因。 它是跨越異構(gòu)系統(tǒng)的一個(gè)標(biāo)準(zhǔn)層。

無服務(wù)器工作負(fù)載

功能即服務(wù)（通常稱為“無服務(wù)器”功能）是一種功能強(qiáng)大且價(jià)格低廉的抽象，開發(fā)人員可以與 Kubernetes 一同使用它，在 Kubernetes 之上使用它，或者在某些情況下，單獨(dú)使用它。

讓我們快速回顧無服務(wù)器應(yīng)用程序的現(xiàn)狀，然后考慮無服務(wù)器和Kubernetes之間的關(guān)系。

功能即服務(wù)的快速回顧[16]：

功能即服務(wù)是無需依賴特定服務(wù)器運(yùn)行的可部署功能。

功能即服務(wù)旨在部署、執(zhí)行和擴(kuò)展開發(fā)人員的單個(gè)調(diào)用。在你調(diào)用無服務(wù)器功能之前，你的功能并沒有在任何地方運(yùn)行，所以你并未使用任何資源，除了存儲(chǔ)原始代碼的數(shù)據(jù)庫以外。當(dāng)你把一個(gè)功能作為服務(wù)調(diào)用時(shí)，你的集群將負(fù)責(zé)調(diào)度和運(yùn)行該功能。

你不必考慮啟動(dòng)一臺(tái)新機(jī)器并監(jiān)控該機(jī)器，或者在機(jī)器閑置時(shí)停機(jī)。 你只需告訴集群你想要運(yùn)行一個(gè)功能，然后集群將執(zhí)行它并返回結(jié)果。

在部署無服務(wù)器功能時(shí)，功能代碼實(shí)際上并未被部署。你的代碼將以純文本形式保存于數(shù)據(jù)庫中。當(dāng)你調(diào)用這個(gè)功能時(shí)，你的代碼將從數(shù)據(jù)庫入口中取出，加載到一個(gè) Docker 容器中并執(zhí)行。

AWS Lambda 在 2014 年開創(chuàng)了“功能即服務(wù)[17]”的理念。從那以后，開發(fā)人員一直在思考各種用例。

有關(guān)開發(fā)人員如何使用無服務(wù)器的完整列表，請參見 CNCF 無服務(wù)器工作組創(chuàng)建的共享 Google 文檔（本文發(fā)布時(shí)文檔為34頁）[18]。

從我在《軟件工程日報(bào)》上的交談中來看，這些作為服務(wù)的功能至少有兩個(gè)明顯的應(yīng)用例子：

• 可以快速而廉價(jià)地進(jìn)行擴(kuò)展以應(yīng)對突發(fā)性的工作負(fù)載的計(jì)算（例如，Yubl 的社交媒體可擴(kuò)展性案例研究[19]）。
• 在多種工作負(fù)載頻度下的的事件驅(qū)動(dòng)粘合代碼（例如，帶有多種數(shù)據(jù)庫消費(fèi)者的事件溯源模型）。

為了創(chuàng)建一個(gè)功能即服務(wù)(FaaS)平臺(tái)，云提供商提供了一個(gè)名為調(diào)用者(invokers)的 Docker 容器集群。

這些調(diào)用者等待得到調(diào)配給他們的大塊代碼。當(dāng)你要求你的代碼執(zhí)行的時(shí)候，你必須等待一段時(shí)間用于將代碼加載到調(diào)用者并執(zhí)行。 這個(gè)等待便是“冷啟動(dòng)”的問題。

冷啟動(dòng)問題是你決定在 FaaS 上運(yùn)行部分應(yīng)用時(shí)必須做的折衷之一。你不需為沒有進(jìn)行任何工作的服務(wù)器的運(yùn)行時(shí)間付費(fèi)，但是當(dāng)你想調(diào)用功能時(shí)，你必須等待代碼被調(diào)配給一個(gè)調(diào)用者。

在 AWS 上，會(huì)為 AWS Lambda 的請求指定調(diào)用者。在 Microsoft Azure 上，會(huì)為 Azure Functions 請求指定調(diào)用者。在 Google Cloud 上，會(huì)為 Google Cloud Functions 保留調(diào)用者。

對于大多數(shù)開發(fā)人員來說，使用 AWS、Microsoft、Google 或 IBM 的“功能即服務(wù)”平臺(tái)都可以。因?yàn)槌杀镜?，冷啟?dòng)問題對于大多數(shù)應(yīng)用來說不成問題。但是一些開發(fā)者會(huì)想要更低的成本。

或者他們可能希望編寫自己的調(diào)度器，該調(diào)度器會(huì)定義如何將代碼調(diào)度到調(diào)用者容器上。這些開發(fā)人員可以推出自己的無服務(wù)器平臺(tái)。

像 Kubeless 這樣的開源 FaaS 項(xiàng)目可以讓你在 Kubernetes 之上配置你自己的無服務(wù)器集群。你可以定義自己的調(diào)用者池，你可以確定如何按照計(jì)劃調(diào)度容器，你可以決定如何解決你的集群的冷啟動(dòng)問題。

Kubernetes 的開源 FaaS 只是一種資源調(diào)度器。它們只是 Kubernetes 之上的其他自定義調(diào)度器的預(yù)覽。開發(fā)人員總是在構(gòu)建新的調(diào)度器，以便在這些調(diào)度器之上構(gòu)建更高效的服務(wù)。

那么，在 Kubernetes 之上還有哪些其他類型的調(diào)度器？ 那么，正如他們所說，未來已經(jīng)到來，但這些調(diào)度器只能作為一個(gè) AWS 受管服務(wù)被提供。

AWS 有一項(xiàng)名為 Amazon Aurora Serverless 的新服務(wù)，它是一種自動(dòng)擴(kuò)展存儲(chǔ)和計(jì)算的數(shù)據(jù)庫。來自 Jeff Barr 關(guān)于 AWS Serverless Aurora 的帖子[20]：

當(dāng)創(chuàng)建 Aurora 數(shù)據(jù)庫實(shí)例時(shí)，你可以選擇所需的實(shí)例大小，并可以選擇使用讀副本提高讀取吞吐量。

如果你的處理需求或查詢速率發(fā)生變化，你可以選擇修改實(shí)例大小或根據(jù)需要更改讀副本的數(shù)量。這個(gè)模型在工作負(fù)載可預(yù)測、并且請求速率和處理需求在一定范圍內(nèi)的環(huán)境下運(yùn)行得非常好。

在某些情況下，工作負(fù)載可能是間歇性的和/或不可預(yù)知的，并且可能每天或每周只能出現(xiàn)持續(xù)幾分鐘或幾小時(shí)的突發(fā)請求。

閃電銷售、不頻繁的或一次性的事件、在線游戲、報(bào)告工作負(fù)載（小時(shí)或每天），開發(fā)/測試和全新的應(yīng)用都符合該條件。做出適當(dāng)?shù)娜萘恳?guī)劃可能需要做很多工作；穩(wěn)定地付費(fèi)可能是不明智的。

由于存儲(chǔ)和處理是分開的，因此可以將規(guī)模一直縮小到零并僅支付存儲(chǔ)費(fèi)用。

我覺得這真的很好，而且我期望它可以帶來新型的瞬時(shí)應(yīng)用程序的出現(xiàn)。擴(kuò)展只需要幾秒鐘，并基于一池子“熱”資源之上進(jìn)行構(gòu)建，這些資源急切地渴望滿足你的要求。

AWS 可以構(gòu)建這樣的東西，我們并不感到驚訝，但是很難想象它會(huì)成為一個(gè)開源項(xiàng)目，直到 Kubernetes 出現(xiàn)。任何開發(fā)人員都可以在 Kubernetes 之上構(gòu)建的這類系統(tǒng)。

如果你想在 Kubernetes 之上構(gòu)建自己的無服務(wù)器數(shù)據(jù)庫，則需要解決一些調(diào)度問題。網(wǎng)絡(luò)、存儲(chǔ)、日志記錄、緩沖和緩存需要不同的資源層級。對于每個(gè)不同的資源層，你需要定義資源如何按照需求進(jìn)行擴(kuò)展和縮減。

就像 Kubeless 為功能代碼的一小部分提供調(diào)度器一樣，我們可能會(huì)看到其他自定義調(diào)度器被人們用作更大應(yīng)用的構(gòu)建塊。

一旦你真正建立你的無服務(wù)器數(shù)據(jù)庫，也許你可以把它賣到 Helm 應(yīng)用程序商店，一次性購買它只需要 99 美元。

總結(jié)

我希望，通過一些 Kubernetes 的歷史和對未來的猜測，你能享受這次旅程。

2018 年已經(jīng)開始，這些將是我們今年想要探索的一些領(lǐng)域：

• 人們?nèi)绾喂芾碓?Kubernetes 上機(jī)器學(xué)習(xí)模型的部署？ 我們和 Matt Zeiler 一起做了一個(gè)展示[21]，他討論了這個(gè)問題，聽起來很復(fù)雜。
• Kubernetes 是否用于無人駕駛汽車？ 如果是這樣，你是否部署了一個(gè)集群來管理整個(gè)汽車？
• Kubernetes 物聯(lián)網(wǎng)部署是什么樣的？ 在具有間歇性網(wǎng)絡(luò)連接的一組設(shè)備上運(yùn)行 Kubernetes 是否有意義？
• 用 Kubernetes 構(gòu)建的新的基礎(chǔ)設(shè)施產(chǎn)品和開發(fā)工具有哪些？ 什么是新的商業(yè)機(jī)會(huì)？

Kubernetes 是構(gòu)建現(xiàn)代應(yīng)用后端的絕佳工具，但它仍然只是一個(gè)工具。如果 Kubernetes 完成其使命，它最終會(huì)消失，成為背景。將來，我們會(huì)像討論編譯器和操作系統(tǒng)內(nèi)核一樣討論 Kubernetes。

Kubernetes 將會(huì)是低層級的管路系統(tǒng)，而不在普通應(yīng)用開發(fā)人員的視野之內(nèi)。

參考地址：

[1] https://www.image-line.com/flstudio/

[2] https://youtu.be/gCQfFXSHSxw?t=611

[3] https://en.wikipedia.org/wiki/High-definition_optical_disc_format_war

[4] https://softwareengineeringdaily.com/2016/10/03/docker-fork-with-alex-williams-and-joab-jackson/

[5] https://rook.io

[6] https://softwareengineeringdaily.com/2016/05/17/dropboxs-magic-pocket-james-cowling/

[7] https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/

[8] https://softwareengineeringdaily.com/2017/11/28/thumbtack-infrastructure-with-nate-kupp/

[9] https://aws.amazon.com/marketplace

[10] https://aws.amazon.com/marketplace

[11] https://cloud.google.com/launcher/

[12] https://www.digitalocean.com/community/tutorials/how-to-install-apache-kafka-on-ubuntu-14-04

[13] https://softwareengineeringdaily.com/2017/11/20/run-less-software-with-rich-archbold/

[14] https://www.youtube.com/watch?v=gCQfFXSHSxw

[15] https://metaparticle.io/posts/welcome-to-metaparticle/

[16] https://www.softwaredaily.com/#/post/5a251d5f0cbcbe0004c932e1

[17] https://aws.amazon.com/cn/blogs/aws/run-code-cloud/

[18] https://docs.google.com/document/d/1UjW8bt5O8QBgQRILJVKZJej_IuNnxl20AJu9wA8wcdI/edit#heading=h.yiaul8is1ki

[19] https://softwareengineeringdaily.com/2017/08/04/serverless-startup-with-yan-cui/

[20] https://aws.amazon.com/cn/blogs/aws/in-the-works-amazon-aurora-serverless/

[21] https://softwareengineeringdaily.com/2017/05/10/convolutional-neural-networks-with-matt-zeiler/