Google 想要稱霸商界的祕密武器——Kubernetes

從某種程度上來講，目前規模較大的公有云服務商都是自給自足的狀態，在他們的基礎設施雲版本上運行他們的應用程序。他們不只本身使用這個基礎設施，也賣給別人用。就這一點而言，這幾家大的雲提供商跟大型企業、政府機關沒什麼不同，然後二者目前則正在努力跟遺留系統作抗爭。

Google 的展望

搜索引擎和在線廣告巨頭 Google 但願本身的雲平臺業務可以與 AWS、微軟競爭，可以一直走在 IBM SoftLayer、Rackspace，以及一些公有云提供商的前面。Google 有兩個戰略性優點，可讓本身最終在雲平臺領域作得如同 AWS 同樣大，甚至作得比剩下的廠商都大。亞馬遜堅信，AWS 會作得比本身的電子商務業務（在線零售）要大，雖然如今還遠遠沒有達到。首先，Google 本身設計本身的服務器，存儲和網絡，以及環繞他們的數據中心。這樣的數據中心在全球範圍內鏈接大面積區域網絡，範圍能夠擴充到一百萬臺機器。第二個優點，不是能夠存儲數據、分析數據的巨大軟件庫，而是開源容器編排工具 Kubernetes，靈感來自於集羣管理系統 Borg 以及 Omega。

Kubernetes 的出生

從 Google 開源 Kubernetes，並將它放在 CNCF（Cloud Native Computing Foundation）旗下，從2015年7月發佈的基礎版本1.0到今年9月底發佈的1.4，Kubernetes 已經誕生一年多了。

Google 的 Google Container Engine——縮寫爲 GKE，以免跟 Google Computing Engine（縮寫爲 GCE）混淆，那麼爲何不叫它 Google  Kubernetes Engine 呢？這個之後再說。由 CNCF 主辦的 KubeCon 大會近日在華盛頓西雅圖舉辦——Kubernetes 如今吸引了足夠多的注意力。也包括，Google 內的開發人員，那些沒有真正操做使用過 Kubernetes 的人。有趣的地方在於，Google 開發人員正着手在 Kubernetes 上運行應用程序，但願可以運行得更加靈活、便捷，也是出於這個緣由，Google 將它做爲一個商品宣傳，做爲裸機或者是公有云上的容器抽象層。

「咱們跟 Google 內部的人對話，話題一般關於「咱們何時將 Kubernetes 的這些性能帶入 Google」，可以在 Kubernetes 上隨機運行一個應用程序，這真是一個複雜的問題。」Tim Hockin（Kubernetes 原始工程師之一） 告訴《The Next Platform》道。Hockin 是 Kubernetes 的發聲者之一。而 Craig Mcluckie，是 Computing Engine 服務的產品經理主管，是 Google 內部 Kubernetes 項目創始人員之一，曾負責過 GKE 容器項目。他如今已經離開 Google，本身創辦了一家公司。Aparna Sinha，Google Container Engine 的高級產品經理，以前也跳槽了。Hockin 回電話給咱們，給了咱們一些 Kubernetes 在 Google 內部做爲項目、工具的更新信息。

「咱們已經爲人們從 Google 內部獲得需求，人們想要在 Kubernetes 上運行，咱們跟他們一塊兒在雲上使用 Kubernetes（其實就是在 Google GKE 上面）。咱們正在這條路上走，阻力很大，由於 Google 帶來了不少要求，而咱們但願這些需求可以暫時被忽略一下。Google 是一個很難搞到的客戶。」

因此，目前最明顯的問題就是，在 Google，Kubernetes 可否替代 Borg？（固然也有人問 Hadoop，這個基於 Google MapReduce 概念的軟件，可能會替代 Google 文件系統，成爲 Hadoop 分佈式文件系統）可是，Google 有它本身的遺留軟件問題，這個問題可能會妨礙開源。

「咱們如今在關注新應用程序，Google 開發人員正在 Borg 和 Kubernetes 之間作選擇，而不少人在這二者之間選擇了 Kubernetes，」Sinha 說道。「可是我以爲將 Gmail 和搜索轉移到 Kubernetes 上沒什麼可行性。」

Kubernetes 和 Borg

可是 Google 不只僅這兩個項目，無論它作出什麼讓公有云更好的服務，它所作出來的服務不只 Google 能用，其它任意一家公司也能用。雲的真實測試就是當 hyperscaler 內部使用的原始基礎設施跟它在公有云上賣的性能和功能沒有差別的時候。真正的創新會向上移動堆棧，移動到應用程序軟件。

