說說Kubernetes是怎么來的，又是怎么沒的

普元云計算架構師宋瀟男點評：

Kubernetes已在容器編排之戰中取勝，未來很可能會成為“多云”之上的標準層，進而為分布式系統的分發和運行帶來根本性的改變，而其自身則會慢慢變得像Linux Kernel一樣，成為一種系統底層的支撐，不再引人注目。

原文的標題是The Gravity of Kuberrnetes，但是從內容上看，更像是近些年流行的“XXX is dead. Long live XXX.”的風格，所以在翻譯標題的時候我們惡搞了一下。

本文金句：

通過Kubernetes，分布式系統工具將擁有網絡效應。每當人們為Kubernetes制作出的新的工具，都會讓所有其它工具更完善。因此，這進一步鞏固了Kubernetes的標準地位。

云提供商并非可替換的商品。不同的云提供的服務會變得越來越獨特和不同。如果可以訪問不同的云提供商提供的不同服務，那么企業將因此受益。

當多節點應用與單節點應用一樣可靠時，我們將看到定價模型的變化。

這就是為什么我會被Kubernetes洗腦的原因。它是跨越異構系統的一個標準層。

將來，我們會像討論編譯器和操作系統內核一樣討論Kubernetes。 Kubernetes將會是低層級的管路系統，而不在普通應用開發人員的視野之內。

Kubernetes已成為部署分布式應用的標準方式。

在不遠的將來，任何新成立的互聯網公司都將用到Kubernetes，無論其是否意識到這點。許多舊應用也正在遷移到Kubernetes。

在Kubernetes之前，特定的分布式系統平臺還沒有一個標準。正如Linux是針對單個節點的標準的服務器側操作系統那樣，Kubernetes已成為編排應用節點的標準方式。

通過Kubernetes，分布式系統工具將擁有網絡效應。每當人們為Kubernetes制作出新的工具，都會讓所有其它工具更完善。因此，這進一步鞏固了Kubernetes的標準地位。

谷歌、微軟、亞馬遜和IBM都有自己的Kubernetes即服務產品，這讓我們在大型云提供商之間切換基礎設施變得更加簡單。我們將很有可能看到Digital Ocean、Heroku和其它長尾型云提供商開始提供受管理的和托管Kubernetes服務。

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

• 為什么正在發生這種情況？
• 對于開發者來說這意味著什么?
• 提供商將受到什么影響？
• 在Kubernetes標準化的世界中，有哪些新的業務模型將會出現？

一、軟件標準

標準化的軟件平臺有利有弊。

標準讓開發者可以對軟件的運行方式抱有一定的預期。如果一個開發者為某個標準化平臺構建了某個東西，他可以評估出該軟件的目標市場總規模。

如果你用JavaScript寫了一個程序，你會知道它將會在所有人的瀏覽器中運行。如果你給iOS創作了一個游戲，你會知道每個有iPhone的人都可以下載它。如果你構建了一個工具來分析.NET中的垃圾收集，你會知道大量的Windows開發者會遇到內存問題，所以他們會購買你的軟件。

標準化的專有平臺可以給平臺提供者創造大量的利潤。1995年，Windows這個很好的平臺讓微軟能夠以100美元的價格售出一個只是紙盒子裝著的光盤。2018年，iPhone這個很好的平臺讓蘋果能夠從平臺所有的應用銷售額中拿走30%。

但是專有的標準會導致分裂。

比如，你的iPhone應用無法在Kindle Fire上運行。我不能在非死book Messenger（臉書信使）上使用你的Snapchat增強現實貼紙。我 最喜歡的數字音頻工作站 只能在Windows上使用，所以我不得不使用Windows電腦來制作音樂。

當開發者們見到這種分裂時，他們會抱怨。他們會聯想到貪婪的資本家，這些資本家為了賺錢，不惜犧牲軟件的質量。開發者們會想：“為什么人們不能和諧共處？”為什么我們不能讓所有東西開放和免費？

開發者們還會想：“我們不需要專有標準。我們可以擁有開放標準。

