automation-suite
2023.10
true
Automation Suite auf EKS/AKS-Installationsanleitung
Last updated 4. Okt. 2024

Netzwerke

Sie müssen Azure- oder AWS-Netzwerkressourcen bereitstellen und konfigurieren, um sicherzustellen, dass die Automation Suite in Ihrem Cluster über Konnektivität und Zugriff auf die Voraussetzungen der Cloud-Infrastruktur (z. B. Speicher, Datenbank, Cache und DNS) verfügt. Je nach Ihrer Netzwerkarchitektur kann dies die Konfiguration von VNETs/VPC, DNS, Subnetzen, NSGs/Sicherheitsgruppen, NAT-Gateways, Elastic IPs und Internetgateways umfassen. Weitere Informationen finden Sie unter Bereitstellungsszenarien.

Beachten Sie, dass je nach Workload-Skalierung möglicherweise mehr Replikate benötigt werden. Standardmäßig erfordert der HA-Modus zwei Replikate und kann bis zu zehn oder mehr Replikate umfassen. Stellen Sie sicher, dass Ihr Netzwerk diese Skalierungsstufe unterstützt.

Sie können ein beliebiges CNI verwenden, solange Pods miteinander kommunizieren können. Wir empfehlen Azure CNI oder Calico.

Es gibt Besonderheiten bei den Cloud-CNIs wie Azure CNI und Amazon VPC CNI, die keine internen oder privaten Pod-Networking-Subnetze unterstützen. Die Anzahl der für die Automation Suite erforderlichen Pods hängt von Ihrer Produktauswahl und der Workload-Skalierung ab. Beispielsweise benötigen Sie für eine Bereitstellung, bei der alle Dienste aktiviert und bei hoher Auslastung sind, möglicherweise über 400 IPs, um die Skalierungsanforderungen zu unterstützen. Aus diesem Grund empfehlen wir, einen CIDR-Bereich von mindestens /23 zuzuweisen.

Wichtig:

Die Automation Suite unterstützt nicht das IPv6-Internetprotokoll.

Benutzerdefinierter Ingress-Controller

Wenn Sie über einen benutzerdefinierten Ingress-Controller (NGINX) verfügen, lesen Sie Konfigurieren von NGINX-Ingress und überspringen Sie den Rest der Seite.

Konfiguration des Lastausgleichs

Die Automation Suite stellt während der Installation einen Lastausgleich in Ihrem Namen bereit. Dem Lastausgleich müssen öffentliche oder private IP-Adressen zugewiesen werden, damit er die eingehenden FQDN-Anforderungen weiterleiten kann. Sie haben zwei Optionen, um den Lastausgleich zu konfigurieren:

  • Vorab zugewiesene IPs: Weisen Sie öffentliche oder private IPs für den Lastausgleich zu, konfigurieren Sie die DNS-Datensätze, um die FQDNs diesen IPs zuzuordnen, und geben Sie diese IPs als Teil des Ingress-Abschnitts von input.jsonan.
  • Dynamisch zugewiesene IPs: Wenn Sie keine IP-Adresse angeben, weist die Automation Suite dem Lastenausgleich dynamisch IPs aus dem Clustersubnetz zu.

Die Netzwerksicherheitsgruppen auf dem Lastenausgleich müssen HTTPS-Datenverkehr von Endclients über Port 443 zulassen. Standardmäßig konfigurieren wir den Lastausgleich so, dass er regelmäßige TCP-Zustandsprüfungen durchführt.

Wenn Sie Ihren eigenen Ingress wie NGINX verwenden, stellen Sie sicher, dass Sie die unter Konfigurieren der NGINX-Ingress-Steuerungdokumentierten Netzwerkanforderungen erfüllen. Bei Verwendung von Istio, das einen NLB bereitstellt, beachten Sie, dass in der Regel drei Listener erstellt werden, darunter die Ports 80, 443 und 15021. Dies ist jedoch ein typisches Setup und Ihre tatsächlichen Anforderungen können je nach Ihren genauen Gegebenheiten abweichen, also passen Sie sie nach Bedarf an.

Vorab zugewiesene IPs

Sie müssen die folgenden Dienstanmerkungen im Abschnitt ingress von input.json.

Eine Liste der Dienstanmerkungen in EKS finden Sie in der Dokumentation zum AWS Load Balancer.

Eine Liste der Dienstanmerkungen in AKS finden Sie in der Dokumentation zum Azure Load Balancer.

Beispiele für EKS-Anmerkungen

Die folgenden Beispiele zeigen, wie der Abschnitt ingress.service_annotations in input.json erstellt wird. Sie müssen vor der Installation einen AWS Load Balancer-Controller auf Ihrem EKS-Cluster bereitstellen, damit die Beispiele ordnungsgemäß funktionieren.

Das folgende Beispiel zeigt, wie elastische IPs von AWS zugewiesen und ein öffentlicher Lastausgleich bereitgestellt wird. Wenn Sie dieses Beispiel als Ausgangspunkt für Ihre Konfiguration verwenden, stellen Sie sicher, dass Sie die IPs durch tatsächliche Werte ersetzen.

