Масштабирование программного обеспечения для видеоконференций в Kubernetes

Question

Я планирую развернуть пользовательское программное обеспечение для видеоконференций WebRT C (на основе NodeJS, с использованием веб-сокетов) с Kubernetes, но у меня есть некоторые сомнения по поводу уменьшения масштаба этой среды. Я планирую использовать Kubernetes, размещенный в облаке (GKE, EKS, AKS или любой другой), чтобы иметь возможность автоматически масштабировать узлы в кластере для учета увеличения и уменьшения спроса. Но проблема не в масштабировании, а в уменьшении.

Масштабирование кластера будет основано на некоторых показателях средней загрузки ЦП в кластере, как я понимаю, и если он попытается удалить какой-то узел, он начнет сливать соединения и перестанет получать новые, верно? Но теперь представьте, что в этом узле «ожидающего удаления» все еще идет видеоконференция. Есть две проблемы:

1 - Остановка узла до завершения видеоконференции (он прерывает встречу)

2 - При сливе, когда он начинает уменьшаться, он перестанет получать новые соединения, поэтому, если кто-то попытается присоединиться к этой запущенной видеоконференции, он получит тайм-аут, верно?

Итак, какова лучшая стратегия уменьшения количества узлов для решения видеоконференции? Есть идеи?

Спасибо

Answer 1

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

Я бы сосредоточился на том, как вы хотите запланировать свои модули. Я бы попытался запланировать их, если возможно, на узле с уже запущенными модулями (взаимосвязь модулей) и настроить бюджет нарушения работы модуля для всех развертываний / StatefulSets / et c (в зависимости от того, как вы хотите запустить стручки). В результате он будет уменьшаться только в том случае, если на определенном c узле не запущены модули, и он уничтожит этот узел, потому что на других узлах есть модули; защищен PDB.

Answer 2

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

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

Фактически вы можете столкнуться с той же проблемой с любым другое приложение, поскольку подавляющее большинство из них основано на каком-то сеансе, который необходимо установить между клиентским программным обеспечением и серверной частью. Я бы сказал, что приложение должно иметь возможность обрабатывать такой сценарий ios. Если некоторые из пользователей неожиданно теряют соединение, должна быть возможность немедленно перенаправить их на работающий экземпляр, например, другой Pod, который все еще может принимать новые запросы.

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