Lastverteiler-Typen

In der folgenden Tabelle werden die wesentlichen Merkmale der einzelnen Lastausgleichsoptionen beschrieben.

Application Load Balancer for VPC

Richten Sie eine Layer 7-Application Load Balancer for VPC-Instanz (VPC-ALB) für mehrere Zonen ein, die als externer Einstiegspunkt für eingehende Anforderungen an eine App in Ihrem Cluster dienen soll. Beachten Sie bei der Planung Ihrer VPC ALB-Einrichtung die folgenden Punkte.

Verwechseln Sie die VPC-Lastausgleichsfunktion für Anwendungen nicht mit Ingress-Lastausgleichsfunktionen für Anwendungen von (Application Load Balancers, ALBs) von Red Hat OpenShift on IBM Cloud. Application Load Balancers for VPC-Instanzen (VPC-ALBs) werden außerhalb Ihres Clusters in Ihrer VPC ausgeführt und werden von Kubernetes-Services vom Typ LoadBalancer konfiguriert, die Sie erstellen. Ingress-Lastausgleichsfunktionen für Anwendungen sind Ingress-Controller, die auf Workerknoten in Ihrem Cluster ausgeführt werden.

• VPC ALB-Namen haben das Format kube-<cluster_ID>-<kubernetes_lb_service_UID>. Führen Sie ibmcloud oc cluster get --cluster <cluster_name> aus, um Ihre Cluster-ID anzuzeigen. Zum Ermitteln der UID des Kubernetes-Service vom Typ LoadBalancer führen Sie den Befehl oc get svc myloadbalancer -o yaml aus und suchen in der Ausgabe nach dem Feld metadata.uid. Die Bindestriche (-) werden aus dem Kubernetes LoadBalancer Dienst UID im VPC ALB-Namen entfernt.

• Wenn Sie einen Kubernetes Service vom Typ LoadBalancer für eine App in Ihrem Cluster erstellen, wird standardmäßig eine Application Load Balancer for VPC-Instanz in Ihrer VPC außerhalb Ihres Clusters erstellt. Die VPC-ALB leitet Anforderungen an Ihre App über die privaten Knotenports weiter, die automatisch auf Ihren Workerknoten geöffnet werden.

• Wenn Sie einen öffentlichen Kubernetes LoadBalancer-Service erstellen, können Sie über das Internet über den Hostnamen, der von der VPC-ALB dem Kubernetes LoadBalancer-Service zugeordnet wurde, auf Ihre App im Format 1234abcd-<region>.lb.appdomain.cloud zugreifen. Auch wenn Ihre Workerknoten nur mit einem privaten VPC-Teilnetz verbunden sind, kann die VPC-ALB öffentliche Anforderungen empfangen und an den Service weiterleiten, über den Ihre App zugänglich gemacht wird. Dabei ist zu beachten, dass kein öffentliches Gateway in Ihrem VPC-Teilnetz erforderlich ist, damit öffentliche Anforderungen an Ihre VPC-ALB zugelassen werden. Wenn allerdings Ihre App Zugriff auf eine öffentliche URL benötigt, müssen Sie den VPC-Teilnetzen, mit denen Ihre Workerknoten verbunden sind, öffentliche Gateways zuordnen.

• Wenn Sie einen privaten Kubernetes Service vom Typ LoadBalancer erstellen, ist Ihre App nur für Systeme zugänglich, die mit Ihren privaten Teilnetzen innerhalb derselben Region und VPC verbunden sind. Wenn Sie mit Ihrem privaten VPC-Netz verbunden sind, können Sie auf Ihre App über den Hostnamen zugreifen, der von der VPC-ALB dem Kubernetes LoadBalancer-Service im Format 1234abcd-<region>.lb.appdomain.cloud zugeordnet wird.

• Sie können einen vorhandenen VPC ALB auf einem anderen Cluster verwenden, indem Sie den VPC ALB umbenennen.

Das folgende Diagramm veranschaulicht, wie ein Benutzer vom Internet aus über die VPC-ALB auf eine App zugreift.

