FAQ
Можно ли использовать для Data-прокси роль с названием, отличным от default (например, heavy)?
Да, но это требует дополнительной настройки.
По умолчанию клиентские библиотеки (SDK) отправляют все тяжёлые запросы (чтение/запись) в группу прокси с ролью default. Если в операторе создать группу с ролью heavy, но не перенастроить кластер, SDK не узнает о её существовании и продолжит искать несуществующую роль default.
Чтобы перенаправить стандартный трафик клиентов в новую группу, измените атрибут @default_role_filter в Кипарисе:
# Теперь клиенты, не указавшие роль явно, будут направляться на прокси с ролью 'heavy'
yt set //sys/http_proxies/@default_role_filter heavy
Можно ли направить весь трафик (включая Data) через Ingress?
Технически — можно, но для высоконагруженных инсталляций это не рекомендуется. Если настроить клиенты на работу без Discovery (только через Ingress), возникнут три проблемы:
- Двойная балансировка. Весь трафик проходит через промежуточный Ingress-контроллер, что увеличивает задержки.
- Сложность настройки. Для работы Discovery через Ingress придётся создавать отдельный Ingress-ресурс и DNS-имя для каждого пода Data-прокси.
- Проблемы с транзакциями. Необходима настройка липких сессий.
Для высоконагруженных инсталляций рекомендуется комбинированный подход:
- L7 (Ingress): Используйте только для Control-трафика (роль
control). Это даст понятное доменное имя, SSL и удобство для пользователей. - L4 (NodePort/LoadBalancer): Используйте для Data-трафика (роль
default). Это позволит клиентам соединяться с подами напрямую (через Discovery и Advertised Addresses), обеспечивая максимальную пропускную способность без узкого места (bottleneck) в виде Ingress-контроллера.
Почему команды list и create работают, а write-table падает с ошибкой сети?
Это признак неверно настроенного (или ненастроенного) Discovery.
Лёгкие команды идут через контрольные прокси. Тяжёлые команды (read-table, write-table) пытаются соединиться с Data-прокси напрямую. Ошибка «Name resolution failure» или «Connection refused» на записи означает, что Discovery возвращает клиенту внутренние адреса подов.
Настройте подмену адресов через атрибут //sys/http_proxies/@balancers (см. раздел Настройка подмены адресов).
Можно ли временно отключить Discovery для отладки?
Да, механизм Discovery можно отключить на стороне клиента (опция конфига enable_proxy_discovery=%false). Это удобно для быстрой отладки и тестирования: трафик перестаёт разделяться и направляется в единую точку входа.
Примеры, как отключить Discovery:
client = yt.YtClient(proxy="localhost:8080", config={"proxy": {"enable_proxy_discovery": False}})
export YT_USE_HOSTS=0
# Или:
# export YT_CONFIG_PATCHES='{proxy={enable_proxy_discovery=%false}}'
Важно
Не используйте этот режим в продакшене для передачи больших данных — это создаст узкое место на входном балансировщике.
Можно ли указать роль прокси через атрибут в Кипарисе?
Да, роль конкретного инстанса можно сменить «на лету», изменив атрибут @role в Кипарисе. Это полезно для оперативного вывода прокси из-под нагрузки.
Пример смены роли через CLI:
# Назначаем конкретному прокси роль control
yt set //sys/http_proxies/hp-0.http-proxies.default.svc.cluster.local:80/@role control
Внимание
При перезапуске пода роль вернётся к значению, указанному в спецификации оператора.