Containerisation和Orchestration使用工具及其原因

Question

披露:

• 我对市场上现有的容器化和编排工具几乎没有什么问题.
• 我曾在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上也很有用.

Answer 1

我很困惑，无法说服对Kubernetes和Docker Swarm表示拒绝的人，如果有人可以，请向我详细介绍在AWS生产中使用什么以及为什么使用？

您提供的三分之二的解决方案与平台无关，因此我们可以在不关注AWS的情况下谈论它们。

我建议您使用Kubernetes，下面将尝试解释原因。

当我必须为管理员提供超过1个虚拟机（由docker-machine创建）作为工人时，Docker Swarm如何更好地平衡负载和自动扩展？

Docker Swarm是使用相对简单的逻辑来编排Docker应用程序的相对简单的平台。要实现基于节点的自动缩放，您应该使用一些外部工具（例如，在AWS中，您可以使用具有一些基于CPU负载的规则的自动缩放组）。而且，您将必须添加一些自定义脚本来添加和删除Docker Swarm集群中的节点。所有这些都是可能的，但是您将需要自己开发它。

Kubernetes是否在实例级别上扩展？

是的，它确实。Kubernetes可以使用cluster- autoscale 守护程序进行扩展，该守护程序可以在集群内部运行，并且可以根据多个指标（包括自定义指标）自动上下扩展实例。您无需创建任何脚本，所有逻辑都已实现，只需设置规则。

如果Elastic Bean Stalk可以管理我的整个容器化以及AutoScaling和负载平衡，那么2以上的需求量如何，并且更好地使用？

Elastic Beanstalk是在AWS内运行应用程序的解决方案，但是您会受到其功能的限制。是的，它可以为您做很多事情，但是如果您需要自定义项目，或者需要创建混合云解决方案-这不是一个选择。

最后，我可以告诉您，使用Kubernetes，您将获得：

1. 大量的文档和社区经验。
2. 从自动缩放到A / B测试，以及自动签名，Let's Encrypt认证几乎可以为您的服务提供所有服务。您将花费大量时间在Docker Swarm或Elastic Beanstalk中实现所有功能，而其中的某些功能在其他协调器中几乎是不可能的。
3. 平台不可知论者。您可以迁移到任何平台（甚至迁移到内部部署），而对应用程序的配置所做的更改很少。Docker Swarm也几乎可以在任何地方工作，但是功能较少。
4. 有关调度，作业，应用程序分发，不同类型的卷等还有很多其他内容。

另外，我可以向您推荐一些Kubernetes模块和应用程序，这些模块和应用程序对（不仅是）AWS可能对您有用。

• Kube2iam工具为您提供AWS IAM角色，将其直接分配给您的Pod，而不是实例。
• 自动缩放模块。
• 证书管理器生成LetsEncrypt SSL密钥。它具有用于DNS挑战的Route53集成。
• Nginx-inress作为入口控制器，可为您提供许多功能和最佳的Nginx体验。
• Kops。但是您已经知道了。