容器編排平臺使容器的使用變得更加容易，在容器上運行任何應用程序將使其可遷移。但是，當需要擴展或添加服務時，如果企業沒有一個平臺來管理和組合所有功能，那么將會遇到問題，并且很快將變得難以處理。

AWS的容器編排平臺有三個主要選項，每個都有自己的優點和缺點。企業做出的選擇最終將取決于其業務需求和持續的維護能力。

為了幫助企業做出決定，以下是每種托管容器編排的優缺點：  

彈性容器服務(ECS)：原生選擇  

彈性容器服務(ECS)是AWS公司推出的第一個托管容器編排產品。對于許多人來說，這是最簡單的選擇，并且它當然具有最少的組件數量。  

作為一個高度集成的編排平臺，對于任何對AWS生態系統感到滿意并希望獲得AWS服務和支持的好處和熟悉度的人來說，這都是一個絕佳的選擇。它也具有成本效益，因為企業不必為使用其控制平臺支付費用，并且可以使用內置的AWS代碼工具，還可以享受服務和任務的細粒度身份和訪問管理(IAM)。  

當企業要將應用程序部署到彈性容器服務(ECS)上時，可以分別為每個應用程序定義操作，例如，指示哪些容器可以訪問S3，哪些容器沒有訪問權限。  

彈性容器服務(ECS)什么時候不是最好的選擇?  

作為專有的AWS解決方案，如果企業使用彈性容器服務(ECS)，則將應用程序克隆到其他云計算供應商并不是一件容易的事。此外，業務流程平臺對路由的支持有限，目前僅支持基于路徑的路由，不支持基于主機的路由。要考慮的另一個因素是，香港免備案主機，彈性容器服務(ECS)對狀態更改的響應比三個云計算行業巨頭中的其他服務器響應還要慢，因此，如果企業要尋求高性能的解決方案，那就不是最好的選擇。  

彈性容器服務(ECS)適合誰?  

如果企業希望進行一個物有所值的投資，而這些因素都不適合，那么彈性容器服務(ECS)是一個不錯的初學者選擇，對于沒有經驗豐富的DevOps進行業務編排的任何企業和用戶來說，它都是完美的選擇。如果企業要在云平臺上部署的服務數量有限(少于10個)，建議可以這樣做。否則將會使解決方案變得更加復雜，企業可能會發現彈性容器服務(ECS)可能更適合。  

EKS：Kubernetes的選擇  

EKS是AWS的Kubernetes產品，Kubernetes是一種流行的開源容器編排平臺。由于EKS是AWS公司的托管服務，因此消除了Kubernetes的初始安裝和維護帶來的許多麻煩。  

Amazon EKS在Kubernetes上運行。它的風格不同，因此企業獲得的功能與創建自己的Kubernetes集群時相同，如果將來要運行多云，則可以輕松克隆該平臺。  

作為一個開源平臺，EKS受益于大量的開發人員，他們不斷開發和改進這種技術，積極地開發新功能。值得一提的獨特賣點包括空間隔離，企業可以在其中用邏輯邊界分割集群，例如，限制開發人員使用特定數量的集群資源。此外，它還提供了運行Cron作業和有狀態工作負載的功能。  

與彈性容器服務(ECS)相比，EKS的部署時間要快得多，只需幾秒鐘，因此企業每天可以部署幾次，并且快速反饋更改?？梢允褂肒ubectl命令行工具聲明所有內容，并且有很多集成。這些功能包括服務到服務的通信以及Pod和Worker節點的本地擴展，使企業的開發人員可以專注于其業務邏輯并提供新功能。在此需介紹Helm，這是一個程序包管理器，它具有將多個應用程序或業務邏輯捆綁在一起以用于整體部署和更新整個單元的功能。  

使用EKS應該注意什么?  

人們必須意識到，Kubernetes只適合一部分企業。企業每個月將增加控制平臺的成本，并且學習曲線比使用彈性容器服務(ECS)時要陡得多，并且目前與AWS云平臺的集成較少。與彈性容器服務(ECS)不同，AWS公司的身份和訪問管理(IAM)不是內置的，因此企業的開發人員或DevOps將需要安裝其他工具來實現此功能。

另一個嚴重的限制是容器密度，這是EKS的獨特問題。每個容器(pod)都綁定到虛擬私有云(VPC)中的某個專用IP，directadmin安裝，并且如果企業的應用程序使用許多副本或微服務，則集群可以擴展，但不是由于企業的實例耗盡了CPU或內存，而是因為實例已經運行IP分配給工作節點。  

這將導致額外的成本，并且可能會受到限制，因為企業的開發人員將為工作節點使用的較小實例提供有限的IP。如果企業的微服務快速并且大規模擴展，這是需要考慮的一個重要因素。  

EKS適合誰?  

這里的關鍵問題是，一旦安裝完成，誰將負責獲得它的所有權?管理和維護EKS需要專門的專家，如果企業沒有人手，則另一種選擇可能更合適。  

Fargate：容器按需選擇