"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
    }
  }"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
    }
  }

Das folgende Beispiel zeigt, wie einem internen Lastenausgleich private IPs aus den EKS-Clustersubnetzen zugewiesen werden. Wenn Sie dieses Beispiel als Ausgangspunkt für Ihre Konfiguration verwenden, stellen Sie sicher, dass Sie die IPs und Subnetze mit tatsächlichen Werten aktualisieren.

"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":"<IP_0>,<IP_1>",
      "service.beta.kubernetes.io/aws-load-balancer-subnets": "<SUBNET_ID_0>,<SUBNET_ID_1>",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
      "service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
    }
  } "ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":"<IP_0>,<IP_1>",
      "service.beta.kubernetes.io/aws-load-balancer-subnets": "<SUBNET_ID_0>,<SUBNET_ID_1>",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
      "service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
    }
  }
Wichtig:

IPs und Subnetze müssen übereinstimmen.

Im vorherigen Beispiel ist <IP_0> in <SUBNET_0> und <IP_1> in <SUBNET_1>.

Beispiel für AKS-Anmerkungen

Das folgende Beispiel zeigt, wie öffentliche IPs von Azure zugewiesen und ein öffentlicher Lastausgleich bereitgestellt wird. Wenn Sie dieses Beispiel als Ausgangspunkt für Ihre Konfiguration verwenden, stellen Sie sicher, dass Sie die IPs mit tatsächlichen Werten aktualisieren.

...
"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "false",
      "service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
    }
  }
......
"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "false",
      "service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
    }
  }
...

Das folgende Beispiel zeigt, wie private IPs einem internen Lastausgleich aus den AKS-Cluster-Subnetzen zugewiesen werden. Wenn Sie dieses Beispiel als Ausgangspunkt für Ihre Konfiguration verwenden, stellen Sie sicher, dass Sie die IPs und Subnetze mit den tatsächlichen Werten aktualisieren.

...
"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "true",
      "service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
      "service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET_0>", "<SUBNET_1>" 
    }
  }
......
"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "true",
      "service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
      "service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET_0>", "<SUBNET_1>" 
    }
  }
...
Wichtig:

Die IPs und Subnetze müssen übereinstimmen.

Im vorherigen Beispiel ist <IP_0> in <SUBNET_0> und <IP_1> in <SUBNET_1>.

DNS-Konfiguration

Stellen Sie sicher, dass die DNS-Datensätze so konfiguriert sind, dass sie die folgenden UiPath®-FQDNs dem Lastausgleich zuordnen:

  • FQDN
  • alm.FQDN
  • Überwachung.FQDN
  • insights.FQDN (bei Installation von UiPath Insights)
Hinweis:

Der FQDN ist eine der Voraussetzungsprüfungen vor der Installation. Wenn Sie keine IP-Adresse angeben oder die FQDN-Zuordnung noch nicht durchgeführt haben, schlägt die Prüfung fehl.

Dynamisch zugewiesene IPs

Wenn Sie keine IPs in input.jsonangeben, weist die Automation Suite dynamisch die privaten IPs aus den Subnetzen der Arbeiterknoten zu. Führen Sie in diesem Szenario die Automation Suite Installation wie folgt aus.

EKS-Beispiel für input.json

...
  "ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
      "service.beta.kubernetes.io/aws-load-balancer-internal": true
    }
  }
......
  "ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
      "service.beta.kubernetes.io/aws-load-balancer-internal": true
    }
  }
...

AKS-Beispiel für input.json

...
  "ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "true"
    }
  }
......
  "ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "true"
    }
  }
...

Installationsschritte

Führen Sie in diesem Szenario das Installationsprogramm wie folgt aus:

  1. Führen Sie das Installationsprogramm nur bis zur Bereitstellung des Lastenausgleichs aus:

    uipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gatewayuipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gateway
  2. Rufen Sie den Hostnamen des Lastenausgleichs ab:

    kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
  3. Konfigurieren Sie Ihr DNS mit FQDNs, die dem Lastausgleichsendpunkt oder den IPs zugeordnet sind.

  4. Führen Sie das Installationsprogramm erneut aus, um die Installation abzuschließen:

    uipathctl manifest apply input.json --versions versions.jsonuipathctl manifest apply input.json --versions versions.json
Hinweis:

Beachten Sie, dass die Überprüfung der FQDN-Voraussetzungen ohne DNS-Zuordnung fehlschlägt. Voraussetzungsprüfungen sollen Ihnen die Gewissheit geben, dass Sie alle Voraussetzungen korrekt bereitgestellt haben, bevor Sie die Automation Suite installieren. Die Überprüfung des FQDN hindert Sie nicht daran, die Automation Suite zu installieren.

War diese Seite hilfreich?

Hilfe erhalten
RPA lernen – Automatisierungskurse
UiPath Community-Forum
Uipath Logo White
Vertrauen und Sicherheit
© 2005–2024 UiPath. Alle Rechte vorbehalten