1. 程式人生 > >ECS vs. Kubernetes 類似而又不同

ECS vs. Kubernetes 類似而又不同

googl pac 高可用 連接 分布 tps 靈活性 供應商 細粒度

C2Container Service (ECS)和Kubernetes (K8s) 都解決了同樣的問題:跨越主機集群管理容器。ECS和Kubernetes之間的鬥爭讓我想起了vi和Emacs之間的編輯器之戰:激烈的討論集中於技術問題和個人信仰上。接下來的問題將幫助你明智的選擇。考慮到問題和答案包含了我的主張——ECS和K8s之間的區別,基於我最近項目上的經驗。

技術分享

它合適嗎?

一個容器是一個隔離的元素。但是跨主機集群啟動容器只是挑戰的一小部分。你的容器在一個由基礎設施和服務組成的世界中存在:舉幾個來說,存儲系統,數據庫,域名服務。

你打算在哪運行你的容器?

  • Amazon Web Services (AWS)
  • Google Cloud Platform (GCP)
  • 其他IaaS供應商

本地部署

能夠整合容器管理解決方案到基礎設施中是關鍵。

ECS在容器和其他AWS服務之間提供最無縫的集成。下面是幾個例子:

  • 分配IAM角色給每個容器,允許細粒度訪問控制其他服務。
  • 在外部負載均衡器註冊容器(應用負載均衡器)。
  • 基於集使用擴展EC2實例(自動伸縮)。
  • 收集日誌(監測日誌)。

在K8s和AWS之間實現一個類似水平的集成是一個大量的工作。例如,用etcd構建一個生產就緒的關鍵值存儲,需要K8s,需要高可用,加密,和幾周的滾動更新。通過負載均衡器和域名系統集成K8s是另一個重大的障礙。

另一方面,K8s提供了與GCP免費的集成。Google Container Engine提供以下內容:

  • 在多個高可用區域之間分布集群。
  • 基於使用擴展集群。
  • 為容器提供持久的磁盤。

K8s在使用Google Container Engine(GKE)時提供了最大的價值,因為它與GCP集成。

如果你正在使用其他IaaS供應商,而不是Amazon和谷歌,或運行在本地部署上,那麽K8s是唯一的選擇,因為ECS只在AWS上運行。可比較的ECS在AWS上或在K8s在GCP上,在這種情況下,構建一個類似的基礎設施將是大量工作。

它和你的架構匹配嗎?

ECS和K8s在服務發現上遵循不同的策略。

ECS使用負載均衡器進行服務發現。通過負載均衡器可以訪問外部和內部服務。應用程序負載均衡器(ALB)提供路徑和基於主機的路由以及內部或外部連接。

K8s使用不同的策略。只有來自集群外部的請求通過負載均衡器。虛擬IP提供對內部服務的訪問,而不需要負載均衡器。

如果你的微服務架構嚴重依賴服務到服務通信,K8s提供較少的通信成本。除此之外,ECS也為微服務體系結構提供了樸素而簡單的方法。特別是,如果大部分的服務需要從互聯網上進行訪問。

誰運營它?

我強烈反對你自己去運營一個容器集群,只要可能。或者,一個自己動手的容器基礎設施是否有有價值會增加你的業務?

通過ECS提供的集群管理是一個完成的管理服務,提供高可用,可擴展性和安全。使用ECS沒有額外費用,而且它也被AWS支持計劃所覆蓋。但是,你仍然對由EC2和VPC組成的底層基礎設施負責。

Google Container Engine(GKE)也提供管理服務。GKE提供管理K8s集群包括底層基礎設施。如果你的集群由超過5個節點組成,Google的管理費用是每月100美元。

它成功了嗎?

K8s在Apache許可2.0下獲得許可,然而ECS是AWS提供的專有服務。盡管如此,AWS發布了Blox,這是一個開源項目的集合,用於在ECS上進行容器管理和編排。

K8s社區充滿活力,產生了許多創新的解決方案。開源生態系統提供了靈活性。但是不要期望除了K8s核心之外的生產解決方案。

廠商鎖定一個流行的爭論在ECS與K8s討論中。我認為,ECS和K8s都將你鎖定在他們的解決方案中。盡管K8s是開源的,但是谷歌在技術演變和商業化其雲平臺方面是主要貢獻者。

總結

你有在用AWS作為基礎設施供應商嗎?使用ECS來管理和調度容器,並從高度集成和完全托管的服務中獲益。

你是否使用GCP作為基礎設施提供商?使用谷歌容器引擎(GKE)提供完全管理的K8s集群,並集成到GCP基礎設施中。

你是在本地部署上運行還是使用另一個IaaS提供商?運營K8s集群可能是你唯一的選擇。在集成你現有的基礎設施,構建一個高可用和伸縮的K8s集群時,預期會有大量的eff。

ECS vs. Kubernetes 類似而又不同