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. 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 on Kubernetes-Bereitstellung auf verschiedenen Plattformen verwendet werden kann, finden Sie hier:
- Application Load Balancing auf EKS
- Application Gateway Ingress Controller auf AKS
- GKE Ingress für Application Load Balancer
Es werden allgemeine und plattformspezifische Ingress-YAML-Daten bereitgestellt, die die initiale Bereitstellung und Konfiguration von Schicht-7-Load-Balancern durch die Erstellung von Kubernetes-Ingress-Objekten ermöglichen. Ingress-YAML-Daten werden in der Dokumentation und als Vorlagen im Ordner layer-7-templates bereitgestellt. Sie können diese Ingress-Objekte weiter konfigurieren, um sie an die Anforderungen der Organisation anzupassen, z. B. durch zusätzliche 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>
Allgemeine Ingress-Anforderungen
Wenn Sie einen Ingress-Controller auf einer Plattform verwenden, die in diesem Dokument nicht angegeben ist, berücksichtigen Sie die folgenden allgemeinen Anforderungen:
- 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.
- Die Beschriftung id: custom ingress resource ist erforderlich und darf nicht gelöscht werden. Sie wird vom Bereitstellungsskript verwendet, um das Ingress-Objekt während der Bereitstellung und der Aufhebung der Bereitstellung zu verwalten.
Im Folgenden finden Sie ein allgemeines 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:
labels:
id: custom-ingress-resource
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.
Anforderungen an die Bereitstellung
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, legen Sie in Ihrer deploy.properties-Datei INGRESS_SERVICE_USE_CLUSTER_IP=true fest. Diese Eigenschaft hat Vorrang vor allen Werten, die für den INGRESS_TYPE-Parameter festgelegt wurden. Wenn Sie das Ingress-Objekt während der Ausführung des Bereitstellungsskripts erstellen möchten, legen Sie CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME auf den Speicherort der Ingress-YAML-Datei fest. Das Erstellen des Ingress-Objekts während der Ausführung des Bereitstellungsskripts wird nur für AWS Application Load Balancer, Azure Application Gateway und Google Cloud Platform Application Load Balancer unterstützt.
- Sollten Sie das Skript im interaktiven Modus ausführen, antworten Sie mit no, wenn Sie gefragt werden, ob Sie einen Cloud-Balancer bereitstellen möchten, und 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.