Apache的增長，Apache是LAMP（Linux、 Apache、MySQL和PHP）堆棧的一部分

Linux就曾發生過這樣的事。現在，大多數新的服務側應用都在使用Linux。但曾經有一段時間，人們對此有爭議。見上圖的左側遠端部分。

最近，我們還看到了一個更新的開放標準：Docker。Docker給了我們一個開放、標準化的打包、部署和分布單個節點的方法。這極其有價值！但在Docker解決的所有大問題之中，有個新的問題非常突出，那就是我們應該如何將這些節點編排到一起？

畢竟，你的應用肯定不只是單個節點。你知道自己希望部署一個Docker容器，但是容器應該如何相互通信呢？你如何向上擴展容器實例呢？你如何在容器實例之間路由流量呢?

二、容器編排

在Docker流行之后，一大批開源項目和專有平臺紛紛出現，以解決容器編排的問題。

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

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

無論一個開發者是否使用編排平臺或者腳本來部署容器，Docker都可以加快開發，并且讓開發者和運營之間更加和諧。

隨著愈來愈多的開發者使用Docker來部署容器，編排平臺的重要性日益突出。 容器對于分布式系統的重要性就如同對象對于面向對象程序的重要性那樣 。所有人都希望使用容器平臺，但是眾多平臺之間存在著競爭，很難看出哪個平臺會最終勝出，所以這可能會是持續十多年的競爭，就如iOS和安卓的競爭那樣。

這樣的競爭正在制造分裂。這并不是因為流行的編排框架是專有的（Swarm、Kubernetes和Mesos都是開源的），而是因為每個容器編排社區都已經在自己的系統上投入了太多資金。

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

集裝箱（container）船傾覆的圖片從不過時。圖片來源：Huffington的帖子

容器編排的戰爭給人感覺就像是一場贏家贏得一切的戰爭。

正如在所有戰爭中那樣，總是有一層霧，讓我們很難看透彼此。在我報道容器編排之戰時，我曾用一條條播客記錄我和容器編排專家的談話，其中，我會問到這樣的問題，”那么，哪一個容器編排系統會贏？“

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

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

當有關容器編排商的辯論如火如荼時，甚至是我這樣的記者也被這樣的情緒激發，并且認為這將是一場與派系斗爭有關的故事時，那些最聰明的人大多數卻正在進行著平靜和科學的談論。

容器編排之戰并非是一場派系斗爭，而更多的是觀點和開發者工程學之間的差異。

好吧，或許容器編排之戰并不只是觀點之間的差異。因為這個領域將會創造大量財富。我們現在談論的是與數十億市值的老組織如銀行、電信公司和保險公司之間的合同，這些組織正在逐步向云遷移。

如果你正在幫助電信公司遷移到正確的平臺，那么你的業務會很好。但如果你擁護了錯誤的平臺，最終你只會得到一倉庫的高清DVD。

沖突最嚴重的時間大約是2016年底，那時有關于Docker可能出現分歧的傳言，原因是 因為Docker公司想改變Docker標準，以更好地適配其容器編排系統Docker Swarm 。但即使在那時，做一個樂觀者仍然是明智的。

具有毀滅性的創新會帶來痛苦，但它是一個進步的標志。在爭取容器編排統治地位的斗爭中，出現了許許多多的毀滅性創新。

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

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

讓我們來看看現狀：

• 開源開發者正在朝同樣的方向前進，并且為他們能構建的東西感到興奮。
• 大公司（無論是新還是老）都在逐漸采用Kubernetes。
• 大型云提供商也準備好迎接低成本的Kubernetes即服務。
• 監控、日志記錄、安全和合規軟件廠商也極為激動，因為他們能更加容易地預測自己要集成的底層軟件堆棧了。

三、走向多云化

今天，盈利最多的專有后端開發者基礎設施提供商就是亞馬遜AWS云服務。開發者并不憎恨AWS，因為AWS是創新和具備使能性的，并且便宜。如果你在AWS花了很多錢，那說明你的生意很好。

