我很难找到正确的标题，但这是问题所在：
让我们想象一下，我正在管理托管在docker中的多个项目，每个项目都在x个节点上成群运行。不同的项目每秒的请求量从数万到数万，并且对于任何给定的项目，需求都可能会快速增长。
我应该为每个项目创建新的群集和节点（azure虚拟机），然后根据使用情况对其进行相应缩放，这会导致大量的小型到大型虚拟机。
或者我应该运行一个较小的大型虚拟机池，也许只有一个集群来处理所有服务。我相当确定这将是更理想的解决方案，因为您将失去运行虚拟机的开销，并且消除了由于该服务当前不受欢迎而只能无所事事的虚拟机。
考虑价格时，cpu / ram线性增长，因此拥有1x 4核计算机与4x 1核计算机没有区别（除非您需要大磁盘）。
我还遇到了内存量极少（1gb）的vms的问题，因为有时某些随机进程会消耗掉所有内存，并且机器基本上已经死了。您的负载平衡服务可能不需要大量内存，但是仍然需要大量节点来确保可靠性（微服务的操作系统开销问题）。
一个具有大型节点的大型集群在性能/优化方面非常有意义，但我担心其可靠性。我知道Docker容器无法访问其他容器或主机数据，但是群又如何？当所有公司的服务都关闭时，是否有一项服务会淹没/破坏整个节点甚至整个集群，进而引发一场噩梦。
答案 0 :(得分：1)
没有适用于每个组织和每个应用程序设计的黑白答案。如果您正在考虑成本和管理开销，那么减少一组大型节点的确是有益的，因此可以最大程度地减少要管理的主机总数，并减少操作系统开销（假设主机操作系统和Docker / Swarm占用了最初的.5GB内存，减少大型实例可以减少浪费。
在此DockerCon Swarm talk中，我将讨论典型的Swarm尺寸和设计。
Docker也是got some guidance for EE，它在下面运行Docker Engine和Swarm。
就我个人而言，我会使用一小组较小的较大节点（使用运行5个管理器的单个10节点Swarm（仅将swarm作为较小的实例大小进行管理）和5个（8xlarge或更高）的工作程序，这非常好例如，在10Gbps网络上，我发现50-100 xlarge的可管理性要比仅1Gbps时高得多。
您可以使用资源保留和限制，以及other features like placement constraints, placement preferences, etc.来确保适当放置服务，并防止失控的进程消耗所有服务器资源。您可以看到一些我在做这些things on GitHub and DockerCon中的一些例子。
最后，如果接近10Gbps的数据还不够好，并且您需要每一盎司的原始网络，请考虑将默认的Swarm网络驱动程序Overlay切换为Host等其他人或Weave等第三方插件。