Google Kubernetes Engine - как развернуть кластер в региональном центре обработки данных с использованием стандартного сетевого уровня?

Мы пытались настроить кластер K8, который развертывается в Google Cloud Platform, используя наиболее экономичную настройку. Наше решение будет развернуто в различных региональных центрах обработки данных из-за нормативных и геополитических ограничений, связанных с нашим коммерческим выставлением счетов в качестве сервисной платформы под названием Bill Rush.

Учитывая наши региональные требования, это означает, что мы хотим использовать следующие настройки инфраструктуры:

  1. Зафиксировано Использовать выделенные ресурсы виртуальной машины. При выделении нашим узлам K8 будут выделены заранее определенные фиксированные квоты вычислительной инфраструктуры.
  2. Стандартный сетевой уровень - поскольку местные клиенты находятся всего в одном или двух прыжках от регионального / зонального центра обработки данных GCP, мы рады использовать внешних сетевых провайдеров для передачи трафика к ближайшей точке выхода сети Google в центр обработки данных. Сетевая маршрутизация премиум-класса не требуется.
  3. Региональные среды и развертывания. Нам требуется только, чтобы система работала на региональном уровне в одной или двух зонах для резервирования. Нам не нужны более сложные настройки глобального резервирования.

Использование этих трех вариантов даст нам самую дешевую настройку для каждой из наших региональных прикладных сред.

Кроме того, всем региональным экземплярам нужны URL-адреса с закладками, чтобы пользователи могли легко находить наши среды приложений. Таким образом, нам необходимо заполнить каждую среду DNS и внешними IP-адресами. На них необходимо ссылаться в наших входящих файлах YAML, когда мы применяем их к нашим кластерным средам K8.

Проблема:

Мы хотели бы использовать обычные лучшие практики Kubernetes и определить вход. Это откроет внешнюю точку входа в кластер, который подготавливается и управляется конкретным облачным контроллером Google для GKE.

В случае входа GKE поддерживается только одна настройка: глобальный балансировщик нагрузки HTTP (S), который включает [прокси, правило пересылки, внешние IP-адреса, серверные части, сертификаты]. При использовании регионального внешнего IP-адреса настройка LB не выполняется.

Вопросы:

  1. Почему нам не разрешено использовать региональные внешние IP-адреса во входном объявлении YAML?
  2. Какие альтернативные конфигурации кластера GKE будут поддерживать внешний IP-адрес, совместимый со стандартным сетевым уровнем
  3. Повлияет ли это на нашу способность использовать Anthos для разработки и кластеры UAT, развернутые локально.

Заранее спасибо.


kubernetes kubernetes-ingress google-kubernetes-engine google-anthos
person Shaun Forgie    schedule 17.05.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

1) Почему нам не разрешено использовать региональные внешние IP-адреса во входном объявлении YAML?

Согласно документации GCP на Статические внешние IP-адреса, «Статический внешний IP Адреса могут быть региональными или глобальными. Региональный статический IP-адрес позволяет ресурсам этого региона или ресурсам зон в этом регионе использовать IP-адрес. В этом случае экземпляры виртуальных машин и региональные правила переадресации могут использовать региональный статический IP-адрес. адрес.

Глобальные статические внешние IP-адреса доступны только для глобальных правил переадресации, используемых для глобальной балансировки нагрузки. Вы не можете назначить глобальный IP-адрес региональному или зональному ресурсу ».

2) Какие альтернативные конфигурации кластера GKE будут поддерживать внешний IP-адрес, совместимый со стандартным сетевым уровнем?

Возможно, вам придется подумать о региональном входе или стороннем входе nginx и использовать там региональный IP-адрес, вам придется создать новый региональный внешний IP-адрес, используя - флаг региона. Вы можете найти дополнительную информацию в этой документации сообщества по "Ingress с контроллером NGINX на Google Kubernetes Engine "

3) Повлияет ли это на нашу способность использовать Anthos для разработки и кластеры UAT, развернутые локально.

Насколько я понимаю, он будет использовать региональные ресурсы, поэтому вы не получите никаких преимуществ глобальных ресурсов, таких как доступ к GCP GFE к ближайшему местоположению клиента или пользователя вашего сервиса.

person userX    schedule 20.05.2020