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。
登录后评论
立即登录 注册