「這件事情不一樣人有不一樣見解，」Hockin 說，Hockin 一開始在 Google 的 Borg 容器管理系統工做，該系統是來管理集羣工具的。「咱們已經從 Google 內部爲那些想要在 Kubernetes 上運行應用的人提了需求，咱們正在跟他們一塊兒合做，在雲（也就是 Google 的 GKE）上使用 Kubernetes。咱們正在往這條路上走，這對咱們來講十分困難由於 Google 提出的需求是咱們想要暫時忽略的。Google 是一個很難搞到的客戶。咱們面對的更大的問題是，咱們能夠在 Google 內部使用 Kubernetes 來替代 Borg，或者說跟 Borg 一塊兒使用，這是一個更加困難的問題。咱們本身起了不少 Borg 集羣，而且讓他們運行，咱們在 Google 內部有不少策略，因此咱們僅僅升級一個集羣到 Kubernetes 是不行的。Borg 有不少不少 Kubernetes 沒有的功能——不論這些功能是好是壞，這些功能是 Borg 有的，人們在使用的。咱們也不想在 Kubernetes 加入這些功能。因此 Kubernetes 要替代 Borg ，這個舉動是一個驚人的嘗試。這個嘗試可能會失敗，也可能須要5-10年的時候纔可走上正軌，又或者是一場博弈，博弈到最後，Borg 會擁有不少的客戶，全部人都在咱們的雲上使用 Kubernetes。」

全部的大型雲供應商都在面對一套一樣的選擇和難題。某種程度上，Borg 與大型機其實沒什麼可比性。可是，由公有云建立的服務會有他們本身的成熟曲線，也會「留戀本身的過去」，由於改變的代價大於一成不變。

咱們老是在尋找下一個平臺，正如咱們這個網站的名字同樣（The Next Platform），顯然，Kubernetes 是一個很強的競爭對手，由於這個引人注目的平臺的亮點就是，它很大程度上是基於開源技術的。（Joe Beda，前谷歌人，曾經和 McLuckie 一塊兒負責 Kubernetes 項目，他幫助過 Urs Hoetzle。 Urs Hoetzle 是搜索引擎的帶頭人，也但願創造一個更加全面化的 Borg 和開源項目，指出下一代平臺應該是什麼樣子的，咱們也跟他討論過將 Kubernetes 和 Prometheus 整合到一塊兒。）

「Kubernetes 的延展性和靈活性造就了這個平臺，」Sinha 說道，「你能夠在虛擬機上、裸機，或者是任何雲上面運行 Kubernetes，這就是它的奇妙之處。它給了你足夠的選擇，而不是你爲了它特意去找合適的雲。你能夠自由選擇存儲，網絡和調度程序，一樣你也能夠在這些裏面插入 Kubernetes。這也是 Kubernetes 更加合適企業的緣由之一，由於它更加適合他們的環境。」

微軟選擇了 Kubernetes 競爭者 Mesos 在 Azure 上管理他們的容器層，固然微軟也支持 Docker Swarm（不過這周他們剛宣佈本身也是支持 Kubernetes 的）。具體來講，Azure 上，原始虛擬機支持 Kubernetes，很快，Azure 容器服務上編排層就能夠用 Kubernetes 來搭建而不是 Mesos（更加準確來講，在商業層面，Mesos 就是 DC/OS，以 Mesosphere 的形式售賣）。這樣，Azure 跟 Kubernetes 合做更深，整合更親密，有趣的是，微軟如今也開放 ACS 引擎的代碼，中間媒介在於 Azure 基礎設施和 DC/OS，Swarm，或者 Kubernetes 容器編排工具。實際上，這也就是，如同微軟說的，是一個開源項目，是 Borg 棧的一部分，並且不是從開源社區那裏借用過來的。微軟很瞭解這個選擇的意義，可是它支持 Linux，就是另外一個例子了。

可是 Google 和微軟是不同的。微軟但願 Azure 能夠什麼都支持，而 Google 則但願 Kubernetes 什麼環境都支持。（在某種意義上來講，微軟沒有辜負 Borg 的名字，同化了全部的編排工具）準確地說，Kubernetes 就是 Google 迎合裸機雲，給它跟 AWS 不同的雲（AWS 不會賣掉它做爲堆棧的基礎設施，雖然它說 VMware 纔是它的私有云夥伴）。

