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 類似而又不同