Балансировка нагрузки Kubernetes-сервисов

Я прочитал этот вопрос, который очень похож на то, что я задаю, но все же хотел написать новый вопрос, поскольку принятый ответ кажется очень неполным, а также потенциально неправильным.

По сути, кажется, что отсутствует или противоречива информация о встроенной балансировке нагрузки для обычных сервисов Kubernetes (я не говорю о сервисах LoadBalancer). Например, в официальной документации Cilium говорится, что «в Kubernetes нет реализации балансировки нагрузки». Кроме того, я не смог найти никакой информации в официальной документации Kubernetes о балансировке нагрузки для внутренних сервисов (был только раздел, посвященный этому, под входами).

Итак, мой вопрос: как работает балансировка нагрузки или распределение запросов, когда мы делаем запрос из кластера Kubernetes на внутренний адрес службы Kubernetes?

Я знаю, что на каждом узле есть прокси-сервер Kubernetes, который создает записи DNS для таких служб, но как насчет служб, которые охватывают несколько модулей и узлов? Должна быть какая-то форма распределения запросов или балансировки нагрузки, иначе это просто не сработает, не так ли?

Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
1
0
91
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Стандартный сервис Kubernetes обеспечивает базовую балансировку нагрузки. Даже для службы типа ClusterIP служба имеет собственный внутренний IP-адрес кластера и DNS-имя и перенаправляет запросы в набор подов, указанный в ее selector:.

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

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

... в официальной документации Cilium говорится ...

Это почти наверняка утверждение о внешней балансировке нагрузки. Как администратор кластера (не программист), «обычная» установка Kubernetes не включает реализацию внешней балансировки нагрузки, а служба типа LoadBalancer ведет себя идентично службе типа NodePort.

У циклического планирования есть очевидные недостатки, особенно если у вас есть отдельные сетевые запросы, которые требуют много времени и ресурсов для обслуживания. Для разработчика приложений лучший способ решить эту проблему — заставить эти очень длительные запросы выполняться асинхронно; вернуть что-то вроде статуса HTTP 201 Created с уникальным URL-адресом для каждого задания и выполнить фактическую работу в отдельном рабочем потоке, поддерживаемом очередью.

Вы правы: в том же абзаце документа написано "Cilium может привлекать этот трафик по BGP". Здесь явно говорят о балансировке нагрузки на внешний трафик. В то время как внутренняя балансировка нагрузки Kubernetes SDN обычно полагается на iptables или ipvs, которые, как мы могли бы далее утверждать, также не являются строго «реализацией Kubernetes», строго говоря. Тем не менее, Kubernetes предлагает балансировку нагрузки Сервисов, прилипание сеансов, ... все, что вы могли бы попросить.

SYN 23.10.2022 13:54

Другие вопросы по теме