咨询QQ:
      杂志订阅

      编辑

      网管

      培训班

      市场部

      发行部

电话服务:
 010-82024981
欢迎, 客人   会员中心   帮助   合订本   发布信息
设为首页 | 收藏本页
企业应该选择哪种AWS容器编排平台?
  • 容器编排平台使容器的使用变得更加容易,在容器上运行任何应用程序将使其可迁移。但是,当需要扩展或添加服务时,如果企业没有一个平台来管理和组合所有功能,那么将会遇到问题,并且很快将变得难以处理。

    容器编排平台使容器的使用变得更加容易,在容器上运行任何应用程序将使其可迁移。但是,当需要扩展或添加服务时,如果企业没有一个平台来管理和组合所有功能,那么将会遇到问题,并且很快将变得难以处理。

    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的部署时间要快得多,只需几秒钟,因此企业每天可以部署几次,并且快速反馈更改。可以使用Kubectl命令行工具声明所有内容,并且有很多集成。这些功能包括服务到服务的通信以及Pod和Worker节点的本地扩展,使企业的开发人员可以专注于其业务逻辑并提供新功能。在此需介绍Helm,这是一个程序包管理器,它具有将多个应用程序或业务逻辑捆绑在一起以用于整体部署和更新整个单元的功能。

    使用EKS应该注意什么?

    人们必须意识到,Kubernetes只适合一部分企业。企业每个月将增加控制平台的成本,并且学习曲线比使用弹性容器服务(ECS)时要陡得多,并且目前与AWS云平台的集成较少。与弹性容器服务(ECS)不同,AWS公司的身份和访问管理(IAM)不是内置的,因此企业的开发人员或DevOps将需要安装其他工具来实现此功能。

    另一个严重的限制是容器密度,这是EKS的独特问题。每个容器(pod)都绑定到虚拟私有云(VPC)中的某个专用IP,并且如果企业的应用程序使用许多副本或微服务,则集群可以扩展,但不是由于企业的实例耗尽了CPU或内存,而是因为实例已经运行IP分配给工作节点。

    这将导致额外的成本,并且可能会受到限制,因为企业的开发人员将为工作节点使用的较小实例提供有限的IP。如果企业的微服务快速并且大规模扩展,这是需要考虑的一个重要因素。

    EKS适合谁?

    这里的关键问题是,一旦安装完成,谁将负责获得它的所有权?管理和维护EKS需要专门的专家,如果企业没有人手,则另一种选择可能更合适。

    Fargate:容器按需选择

    有了Fargate,这将是一个全新的游戏。企业无需创建自己的控制平台或实例,不需要集群,也不需要基础设施升级或维护。与其相反,企业可以指定要使用多少资源,并按需付费。这使企业有机会专注于应用程序的设计和构建,而不必担心底层基础设施。

    Fargate最棒的地方就是可以快速地横向扩展,也就是按需扩展的能力。开发人员只需创建容器并部署到Fargate服务。其设置简单,无需学习。

    Fargate不适合有状态工作负载,它要求企业的应用程序是无状态的,这是某些公司不选择Fargate的主要原因之一。此外,尽管能够在短时间内进行扩展是令人兴奋的,但可能没有多少用户需要此功能。

    谁最适合Fargate?

    企业需要了解其预算是否适合选择Fargate而不是投资DevOps团队,以及了解其按需扩展的好处是否值得更多投资。如果企业只有少量服务,则很有可能。

    对于许多人来说,Fargate可以很好地用作混合解决方案,从而使企业的应用程序可以按需扩展以实现按需任务,而不必全天候使用。另一个考虑因素是隔离那些资源使用量激增的工作负载,并在Fargate上运行它们,以最大程度地减少对弹性容器服务(ECS)或EKS集群性能的影响。

    最后,EKS是容器编排中越来越受欢迎的选择,但这并不意味着它是满足企业业务需求的最适合的解决方案。需要记住,更多的特性和功能会带来更多的复杂性,并且管理生态系统将需要更多的资源。因此,企业在选择AWS容器编排平台之前需要确定是否符合自己的最大利益。

    编辑:NIKI

    容器编排平台使容器的使用变得更加容易,在容器上运行任何应用程序将使其可迁移。但是,当需要扩展或添加服务时,如果企业没有一个平台来管理和组合所有功能,那么将会遇到问题,并且很快将变得难以处理。