Балансировщики нагрузки

Управляемый балансировщик распределяет входящий трафик между серверами. Поддерживаются HTTP, HTTPS и TCP, проверки работоспособности backend-узлов и отказоустойчивая пара узлов балансировщика. Для Kubernetes используйте отдельное руководство по Service LoadBalancer.

Настройка для серверов

1. В панели управления откройте балансировщики и создайте ресурс в нужном проекте и регионе.
2. Выберите сеть, из которой доступны целевые серверы.
3. Добавьте backend-адреса и порты ваших приложений.
4. Настройте входящий порт и протокол: HTTP/HTTPS для веб-приложений или TCP для других сервисов.
5. Задайте health-check: проверка должна отражать готовность приложения обслуживать запросы, а не только доступность порта.
6. Для HTTPS подключите домен и сертификат Let's Encrypt либо свой сертификат.
7. После готовности направьте DNS вашего домена на выданный адрес.

Сохранить текущий публичный IP

Для уже работающего публичного LB откройте вкладку «Сеть» в его карточке и нажмите «Закрепить текущий IP». Подтвердите показанный адрес: платформа создаст резерв именно для него, сохранив IP, ID и конфигурацию балансировщика. Нужны права аккаунта на управление балансировщиками и сетями.

После закрепления нажмите «Открыть IP-адрес», чтобы перейти к деталям резерва в разделе «Плавающие адреса». UUID, переименование и освобождение резерва доступны там. Из адреса можно вернуться во вкладку «Сеть» связанного LB.

В ответе API появится floating_ip_id; при повторном запросе с тем же expected_vip возвращается тот же резерв. Сначала IP оплачивается в текущей подписке LB, а после её освобождения — отдельно как плавающий адрес. При удалении LB резерв остаётся в аккаунте. Для нового LB выберите этот же резерв после его перехода в available.

tatnet api /projects/<project-id>/load-balancers/<lb-id>/retain-ip \
  -f expected_vip=198.51.100.42 -o json

Нужен CLI 0.17.0+. Замените пример адреса на фактический текущий VIP. Несовпадение даёт 409 и не приводит к выбору другого IP. Из MCP доступна операция retain_load_balancer_ip с теми же project/LB ID и expected_vip.

Для LB из Kubernetes также сохраните UUID в аннотации Service и исходных Helm/GitOps values. Пошаговая инструкция для существующего Service описывает подготовку CCM, права ключей и проверку адреса без пересоздания LB.

Проверка

Проверьте запрос через публичный адрес, затем доступность каждого backend и статус health-check. При обслуживании одного сервера убедитесь, что оставшиеся принимают трафик. Само создание балансировщика не проверяет доступность вашего приложения и не делает его базу данных отказоустойчивой.

Обзор возможностей — Балансировщики нагрузки. Сетевые адреса и исходящий доступ — в разделе Сети.