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

Question

Мне было нелегко получить правильное название, но вот проблема:

Давайте представим, что я управляю несколькими проектами, размещенными в докере, каждый из которых работает в рое через x узлов. Различные проекты варьируются от десятков до десятков тысяч запросов в секунду, и спрос может очень быстро возрасти для любого конкретного проекта.

Должен ли я создавать новые рой и узлы (Azure vms) для каждого проекта и масштабировать их соответственно в зависимости от использования, что приведет к большому количеству малых и больших vms.

Или я должен иметь намного меньший пул больших виртуальных машин, работающий, может быть, только один рой, который обрабатывает все службы. Я вполне уверен, что это было бы более оптимальным решением, потому что вы теряете накладные расходы при запуске vm, а также устраняете vms, которые просто не делают ничего, потому что сервис в настоящее время не популярен.

Когда вы думаете о ценах, процессор / оперативная память масштабируется линейно, поэтому нет никакой разницы в том, что машина с 1x 4 ядрами и 4x с 1 ядром (если вам не нужен большой диск).

У меня также были проблемы с vms, которые имеют минимальный объем памяти (1 ГБ), потому что иногда какой-то случайный процесс съедает всю память, и машина в основном мертва. Службе с балансировкой нагрузки может не потребоваться много памяти, но вам все равно нужно много узлов для обеспечения надежности (проблемы с микросервисами из-за накладных расходов).

Один большой рой с большими узлами имеет смысл с точки зрения производительности / оптимизации, но я беспокоюсь о надежности. Я знаю, что у докеров нет доступа к другим контейнерам или данным хоста, но как насчет роя? Возможно ли, что одна служба затопит / сломает весь узел или даже весь рой, и когда все службы компании не работают, возникает кошмар.

Answer 1

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

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

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

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

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

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