Масштабируемость Kube-прокси

Я столкнулся с проблемой масштабируемости при тестировании кластера kubernetes. Чтобы упростить топологию на моем тестовом компьютере, тип NodePort используется для внешнего предоставления отдельного сервиса. Базовым узлом для размещения узла и мастера является RHEL 7 с 24 CPU и 32G RAM; У меня еще нет выделенного балансировщика нагрузки или такого облачного провайдера, как инфраструктура. Фрагмент определения сервиса выглядит так, как показано ниже

    "spec": {       
         "ports": [{
             "port": 10443,             
             "targetPort": 10443,               
             "protocol": "TCP",                                
             "nodePort": 30443
    } ],
   "type": "NodePort",

Таким образом, приложение может быть доступно через https://[node_machine]:30443/[a_service]

Такой сервис поддерживается только одним Pod. В идеале я хотел бы иметь несколько служб, развернутых на одном узле (но с использованием разных NodePort), и работающих одновременно.

Все работало хорошо, пока не стало очевидно, что при аналогичной рабочей нагрузке увеличение количества развертываемых служб (и, следовательно, внутренних модулей) приводит к снижению производительности приложений. Удивительно, но когда я сократил время загрузки сервиса, я заметил резкое ухудшение "Время соединения", которое, похоже, указывает на замедление где-то на "сетевом" уровне. Обратите внимание, что нагрузка недостаточно высока, чтобы загружать большую часть ЦП на узле. Я читал о недостатках в документе, но не уверен, что именно то, что я затронул, является именно ограничением описанного там kube-proxy/Service.

Вопросы:

  1. Есть ли какие-либо предложения о том, как сделать его более масштабируемым? Т.е. чтобы иметь возможность поддерживать больше сервисов / модулей без ущерба для производительности приложений? Тип NodePort - это самый простой способ настроить "публичный" адрес для наших сервисов, но есть ли ограничения для масштабируемости или производительности, если все сервисы и модули настраиваются таким образом?

  2. Будет ли какая-либо разница, если мы изменим тип на LoadBalancer? "type": "LoadBalancer"

  3. Более того, есть ли преимущество в том, чтобы иметь выделенный LoadBalancer или обратный прокси-сервер для улучшения масштабируемости, например, HAProxy или тому подобное, который направляет трафик от внешнего к бэкэнд-модулям (или сервисам)? Я заметил, что для Nginx darkgaro/kubernetes-reverseproxy проделана определенная работа - к сожалению, документ кажется неполным, и конкретного примера нет. В некоторых других темах люди говорили о Vulcan - это рекомендуемый инструмент LB для kubernetes?

Ваши рекомендации и помощь высоко ценятся!

Источник

2 ответа

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

Если вы развертываете Kubernetes у провайдеров без поддержки облачных сред, таких как, например, vagrant / local и т. Д., То некоторые функции в настоящее время не предлагаются и не автоматизированы платформой для вас.

Одной из таких вещей является служба "LoadBalancer". Автоматическое предоставление и присвоение общедоступного IP-адреса службе (действуя как LB) в настоящее время происходит только на таких платформах, как движок Google Container.

Смотрите проблему здесь и здесь.

Официальная документация гласит

В облачных провайдерах, которые поддерживают внешние балансировщики нагрузки, установка поля типа "LoadBalancer" обеспечит балансировщик нагрузки для вашей службы.

В настоящее время разрабатывается и документируется альтернатива, смотрите здесь, используя HAProxy.

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

То, что вы называете снижением производительности, скорее всего связано с тем, что функция PublicIP ( NodePort начиная с версии 1.0 и выше) работает. Это означает, что с использованием типа сервиса NodePort kubernetes назначает порт на ВСЕХ узлах кластера для этого вида сервиса. Затем kube-прокси перехватывает вызовы к этим портам для фактической службы и т. Д.

Пример использования HaProxy для решения той же проблемы можно найти здесь.

Надеюсь, это немного помогло.

Источник

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

Я нашел эту статью, которая описывает подобные проблемы. Он рекомендует взглянуть на vulcan, так как он использует внутри себя etcd, и, вероятно, целью этого проекта является обеспечение полнофункционального LB для k8s в будущем.

Источник
Другие вопросы по тегам