#kubernetes #routes #ibm-cloud #load-balancing #kubernetes-ingress
#kubernetes #маршруты #ibm-cloud #балансировка нагрузки #kubernetes-вход
Вопрос:
Все мы знаем использование ingress в кластере kubernetes в качестве решения для маршрутизации на основе пути / контекста / url для нескольких служб, размещенных в кластере kubernetes. Однако мои требования немного отличаются. У меня есть 2 кластера — в регионах ЕС и США. В обоих этих кластерах размещены разные наборы приложений app1, app2 в кластере США и app3 и app4 в кластере ЕС. Теперь мне требуется маршрутизатор входного типа, расположенный за пределами моих кластеров, чтобы у меня была общая точка входа для всех приложений, т.е. www.example.com/us для кластеров США и www.example.com/eu для кластеров ЕС. И затем соответствующий вход в каждом кластере будет маршрутизироваться на основе приложения ИЛИ www.example.com/app1 , / app2, / app3 и т.д. на основе приложений, которые перенаправляются в исправленный кластер, а затем вводят fwd для исправления обслуживания в этом кластере.
У меня есть свой собственный домен www.example.com , но какое решение или продукт я использую на своем сетевом уровне для реализации этой маршрутизации на основе контекста / пути к 2 кластерам? Команда DNS заявила, что это не может быть достигнуто на уровне DNS, а другие балансировщики нагрузки следуют алгоритмам циклического перебора и т. Д., Которым Нужны все 4 приложения в обоих кластерах, но для меня это неосуществимое решение. Кто-нибудь может подсказать, что здесь делать? Мои кластеры kubernetes находятся в IBM Cloud. Я не могу иметь избыточные службы, но мне нужна общая точка входа для обоих кластеров.
Комментарии:
1. Наличие всех приложений в обоих кластерах кажется самым простым решением. Существуют ли какие-либо точки блокировки при развертывании в обоих кластерах?
Ответ №1:
Вы можете ознакомиться со службой шлюза IBM Cloud API.
Для этого примера я вошел в cloud.ibm.com с моим IBM ID все шаги выполнялись в пользовательском интерфейсе. Я создал экземпляр службы API Gateway с тарифным планом Lite (бесплатно).
Чтобы попробовать, перейдите в IBM Cloud API Gateway, выберите значимое имя для вашего экземпляра службы API Gateway и нажмите кнопку «Создать».
В качестве следующего шага найдите кнопку «Создать прокси-сервер API», нажмите на нее и на следующем экране выберите имя для вашего API, например USA, укажите базовый путь / us и скопируйте URL вашего приложения в США.
Повторите этот шаг и выберите другое имя (например, EU), на этот раз укажите базовый путь / eu и скопируйте URL вашего приложения на базе EU.
Теперь у вас есть настройка, которая очень близка к тому, что вы искали. Оба прокси-сервера API используют один и тот же домен по умолчанию, и запросы на путь «/ us» направляются в приложение на базе США, а запросы на путь «/ eu» направляются в приложение на базе ЕС.
Чтобы заменить домен по умолчанию вашим пользовательским доменом, вам необходимо перейти к «Управление API» -> «Пользовательские домены» и предоставить подробную информацию.
Надеюсь, это поможет. Я попробовал настройку с помощью примера приложения IBM Cloud Cloud Foundry в качестве приложения для ЕС и приложения IBM Cloud Code Engine в качестве приложения для США, и для этого простого теста все работало, как ожидалось, с доменом по умолчанию моего экземпляра API Gateway.
Пожалуйста, прокомментируйте, работает ли это также в вашем случае, когда ваши приложения выполняются в кластере Kubernetes в IBM Cloud.