У меня есть два одинаковых кластера GKE (назовем их «синий» и «зеленый»). У каждого из них есть один вход через балансировщик нагрузки GCP. Я хотел бы перенаправить трафик из одного кластера в другой. Это будет использоваться для тестирования основных изменений, таких как обновления K8s / Istio и т. Д.
Я не уверен, как добиться этого с помощью инфраструктуры GCP.
Варианты, которые я изучил:
Облачный DNS - это самое простое, я просто переключаю запись A с "синего" -> "зеленого" LB и жду, пока истечет TTL. Это нормально, но для обучения трафика потребуется время, а некорректное поведение клиентов DNS может потенциально вызвать проблемы. Я также не могу пропускать трафик, поскольку в Cloud DNS нет «взвешенного циклического перебора», переключение - «все или ничего», чего я не хочу.
Облачный CDN - Я могу добавить два LB в качестве источников, но переключение между ними будет очень медленным, и мне кажется, что это неправильное использование инструмента.
Многослойные LB - Имейте LB, который находится поверх «синего» и «зеленого» LB и направляет трафик на текущий «активный». В GCP это вообще невозможно. Кажется, LB не могут использовать LB в качестве бэкэнда (включая HTTP, TCP, сеть)
Пользовательский LB верхнего уровня - Я мог бы использовать HAProxy или что-то еще для балансировки нагрузки GCP, но это заставляет меня нервничать. Это будет канал с довольно высокой пропускной способностью, и я не хочу жертвовать хорошей производительностью и характеристиками высокой доступности.
Как мне добиться этого в GCP без потери свойств высокой доступности и производительности существующей настройки?
На самом деле существует несколько различных способов балансировки нагрузки трафика между двумя кластерами GKE.
Вы можете использовать инструменты: Mutli-cluster Ingress 1 что Google запустил. Это создаст облачный балансировщик нагрузки http для кластеров с несколькими GKE.
Как вы упомянули, вы можете использовать Директор трафика Google 2 направлять трафик в разные кластеры GKE.
И Istio также предоставляет несколько кластеров 3 вариант, чтобы дать вам больше контроля над трафиком между несколькими кластерами Kubernetes.