通過AWS，開發者不會感到90年代時的主導專有平臺所給人的那種被鎖定的感覺。但仍然有一些鎖定感。一旦你深深地扎根于AWS的生態系統中，并使用如DynamoDB、Amazon Elastic Container Service（彈性容器服務）、或Amazon Kinesis服務時，你會發現你很難再脫離亞馬遜。

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

如果你決定遷移你的應用，你需要重寫應用的部分組件來停止使用亞馬遜特定的服務（如亞馬遜S3）。例如，如果你想要一個可以在任何云上運行的S3替代品，你可以配置一個帶 Rook 的Kubernetes集群，并使用與你在S3上使用的相同API 來存儲對象到Rook上。

這是一個很好的選項，但是我還從未聽說過誰真正地將他們的應用從云中遷走， 除了Dropbox 之外，但他們的遷移是如此宏大， 以至于耗費了2年半的時間 。

當然，除了Dropbox之外，肯定還有其他人也在亞馬遜S3上投入了很多錢，雖然他們也想創造自己的對象存儲，但是遷移會非常費力。

Kubernetes可以被用于遷移應用，但更可能會用于在不同的云之中提供相似的操作層

在不遠的將來，Kubernetes或許不會成為一個廣泛用于應用遷移的工具。更可能的情況是Kubernetes將會成為一個無所不在的控制平面，企業可以在多個云上使用它。

NodeJS便是一個有用的類比。為什么人們喜歡NodeJS的服務器側應用？這并不一定是因為NodeJS是最快的web服務器，而是因為人們喜歡在客戶端和服務器上使用相同的語言。NodeJS可以讓你在客戶端和服務器節點切換，而無需切換語言，同樣，Kubernetes也能讓你在不同的云之間切換，而無需改變運營方式。

在每個云上，你都會有一些定制的應用代碼，它們由Kubernetes運行，并且與那個云提供的受管服務進行交互。

企業希望多云化，部分是因為容災的考慮，但還因為訪問不同云上的受管服務有實際的好處。

一個新出現的模式是將基礎設施分布于AWS（用于用戶流量）和Google Cloud（用于數據工程）上。 Thumbtack 公司正在使用此模式。

在Thumbtack，位于AWS的生產基礎設施負責處理用戶請求。事務日志將從AWS推送到Google Cloud，并在那里進行數據工程。在Google Cloud上，事務記錄在Cloud PubSub中排隊。Cloud PubSub是一個信息隊列服務。這些事務會從隊列里被抽出，并存儲在BigQuery中，BigQuery是一個存儲和查詢大量數據的系統。

BigQuery充當編排機器學習任務時的數據池，以便人們從中抽取數據。這些機器學習任務是在Cloud Dataproc中運行的，Cloud Dataproc是一個運行Apache Spark的服務。在Google Cloud上訓練好一個模型之后，這個模型會被部署到AWS側，然后處理用戶流量。在Google Cloud側，這些不同的受管服務的編排是由Apache Airflow完成的。Apache Airflow是一個開源工具。Thumbtack在Google Cloud上管理自己時，需要Apache Airflow。

今天，Thumbtack用AWS來處理用戶請求，并用Google Cloud來進行PubSub中的數據工程和排隊。Thumbtack在谷歌中訓練其機器學習模型，并將它們部署到AWS中。

這就是今天我們常見的現象。Thumbtack最終或許還會將Google Cloud用于面向用戶的服務。

某家日本公司采用的多云化的數據工程流水線

越來越多的公司將逐漸遷移至多個云，而且它們當中的某些公司會在每個云上管理獨立的Kubernetes集群。

你可能在谷歌上有一個GKE Kubernetes集群來編排BigQuery、Cloud PubSub和Google Cloud ML之間的負載，而且你可能會有一個Amazon EKS集群來編排DynamoDB、 Amazon Aurora和你的生產NodeJS應用之間的負載。

云提供商并非可替換的商品。不同的云提供的服務會變得越來越獨特和不同。如果可以訪問不同的云提供商提供的不同服務，那么企業將因此受益。

