为什么应该使用Amazon ECS而不是Kubernetes？

2 年 ago

雅, 悟

1 minute

概括：

Kubernetesのデメリットを把握した上で導入するべき

Kubernetes和Amazon ECS在Docker容器编排工具的领域中处于相同的位置。

首先，为什么需要编排工具呢？因为它可以实现在生产级别上进行操作。管理分布在多个主机上启动的Docker容器的生死监控、自动扩展等并不简单。为了解决这些问题，存在着Kubernetes和ECS等编排工具。

在这个工具中，Kubernetes是一个典型的代表。Kubernetes是一种开源工具，最初是Google内部使用的”Borg”工具的开源版本，目前由许多开发人员和云服务提供商进行维护。

亚马逊 ECS 是亚马逊提供的容器编排服务。ECS 消除了 Kubernetes 中的各种概念，定位为轻量级的编排工具。只需指定所需的任务定义（包括启动的容器数量和资源等），ECS 就会自动进行托管管理。

Kubernetes通过设置类似服务空间的Namespace，为每个Namespace提供详细的权限。这样一来，例如每个微服务团队就能够自主运营一个服务。

如果是微服务架构的话，可以说在一个账户上运营多个单体服务是没有必要的。向每个团队教授Kubernetes的基础知识，然后告诉他们“从现在开始请独立操作”，但是这对他们来说没有任何优势，在许多组织中这也是技能上的困难。

Kubernetes是一种高度抽象化的系统，可以适用于各种环境和用途。相比于ECS，在将其具体化以用于自己的组织中运营时，需要投入更多的时间和资源。考虑到后续提到的大量周边工具的混乱期，我担心Kubernetes会变成一个纯粹的时间浪费。

Kubernetes的持续交付工具”Spinnaker”非常著名，Spinnaker可以进行金丝雀部署。然而，金丝雀部署是否成为引入Kubernetes的原因是可疑的。在许多情况下，蓝绿部署已经足够，并且每次都必须使用金丝雀部署对于恐惧部署的状态并不健康，也不能解决根本性问题。

另外，还需要构建和运维Spinnaker本身。我曾经也搭建过Spinnaker，但许多人似乎在引入和运维方面遇到困难。相比之下，AWS提供了托管式部署服务CodeDeploy，它支持向ECS进行蓝绿部署。当然，使用CodeDeploy不需要进行构建和运维。

服务网格是一种用于控制各个微服务之间通信和路径的思想，这些需考虑跨越多个服务。在ECS中，目前引入服务网格较为困难，而在Kubernetes中，可以通过使用Istio或Envoy等方式引入。

AWS App Mesh等类似的服务（尚未正式发布）可以作为管理微服务的基础设施，能够与ECS和EKS集成。随着AWS推出托管服务，自己运维Kubernetes的优势逐渐减少。

如果要列出Kubernetes的一个优点，那就是它不依赖于特定的供应商。Amazon ECS仅适用于AWS，在GCP或自有服务器中只能选择使用Kubernetes。

有些人认为，“过度依赖供应商是不应该使用ECS的原因。” 但是无法否认的事实是，供应商锁定是不可避免的，几乎不可能将云从AWS迁移到其他地方。即使真的需要迁移云，仅仅运行10到30个单体服务在ECS上，根本不会构成迁移的障碍。

如果使用ECS的话，可以使用Terraform来完成应用程序配置和持续交付的构建，一切都可以在Terraform上完成。例如，如果想在ECS上运行Nuxt.js并使用CodePipeline进行持续交付，可以将所有内容都在这个Terraform仓库中管理。

然而，在使用Kubernetes时，需要使用Helm、Kustomize等工具来创建YAML文件，如果需要的话还需与Spinnaker进行集成。个人认为，由于Kubernetes的YAML管理工具过多，让人感到难以入门。至今仍然没有摆脱周边工具混乱的时期，并且很难否认被工具左右的印象。

如果您可以使用AWS并且ECS足够了的话，就选择使用ECS吧。

上述内容显示，使用Kubernetes的原因并不适用于许多组织。通过ECS，可以充分运营生产级别的Docker应用程序。

作为一项仅限于Kubernetes平台中的尝试，我们在Kubernetes上运营了数百个以上的Docker开发环境。如果要引入Kubernetes作为招聘的亮点之一，我们需要谨慎思考。