У организаций могут быть особые требования к обработке клиентского трафика, направляемого в развертывание ArcGIS Enterprise on Kubernetes. Эти требования могут потребовать использования расширенных функций, предлагаемых решениями для балансировки нагрузки от определенного поставщика, которые работают на уровне 7 (L7) модели OSI, таких как Web Application Firewall, маршрутизация на основе пути и хоста или другое детерминированное поведение маршрутизации, основанное на заголовках клиентских запросов.
Как администратор, вы можете использовать входной контроллер уровня кластера для маршрутизации входящего трафика в ваше развертывание ArcGIS Enterprise on Kubernetes. Эти контроллеры входа уровня кластера позволяют организациям использовать преимущества этих функций. Входные контроллеры преобразуют входные объекты Kubernetes в функциональные правила маршрутизации в соответствующих реализациях балансировщика нагрузки L7. Спецификация внутри входящего объекта содержит набор правил маршрутизации к одному или нескольким объектам внутренней службы в пространстве имен Kubernetes.
Эти входные объекты в итоге реализуются с помощью балансировщиков нагрузки, поддерживающих уровень 7, в управляемых облачных провайдерах, таких как Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS) и Google Kubernetes Engine. Создание входных объектов с определенными аннотациями и именами ingressClass может инициировать подготовку и настройку средств балансировки нагрузки, включая интерфейсные и серверные прослушиватели и настройки целевой группы. Эти контроллеры входа уровня кластера управляют маршрутизацией трафика от границы кластера к внутренним службам.
Дополнительные сведения об использовании контроллера входа уровня кластера для маршрутизации трафика в развертывании ArcGIS Enterprise, см. в следующих разделах:
- Использование балансировки нагрузки приложения на EKS
- Использование Application Gateway Ingress Controller на AKS
- Использование GKE Ingress для балансировщиков нагрузки приложения
Для каждой платформы развертывания предоставляются данные YAML, которые позволят выполнить первоначальное развертывание и настройку средств балансировки нагрузки уровня 7 путем создания объектов Ingress Kubernetes. Вы можете добавить дополнительные настройки к этим входным объектам в соответствии с целями организации, такими как применение дополнительных аннотаций к входным объектам. При необходимости также могут быть сделаны аннотации к существующей внутрикластерной службе входного контроллера NGINX, инструкции о выполнении этих аннотаций предоставляются.
Примечание:
Некоторым поставщикам может потребоваться обновить развертывание arcgis-ingress-controller, чтобы установить правильное подключение через недавно созданный Ingress. Если вы получаете сообщение об ошибке при доступе к ArcGIS Enterprise Manager после создания входа, попробуйте выполнить следующее:
kubectl rollout restart deployment/arcgis-ingress-controller -n <deploymentNamespace>
Предварительные условия
При первоначальном развертывании ArcGIS Enterprise on Kubernetes вы должны указать, что хотите использовать контроллер входа на уровне кластера для маршрутизации трафика в ваше развертывание. То, как вы это сделаете, будет зависеть от того, в каком режиме вы запустите скрипт развертывания:
- Если вы запускаете скрипт в автоматическом режиме, вам нужно будет установить INGRESS_SERVICE_USE_CLUSTER_IP=true в файле deploy.properties. Это свойство переопределяет любое значение, заданное для параметра INGRESS_TYPE.
- При запуске скрипта в интерактивном режиме необходимо ответить no на вопрос, хотите ли вы предоставить облачный балансировщик, а затем на вопрос yes, будете ли вы использовать контроллер входа на уровне кластера для маршрутизации трафика в ваше развертывание. Это позволит создать внутрикластерную службу входного контроллера NGINX, которая обеспечивает правильную маршрутизацию клиентского трафика к запрашиваемым конечным точкам ArcGIS Enterprise, созданных как тип ClusterIP.
Балансировщик нагрузки уровня 7 будет служить точкой доступа клиентского трафика к службам внутри кластера. Для ArcGIS Enterprise on Kubernetes, входной контроллер уровня кластера должен быть сконфигурирован для передачи трафика встроенному входному контроллеру, развернутому как часть приложения.
Примечание:
До версии ArcGIS Enterprise 11.2 возможность создания службы контроллера входа в кластер типа ClusterIP предоставлялась с помощью опции, позволяющей указать, будет ли использоваться маршрут OpenShift для маршрутизации трафика к развертыванию. Этот вопрос был изменен в сценарии развертывания, чтобы запросить, будет ли использоваться контроллер входа на уровне кластера для маршрутизации трафика к развертыванию. Если для этого параметра установлено значение true, служба входного контроллера будет создана как тип ClusterIP, независимо от того, было ли установлено значение INGRESS_TYPE для развертывания на NodePort или LoadBalancer.
Общие требования к входным контроллерам
Вы можете использовать контроллер входа на платформе, которая не была указана в этом документе. Для этого также применяются общие условия, изложенные выше. Также имейте в виду:
- Убедитесь, что внутрикластерная служба arcgis-ingress-nginx используется в качестве внутренней цели, к которой будет перенаправляться клиентский трафик, при настройке объекта Ingress для маршрутизации трафика в развертывание ArcGIS Enterprise on Kubernetes.
- Убедитесь, что протокол TLS используется при передаче трафика от средства балансировки нагрузки, управляемого контроллером входа, к серверному контроллеру входа NGINX внутри кластера.
Ниже приведен обобщенный пример входящего YAML, который не зависит от поставщика и содержит необходимые значения для маршрутизации трафика в развертывание ArcGIS Enterprise on Kubernetes:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: arcgis-enterprise-ingress
namespace: <deploymentNamespace>
annotations:
spec:
tls:
- hosts:
- <deploymentFQDN>
secretName: <tlsSecretName>
rules:
- host: <deploymentFQDN>
http:
paths:
- backend:
service:
name: arcgis-ingress-nginx
port:
number: 443
path: /<context>
pathType: Prefix
Примечание:
В приведенном выше примере предполагается, что секрет TLS, содержащий информацию о сертификате, был создан в пространстве имен развертывания и будет использоваться для настройки сертификата TLS с помощью контроллера входа. Некоторые поставщики разрешают указывать эту информацию с помощью аннотации, которую также можно использовать.