小编Nai*_*hah的帖子

披露:

• 我对市场上现有的容器化和编排工具几乎没有什么问题.
• 我曾在docker swarm,kubernetes和Elastic Bean Stalk工作过.

问题:我想自动扩展,而不必处理ec2实例,我不必担心扩展实例.我知道GKE提供了这个,但我想坚持使用AWS.我可以根据请求,内存,仪表板上的CPU定义扩展触发器的系统(与弹性beanstalk相同但我需要运行多个服务.所有服务都有不同的缩放触发器).从我读到的,一个常见的事情是kubernetes和ECS是我必须编写基于云监视事件的脚本.

问题1:对于Docker Swarm:

当我必须提供超过1台虚拟机(由docker-machine创建)作为我的经理的工作人员时,Docker Swarm如何更好地平衡负载和自动扩展？

我的看法:

• 这是成本明智的不好,因为无论如何我将不得不支付这2个实例.
• 当负载较低时,此VM仍将存在.
• 我不认为除了手动运行的脚本之外,这里不会有任何自动缩放.
• 我将在这里管理一个docker-compose.yml.

问题2:对于Kubernetes:Kubernetes

是否在实例级别上扩展？

我的看法:

• Kubernetes提供了自动缩放的选项(如水平缩放等)但这一切都发生在服务级别上,最后会有多个pod和容器
• 据我所知,Kops生产的Kubernetes集群中一切都会发生,所以如果它在实例级别上扩展,它会怎么做？因为它没有像docker中的SWARM那样的虚拟机概念.
• 我将根据我的服务在这里管理多个YAML文件.

Q.3对于Elastic Bean Stalk:

如果Elastic Bean Stalk可以管理我的整个容器化以及AutoScaling和Load Balancing那么如何满足需求并且更好地使用？

我的看法:

• Elastic Bean Stalk现在更倾向于Fargate,目前并不适用于所有区域.
• 我在此过程中看到,它通过提供基于我的服务的完整配置仪表板来完全控制.
• 它将根据我的加载和自动缩放创建一个新的实例.

我很困惑,无法说服那些对Kubernetes和Docker Swarm说"不"的人,如果有人可以请详细介绍在AWS上使用什么和为什么用于生产？因为即使知道上面的这个工具,我也没有回答主要的AutoScaling和LoadBalancing on Production.

上面列出的问题将AWS视为云部署平台我也想告诉您,我已经在Docker Swarm上成功运行了docker-compose.yml,为Kubernetes运行了4个不同的YAML文件,这些文件在Minikube上也很有用.