1. Eine Anforderung an Ihre App verwendet den Hostnamen, der dem Kubernetes LoadBalancer-Service von der VPC-ALB zugewiesen wird, z. B. 1234abcd-<region>.lb.appdomain.cloud.
2. Die Anforderung wird von der VPC-ALB automatisch an einen der Knotenports auf dem Workerknoten und dann weiter an die private IP-Adresse des App-Pods geleitet.
3. Wenn App-Instanzen auf mehreren Workerknoten im Cluster bereitgestellt werden, verteilt die Lastausgleichsfunktion die Anforderungen unter den App-Pods auf verschiedenen Workerknoten. Wenn Sie einen Mehrzonencluster haben, leitet die VPC-ALB Anforderungen zudem an Workerknoten in allen Teilnetzen und Zonen in Ihrem Cluster weiter.

Netzlastausgleichsfunktion für VPC

Richten Sie in VPC-Clustern eine layer-4 Network Load Balancer for VPC (VPC NLB) in jeder Zone Ihres Clusters ein, um als externer Einstiegspunkt für eingehende Anfragen an eine Anwendung zu dienen.

VPC-NLBs bieten verschiedene Vorteile, zum Beispiel die Bereitstellung eines höheren Durchsatzes und einer besseren Leistung durch den Einsatz von DSR (Direct Server Return). Mithilfe von DSR können App-Antwortpakete vom Workerknoten direkt an die Client-IP-Adresse gesendet und die VPC-NLB übersprungen werden, wodurch sich der Umfang des Datenverkehrs, der von der VPC-NLB verarbeitet werden muss, verringert. Zusätzlich können Sie den VPC NLB so konfigurieren, dass die Quell-IP-Adresse bei allen Client-Anfragen erhalten bleibt, indem Sie die externalTrafficPolicy: Local-Spezifikation einfügen.

• Standard-VPC-NLB-Namen haben das Format kube-<cluster_ID>-<kubernetes_lb_service_UID>. Führen Sie ibmcloud oc cluster get --cluster <cluster_name> aus, um Ihre Cluster-ID anzuzeigen. Zum Ermitteln der UID des Kubernetes-Service vom Typ LoadBalancer führen Sie den Befehl oc get svc myloadbalancer -o yaml aus und suchen in der Ausgabe nach dem Feld metadata.uid. Die Bindestriche (-) werden aus der Kubernetes LoadBalancer Dienst-UID im VPC NLB-Namen entfernt.

• Wenn Sie einen Kubernetes-Service vom Typ LoadBalancer für eine App in Ihrem Cluster erstellen und die Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb" einschließen, wird eine VPC-NLB in Ihrer VPC außerhalb Ihres Clusters erstellt. Die VPC-NLB leitet Anforderungen für Ihre App über die privaten Knotenports (NodePorts) weiter, die automatisch auf Ihren Workerknoten geöffnet werden.

• Wenn Sie einen öffentlichen Kubernetes-Service vom Typ LoadBalancer erstellen, können Sie über das Internet mit der externen öffentlichen IP-Adresse, die dem Kubernetes-Service vom Typ LoadBalancer von der VPC-NLB zugeordnet wird, auf Ihre App zugreifen. Auch wenn Ihre Workerknoten nur mit einem privaten VPC-Teilnetz verbunden sind, kann die VPC-NLB öffentliche Anforderungen empfangen und an den Service weiterleiten, über den Ihre App zugänglich gemacht wird. Dabei ist zu beachten, dass kein öffentliches Gateway in Ihrem VPC-Teilnetz erforderlich ist, damit öffentliche Anforderungen an Ihre VPC-NLB zugelassen werden. Wenn allerdings Ihre App Zugriff auf eine öffentliche URL benötigt, müssen Sie den VPC-Teilnetzen, mit denen Ihre Workerknoten verbunden sind, öffentliche Gateways zuordnen.

• Wenn Sie einen privaten Kubernetes Service vom Typ LoadBalancer erstellen, ist Ihre App nur für Systeme zugänglich, die mit Ihren privaten Teilnetzen innerhalb derselben Region und VPC verbunden sind. Wenn Sie mit Ihrem privaten VPC-Netz verbunden sind, können Sie auf Ihre App über die externe, private IP-Adresse zugreifen, die vom VPC-NLB dem Kubernetes LoadBalancer-Service zugewiesen wird.