四、分布式系統分發

Google BigQuery 等 AWS Redshift服務十分流行，因為它們給了你強大、可擴展和多節點的工具，而且API還簡單。開發者經常選擇這些受管服務，因為它們是如此好用。

針對單個節點的付費工具并不常見。我不需要給NodeJS、React或Ruby on Rails付費。

針對單個節點的工具比針對分布式系統的工具用起來更容易。相比于在我的筆記本上運行Ruby on Rails應用來說，在許多服務器上部署Hadoop難多了。然而，有了Kubernetes后，這一切都將改變。

如果你正在使用Kubernetes，你可以使用一個名叫Helm的分布式系統包管理器。它就好比是用于Kubernetes應用的npm。如果你正在使用Kubernetes，無論你使用的是哪個云提供商，你都可以用Helm來輕松安裝一個復雜的多節點應用。

下面是對Helm的描述：

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

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

未列出的還有WordPress、Jenkins和Kafka

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

在Helm之前，最接近分布式系統軟件包管理器（就我所知道的）的東西是 AWS 或 Azure 或 Google Cloud Launcher 上的應用市場。在這里，我們再次看到了專有軟件如何導致分裂。在Helm之前，沒有任何一個標準的、與平臺無關的一鍵安裝Kafka的方法。

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

Helm是一個在任何Kubernetes實例上分布多節點軟件的跨平臺系統。 你可以在任何云提供商那里或你自己的硬件上使用已安裝有Helm的應用。 你可以輕松安裝Apache Spark或Cassandra系統。眾所周知，它們都是難以設置和操作的。

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

你可以賣什么樣的軟件？

你可以銷售Cloudera Hadoop，Databricks Spark和Confluent Kafka等分布式系統平臺的企業版。 或者難以安裝的Prometheus等新型監控系統和Cassandra等多節點數據庫。

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

自主托管Zendesk的想法聽起來很瘋狂，但是有人的確可以構建它，并以專有二進制文件的形式出售，以固定費用而不是訂閱進行收費。 如果我向你出售價值99美元的Zendesk-for-Kubernetes，并且你可以在AWS上的Kubernetes集群上輕松運行它，那么你將在工單軟件上節省大量支持費用。

企業經常運行自己的WordPress來管理公司的博客。 Zendesk的軟件比WordPress更復雜嗎？ 我不這么認為，但比起管理自己的博客軟件，企業更害怕管理自己的Help Desk軟件。

我經營了一家非常小的公司，但我訂閱了很多不同的軟件即服務工具。 包括一個昂貴的WordPress主機，一個用于廣告銷售的昂貴的CRM軟件，和用于通訊簡報的MailChimp。 我支付這些服務是因為它們超級可靠和安全，而且它們也是復雜的多節點應用。 我不想在自己的機房里運行它們。我也不想自己管理它們。 當我的簡報發送失敗時，我不想自己排除技術故障。 我不想運行太多的軟件 。

相比之下，我并不擔心我的單機軟件出錯。

我在單機軟件上的開銷往往要便宜得多，因為我不需要把它們作為服務購買。 我用來寫音樂的軟件有一次性的固定成本。 Photoshop有一次性固定成本。 我支付電費來運行我的電腦，但除此之外，我不需要持續的資本支出才能運行Photoshop。

當多節點應用與單節點應用一樣可靠時，我們將看到定價模型的變化。

也許有一天我可以購買Zendesk-for-Kubernetes。 Zendesk-for-Kubernetes將會給我提供我需要的所有東西——它將啟動一個電子郵件服務器，它會給我一個網絡前端來管理工單。 如果出現任何問題，我可以在需要支持時支付費用。

Zendesk是一個非常棒的服務，但如果它有一個固定的定價模式，那將會更好。

五、Metaparticle

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

這是Brendan Burns最近所作的一篇CloudNative Con / KubeCon主題演講的焦點，那個演講的題目為“ 構建新工具、模式和范例來讓分布式系統開發更加大眾化的工作實在太難了 ”。

