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。