Лучшие практики управления докерскими узлами и роями в масштабах всей компании

Там нет черно-белый ответ, который работает для каждой организации и каждого дизайна приложения. Если вы смотрите на стоимость и накладные расходы на управление, то полезно иметь меньший набор больших узлов, поэтому вы минимизируете общее количество управляемых хостов и сокращаете накладные расходы ОС (предполагая, что хост-ОС и Docker / Swarm занимают Первые 0,5 ГБ памяти, имея меньшее количество больших экземпляров, могут помочь сократить эти потери).

Я говорю о типичных размерах и дизайне Swarm в этом DockerCon Swarm talk .

Докер также получил руководство по EE , в котором работают Docker Engine и Swarm.

Лично я бы выбрал меньший набор более крупных узлов (это здорово, что вы можете сделать с одним 10-узловым Swarm, работающим с 5 менеджерами (только управляющими роем с меньшими размерами экземпляров) и 5 ​​(8 большими или более) рабочими. в сети 10 Гбит / с. Я считаю, что гораздо более управляемой, чем 50-100 xlarge, например, только на 1 Гбит / с.

Вы можете использовать резервирование ресурсов и ограничения, а также другие функции, такие как ограничения размещения, настройки размещения и т. д. . , чтобы убедиться, что сервисы размещены надлежащим образом и не позволяют запущенным процессам потреблять все ресурсы сервера. Вы можете видеть несколько примеров того, как я выполняю некоторые из этих вещей на GitHub и DockerCon .

[ 1110] Наконец, если скорость около 10 Гбит / с недостаточно хороша, и вам нужна каждая унция сырой сети, рассмотрите возможность отключения сетевого драйвера Swarm по умолчанию, Overlay, для других, таких как Host, или сторонних плагинов, таких как Weave . .