Стручки Kubernetes для масштабирования с использованием собственного алгоритма - PullRequest
0 голосов
/ 04 мая 2018

Наше облачное приложение состоит из 3 тесно связанных Docker-контейнеров, Nginx, Web и Mongo. В настоящее время мы запускаем эти контейнеры на одной машине. Однако, поскольку наши пользователи растут, мы ищем решение для масштабирования. Используя Kubernetes, мы сформировали бы много контейнеров. Если мы хотим повторить, нам нужно скопировать все 3 контейнера как единое целое. Наше облачное приложение используется пользователями мобильных приложений. Наше приложение может обрабатывать только около 30000 пользователей на рабочий узел, и мы намерены разместить один модуль на одном рабочем узле. Когда мобильное устройство подключено к рабочему узлу, оно должно продолжать использовать только этот компьютер (уникальный IP-адрес)

Мы планируем использовать Kubernetes для управления контейнерами. Балансировка нагрузки не работает для нашего варианта использования, так как мобильное устройство должно быть привязано к одному компьютеру после назначения, и каждый Pod работает независимо со своим постоянным томом. Однако нам нужен способ раскрутки новых модулей на рабочих узлах, если число пользователей превышает 30000 и так далее.

Идея в том, что у нас есть какой-то специальный планировщик, который назначает мобильному устройству рабочий узел (домен / IP-адрес) в зависимости от количества пользователей на этом узле.

Подходит ли Kubernetes для этого дизайна и как мы можем реализовать собственный алгоритм масштабирования pod.

Спасибо

Ответы [ 2 ]

0 голосов
/ 04 мая 2018

Копилка на ответ Джоны Бентона:

Хотя это технически возможно - ваша проблема не в Kubernetes, а в вашем приложении! Позвольте мне указать вам проблему:

Наше облачное приложение состоит из 3 тесно связанных Docker-контейнеров, Nginx, Web и Mongo.

Вот ваша первая проблема: можете ли вы развернуть эти три контейнера только вместе, а не независимо - вы не можете масштабировать один или другой! Хотя MongoDB можно масштабировать до безумных нагрузок, - если он связан с вашим веб-сервером и веб-приложением, он не сможет ...

Итак, первый шаг для вас - разбить эти три компонента, чтобы ими можно было управлять независимо друг от друга. Далее:

В настоящее время мы запускаем эти контейнеры на одной машине.

Хотя это и не является проблемой - я серьезно сомневаюсь, что это будет означать масштабирование вашего приложения и какие проблемы связаны с масштабируемостью!

Как только мобильное устройство подключено к рабочему узлу, оно должно продолжать использовать только этот компьютер (уникальный IP-адрес)

Теперь это проблема. Вы хотите запустить приложение в Kubernetes, но я не думаю, что вы понимаете последствия этого: Kubernetes управляет вашими ресурсами. Это означает, что он будет перемещать модули (убивая и воссоздавая) между узлами (и, если необходимо, в один и тот же узел). Это делает его полностью автономным (что здорово и дает вам хороший ночной сон). Если вы полагаетесь на клиентов, придерживающихся IP-адреса одного узла, вы встанете посреди ночи, потому что Kubernetes попытался исправить сбой узла и перемещение вашего модуля, который теперь отсутствует, и ваши пользователи больше не могут подключиться. Вам необходимо использовать функции (услуги) балансировки нагрузки в Kubernetes. Только они способны справляться с динамическими изменениями, которые происходят в кластерах Kubernetes.

Используя Kubernetes, мы сформировали бы несколько контейнеров.

И у нас есть еще один победитель - нет! Вы пытаетесь обращаться с Kubernetes, как если бы это была ваша локальная инфраструктура! Если вы продолжите делать это, то потерпите неудачу и проклянете Кубернетеса в процессе!

Теперь, когда я рассказал вам о некоторых вещах, которые вы считаете неправильными - кем бы я был, если бы не дал несколько советов о том, как сделать эту работу:

В Kubernetes ваши три приложения не должны запускаться в одном модуле! Они должны работать в отдельных контейнерах:

Не стесняйтесь спрашивать, если у вас есть еще вопросы!

0 голосов
/ 04 мая 2018

Поддерживается создание собственного планировщика и одновременный запуск нескольких планировщиков:

https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/

Тем не менее, на вопрос о том, подходит ли kubernetes для этого дизайна - мой ответ: не совсем.

K8 могут быть сложными в эксплуатации, а отдачей является уровень автоматизации и отказоустойчивости, который он обеспечивает «из коробки» для целых классов рабочих нагрузок.

Эта рабочая нагрузка не относится к числу таких. Чтобы получить какую-либо выгоду, вы должны написать планировщик для обработки краевых сбоев и ошибок, которые есть в этом приложении (что происходит, когда вы теряете узел на короткий промежуток времени ...) таким образом, который имеет смысл для k8s. , И вам придется набрать скорость с обычными операциями на k8s.

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

...