Das folgende Diagramm veranschaulicht, wie ein Benutzer vom Internet aus über die VPC-NLB auf eine App zugreift.

1. Eine Anforderung an Ihre App verwendet die IP-Adresse, die dem Kubernetes-Service vom Typ LoadBalancer von der VPC-NLB zugeordnet wird.
2. Die Anforderung wird von der VPC-NLB automatisch an einen der Knotenports auf dem Workerknoten und dann weiter an die private IP-Adresse des App-Pods geleitet.
3. Wenn Anwendungsinstanzen auf mehreren Worker Nodes im Cluster bereitgestellt werden, leitet der VPC NLB die Anfragen zwischen den Anwendungs-Pods auf verschiedenen Worker Nodes über alle Zonen des Clusters weiter.

Einschränkungen

Machen Sie sich mit den folgenden Standardeinstellungen und Einschränkungen vertraut.

• Prüfen Sie die bekannten Einschränkungen für VPC-ALBs und die bekannten Einschränkungen für VPC-NLBs.
• Private VPC-ALBs akzeptieren nicht den gesamten Datenverkehr, sondern nur RFC 1918-Datenverkehr.
• Private VPC-NLBs müssen in einem dedizierten VPC-Teilnetz erstellt werden, das in derselben VPC und an derselben Position wie Ihr Cluster vorhanden sein muss, aber das Teilnetz kann nicht an Ihren Cluster oder an Workerknoten angehängt werden.
• Red Hat OpenShift: Obwohl das Kubernetes SCTP-Protokoll in der Kubernetes-Community-Version allgemein verfügbar ist, wird die Erstellung von Load Balancern, die dieses Protokoll verwenden, in IBM Cloud Kubernetes Service-Clustern nicht unterstützt.
• Für jeden Kubernetes Service vom Typ LoadBalancer, den Sie erstellen, wird genau eine VPC-Lastausgleichsfunktion erstellt und diese leitet Anforderungen nur an diesen Kubernetes Service vom Typ LoadBalancer weiter. In allen VPC-Clustern in Ihrer VPC können maximal 50 VPC-Lastausgleichsfunktionen erstellt werden. Weitere Informationen finden Sie in der Dokumentation zu VPC-Quoten.
• Der VPC-Load-Balancer kann Anfragen an eine begrenzte Anzahl von Worker-Knoten weiterleiten. Die maximale Anzahl von Knoten, an die Sie Anfragen weiterleiten können, hängt davon ab, wie Sie die externalTrafficPolicy-Anmerkung setzen.
  • Wenn Sie externalTrafficPolicy: Cluster in Ihrer Load Balancer-Konfiguration einstellen:
    • Der VPC-Loadbalancer leitet zu den ersten 8 Arbeitsknoten, die in jeder Zone entdeckt werden. Bei einem Cluster mit Arbeitsknoten in drei Zonen führt dies dazu, dass der Load Balancer insgesamt 24 Arbeitsknoten ansteuert. Bei einem Single-Zone-Cluster leitet der Load Balancer an insgesamt 8 Worker Nodes weiter. Sie können die Anzahl der Arbeitsknoten pro Zone, zu denen der Load Balancer leitet, mit service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota ändern, aber die Gesamtzahl für alle Zonen darf 50 nicht überschreiten. Wenn der Cluster weniger als 50 Arbeitsknoten in allen Zonen hat, geben Sie 0 an, um zu allen Arbeitsknoten in einer Zone zu leiten. Die kube-proxy konfiguriert IP-Tabellen, um den eingehenden Datenverkehr vom Arbeitsknoten an den Anwendungs-Pod auf dem jeweiligen Knoten weiterzuleiten, auf dem sich der Anwendungs-Pod befindet.
  • Wenn Sie externalTrafficPolicy: Local in Ihrer Load Balancer-Konfiguration festlegen, wird der VPC-Load Balancer nur erstellt, wenn der Cluster 50 oder weniger Arbeitsknoten enthält. Diese Grenze wird durch die VPC-Quotenbeschränkung von 50 Poolmitgliedern pro VPC-Loadbalancer-Pool festgelegt. Um diese Einschränkung zu vermeiden, verwenden Sie die service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector-Anmerkung, um die Anzahl der Arbeitsknoten im Lastausgleichspool zu begrenzen. Sie können diese Anmerkung zum Beispiel verwenden, um eingehenden Datenverkehr zu einem bestimmten Worker-Pool zu leiten. Wenn Sie diese Anmerkung verwenden, um den Datenverkehr zu einem bestimmten Worker-Pool zu zwingen, müssen Sie auch sicherstellen, dass der Anwendungs-Pod im selben Worker-Pool läuft.
