Внедрить запуск контейнера док-станции по требованию

Ситуация: много тяжелых докеров, которые периодически попадают, а затем остаются неиспользованными в течение более длительного периода.

Желание: запускать контейнеры по требованию (например, systemd запускает вещи через активацию сокета) и останавливать их после холостого хода в течение заданного периода времени. Отсутствие видимого времени простоя для конечного пользователя.

Опции:

  • В Kubernetes есть контроллеры ресурсов, которые могут масштабировать реплики. Я полагаю, что можно было бы сохранить количество реплик на 0 и при необходимости установить его на 1, но как это можно достичь? Руководство пользователя говорит, что есть что-то, называемое агентом автоматического масштабирования, но я не вижу никакой дополнительной информации об этом. Есть ли подключаемый программируемый агент, который можно использовать для отслеживания запросов и масштабирования на основе пользовательской логики?
  • Я не вижу никакого решения в Docker Swarm, поправьте меня, если я ошибаюсь.
  • Используйте собственный HTTP-сервер, написанный на выбранном языке, который будет иметь доступ к демону докеров. Перед отправкой в правильное место он будет проверять наличие контейнера и обеспечить его работу. Недостаток - не общее решение, не должно быть контейнером или иметь доступ к демону.
  • Используйте systemd, как описано здесь. Такие же недостатки, как и выше, то есть не общие, и один должен сам решать сетевые задачи (например, найти IP-адрес созданного контейнера и загрузить его в конфигурацию сервера/прокси).

Любые идеи оценили!

ОТВЕТЫ

Ответ 1

Вы можете использовать встроенный Horizonal Pod Autoscaling (HPA) Kubernetes для увеличения от 1 экземпляра каждого контейнера до того, как многие из них необходимы для обработки нагрузки, но нет встроенной функциональности для масштабирования от 0 до 1 при получении запрос, и я не знаю ни одного широко используемого решения.

Ответ 2

  1. Вы можете использовать systemd для управления контейнерами докеров. См. Https://developer.atlassian.com/blog/2015/03/docker-systemd-socket-activation/

  2. Некоторое время назад я поговорил с парнем ops для pantheon.io о том, как они делают это с докером. Наверное, это было бы до того, как Кубернетес даже вышел. Pantheon do drupal хостинг. То, как они настроены, каждый сервер, который они запускают для клиентов, контейнер, но, как вы описали, контейнер уходит, когда он не нужен. Единственный ресурс, который зарезервировал, кроме хранения на диске, - это номер сокета на хосте.

    У них довольно простой демон, который прослушивает сокеты всех неактивных серверов. Когда он получает запрос, демон прекращает прослушивать больше входящих подключений в этом сокете, запускает требуемый контейнер и прокси-серверы, которые запрашивают новый контейнер. Последующие соединения идут прямо к контейнеру до тех пор, пока он не будет простаивать в течение определенного периода времени, а демон слушателя снова берет порт. Это примерно так же подробно, как я знаю о том, что они сделали, но вы поняли эту идею.

  3. Я полагаю, что что-то вроде демона, который реализовал пантеон, можно было использовать для отправки команд Кубернету, а не прямо к демону Докера. Возможно, основанный на systemd подход к динамически запускающему контакту также может взаимодействовать с Kubernetes по мере необходимости. Любой из них может позволить вам запускать контейнеры, а не только контейнеры.