從開發(fā)人員的角度來看，EKS與AKS與GKE

在2019年2月，就在AWS宣布將GA發(fā)行版的EKS加入Azure的AKS和GCP的GKE幾個月之后，我就將這些服務進行了比較，作為第一版開源Kubernetes書的一部分。 從那時起，Kubernetes的使用激增，所有主要云提供商的托管Kubernetes產(chǎn)品都變得標準化。 根據(jù)Cloud Native Computing Foundation(CNCF)于2020年3月發(fā)布的最新調查，在AWS和GCP的托管Kubernetes服務中，Kubernetes的生產(chǎn)使用率從58%躍升至78%。

> Container Management Usage from CNCF 2019 Survey

根據(jù)我與Kubernetes的親身經(jīng)歷，從2019年到現(xiàn)在，最顯著的不同之處在于云之間的功能均等性。 GKE曾經(jīng)享有的巨大領先優(yōu)勢已大大減少，在某些情況下已被其他提供商所超越。 由于有很多資源可以比較每種服務的提供和價格差異(例如，learnk8s.io，stackrox.com，parkmycloud.com)，因此，在本文中，我將重點介紹在開發(fā)和生產(chǎn)中使用這些服務的個人經(jīng)驗。 。

亞馬遜EKS

考慮到AWS在云上的主導地位，EKS和kops的大量使用量就不足為奇了。 現(xiàn)有AWS客戶的明顯優(yōu)勢是，只需對其他服務進行最少的修改即可將工作負載從EC2或ECS遷移到EKS。 但是，就托管Kubernetes功能而言，我通常發(fā)現(xiàn)EKS落后于GKE和AKS。 Github上有一個針對所有AWS容器服務(ECS，ECR，F(xiàn)argate和EKS)的公開路線圖，但我從AWS上獲得的總體印象是推動更多的無服務器產(chǎn)品(例如Lambda，F(xiàn)argate)，而不是容器使用。

但這并不是說Amazon的支持并不出色，我也不認為EKS并不是Amazon的優(yōu)先事項。 實際上，EKS提供了有財務支持的SLA來鼓勵企業(yè)使用(2020年6月15日更新-從5/19/20開始，AKS還提供了有財務支持的SLA)。 由于EKS強制執(zhí)行RBAC和Pod安全策略，因此在基本級別的安全性方面勝過GKE和AKS。 最后，既然GKE還在每個主節(jié)點管理上每小時收取$ 0.10的費用，那么使用預留實例和其他企業(yè)協(xié)議，這兩個云之間的價格差異甚至可以忽略不計。

與許多其他AWS服務一樣，EKS在配置集群方面提供了很大的靈活性。 另一方面，這種靈活性也意味著管理負擔落在了開發(fā)人員身上。 例如，EKS為Calico CNI提供網(wǎng)絡策略支持，但要求用戶手動安裝和升級它們。 Kubernetes日志可以導出到CloudWatch，但默認情況下處于關閉狀態(tài)，并留給開發(fā)人員來部署日志記錄代理來收集應用程序日志。 最后，升級也是由用戶發(fā)起的，負責更新開發(fā)者身上的主服務組件(例如CoreDNS，kube-proxy等)。

> Deploying Worker Nodes is a Separate Step than Provisioning a Cluster — Image from AWS

EKS最令人沮喪的部分是創(chuàng)建實驗集群的困難。 在生產(chǎn)中，以上大多數(shù)問題都可以通過Terraform或CloudFormation解決。 但是，當我只想創(chuàng)建一個小的集群來嘗試新事物時，使用CLI或GUI往往要花一些時間，卻意識到在此過程的后期我錯過了設置或IAM角色。

在我們完善Terraform配置之前，我發(fā)現(xiàn)eksctl是創(chuàng)建可用于生產(chǎn)環(huán)境的EKS集群的最可靠方法。 eksworkshop網(wǎng)站還為常見的群集設置操作(例如部署Kubernetes儀表板，站立EFK堆棧進行日志記錄以及與其他AWS服務(如X-Ray和AppMesh)集成)提供了出色的指南。

> eksctl — cli tool for EKS b WeaveWorks

總體而言，直到EKS在Kubernetes 1.14及更高版本中引入受管節(jié)點組之前，我發(fā)現(xiàn)EKS的管理負擔相當重，尤其是在開始時。 AWS正在迅速趕上競爭者，但是EKS仍然不是新用戶的最佳起點。

Azure AKS

出人意料的是，在為較新的Kubernetes版本提供支持方面，AKS超過了GKE(截至2020年6月，AKS的預覽版為1.18，而GKE的預覽版為1.17)。 同樣，AKS仍然是唯一不對控制平面使用收費的服務。 像EKS一樣，主節(jié)點升級必須由開發(fā)人員啟動，但是EKS負責基礎系統(tǒng)升級。

就個人而言，我沒有在生產(chǎn)中使用AKS，因此我無法評論技術或運營方面的挑戰(zhàn)。 但是，自2020年5月19日起，AKS不僅提供了財務支持的SLA(99.95%的可用區(qū))，而且還使其成為可選功能以允許無限的免費集群(2020年6月15日更新)。

盡管如此，Azure在從CNCF畢業(yè)時對Helm(微軟收購了創(chuàng)建Helm的Deis的貢獻)的貢獻就體現(xiàn)了Azure對Kubernetes的持續(xù)投資。 隨著Azure繼續(xù)縮小與AWS的差距，我希望隨著對社區(qū)關注的支持不斷增加，AKS的使用量將會增加。

> Packaging Applications — CNCF Survey

Google Cloud GKE

盡管Google決定開始對非Anthos集群的控制平面使用收取費用的決定激起了開發(fā)人員社區(qū)的挫敗感，但GKE在功能，支持和易用性方面無疑仍然是托管Kubernetes的王者。 對于不熟悉Kubernetes的新用戶，GUI的創(chuàng)建集群以及通過Stackdriver進行默認日志記錄和監(jiān)視集成的經(jīng)驗使您輕松上手。

GKE還是唯一提供完全自動化的主節(jié)點和節(jié)點升級過程的服務。 通過引入群集維護窗口，可以在受控環(huán)境中以最小的開銷進行節(jié)點升級。 節(jié)點自動修復支持還減輕了開發(fā)人員的管理負擔。

與許多GCP產(chǎn)品類似，GKE出色的托管環(huán)境確實意味著定制可能很困難，甚至有時是不可能的。 例如，GKE默認情況下會安裝kube-dns，要使用CoreDNS，您需要修改kube-dns設置。 同樣，如果Stackdriver不適合您的日志記錄和監(jiān)視需求，則您必須卸載這些代理并自己管理其他日志記錄代理。

盡管如此，我在GKE上的經(jīng)歷總體上還是令人愉快的，即使考慮到價格上漲，我仍然建議將GKE推薦給EKS和AKS。 GKE最令人興奮的部分是基于托管Istio和Cloud Run的基于服務的服務數(shù)量不斷增長。 托管服務網(wǎng)格和用于容器的無服務器環(huán)境將繼續(xù)降低向云和微服務架構遷移的門檻。

盡管GCP在整體云市場份額方面落后于AWS和Azure，但它在2020年仍然在Kubernetes方面保持領先地位。

> Google Cloud Service Platform — GCP Blog

資源資源

• CNCF調查2019
• Kubernetes托管服務
• Kubernetes書
• 比較：Amazon，Azure和Google的托管Kubernetes服務
• EKS對GKE對AKS