Brendan在發言中提出了一個名為Metaparticle的項目。 Metaparticle是云原生開發的標準庫，其目標是實現分布式系統的大眾化。 Brendan在對 Metaparticle的介紹 中寫道：

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

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

經過幾十年的分布式系統研究和應用，我們如何構建這些系統的模式已經顯現。 我們需要一種方法來鎖定一個變量，這樣兩個節點便不能以非確定性的方式寫入該變量。 我們需要一種方法來做主選舉，以便在主節點死亡時，其他節點可以選擇一個新節點來編排系統。

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

Brendan用ZooKeeper的例子來說明這一點。Hadoop和Kafka都使用ZooKeeper來做主選舉。 你需要花費大量的時間和精力來學習如何操作ZooKeeper。 在構建Hadoop和Kafka的過程中，這些項目的創始工程師設計的系統可以與ZooKeeper協作，共同來維護一個主節點。

如果我正在編寫一個系統來執行分布式MapReduce，我希望不考慮節點故障和競爭條件。 Brendan的想法是將這些問題推到一個標準的庫中，從而讓下一個開發人員為多節點應用程序提出新想法更加容易。

重要的元點：使用Metaparticle的前提是使用Kubernetes。 Metaparticle是一個語言層級的抽象，它是建立在對底層（分布式）操作系統的假設之上的。這再一次使我們回到了標準這一話題。 如果每個人都在同一個分布式操作系統上，我們可以對我們項目的下游用戶做出更大的假設。

這就是為什么我會被Kubernetes洗腦的原因。 它是跨越異構系統的一個標準層。

六、無服務器工作負載

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

讓我們快速回顧無服務器應用程序的現狀，然后考慮無服務器和Kubernetes之間的關系。

功能即服務的快速回顧 ：

功能即服務是無需依賴特定服務器運行的可部署功能。

功能即服務旨在部署、執行和擴展開發人員的單個調用。 在你調用無服務器功能之前，你的功能并沒有在任何地方運行 - 所以你并未使用任何資源，除了存儲原始代碼的數據庫以外。 當你把一個功能作為服務調用時，你的集群將負責調度和運行該功能。

你不必考慮啟動一臺新機器并監控該機器，或者在機器閑置時停機。 你只需告訴集群你想要運行一個功能，然后集群將執行它并返回結果。

在部署無服務器功能時，功能代碼實際上并未被部署。 你的代碼將以純文本形式保存于數據庫中。 當你調用這個功能時，你的代碼將從數據庫入口中取出，加載到一個Docker容器中并執行。

來自 https://medium.com/openwhisk/u ... 05f71 的圖表

AWS Lambda在2014年開創了“ 功能即服務 ”的理念。 從那以后，開發人員一直在思考各種用例。 有關開發人員如何使用無服務器的完整列表，請參見 CNCF無服務器工作組創建的共享Google文檔（本文發布時文檔為34頁） 。

從我在《軟件工程日報》上的交談中來看，這些作為服務的功能至少有兩個明顯的應用例子：

• 可以快速而廉價地進行擴展以應對突發性的工作負載的計算（例如， Yubl的社交媒體可擴展性案例研究 ）
• 在多種工作負載頻度下的的事件驅動粘合代碼（例如，帶有多種數據庫消費者的事件溯源模型）

為了創建一個功能即服務（FaaS）平臺，云提供商提供了一個名為調用者（invokers）的Docker容器集群。 這些調用者等待得到調配給他們的大塊代碼。 當你要求你的代碼執行的時候，你必須等待一段時間用于將代碼加載到調用者并執行。 這個等待便是“冷啟動”的問題。

冷啟動問題是你決定在FaaS上運行部分應用時必須做的折衷之一。 你不需為沒有進行任何工作的服務器的運行時間付費 - 但是當你想調用功能時，你必須等待代碼被調配給一個調用者。

在AWS上，會為AWS Lambda的請求指定調用者。 在Microsoft Azure上，會為Azure Functions請求指定調用者。 在Google Cloud上，會為Google Cloud Functions保留調用者。

