技術專欄
.svg){kind=logo}
隨著雲原生(Cloud Native)、微服務(Microservice)等概念蔚為顯學，越來越多企業紛紛改造舊有單體式應用程式架構、轉而擁抱容器化架構，與此同時也需要借助適當的容器管理平台（Container Orchestrator Platform）來支援大規模應用，針對容器進行生命週期管理。
但問題來了，現階段市面上似乎已有許多容器管理平台產品，其中包括Kubernetes、Docker Swarm、Red Hat Open Shift、Rancher等開源解決方案，另外也有像是VMware Tanzu、AWS、Azure相關服務等多種商業化產品，到底該怎麼選擇會比較好？
持平而論，不同的平台都各有其優勢或劣勢。因此AWS儘可能提供多種不同的容器管理服務及相關工具，以期滿足不同用戶的各種考量。截至目前，AWS提供的選項包括Amazon Elastic Container Service（ECS）、Amazon Elastic Kubernetes Service（EKS）、AWS Fargate，以及最新推出的Amazon EKS Anywhere。接下來的篇幅，將針對這些方案進行詳盡說明，指引AWS使用者選擇最適合自身需求的項目。
容器(Container)是一個輕量級的、獨立的、可移植的、可執行的軟體封裝套件（Software Package），涵括運行一個應用程式所需之一切機能，從應用程式本身到所有的設定、相依性軟體或套件、系統資源庫等。由於容器化套件的存在，讓我們能夠大幅簡化應用程式的開發與部署。而Amazon ECS，便是具有容器的代表性產品。
理解什麼是容器後，現在我們來談談為何需要使用容器管理平台。正式的應用程式環境單單只有容器還不夠，我們還需要下列資源，才能輔助容器順暢運作：
儘管容器封裝了應用程式本身，然而仍需要透過容器管理平台，才能在容器運作的整個生命週期當中，滿足前述所提到的其他需求。而Amazon EKS，便是具有容器管理功能的代表性產品。
Amazon Elastic Container Service (Amazon ECS) 是具高可擴展性且快速的容器管理服務，可讓您輕鬆執行、停止和管理叢集上的容器。在Amazon ECS中， 您的容器是在"任務定義"(task definition)中定義的，您可以使用該"任務定義" (task definition)來運行單個任務或服務中的任務。在此內容中，服務是可讓您在叢集中同時執行並維持指定數目之任務的組態。您可以在由 AWS Fargate 管理的無伺服器基礎設施上執行您的任務和服務。如您需對基礎設施掌握更大的控制權，您可以在您管理的 Amazon EC2 執行個體叢集上執行任務和服務。
Amazon Elastic Kubernetes Service (Amazon EKS) 是一項受管服務，可用於在 AWS 上執行 Kubernetes，而無需安裝、操作和維護您自己的 Kubernetes 控制平面或節點。Kubernetes 是一套開放原始碼系統，用於容器化應用程式的自動化部署、擴展與管理。
Amazon EKS 引進 Kubernetes Pod 概念來部署與管理容器， Amazon ECS 則直接使用單個容器來滿足部署需求。 Kubernetes Pods，可以包含一或多個具有共享資源池的容器，且為服務當中的元件提供更靈活、也更細緻的控制功能；像是Proxy、Service Discovery 等等所有運行容器時需要使用的服務，都包含在 Kubernetes Cluster 裡頭。
這邊做一個假設，我們的應用服務係由微服務API、映像檔管理及儲存空間等三個獨立元件組合而成，Kubernetes會允許我們把三個獨立元件、列為不同容器在構成應用服務的一個Pod當中運行，而Pod裡頭的容器相互搭配執行，它們可以輕易地相互存取，也可以共享儲存等資源，並不需要依賴複雜設定或外部服務。這也意謂著，使用者可以善用Amazon EKS來建構更複雜的應用程式架構。
不僅如此，EKS還能讓使用者進入更為廣泛的Kubernetes生態系，同時運用多樣化的附加元件，其中包括Cisco ACI、VMware NSX、Red Hat OVS或Project Calico等網路政策管理及網路解決方案（CNI），還有負責提供DNS服務的CoreDNS，以及其餘眾多的第三方附加元件與整合服務。另外，因為Amazon EKS奠基於Kubernetes，以致使用者可靈活地在不同Kubernetes Cluster之間移動工作負載，不會被綁定在某個特定廠商的平台或產品之上。
不可諱言，即便採用AWS全託管服務，但提供運算的伺服器依然存在，因此使用者可以決定哪種類型的運算資源，究竟是要提供給Amazon ECS或Amazon EKS來使用。
接著談到AWS Fargate，它是一個無伺服器（Serverless）、Pay-as-you-go的運算引擎，允許使用者專注開發應用程式，無需分神管理伺服器。這意謂AWS將接管底層伺服器的管理事務，不會要求使用者建立伺服器、安裝軟體並維持更新。換句話說，你一旦使用AWS Fargate，僅需建立一個叢集、同時新增一個工作負載，緊接著AWS就會自動添加Pre-configured的伺服器，來匹配你的工作負載需求。
由此看來，其實在大部份情況下，AWS Fargate顯然會是更理想的解決方案，因為它不會比自我管理的伺服器花費更多，況且在多數情形下，僅對確切的使用量收費，似乎更具成本撙節效益。
如此一來，AWS Fargate使用者不必像自我管理的伺服器時那麼擔心未使用容量（需要自己手動關閉來節約成本）。但是AWS Fargate並不適用於所有應用情境，使用者需要留意一些例外狀況。舉例來說，AWS Fargate不能用於具有嚴格安全與合規要求的環境，此乃由於AWS Fargate使用者失去了對底層伺服器的存取權，導致無法藉由控制這些伺服器來滿足嚴苛的合規需要，再者AWS Fargate也完全不支援「dedicated tenancy 」的獨立託管要求。
另一方面，AWS Fargate與Amazon ECS有一點很類似，都僅能支援Amazon VPC網路模式，因而無法對網路層執行深度控制。再者，AWS Fargate主要是根據工作負載來自動分配資源，所以無法針對特定的控制進行設定；肇因於這般自動資源分配模式，可能意外導致某些場景的使用成本飆升，尤其在測試許多工作負載的研發環境更是如此。在此情況下，擁有使用容量限制機制的自我管理伺服器，仍會是更適合上述?
談到Amazon EKS，主要特色在於擴展了EKS的功能，允許使用者在自行管理的基礎設施上啟用預設的設定，來建立與執行Kubernetes Cluster。在此同時，它也提供了使用EKS控制台管理叢集的必需工具。
談到Amazon EKS，主要特色在於擴展了Amazon EKS的功能，允許使用者在自行管理的基礎設施上啟用預設的設定，來建立與執行Kubernetes Cluster。在此同時，它也提供了使用Amazon EKS控制台管理叢集的必需工具。
大致上來說，Amazon EKS Anywhere是建立在Amazon EKS Distro基礎上，提供所有最新而且必要的軟體，你可將這些軟體安裝於你的基礎設施之上。更重要的，如果和需要完全自我管理的Kubernetes Cluster相較，Amazon EKS Anywhere顯然更能提供一個相對可靠的Kubernetes平台。
由於Amazon EKS Anywhere採取混合雲架構，因此讓企業不管在雲端或地端操作，皆可保持如同內網運作的一致性。對於資料安全有所顧慮的企業，正好可以利用Amazon EKS Anywhere兼能支援雲地環境的特質，選擇將資料保存在企業內部的基礎設施，再利用AWS服務來管理應用程式的架構與部署。
迄至目前，迎向容器化架構的多數企業，普遍會在Amazon ECS、Amazon EKS兩者間進行抉擇，也非常想瞭解自己到底適合哪一邊。相形之下，Amazon EKS比起Amazon ECS無疑是更強大的平台，但並不代表Amazon EKS是所有工作負載的最佳解方，Amazon ECS挾著簡單性和直覺的功能設置功能，依然適用於不少工作負載。
接著來談談Amazon ECS的使用時機。首先Amazon ECS入手門檻低，學習曲線不高，因此一些小型組織、或資源有限的團隊，往往會認為Amazon ECS是用來管理容器工作負載的最佳選擇。其次Amazon ECS有一大特性，即是允許使用者更緊密地整合已經熟悉的AWS資源，例如Amazon ALB(Application Load Balancer)、Amazon NLB(Network Load Balancer)或Amazon Route 53等等，有助於管理應用程式架構，並且快速啓動及執行應用程式。再來Amazon ECS可以被視為Kubernetes雲端化的起手式，使用者不需要一次性適應Amazon EKS，而能夠使用Amazon ECS來執行容器化策略，以較少的前期投資負擔，把工作負載轉移到Amazon ECS全託管服務。
反觀Amazon EKS的優勢，則建立在Amazon ECS「過於簡單、設定選項不多」的限制上。它提供更多的功能與整合，以便於建立與管理任何規模的工作負載。論及它的使用時機，首先在於儘管許多工作負載可能不需要Pods，但Pod提供了對Pod放置與資源共享的完整控制，這在處理多數基於服務的架構時，堪稱是無比的價值。其次Amazon EKS在管理底層資源時提供更大的靈活性，不僅可靈活地在Amazon EC2、AWS Fargate上運作，甚至可透過Amazon EKS Anywhere在企業內部使用。
其次Amazon EKS提供了使用任何公開或私有容器儲存庫的一切能力。再來，Amazon ECS的監控與管理工具僅限於AWS所提供的工具，雖然它們足以滿足多數使用場景，但對照於Amazon EKS能透過內建的Kubernetes工具及現成的外部整合資源，展現更大的管理監控能力，Amazon EKS明顯更勝一籌。
總而言之，平台的選擇為何，取決於使用者的實際需求。不論是Amazon ECS或Amazon EKS，其實都有其優缺點，只要使用者認清自己的工作負載特質，即可正確地選用Amazon ECS或Amazon EKS、發揮最大功效。基本上，倘若你很熟悉Kubernetes，並且想要引用它所提供的靈活性和較為豐富的功能，以Amazon EKS為宜；反之如果你才剛開始使用容器，或者傾向引用相對簡單的解決方案，則Amazon ECS會是理想選項。
