Organisationen können spezifische Anforderungen an den Umgang mit Client-Verkehr haben, der an eine ArcGIS Enterprise on Kubernetes-Bereitstellung geleitet wird. Diese Anforderungen können den Einsatz erweiterter Funktionen erforderlich machen, die von anbieterspezifischen Load-Balancing-Lösungen angeboten werden, die auf Schicht 7 (L7) des OSI-Modells laufen, wie z. B. Web Application Firewall-Funktionen, pfad- und hostbasiertes Routing oder anderes deterministisches Routing-Verhalten auf der Grundlage von Client-Anfrage-Headern.
Als Administrator können Sie einen Ingress-Controller auf Clusterebene verwenden, um eingehenden Verkehr zu Ihrer ArcGIS Enterprise on Kubernetes-Bereitstellung zu leiten. Diese Ingress-Controller auf Clusterebene ermöglichen es Organisationen, diese Funktionen zu nutzen. Ingress-Controller übersetzen Kubernetes-Ingress-Objekte in den jeweiligen L7-Load-Balancer-Implementierungen in funktionale Routing-Regeln. Die Spezifikation innerhalb eines Ingress-Objekts enthält eine Reihe von Routing-Regeln für ein oder mehrere Backend-Service-Objekte innerhalb eines Kubernetes-Namespace.
Diese Ingress-Objekte werden letztendlich durch Schicht-7-fähige Load Balancer bei Managed-Cloud-Anbietern Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS) und Google Kubernetes Engine umgesetzt. Die Erstellung von Ingress-Objekten mit spezifischen Annotationen und ingressClass-Namen kann die Bereitstellung und Konfiguration der Load Balancer einschließlich der Frontend- und Backend-Listener und Zielgruppeneinstellungen auslösen. Diese Ingress-Controller auf Clusterebene übernehmen das Routing des Verkehrs vom Rand eines Clusters zu den intern verfügbaren Services.
Details dazu, wie ein Ingress-Controller auf Clusterebene zum Weiterleiten von Verkehr zu einer ArcGIS Enterprise-Bereitstellung verwendet werden kann, finden Sie hier:
- Application Load Balancing auf EKS
- Application Gateway Ingress Controller auf AKS
- GKE Ingress für Application Load Balancer
Für jede Bereitstellungsplattform werden YAML-Daten bereitgestellt, die die initiale Bereitstellung und Konfiguration von Schicht-7-Load-Balancern durch die Erstellung von Kubernetes-Ingress-Objekten ermöglichen. Sie können diesen Ingress-Objekten weitere Konfigurationen hinzufügen, um sie an Organisationsziele anzupassen, z. B. die Anwendung zusätzlicher Ingress-Objekt-Annotationen. Bei Bedarf können auch Annotationen zum bestehenden Ingress-Controller-Service von NGINX im Cluster gemacht werden, und es werden Anweisungen zur Durchführung dieser Annotationen bereitgestellt.
Hinweis:
Bei einigen Anbietern muss unter Umständen die Bereitstellung von "arcgis-ingress-controller" aktualisiert werden, um eine ordnungsgemäße Verbindung über den neu erstellten Ingress herzustellen. Wenn Sie nach der Erstellung des Ingress eine Fehlermeldung beim Zugriff auf ArcGIS Enterprise Manager erhalten, versuchen Sie Folgendes:
kubectl rollout restart deployment/arcgis-ingress-controller -n <deploymentNamespace>
Voraussetzungen
Bei der ersten Bereitstellung von ArcGIS Enterprise on Kubernetes müssen Sie angeben, dass Sie einen Ingress-Controller auf Clusterebene verwenden möchten, um den Verkehr zu Ihrer Bereitstellung zu leiten. Wie Sie dies tun, hängt davon ab, in welchem Modus Sie das Bereitstellungsskript ausführen:
- Wenn Sie das Skript im automatischen Modus ausführen, müssen Sie in Ihrer deploy.properties-Datei INGRESS_SERVICE_USE_CLUSTER_IP=true festlegen. Diese Eigenschaft hat Vorrang vor allen Werten, die für den INGRESS_TYPE-Parameter festgelegt wurden.
- Wenn Sie das Skript im interaktiven Modus ausführen, müssen Sie mit no antworten, wenn Sie gefragt werden, ob Sie einen Cloud-Balancer bereitstellen möchten, und dann mit yes, wenn Sie gefragt werden, ob Sie einen Ingress-Controller auf Clusterebene verwenden möchten, um den Verkehr zu Ihrer Bereitstellung zu leiten. Dadurch kann der clusterinterne NGINX-Ingress-Controller-Service, der die ordnungsgemäße Weiterleitung des Client-Verkehrs an die angeforderten ArcGIS Enterprise-Endpunkte ermöglicht, als Typ "ClusterIP" erstellt werden.
Der Schicht-7-Load-Balancer dient als Zugangspunkt für den Client-Verkehr zu den Services innerhalb des Clusters. Für ArcGIS Enterprise on Kubernetes sollte der Ingress-Controller auf Clusterebene so konfiguriert werden, dass er den Verkehr an den eingebetteten Ingress-Controller weiterleitet, der als Teil der Anwendung bereitgestellt wird.
Hinweis:
Vor ArcGIS Enterprise 11.2 war es möglich, einen Ingress-Controller-Service vom Typ "ClusterIP" zu erstellen, indem angegeben werden konnte, ob eine OpenShift-Route verwendet werden soll, um den Verkehr zur Bereitstellung zu leiten. Diese Frage wurde im Bereitstellungsskript dahingehend geändert, dass gefragt wird, ob ein Ingress-Controller auf Clusterebene verwendet wird, um den Verkehr zur Bereitstellung zu leiten. Wenn diese Option auf true gesetzt ist, wird der Ingress-Controller-Service als Typ "ClusterIP" erstellt, unabhängig davon, ob der INGRESS_TYPE für die Bereitstellung auf NodePort oder LoadBalancer gesetzt wurde.
Allgemeine Ingress-Anforderungen
Sie können einen Ingress-Controller auf einer Plattform verwenden, die in diesem Dokument nicht angegeben ist. Hierzu gelten auch die oben genannten allgemeinen Voraussetzungen. Beachten Sie außerdem Folgendes:
- Stellen Sie sicher, dass der Service arcgis-ingress-nginx im Cluster als Backend-Ziel verwendet wird, an das der Client-Verkehr weitergeleitet werden soll, wenn Sie das Ingress-Objekt zum Weiterleiten des Verkehrs an eine ArcGIS Enterprise on Kubernetes-Bereitstellung konfigurieren.
- Stellen Sie sicher, dass das TLS-Protokoll verwendet wird, wenn der Verkehr vom Load Balancer, der vom Ingress-Controller verwaltet wird, an den Backend-NGINX-Ingress-Controller im Cluster weitergeleitet wird.
Im Folgenden finden Sie ein verallgemeinertes Beispiel für eine anbieterunabhängige Ingress-YAML, die die notwendigen Werte enthält, um den Verkehr zu einer ArcGIS Enterprise on Kubernetes-Bereitstellung zu leiten:
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
Hinweis:
Im Beispiel oben wird davon ausgegangen, dass ein TLS-Secret mit Zertifikatsinformationen im Namespace der Bereitstellung erstellt wurde und für die Konfiguration eines TLS-Zertifikats mit dem Ingress-Controller verwendet wird. Bei einigen Anbietern können diese Informationen durch eine Annotation angegeben werden, die ebenfalls verwendet werden kann.