譯者注：

本文帶有一些主觀色彩，作者的觀點(diǎn)是否客觀我還沒有去考證，僅供參考。以下是對本文中一些縮寫的解釋：

• Google GKE = Google Kubernetes Engine
• Microsoft AKS = Microsoft Azure Kubernetes Services
• Amazon EKS = Amazon Elastic Container Service for Kubernetes

之前已經(jīng)有非常多關(guān)于這些托管在云上的Kubernetes供應(yīng)商之間的對比，但是，或許這次的對比是最有誠意的。

下面是一張Google表格的截圖，它對比了GKE、AKS和EKS。你可能注意到有些格子里面已經(jīng)有了評論。這些評論會鏈接到我獲取信息的地方。

更新：這份表格現(xiàn)在也包含了IBM IKS和阿里云ACK。 

如果有任何不正確的地方，請在表格里寫下評論或者在文章下面給我留言。

這將會是一次殘酷的對比，如果有人能提供一些事實依據(jù)，我會很樂意改變我的想法。

就目前的情況，我用過EKS，也是AWS的重度用戶。我還接觸過一點(diǎn)GKE，但那只是不久前我出于個人目的，制作Kubernetes The Hard way這個教程時在GKE上啟了一個簡單快速的測試集群。我挺想多使用一下GKE的，但公司里用得是AWS。

自從去年我用了幾個月的Azure之后，就一直想回避它。當(dāng)時我是微軟的一個合作伙伴，所以免不了要使用Azure。它的部分功能還不錯，但是用戶體驗和亞馬遜相比真是天壤之別。

我會根據(jù)不同的場景將我的建議分類。

新上的項目

我一直在試著權(quán)衡是否建議人們?nèi)ピu估谷歌、亞馬遜以及微軟提供的所有云服務(wù)。Kubernetes只是一個大型系統(tǒng)中的單一組件，還有其他的因素會影響我們的決定。但不管怎樣，其實現(xiàn)在各個云廠商所提供的功能和服務(wù)并沒有太大的不同。

當(dāng)然市場團(tuán)隊可能會說并非如此，但當(dāng)你看看大部分公司所需要的那些功能特性，其實那些云廠商都能提供。

所以我們就簡單粗暴一點(diǎn)，比如你就只想用Kubernetes。那答案很清晰，就選GKE吧。

為什么?因為用幾乎每一種可量化的方式將它與競爭對手相比，它都是更便宜、更快、更好的那個。

你可能會覺得集群創(chuàng)建時間并不是什么大問題，3分鐘和20分鐘相比沒什么區(qū)別。畢竟你有多少次會去真正創(chuàng)建一個集群呢?好吧，如果要花費(fèi)20多分鐘而且有時還會報錯，那確實不會經(jīng)常去創(chuàng)建，因為你會為了適應(yīng)它而去改變自己的整個工作流程。

但是，如果創(chuàng)建集群只需要3分鐘，那你會發(fā)現(xiàn)你所用的測試基礎(chǔ)架構(gòu)是可以隨時丟棄重建的，這會是一種完全不同的工作方式。

網(wǎng)絡(luò)功能是另外一個因素，谷歌在這方面可是甩開其他對手10條街的水平。在高可用和擴(kuò)展性方面也差不多。

我不會說表格中的每一行都是一個原因，因為我覺得數(shù)據(jù)不言自明。

我們已經(jīng)被AWS綁定了

那你可能沒有太多的選擇，光是一個Kubernetes還不足以成為遷移到其他云平臺的理由。

希望你能看到這次對比并且認(rèn)識到情況可能會更糟。EKS剛推出不久，亞馬遜團(tuán)隊會快速迭代。我對于亞馬遜能否在網(wǎng)絡(luò)性能或者虛擬機(jī)啟動時間上趕上谷歌持懷疑態(tài)度，但情況還是可以忍受的。

如果他們能在主節(jié)點(diǎn)上啟用默認(rèn)的準(zhǔn)入控制器就好了。還有，我完全不明白為什么創(chuàng)建集群會這么慢。我在工作中測量過集群構(gòu)建時間，每次都要花大約20分鐘才能達(dá)到我能在上面跑集成測試的狀態(tài)。

更新：準(zhǔn)入控制器已經(jīng)被加上了。

另一個煩人的地方是缺少工作節(jié)點(diǎn)的管理。希望EKS的工程師們能像GKE那樣都打包集成好。

有意思的是我注意到EKS居然支持i3.metal實例，這是Kubernetes支持裸金屬工作節(jié)點(diǎn)的唯一解決方案。這對于一些用戶來說可能會有用。

我的公司正在考慮用Azure

同樣的，你真正能做的也不多。我的建議是準(zhǔn)備一個demo來對比AKS和GKE，試著將開放人員的經(jīng)驗傳遞給做決定的人。

給他們展示Azure上的某些操作是如何通過一個難用的交互頁面才能完成，其他的需要Powershell，還有一些亂七八糟的還要用到命令行。試著讓人們?nèi)フf明操作緩慢的原因，以及它在整體上是如何影響DevOps流水線和自動化的。沒錯，你確實能讓Azure跑起來，但生活已經(jīng)如此艱難，為什么不讓自己輕松一點(diǎn)呢?

有可能你被類似Active Directory這樣的需求所綁架了，那就真的是不走運(yùn)了。

我說下面這句話的時候是很認(rèn)真的：如果我所在的公司決定遷移到Azure上，我會重新找一份工作的。順便說一句，情況并非總是如此。我年輕的時候管理過Windows服務(wù)器，當(dāng)時每個禮拜我都要修復(fù)損壞的TFS(Team Foundation Server)，還要走進(jìn)機(jī)房去更換磁帶。

現(xiàn)如今我想要用編程的方式來控制基礎(chǔ)架構(gòu)。所以它需要高效又沒有太多Bug，這樣我才能在上面去構(gòu)建一些酷炫的自動化工程。而在Azure這樣的產(chǎn)品上工作，尤其是我還用了好多年的AWS，真的會讓人感到絕望。

更新：為了量化Azure AKS到底有多慢以及有多少bug，有可能會想看看Dolos項目。

對于所有那些正在從本地數(shù)據(jù)中心往Azure上遷移的人來說，在敏捷性方面可能會是一個進(jìn)步，所以我祝你好運(yùn)吧。

好了，現(xiàn)在你清楚了!這個網(wǎng)站需要對比跑在云上的Kubernetes服務(wù)。我的建議是只要有可能就用谷歌 GKE.如果你已經(jīng)上了AWS，那么就試試EKS吧，但現(xiàn)階段它真的給不了你太多東西。在他們將可管理的工作節(jié)點(diǎn)以及其他一些功能集成之前，你可能***先看看Kops和一些其他的云產(chǎn)品。