实战中如何扩展Docker容器

Question

我对 Docker 容器的扩展有一些基本问题：

我有 5 个不同的应用程序，它们之间没有连接。在使用容器之前，我会在云中为每个虚拟机运行一个应用程序，并单独地进行上下扩展。

现在，使用容器后，我可以在一个主机上运行 5 个 Docker 容器，其中每个应用程序都在其自己的容器中进行隔离。

只要我在主机上有足够的资源，就可以根据流量增长或缩小来单独扩展这些容器。例如，我运行了 3 个容器来运行应用程序 1，但只有 1 个容器运行应用程序 2。

在高峰时期，应用程序 3 的流量很大，我需要启动第二个主机，仅运行应用程序 3 的容器。

我的第一个问题是，我是否理解得正确，我的第二个问题是，目前有哪些技术可以以自动化的方式完成所有这些操作。我需要负载均衡器和能够在不需要手动干预的情况下满足上述场景的自动伸缩组。

我研究了 AWS ECS，但不确定它是否能满足我上述的需求。

有人知道如何实现这一点吗？或者我错过了管理和扩展我的五个应用程序的更好方法吗？

更新：

通过 Twitter，我被引导到 Kubernetes 并特别是关于 Horizontal Pod Autoscaler 的文档。

对其他人也可能有用。我将在学到更多信息时更新此问题。

- dustinmoris

---

在StackOverflow上，如果没有提供关于为什么要这样做的评论，就不应该有可能对一个问题进行负投票。 - dustinmoris

好的，也许你是对的，但是在DevOps问题上，今天的界限在哪里呢？它更偏向于开发还是运维？此外，这个问题类似，并且没有被踩过：https://dev59.com/BWMl5IYBdhLWcg3wkn0T - dustinmoris

这是一个越来越模糊的界限。我只是告诉你为什么你可能会被踩。我不能告诉你为什么其他问题没有被踩，它似乎更适合于serverfault。我不是在试图证明踩的理由，或证明stackexchange网站的分离，我只是让你知道为什么我经常看到这里发生踩的情况。我个人认为，软件工程师凭借其固有的需要将事物分开和编码，已经将stackexchange网络分成了太多具有重叠主题的网站。 - Mark B

我建议在这里发出一些声音：https://meta.stackoverflow.com/questions/271279/topicality-of-devops-questions我的DevOps问题总是被踩，无论我是在StackOverflow还是ServerFault上发布，而在PowerUser上也没有人回应。 - Jan Vladimir Mostert

@poida 我们最终同时使用了Kubernetes和AWS ECS。在撰写本问题时，AWS ECS与今天有所不同，特别是新的应用程序负载均衡器已经产生了巨大的影响。我们有两个不同的团队，其中一个使用Kubernetes，另一个现在使用AWS ECS。我认为两者都似乎很满意。 - dustinmoris

Answer 1

有几种选择，但我不知道是否有一种可以满足所有需求：您需要两个东西：根据信号自动扩展主机，然后自动扩展主机上的容器。

以下是部署和扩展主机上容器（不一定是自动缩放）的解决方案：

Kubernetes是一个编排工具，允许在集群中调度并（通过可选的自动缩放器）自动扩展pod（容器组）。如果主机失败，它确保您的容器在某个地方运行。Google Container Engine（GKE）提供此服务，但我不确定他们是否具有与AWS相同的功能来自动缩放集群中VM的数量。

Mesos：与Kubernetes有些相似，但不专用于运行容器。

Docker Swarm：Docker多主机部署解决方案，允许您像单个Docker主机一样控制许多主机。我不认为它具有任何形式的“自动缩放”功能，并且我也不认为它会确保pod始终在某个地方运行：它基本上是集群的docker。 [EDIT] Docker支持使用restart=always选项重新启动失败的容器，此外，从Docker 1.11开始，Docker Swarm是Docker守护进程的一种模式，并支持在节点故障时重新调度容器：如果节点不再可用，它将在不同节点上重新启动容器。 Docker 1.11+在功能上变得很像Kubernetes。它具有一些很好的功能（如默认情况下节点间的TLS），但仍然缺少静态IP和存储配置等功能。

这些解决方案都不能为您自动缩放主机数量，但可以在主机上缩放容器数量。

针对自动缩放主机的解决方案与您的云提供商有关，因此这些是专用解决方案。对于您来说的关键部分是要将两者集成起来： AWS允许在CoreOS上部署Kubernetes，我认为他们没有将其作为服务提供，因此您需要部署自己的CoreOS集群和Kubernetes。

现在是我的个人意见（以及免责声明）

我主要在GKE和裸金属上使用Kubernetes，大约6个月前也使用了Swarm，并在GKE上运行了约35个服务的基础架构:

坦率地说，使用Kubernetes作为服务的GKE提供了大部分你想要的功能，但它不是AWS。扩展主机仍然有点棘手，需要一些工作。

在AWS或裸机上设置自己的Kubernetes或Mesos非常可行，但有相当大的学习曲线：这完全取决于你是否真的强烈希望在AWS上，并愿意花费时间。

Swarm可能是最容易使用的，但更受限制，但是自建脚本可以很好地完成核心工作：使用AWS API扩展主机，并使用Swarm进行部署。但如果节点失败，则可用性保证需要您监视并重新启动容器。

除此之外，还有可能为您提供服务的容器托管提供商：

• Scalingo是我知道的其中一个，但还有其他https://scalingo.com/。

• OVH Sail Above在alpha版中提供此服务https://www.runabove.com/sailabove.xml。

- MrE

---

使用云服务提供商的API来扩展主机似乎是正确的选择 - 但自然而然地，人们不会独立于底层容器缩放要求（上或下）来扩展主机。看起来需要一个控制器来管理主机和容器级别的缩放，后者触发前者（上和下）。 - Nico de Wet

Answer 2

我会看一下Tutum（最近被Docker收购了）。它与CI相结合，我相信它具备自动扩展能力。

https://www.tutum.co/

- errata

Answer 3

更新：这已经被AWS ECS支持，使用任务放置约束。

1. 让您的ECS集群由两个自动扩展组（ASG）提供服务。

2. 在第一个ASG中，将min、max和desired大小都设置为1。

   使用用户数据脚本为此实例打上自定义属性标签ALLOW_ALL_APPS = TRUE。

3. 在第二个ASG中，将min和desired大小设置为0，将max大小设置为1（假设您只想要2个实例）。

   再次使用用户数据脚本为此实例打上自定义属性标签ALLOW_ALL_APPS = FALSE。

4. 第二个ASG的扩容警报将由第一个ASG的负载决定。

   如果您知道应用程序3的高峰时间，可以通过预定的扩展操作提前增加它。

5. 第二个ASG的缩容是指其负载降低到足以由第一个ASG独立处理。

6. 在应用程序1、2、4和5的服务定义中，您将有放置约束，限制它们仅在ALLOW_ALL_APPS = TRUE的节点上运行。

7. 在应用程序3的服务定义中没有放置约束。

8. 基于容器或应用程序指标为所有应用程序配置了服务自动扩展。

- poida