Балансировщики нагрузки
Балансировщик нагрузки распределяет входящий сетевой трафик между облачными серверами в рамках одного кластера Kubernetes.
Облачный балансировщик нагрузки можно использовать для повышения доступности сервисов — он оптимально распределит запросы между серверами и снизит нагрузку. Если один сервер выйдет из строя, балансировщик перенаправит трафик на другой подходящий сервер.
Трафик распределяется между серверами по правилам — настраивается порт и протокол балансировщика и серверов, алгоритм распределения запросов, проверки доступности и параметры соединений. Количество правил не ограничено.
Как работает балансировщик
В балансировщике нагрузки используется модель OpenStack Octavia, которая включает в себя:
- Amphorae (амфора) — выполняет балансировку нагрузки. Запускается на облачном сервере и использует HAProxy (High-Availability Proxy) — программное обеспечение для проксирования трафика. В балансировщиках с резервированием (типов Базовый с резервированием и Продвинутый с резервированием) создается две амфоры, без резервирования — одна.
- Listener (слушатель) — прослушивает поступающий на балансировщик нагрузки поток трафика, используя указанные в правиле порты и протоколы. Затем маршрутизирует трафик к необходимой группе серверов.
- Pool (пул) — группа серверов, к которой направляет запросы слушатель.
- Members (серверы) — серверы, которые обслуживают трафик в пуле. Доступны по указанному в правиле IP-адресу и порту.
- Health Monitor (проверка работоспособности) — процесс проверки работоспособности всех серверов внутри пула.
Порты балансировщика
Амфоры балансировщика нагрузки используют несколько портов:
- Входящий порт (uplink). Это виртуальный порт, на котором размещается VIP — виртуальный IP-адрес. На нем слушатель прослушивает входящий трафик. Выделяется при создании балансировщика нагрузки и находится в его подсети. У балансировщиков с резервированием (типов Базовый с резервированием и Продвинутый с резервированием) VIP резервируется по протоколу VRRP.
- Служебные VRRP-порты. При создании базового балансировщика нагрузки в его подсети выделяется один служебный порт. При создании балансировщика с резервированием выделяется два служебных порта для основной и резервной амфоры, между ними настраивается VRRP.
- Служебные порты (downlinks). Если серверы находятся не в подсети балансировщика, то при его создании в подсетях с серверами выделяются порты для амфор: для базового балансировщика один порт, для балансировщиков с резервированием — два порта (основной и резервный).
При неполадках в работе балансировщика нагрузки он автоматически создает новую амфору (и только потом удаляет старую) — для этого нужен свободный порт. Если свободного порта не будет, балансировщик перейдет в статус ERROR.
Мы рекомендуем выбирать приватную сеть с публичным IP-адресом (адрес нужен для доступа в интернет) — в таком случае для пересоздания амфоры всегда будет доступен свободный порт. Балансировка трафика будет производиться внутри приватной сети.
Типы балансировщиков
Список типов балансировщиков
Когда вы встанете перед выбором балансировщика, вам будет необходимо указать ID типа балансировщика в аннотации к сервису вашего кластера. ID флейворов и их цены можно найти в таблице:
Вам необходимо указать ID типа балансировщика в аннотации к сервису вашего кластера. Примеры настройки можно найти по ссылке.
Правила балансировщика
Правило — это настройки балансировщика, которые обслуживают поток трафика с конкретным портом и протоколом и распределяют этот трафик на нужную группу серверов.
В правиле можно настроить:
- протоколы и порты входящего трафика балансировщика нагрузки и серверов, которые будут обслуживать трафик;
- алгоритмы, по которым распределяются запросы;
- проверки доступности для отслеживания состояния серверов;
- соединения, проходящие через балансировщик.
Количество правил в балансировщике не ограничено.
Все настройки балансировщиков в Vscale производятся в kubectl. Примеры настройки можно найти по ссылке.
Протоколы
Доступны комбинации протоколов:
- TCP–TCP — классическая L4-балансировка;
- TCP–PROXY — информация о клиенте не теряется и передается в отдельном заголовке соединения;
- UDP–UDP — UDP-протокол быстрее, чем TCP, но менее надежен;
- HTTP–HTTP — L7-балансировка;
- HTTPS–HTTP — L7-балансировка с шифрованием и терминацией SSL-сертификата на балансировщике.
Все настройки балансировщиков в Vscale производятся в kubectl. Примеры настройки можно найти по ссылке.
Алгоритмы распределения запросов
Слушатель распределяет запросы по выбранному алгоритму. Доступно два алгоритма:
- Round Robin — алгоритм кругового обслуживания. Первый запрос передается одному серверу, следующий запрос — другому и так далее до достижения последнего сервера. Затем цикл начинается сначала. Запросы распределяются на серверы в соответствии с заданным весом.
- Least connections — алгоритм учитывает количество подключений к серверам. Новый запрос передается серверу с наименьшим количеством активных подключений, вес сервера не учитывается.
Все настройки балансировщиков в Vscale производятся в kubectl. Примеры настройки можно найти по ссылке.
Sticky Sessions
Дополнительно можно включить Sticky Sessions. Метод необходим, когда конечное приложение держит длительное соединение с каждым клиентом и сохраняет внутреннее состояние данных, которое не синхронизируется между серверами в правиле.
Новые запросы будут распределяться по выбранному алгоритму, а затем сессия закрепится за сервером, который начал обрабатывать запросы. Все последующие запросы этой сессии будут распределяться на сервер, не учитывая выбранный алгоритм. Если сервер недоступен, запрос перенаправится на другой.
Параметры определения сессии можно настроить — балансировать сессии или балансировать одного клиента на один сервер. Можно идентифицировать сессию:
- по
APP-cookie— уже существующая cookie, которая задана в коде приложения; - по
HTTP-cookie— cookie, которую создает и прикрепляет к сессии балансировщик; - по
Source IP— IP-адрес клиента хешируется и делится на вес каждого сервера в правиле — так определяется сервер, который будет обрабатывать запросы.
Все настройки балансировщиков в Vscale производятся в kubectl. Примеры настройки можно найти по ссылке.
Проверки доступности
Для балансировщика можно включить проверку доступности. Балансировщик будет отслеживать состояние серверов — если какой-либо сервер окажется неработоспособным, балансировщик перенаправит соединение на другой.
Параметры проверки:
- тип проверки:
HTTP,HTTPS,PING,TCP,TLS-HELLO,UDP-CONNECT; - интервал в секундах, с которым балансировщик отправляет проверяющие запросы серверам;
- таймаут соединения — время ожидания ответа;
- для протоколов проверки HTTP и HTTPS можно настроить обращение к URL и ожидаемые коды ответа;
- порог успеха — количество успешных обращений подряд, после которых сервер переводится в рабочее состояние;
- порог неуспеха — количество неуспешных обращений подряд, после которых работа сервера приостанавливается.
Все настройки балансировщиков в Vscale производятся в kubectl. Примеры настройки можно найти по ссылке.
Настройки соединений
Можно задать настройки соединений, проходящих через балансировщик — между входящими запросами и балансировщиком, балансировщиком и серверами.
Настройки соединений:
- таймаут соединения — время ожидания ответа;
- количество соединений — ограничено или нет;
- таймаут неактивности — время, в течение которого подключение считается активным, даже если данные не передаются;
- таймаут ожидания TCP-пакетов — время, в течение которого балансировщик ждет передачи данных для инспекции по уже установленному соединению.
Все настройки балансировщиков в Vscale производятся в kubectl. Примеры настройки можно найти по ссылке.
Заголовки HTTP-запросов
В обычном режиме работы балансировщик передает серверу только исходное тело HTTP-запроса, заменяя IP-адрес клиента на свой.
Включи необходимые типы дополнительных заголовков в запрос, чтобы серверы получали эту информацию для корректной работы или анализа:
- X-Forwarded-For,
- X-Forwarded-Port,
- X-Forwarded-Proto,
- X-SSL-Client-Verify,
- X-SSL-Client-Has-Cert,
- X-SSL-Client-DN,
- X-SSL-Client-CN,
- X-SSL-Issuer,
- X-SSL-Client-SHA1,
- X-SSL-Client-Not-Before,
- X-SSL-Client-Not-After.
Стоимость
Средства списываются с баланса Облачной платформы каждый час — подробнее о модели оплаты облачной платформы.