對于大多數開發人員來說，使用AWS、Microsoft、Google或IBM的“功能即服務”平臺都可以。 因為成本低，冷啟動問題對于大多數應用來說不成問題。 但是一些開發者會想要更低的成本。 或者他們可能希望編寫自己的調度器，該調度器會定義如何將代碼調度到調用者容器上。 這些開發人員可以推出自己的無服務器平臺。

像Kubeless這樣的開源FaaS項目可以讓你在Kubernetes之上配置你自己的無服務器集群。 你可以定義自己的調用者池。 你可以確定如何按照計劃調度容器。 你可以決定如何解決你的集群的冷啟動問題。

Kubernetes的開源FaaS只是一種資源調度器。 它們只是Kubernetes之上的其他自定義調度器的預覽。 開發人員總是在構建新的調度器，以便在這些調度器之上構建更高效的服務。

那么，在Kubernetes之上還有哪些其他類型的調度器？ 那么，正如他們所說，未來已經到來，但這些調度器只能作為一個AWS受管服務被提供。

AWS有一項名為Amazon Aurora Serverless的新服務，它是一種自動擴展存儲和計算的數據庫。 來自Jeff Barr關于AWS Serverless Aurora的帖子 ：

當創建Aurora數據庫實例時，你可以選擇所需的實例大小，并可以選擇使用讀副本提高讀取吞吐量。 如果你的處理需求或查詢速率發生變化，你可以選擇修改實例大小或根據需要更改讀副本的數量。 這個模型在工作負載可預測、并且請求速率和處理需求在一定范圍內的環境下運行得非常好。

在某些情況下，工作負載可能是間歇性的和/或不可預知的，并且可能每天或每周只能出現持續幾分鐘或幾小時的突發請求。 閃電銷售、不頻繁的或一次性的事件、在線游戲、報告工作負載（小時或每天），開發/測試和全新的應用都符合該條件。 做出適當的容量規劃可能需要做很多工作；穩定地付費可能是不明智的。

由于存儲和處理是分開的，因此可以將規模一直縮小到零并僅支付存儲費用。 我覺得這真的很好，而且我期望它可以帶來新型的瞬時應用程序的出現。 擴展只需要幾秒鐘，并基于一池子“熱”資源之上進行構建，這些資源急切地渴望滿足你的要求。

AWS可以構建這樣的東西，我們并不感到驚訝，但是很難想象它會成為一個開源項目 - 直到Kubernetes出現。任何開發人員都可以在Kubernetes之上構建的這類系統。

如果你想在Kubernetes之上構建自己的無服務器數據庫，則需要解決一些調度問題。 網絡、存儲、日志記錄、緩沖和緩存需要不同的資源層級。 對于每個不同的資源層，你需要定義資源如何按照需求進行擴展和縮減。

就像Kubeless為功能代碼的一小部分提供調度器一樣，我們可能會看到其他自定義調度器被人們用作更大應用的構建塊。

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

總結

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

2018年已經開始，這些將是我們今年想要探索的一些領域：

• 人們如何管理在Kubernetes上機器學習模型的部署？ 我們 和Matt Zeiler一起做了一個展示 ，他討論了這個問題，聽起來很復雜。
• Kubernetes是否用于無人駕駛汽車？ 如果是這樣，你是否部署了一個集群來管理整個汽車？
• Kubernetes 物聯網部署是什么樣的？ 在具有間歇性網絡連接的一組設備上運行Kubernetes是否有意義？
• 用Kubernetes構建的新的基礎設施產品和開發工具有哪些？ 什么是新的商業機會？

Kubernetes是構建現代應用后端的絕佳工具——但它仍然只是一個工具。

如果Kubernetes完成其使命，它最終會消失，成為背景。 將來，我們會像討論編譯器和操作系統內核一樣討論Kubernetes。Kubernetes將會是低層級的管路系統，而不在普通應用開發人員的視野之內。

對但在那成為現實之前，我們仍會對Kubernetes繼續報道。

原文鏈接： The Gravity of Kubernetes

 

來自：http://dockone.io/article/3286