GCP Backend сервис соединения подключения ресурсов для развертываний

Question

Кто-нибудь когда-либо пытался добиться того, чтобы бэкэнд-соединение балансировщика нагрузки GC HTTP(S) терял

1. Установка емкости соответствующих групп экземпляров внутри серверной службы на 0% (0 RPS)
2. Удаление группы экземпляров из бэкэнд-сервиса
3. Изменение бэкэнд-сервиса в карте URL для указания на другой бэкэнд-сервис.

Я хотел бы добиться развертывания A/B-тестирования с помощью GCLB перед двумя кластерами GKE. В документах только сказано, что отключение соединения запускается для конкретного экземпляра, когда экземпляр удаляется из группы экземпляров (автоматически или вручную): https://cloud.google.com/load-balancing/docs/enabling-connection-draining

Answer 1

Это очень конкретные сценарии, однако ожидаемое поведение следующее:

1. Установка максимальной скорости для каждого экземпляра или максимальной скорости (для группы экземпляров) равной нулю (когда режим балансировки - это скорость), не истощит существующие соединения. Режим балансировки просто помогает подсистеме балансировки нагрузки ранжировать бэкэнды (группы экземпляров в этой ситуации) от наиболее привлекательных для обработки новых соединений. Когда режим балансировки - это скорость, а максимальное число запросов в секунду равно нулю, это просто означает, что серверная часть "не привлекательна", даже когда она обслуживает нулевые запросы. Но если для всех бэкэндов установлено значение RPS, равное нулю, или если их нет, но они близки к емкости, возможно, что бэкэнд с нулевым значением RPS будет одинаково (столь же непривлекательно), как и все остальные бэкэнды.
2. Удаление группы экземпляров в качестве бэкэнда из бэкэнд-службы, скорее всего, не будет учитывать потери соединения, поскольку это удаляет балансировщик нагрузки из уравнения.
3. Этот сценарий очень похож на вышеприведенное утверждение, без обратной стороны удаления балансировщика нагрузки. Однако я думаю, что указание URL-карты на другой бэкэнд не приведет к истощению соединения, так как экземпляры будут доступны, несмотря на то, что вы ссылаетесь на другой бэкэнд. Время простоя ожидается, но слив не должен быть активирован.