как распределяется нагрузка службы openshift между модулями?
Это довольно простой вопрос, поэтому я полагаю, что, должно быть, упускаю что-то очевидное: использует ли служба openshift циклический перебор для балансировки нагрузки между модулями? Или он перенаправляет запросы к поду с наибольшим количеством доступных ресурсов? Или это совершенно случайно?
Конфигурация моего сервиса выглядит так:
kind: service
metadata:
name: temp
labels:
app: temp
spec:
port:
targetPort: temp-port
to:
kind: Service
name: temp
1 ответ
Публикация этого ответа в вики сообщества указывает на официальную документацию Openshift и Kubernetes (в дополнительных ресурсах), которая должна ответить на опубликованный вопрос.
Не стесняйтесь редактировать и расширять.
Согласно документации OpenShift (v3.11
):
Услуги
Служба Kubernetes служит внутренним балансировщиком нагрузки. Он идентифицирует набор реплицируемых модулей, чтобы проксировать соединения, которые он получает к ним. Резервные модули можно добавлять в службу или удалять из нее произвольно, при этом служба остается постоянно доступной, что позволяет всему, что зависит от службы, ссылаться на нее по единому адресу. IP-адреса кластера служб по умолчанию взяты из внутренней сети OpenShift Container Platform и используются для разрешения модулям доступа друг к другу.
- Docs.openshift.com: Контейнерная платформа: 3.11: Архитектура: Основные концепции: модули и сервисы.
Режим сервисного прокси
Контейнерная платформа OpenShift имеет две разные реализации инфраструктуры маршрутизации услуг. Реализация по умолчанию полностью основана на iptables и использует вероятностные правила перезаписи iptables для распределения входящих сервисных подключений между модулями конечных точек. Более старая реализация использует процесс пользовательского пространства для приема входящих соединений, а затем прокси-трафика между клиентом и одним из модулей конечных точек.
Реализация на основе iptables гораздо более эффективна, но требует, чтобы все конечные точки всегда могли принимать соединения; реализация пользовательского пространства медленнее, но может по очереди пробовать несколько конечных точек, пока не найдет ту, которая работает. Если у вас есть хорошие проверки готовности (или в целом надежные узлы и модули), то сервисный прокси на основе iptables — лучший выбор. В противном случае вы можете включить прокси-сервер на основе пользовательского пространства при установке или после развертывания кластера, отредактировав файл конфигурации узла.
Отвечая на вопрос, как распределяется нагрузка трафика при выходе наService
:
Реализация по умолчанию полностью основана на iptables и использует вероятностные правила перезаписи iptables для распределения входящих сервисных подключений между модулями конечных точек.
Я думаю, вы также можете взглянуть на дополнительные ресурсы: