Существуют ли два уровня балансировки нагрузки при использовании Правил назначения Istio? - PullRequest
1 голос
/ 27 марта 2020

Насколько я понял, правила назначения Istio могут определять политики балансировки нагрузки для достижения подмножества сервиса, например подмножества, основанного на разных версиях сервиса. Таким образом, Правила назначения - это первый уровень балансировки нагрузки.

Запрос в конечном итоге достигнет службы K8s, которая обычно реализуется посредством kube-proxy. Kube-proxy выполняет простую балансировку нагрузки с помощью модулей в своем бэкэнде. Вот второй уровень балансировки нагрузки.

Есть ли способ удалить второй балансировщик нагрузки? Например, можем ли мы создать множество экземпляров служб, которые предлагают одну и ту же услугу и могут быть сбалансированы по нагрузке правилами назначения, а затем иметь только один модуль на экземпляр службы, чтобы kube-proxy не применял балансировку нагрузки?

1 Ответ

0 голосов
/ 31 марта 2020

В соответствии с документацией istio :

Правила маршрутизации Istio traffi c позволяют легко контролировать поток вызовов traffi c и API между службами. Istio упрощает настройку свойств уровня обслуживания, таких как автоматические выключатели, тайм-ауты и повторные попытки, а также упрощает настройку важных задач, таких как A / B-тестирование, развертывание канареечного типа и поэтапное развертывание, с разбивкой по трафику в процентах c. Он также предоставляет встроенные функции восстановления после сбоев, которые помогают сделать ваше приложение более устойчивым к сбоям зависимых служб или сети.

Модель управления Istio traffi c опирается на прокси-серверы Envoy, которые развертываются вместе с ваши услуги. Все трафики c, которые отправляют и получают ваши службы me sh (трафик плоскости данных c), передаются через Envoy, что позволяет легко направлять и контролировать трафики c вокруг вашего me sh без каких-либо изменений в ваши услуги.

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

Это означает, что служба istio me sh осуществляет связь через прокси-сервер-посредник, который, в свою очередь, использует сеть Kubernetes.

У нас может быть пример, когда VirtualService, использующий istio ingress gateway, балансирует трафик c двум различным сервисам на основе меток. Тогда эти службы могут иметь несколько модулей.

Балансировка нагрузки Istio в этом случае работает только на (уровне 7), что приводит к маршруту к указанной конечной точке c (одна из служб) и зависит от kubernetes для обработки соединения и остальное, включая циклическое распределение нагрузки (уровень 4) в случае нескольких модулей.

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

На Youtube есть отличное видео, которое частично охватывает эту топи c: Жизнь пакета через Istio от Мэтта Тернера .

Я настоятельно рекомендую посмотреть, поскольку он объясняет, как istio работает на фундаментальном уровне.

...