Q: Эффективное распределение нагрузки в Kubernetes

Question

Я изучал сети Kubernetes, в частности, как наиболее эффективно обслуживать пользователей HTTPS.

Я смотрел этот разговор: https://www.youtube.com/watch?v=0Omvgd7Hg1I и с 22:18 он объясняет, в чем проблема с балансировщиком нагрузки, который не знает о модуле. Теперь, как они решают это в kubernetes, позволяя узлам также действовать как «маршрутизатор» и позволяя узлу передавать запрос другому узлу. (объяснил в 22:46). Это не кажется очень эффективным, но при просмотре SoundCloud (https://developers.soundcloud.com/blog/how-soundcloud-uses-haproxy-with-kubernetes-for-user-facing-traffic), похоже, что-то похожее, но с NodePorts. Они говорят, что накладные расходы стоят меньше, чем создание лучшего балансировщика нагрузки.

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

Эта информация относится к 2017 году, поэтому мой вопрос таков: существует ли какой-либо подсистема балансировки нагрузки с поддержкой pod или есть какой-то другой метод, который не предусматривает отправку http-запроса и ответа по сети дважды?

Заранее спасибо, Хендрик

Answer 1

То, как трафик c направляется к модулям, зависит от того, используется ли управляемый кластер.

Почти все облачные провайдеры могут перенаправлять трафик c облачным способом в своих управляемых кластерах K8s. Во-первых, вы можете управлять кластером с некоторыми специальными сетевыми настройками (например, vp c - собственный кластер GKE). Затем единственное, что вам нужно сделать, - это создать службу типа LoadBalancer для представления вашей рабочей нагрузки. Вы также можете создавать Ingresses для ваших рабочих нагрузок L7, они будут обрабатываться предоставленными IngressControllers (например, ALB AWS).

В локальном кластере без какого-либо облачного провайдера (OpenStack или vSphere), единственный способ выставить рабочие нагрузки - NodePort напечатанный Сервис. Это не значит, что вы не можете улучшить его.

Если ваш кластер находится за обратными прокси-серверами (случай SoundCloud), установка externalTrafficPolicy: Local на Services может нарушить пересылку трафика c между рабочими узлами. Когда трафик c получен через NodePorts, он перенаправляется на локальные блоки или удаляется, если блоки находятся на других узлах. Резервный прокси пометит эти NodePort как нездоровые при проверке работоспособности бэкэнда и отклонит переадресацию на них трафик c. Другой выбор - использовать topology-aware service routing. В этом случае локальные блоки имеют приоритеты, и трафик c все еще пересылается между узлами, когда не найдено ни одного локального блока.

Для IngressController в локальных кластерах это немного отличается. У вас могут быть некоторые рабочие узлы, которые имеют EIP или publi c IP. Чтобы предоставить службы HTTP (S), IngressController обычно развертывается на этих рабочих узлах через DaemeaSet и HostNetwork таким образом, чтобы клиенты обращались к IngressController через хорошо известные порты и EIP узлов. Эти рабочие узлы регулярно не принимают другие рабочие нагрузки (например, инфра-узел в OpenShift), и требуется еще один шаг вперед в сети Pod. Вы также можете развернуть IngressController на всех рабочих узлах, а также на других рабочих нагрузках, поэтому трафик c можно переадресовать на более близкий Pod, если IngressController поддерживает topology-aware service routing, хотя теперь он может.

Надеюсь, это поможет!