В документация здесь описывает, как настроить балансировщик нагрузки на основе использования http (s) с помощью kubernetes на облачной платформе Google.
Вопрос в том, как на самом деле удается выполнять балансировку нагрузки на основе использования. Например, со следующей конфигурацией:
Предполагая, что LB выберет наименее используемый из 10 узлов и направит к нему через порт X, как выбирается модуль для обслуживания запроса? Выбирает ли служба kubernetes модуль на основе какого-либо другого алгоритма балансировки?
Очевидно, что происходит что-то интересное, потому что в большинстве экземпляров не будет запущенного модуля (и, следовательно, вероятность его использования будет меньше).
Как описано в этом статья:
Балансировщики нагрузки GCE / AWS не предоставляют веса для своих целевых пулов. Это не было проблемой со старыми правилами LB kube-proxy, которые правильно балансировали на всех конечных точках.
Благодаря новой функциональности внешний трафик не будет равномерно балансироваться между модулями, но будет одинаково сбалансирован на уровне узла (поскольку GCE / AWS и другие внешние реализации LB не имеют возможности указывать вес для каждого узла, они балансируются одинаково на всех целевых узлах, не учитывая количество модулей на каждом узле).
Однако мы можем констатировать, что для NumServicePods «NumNodes или NumServicePods» NumNodes будет видно довольно близкое к равному распределение, даже без весов.
После того, как внешние балансировщики нагрузки предоставят веса, эту функцию можно добавить в путь программирования LB. Дальнейшая работа: поддержка весов в версии 1.4 не предусмотрена, но может быть добавлена в будущем.
Внутренний трафик от модуля к поду должен вести себя так же, как сервисы ClusterIP, с равной вероятностью для всех модулей.