「這纔是正確的思考方式，纔是正確的意圖，以及那些公司是如何使用 Kubernetes 的，以及集羣聯盟也就是意味着在那上面建立，」Sinha 說，「咱們的策略就是，Kubernetes 老是提供開源設施，這樣公司就能夠在裸機上使用你選擇的雲。因此它也不只僅只是混合雲，或者公有云，它是多種雲，真的有用戶在使用這一點。他們能夠在任意的地方部署工做：在 AWS 上，在 GCP 上，或者裸機上，又或者容許他們建立控制面板的聯盟上。」

Kubernetes 引入集羣聯盟

今年發佈的 Kubernetes1.3 版本中引入了集羣聯盟，容許多個 Kubernetes 集羣被擴展到多個雲上面，公有云或者私有云，或者是跨雲提供商的不一樣領域，有統一的控制面板，容許集羣或者是他們的 replica set，就如同他們是在一個巨大的基礎設施上面。顯然，這個聯盟層能夠幫助彈性和災難恢復，同時也被打算用來容許設置策略，這樣就能夠推送特定的工做和數量種類到特定區域的集羣，若是有依從性或者其它限制的話。你能夠放東西在雲上的任意地方，可是並不意味着開發人員就要這麼作。

抽象層和控制中心二者是種強大的聯合，是一項 Google 在它本身的基礎設施上收益不菲的技術。

「有件事在 Kubernetes 社區絕對狂熱，來自雲提供商和他們的實踐的抽象層，」Hockin 解釋道，「咱們並無想用 Kubernetes 系統的任意部分來複制咱們自身，成爲 Google 雲平臺，或者亞馬遜的 AWS，或者是任意的裸機基礎設施。對於在實現過程當中引發的疼痛，這件事真的十分重要。這會反映在咱們的 API 和存儲中。Kubernetes 系統使用抽象存儲，可是它被綁定在後端，使存儲具體化。因此做爲一個開發人員，我只想提 100GB 的快速磁盤的需求，這個快速取決於集羣管理人員設置了什麼。在個人裸機上，Kubernetes 集羣可能就意味着 NetApp 裝置；在 GCP 上，它可能就意味着持久性磁盤；在 AWS 上，它可能就意味着 Elastic Block Storage；可是做爲開發人員，其實我不是很瞭解，也不是很在乎。」

在 《Next Platform》，咱們度過一段艱難的時期，由於那會兒人們不知道，也不在乎，可是 Hockin 的觀點是對的。他們老是想要更快的速度，更多的性能，更少的延遲性。哦，還有擴容，擴容得更大。這也就是 Google 一直在爲 Kubernetes 擴大規模的緣由。由於它很清楚要如何處理跨 50000 多個服務節點的 Borg 集羣，以及跨 10000 個節點的集羣。

「咱們有至關強烈的 API 遺留需求，以及咱們怎麼定義擴容限制，尤爲是對於 Google 雲平臺來講，」Sinha 解釋道，「在 Kubernetes1.3 的時候，咱們宣佈能夠支持 2000 個節點，咱們計劃最高能夠擴大規模到 5000 個節點。在外部，用戶 push 這個到他們的極限，因此像這樣設置限制根本沒有困難。可是咱們看到的就是全球範圍內的消費者正在用 1000 或者 2000 個節點進行工做，而後他們想要擁有分開的集羣，可是仍是運行在一塊兒的——因而集羣聯盟誕生了。」

Hockin 說，Google 內部測試 Kubernetes 運行在不少聯合集羣上面，以及這個聯合集羣的功能就是，它是分別被建立的，這樣消費者就能夠將集羣膠合在一塊兒，從管理和工做分享角度來看，在每一個 Google 雲平臺區域，在容許狀況下，要充分利用全部的地理分佈。

「若是一個聯盟裏有很多於 100 個的集羣，那麼咱們的目標就是幾十個。每一個集羣能夠有 2000-5000 不等的節點，最高擁有 60000 個 pod，」Hockin 說，「若是將12個雲區域乘以每一個雲區域裏的 12 個集羣，再乘以 5000 個節點，那麼你就擁有了一堆機器。」（若是準確來講的話，就是 720000 個節點，即便一個節點算做一個虛擬機，那也是很大數目的一堆機器...…目前，大概每一個雙路服務器有 40 臺虛擬機，不過這樣算下來也是 18000 臺物理機。）

 

Google 的祕密武器——Kubernetes

Google 想要開啓一場戰爭，想要在商界稱霸。而 Kubernetes 就像是一個飛行員，在雲端操縱着它的用戶。

原文連接：

https://www.nextplatform.com/2016/11/08/google-wants-kubernetes-rule-world/?from=groupmessage&isappinstalled=0