• Wenn Sie die YAML-Konfigurationsdatei für einen Kubernetes Service vom Typ LoadBalancer definieren, werden die folgenden Annotationen und Einstellungen nicht unterstützt:
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
  • spec.loadBalancerIP
  • spec.loadBalancerSourceRanges
  • Nur VPC-NLBs: service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
  • Nur VPC-ALBs: Die Einstellung externalTrafficPolicy: Local wird zwar unterstützt, jedoch wird bei dieser Einstellung die Quellen-IP-Adresse der Anforderung nicht beibehalten.
• Wenn Sie einen VPC-Cluster löschen, werden alle nicht persistenten VPC-Loadbalancer, die im Format kube-<cluster_ID>-<kubernetes_lb_service_UID> benannt sind und automatisch von Red Hat OpenShift on IBM Cloud für die Kubernetes LoadBalancer-Dienste in diesem Cluster erstellt werden, ebenfalls automatisch gelöscht. Allerdings werden persistente Load Balancer mit eindeutigen Namen und VPC-Load Balancer, die Sie manuell in Ihrer VPC erstellt haben, nicht gelöscht.
• Sie können bis zu 128 Unterdomänen für Hostnamen von VPC-Lastausgleichsfunktionen registrieren. Diese Begrenzung kann auf Anforderung aufgehoben werden, indem ein Supportfall geöffnet wird.
• Subdomains, die Sie für VPC-Loadbalancer registrieren, sind auf 130 Zeichen oder weniger beschränkt.
• VPC-ALBs überwachen dieselben VPC-Subnetze, denen die Cluster-Arbeitsknoten zugewiesen sind, es sei denn, der Kubernetes-Load-Balancer-Dienst wird mit den service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets- oder service.kubernetes.io/ibm-load-balancer-cloud-provider-zone-Annotationen erstellt, die den Verkehr auf bestimmte Knoten beschränken.
  • Die Subnetze und Zonen des VPC ALB können aktualisiert oder geändert werden, nachdem der ALB erstellt wurde. Wenn Sie dem Cluster weitere Zonen hinzufügen oder den Kubernetes-Load-Balancer-Dienst mit den service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets- oder service.kubernetes.io/ibm-load-balancer-cloud-provider-zone-Anmerkungen aktualisieren, wird der VPC ALB aktualisiert, um die neuen Subnetze zu überwachen.
• VPC NLBs lauschen nur auf einem einzigen VPC-Subnetz in einer einzigen Zone. Sie können nicht so konfiguriert werden, dass sie mehrere VPC-Subnetze abhören oder mehrere Zonen abhören. Mit den Anmerkungen service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets oder service.kubernetes.io/ibm-load-balancer-cloud-provider-zone können Sie das einzelne Subnetz angeben, das ein NLB abhören soll.
  • VPC NLBs leiten eingehenden Datenverkehr an alle Arbeitsknoten im Cluster weiter, es sei denn, Sie beschränken den eingehenden Datenverkehr auf bestimmte Arbeitsknoten mit service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector oder service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations. Um den Datenverkehr auf eine bestimmte Zone zu beschränken, können Sie diese Anmerkungen verwenden, um Arbeitsknoten in dieser Zone anzugeben.
• Die Inaktivierung der NodePort-Zuordnung der Lastausgleichsfunktion wird für VPC-Lastausgleichsfunktionen nicht unterstützt.
• VPC NLBs können sowohl mit UDP als auch mit TCP auf derselben VPC LB eingerichtet werden, aber der abhörende Port muss unterschiedlich sein.