Network Load Balancer for VPC

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

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. Darüber hinaus unterstützt die VPC-NLB standardmäßig das Beibehalten der Quellen-IP-Adresse bei allen Clientanforderungen.

• 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 LoadBalancer Service-UID Kubernetes im VPC-NLB-Namen entfernt.

• Persistente 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 LoadBalancer Service-UID Kubernetes 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 App-Instanzen auf mehreren Worker-Knoten im Cluster bereitgestellt werden, leitet der VPC NLB die Anfragen zwischen den App-Pods auf verschiedenen Worker-Knoten über alle Zonen des Clusters hinweg weiter.

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.

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.

• Die Namen von VPC-ALBs haben das folgende 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 LoadBalancer Service-UID Kubernetes 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.

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.

NLB mit Portbereich einrichten

Portbereiche können in öffentlichen NLBs verwendet werden, wenn ein Service von einem einzelnen Hostnamen mit mehreren Back-End-Anwendungen gehostet werden muss, die jeweils an einer separaten Portnummer empfangsbereit sind. Damit Portbereiche in Ihrem Kubernetes-Cluster verwendet werden können, muss eine manuelle Konfiguration durchgeführt werden. Zuerst muss die Option ibm-load-balancer-cloud-provider-vpc-port-range festgelegt werden. Sie kann einen oder mehrere Bereiche enthalten, die jeweils durch ein Komma voneinander getrennt sind. Der Wert spec.ports.port muss auch auf den Mindestwert im Portbereich gesetzt werden.

Im folgenden Beispiel wird der Portbereich 30000-30010 verwendet.

Nodeport-Services müssen für jede Implementierung, in der der NLB-Service die Anforderung weiterleitet, manuell erstellt werden. Die Portnummer jedes dieser Nodeport-Services muss innerhalb des Portbereichs liegen, der im NLB-Service konfiguriert ist.

Im folgenden Beispieldiagramm wird ein Nodeport-Service mit Port 30000 für Implementierung 1 erstellt, während ein Nodeport-Service mit Port 30001 für Implementierung 2 erstellt wird.

Der Benutzer stellt eine Anforderung an Port 30001 der NLB, die den Portbereich enthält. Diese Anforderung wird an den VPC-NLB-Service weitergeleitet, der die Anforderung an den Nodeport-Service im Cluster weiterleitet, der auch an Port 30001 empfangsbereit ist, der in diesem Fall für Implementierung 2 bestimmt ist. Anschließend leitet der Nodeport-Service die Anforderung an den Zielport der ausgewählten Pod von Implementierung 2 weiter.

Erstellen Sie mithilfe des folgenden Beispiels eine NLB, die einen Portbereich verwendet. Die Selektor-und Back-End-Pods müssen dem Lastausgleichsservice für den Portbereich zugeordnet werden, damit die Statusprüfungen den Erfolg zurückgeben und Daten an die Ports im Portbereich übermittelt werden. Wenn Sie einen Portbereich verwenden möchten, müssen Sie zusätzliche NodePort-Services erstellen, deren Portwerte in dem vom Lastausgleichsservice definierten Bereich liegen.

1. Speichern Sie die folgende LoadBalancer-Beispielkonfiguration als Datei mit dem Namen loadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-port-range: 30000-30010
     name: nlb-port-range
   spec:
     externalTrafficPolicy: Cluster
     ports:
     - port: 30000 # Must match min from the port range
       protocol: TCP
       nodePort: 30011 # Can be port in range or not
       targetPort: 8080
     selector:
       app: echo-server  # Must be valid for health checks to work
     type: LoadBalancer
   

2. Erstellen Sie den Service.

   oc apply -f loadbalancer.yaml
   

3. Erstellen Sie einen NodePort-Service mit Portwerten, die in dem Portbereich liegen, der im zuvor erstellten LoadBalancer angegeben wurde.

   apiVersion: v1
   kind: Service
   metadata:
     name: echo-server-node-port
   spec:
     ports:
     - port: 80
       protocol: TCP # The protocol of the port range
       nodePort: 30003 # Node port in the port range
       targetPort: 8080
     selector:
       app: echo-server
     type: NodePort
   

4. Erstellen Sie den Dienst NodePort.

   oc apply -f nodeport.yaml
   

5. Für den Zugriff auf einen Port, der sich in dem von der NLB bereitgestellten Bereich befindet

   curl https://<public ip assigned to NLB>:30003
   

   • 30003 = Ist ein Knotenport in dem Bereich, der auf die Anforderung antwortet.
   • Andere Ports im Bereich antworten nur, wenn zusätzliche Knotenportservices erstellt werden.

Privaten VPC-NLB einrichten

Setzen Sie Ihre App auf den privaten Netzdatenverkehr, indem Sie einen Kubernetes-LoadBalancer-Service in jeder Zone Ihres Clusters einrichten. Wenn Sie den Kubernetes-LoadBalancer-Service erstellen, wird ein privates Lastausgleichsfunktionsnetz für VPC (VPC-NLB), das Anforderungen an Ihre App weiterleitet, automatisch für Sie in Ihrem VPC außerhalb Ihres Clusters erstellt.

Vorbereitende Schritte

• Vergewissern Sie sich, dass Sie über die Writer- oder **Manager-**IBM CloudIAM-Service-Zugriffsrolle für den Namensbereich verfügen, in dem Sie den Kubernetes-LoadBalancer-Service für den VPC NLB bereitstellen.
• Stellen Sie eine Verbindung zu Ihrem privaten VPC-Netz her, z. B. über eine VPC-VPN-Verbindung,
• Rufen Sie Ihren Red Hat OpenShift-Cluster auf.
• Installieren Sie zum Anzeigen von VPC-NLBs das Plug-in infrastructure-service. Das Präfix für die Ausführung von Befehlen ist ibmcloud is.

  ibmcloud plugin install infrastructure-service
  

Gehen Sie wie folgt vor, um Ihre App für den Empfang privater Netzanforderungen zu aktivieren:

1. Erstellen Sie ein VPC-Teilnetz, das Ihrem VPC-NLB zugeordnet ist. Dieses Teilnetz muss in derselben VPC und an derselben Position wie Ihr Cluster vorhanden sein, kann aber nicht mit Ihrem Cluster oder Workerknoten verbunden werden.

   1. Klicken Sie im VPC-Subnetz-Dashboard auf Neues Subnetz.
   2. Geben Sie einen Namen für Teilnetz ein.
   3. Wählen Sie die Speicherposition, an dem Ihr Cluster existiert, und die Zone, in der Sie den VPC-NLB erstellen möchten.
   4. Wählen Sie den Namen des VPC aus, in dem Ihr Cluster vorhanden ist.
   5. Geben Sie die Anzahl der zu erstellenden IP-Adressen an. Da dieses Teilnetz dem VPC-NLB zugeordnet ist, können Sie eine kleinere Größe auswählen, z. B. 16. Sie können die Anzahl der IPs, über die ein VPC-Teilnetz später verfügt, nicht ändern. Wenn Sie einen bestimmten IP-Bereich eingeben, verwenden Sie nicht die folgenden reservierten Bereiche: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 und 172.20.0.0/16.
   6. Klicken Sie auf Teilnetz erstellen. Notieren Sie sich nach der Bereitstellung des Teilnetzes die zugehörige ID.

2. Wenn der Client, der sich über die VPC-NLB mit Ihrer App verbinden muss, außerhalb der VPC und der Zone liegt, in der Sie das dedizierte VPC-Teilnetz erstellt haben, müssen Sie eine angepasste Ingress-Routing-Tabelle erstellen. Private VPC-NLBs können der angepassten Routing-Tabelle Regeln hinzufügen, um die Serviceverfügbarkeit für einige Fehlerbedingungen zu gewährleisten. Weitere Informationen finden Sie in der Tabelle unter den bekannten Einschränkungen und unter Über Routing-Tabellen und Routen.

   1. Klicken Sie im Dashboard VPC-Routing-Tabellen auf Erstellen.
   2. Geben Sie einen Namen für Ihre Routing-Tabelle ein.
   3. Wählen Sie die Speicherposition und Zone aus, in der Sie das dedizierte Teilnetz erstellt haben.
   4. Wählen Sie den Namen des VPC aus, in dem Ihr Teilnetz vorhanden ist.
   5. Wählen Sie für den Verkehrstyp den Eintrag Ingress aus.
   6. Wählen Sie, je nachdem wo der Client auf Ihre App zugreift, eine Verkehrsquelleaus. Weitere Informationen zum Einrichten von Verbindungen zu Ihrem privaten VPC-Netz finden Sie in der Dokumentation zur Auswahl des IBM Cloud VPC-VPNTransit Gateway oder Direct Link zur VPC-Konnektivität.
      • Lokales Netz: Direkter Link
      • Eine weitere VPC- oder klassische Infrastruktur: Transit-Gateway
      • Eine andere Zone innerhalb des gleichen VPC: VPC-Zone

3. Stellen Sie die App im Cluster bereit. Stellen Sie sicher, dass Sie im Metadatenabschnitt der Konfigurationsdatei für die Bereitstellung eine Bezeichnung hinzufügen. Mit dieser angepassten Bezeichnung werden alle Pods gekennzeichnet, in denen Ihre App ausgeführt wird und die in den Lastausgleich einbezogen werden sollen.

4. Erstellen Sie eine YAML-Konfigurationsdatei für Ihren Kubernetes Service vom Typ LoadBalancer. Sie können den Service im Format <app_name>-vpc-nlb-<VPC_zone> benennen.

   apiVersion: v1
   kind: Service
   metadata:
     name: <app_name>-vpc-nlb-<VPC_zone>
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp: "<tcp_port"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
     type: LoadBalancer
     selector:
       <selector_key>: <selector_value>
     ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   Optional. Schließen Sie einen eindeutigen Namen ein, um Ihre VPC-Lastausgleichsfunktion persistent zu machen. Persistente VPC-Lastausgleichsfunktionen werden nicht gelöscht, wenn der Cluster, zu dem sie gehören, gelöscht wird. Weitere Informationen finden Sie unter Persistente VPC-Lastausgleichsfunktionen.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"

   Erforderlich: Annotation zum Erstellen einer VPC-NLB.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

   Erforderlich: Annotation zur Angabe eines Service, der private Anforderungen akzeptiert.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   Erforderlich: Annotation zur Angabe des dedizierten Teilnetzes, für das der VPC-NLB implementiert werden soll. Der Wert kann als VPC-Teilnetz-ID, VPC-Teilnetzname oder VPC-Teilnetz-CIDR angegeben werden. Sie müssen nur ein Teilnetz angeben. Das Teilnetz muss sich in derselben VPC wie Ihr Cluster und in einer Zone befinden, in der Ihr Cluster über Workerknoten verfügt, aber es können keine Workerknoten mit diesem Teilnetz verbunden sein. Die Workerknoten, die sich in der gleichen Zone wie dieses Teilnetz befinden, sind so konfiguriert, dass sie Verkehr vom VPC-NLB empfangen. Um Teilnetze in allen Ressourcengruppen anzuzeigen, führen Sie ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone> aus.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   Optional: Annotation zur Angabe eines Selektors für Workerknotenbezeichnungen. Innerhalb derselben Zone wie das dedizierte Teilnetz für den VPC-NLB können Sie bestimmte Workerknoten für den Empfang von Datenverkehr konfigurieren, indem Sie einen der unterstützten Kennzeichenauswahltasten auswählen. Dabei ist zu beachten, dass Sie nur einen einzigen Bezeichnungsselektor in die Annotation einschließen können und dass der Selektor im Format "key=value" angegeben werden muss. Wenn diese Annotation nicht angegeben wird, werden alle Workerknoten in derselben Zone wie das VPC-Teilnetz, das Sie in der Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets angegeben haben, so konfiguriert, dass sie Verkehr vom VPC-NLB empfangen. Wenn diese Option angegeben ist, werden alle dedicated: edge-Bezeichnungen auf Workerknoten ignoriert.

   Die folgenden Schlüssel sind zulässig. - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp

   Optional: Geben Sie einen TCP-Knotenport an, der für TCP-Statusprüfungen in einer UDP-Lastausgleichsfunktion verwendet wird. Erforderlich für UDP-Lastausgleichsfunktionen, bei denen externalTrafficPolicy auf Cluster festgelegt ist. Weitere Hinweise zum Festlegen eines Portwerts finden Sie unter TCP-Statusprüfungen für UDP-Lastausgleichsfunktionen konfigurieren.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   Optional: Diese Anmerkung legt das Statusprüfungsprotokoll für die VPC-Lastausgleichsressource fest, die dem Kubernetes zugeordnet ist. Normalerweise wird das Protokoll der VPC-LB-Statusprüfung durch den Wert der Einstellung externalTrafficPolicy in der Spezifikation des Kubernetes-Service für die Lastausgleichsfunktion bestimmt. Diese Annotation überschreibt diese Logik. Diese Annotation ändert nicht das Verhalten von Kubernetesund insbesondere von 'kube-proxy' in Bezug auf die verschiedenen Einstellungen von externalTrafficPolicy.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   Optional. Der Port TCP, der für die Zustandsprüfungen verwendet wird. Diese Annotation gilt nur, wenn auch ibm-load-balancer-cloud-provider-vpc-health-check-protocol angegeben ist.

   • Liegt der angegebene TCP-Port außerhalb des Portbereichs für Kubernetes-Knoten (30.000–32.767), muss die auf die Cluster-Worker-Knoten angewendete VPC-Sicherheitsgruppe angepasst werden, um eingehenden Datenverkehr auf diesem Port zuzulassen.
   • Wird diese Anmerkung auf einen Kubernetes-Load-Balancer-Dienst angewendet, der mit einem VPC-ALB verknüpft ist, müssen die ausgehenden Regeln der dem VPC-ALB zugewiesenen Sicherheitsgruppe geändert werden, um ausgehenden Datenverkehr zum angegebenen TCP-Port zuzulassen.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   Optional. Der Health-Check- URL spfad für HTTP und HTTPS-Health-Checks. Diese Annotation gilt nur, wenn ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist.

   • Der Pfad URL muss im Format eines Origin-Form-Anfrageziels vorliegen.
   • Wenn diese Annotation nicht angegeben ist und die Annotation ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist, wird der Standardwert / angewendet.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   Optional. Die Anzahl der Sekunden, die zwischen Statusprüfungsversuchen gewartet werden soll. Standardmäßig ist dieser Wert auf 5 gesetzt und hat ein Minimum von 2 und ein Maximum von 60. Dieser Wert muss größer als der Wert ibm-load-balancer-cloud-provider-vpc-health-check-timeout sein, der standardmäßig auf 2 gesetzt ist.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   Optional. Die Anzahl der Sekunden, die auf eine Antwort auf eine Statusprüfung gewartet wird. Standardmäßig ist dieser Wert auf 2 gesetzt und hat ein Minimum von 1 und ein Maximum von 59. Dieser Wert muss kleiner als die ibm-load-balancer-cloud-provider-vpc-health-check-delay sein, die standardmäßig auf 5 gesetzt ist.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   Die maximale Anzahl der Wiederholungen der Statusprüfung für die VPC-Lastausgleichsfunktion. Standardmäßig ist dieser Wert auf 2 gesetzt und hat ein Minimum von 1 und ein Maximum von 10.

   selector

   Der Bezeichnungsschlüssel (<selector_key>) und der Wert (<selector_value>), die Sie im Abschnitt spec.template.metadata.labels Ihrer YAML-Datei für die App-Bereitstellung verwendet haben. Mit dieser angepassten Bezeichnung werden alle Pods gekennzeichnet, in denen Ihre App ausgeführt wird und die in den Lastausgleich einbezogen werden sollen.

   port

   Der Port, den der Service überwacht.

   targetPort

   Optional: Der Port, an den der Datenverkehr vom Service weitergeleitet wird. Die im Pod ausgeführte Anwendung muss auf eingehenden TCP-Datenverkehr an diesem Zielport warten. Der Zielport wird häufig statisch in dem Image definiert, das im Anwendungspod ausgeführt wird. Der im Pod konfigurierte Zielport unterscheidet sich vom Knotenport für den Service und kann sich auch von dem externen Port unterscheiden, der in der VPC-Lastausgleichsfunktion konfiguriert ist.

   externalTrafficPolicy

   Erforderlich. Angeben Local oder Cluster.

   Setzen Sie die Einstellung auf, um Local die Quell-IP-Adresse von Client-Anfragen an Ihre Apps zu erhalten. Diese Einstellung verhindert, dass der eingehende Datenverkehr an einen anderen Knoten weitergeleitet wird. Diese Option konfiguriert auch HTTP-Statusprüfungen.

   Wenn gesetzt Cluster ist, wird DSR nur von dem Worker-Knoten aus implementiert, an den der VPC-NLB die eingehende Anfrage ursprünglich weiterleitet. Nach Eingang der eingehenden Anforderung wird die Anforderung an einen Workerknoten weitergeleitet, der den App-Pod enthält, der sich möglicherweise in einer anderen Zone befindet. Die Antwort des App-Pods wird an den ursprünglichen Workerknoten gesendet und dieser Workerknoten verwendet DSR, um die Antwort direkt unter Umgehung der VPC-NLB an den Client zu senden. Diese Option konfiguriert auch TCP-Statusprüfungen. Bei Load Balancern für UDP service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp ist die erforderlich, wenn Sie die Option Cluster wählen. Weitere Informationen finden Sie unter Konfigurieren von TCP-Zustandsprüfungen für UDP-Lastverteiler.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   Optional. Die Anzahl der Arbeitsknoten pro Zone, zu denen der Load Balancer leitet. Der Standardwert ist '8'. Bei einem Cluster mit Arbeitsknoten in drei Zonen führt dies dazu, dass der Load Balancer an insgesamt 24 Arbeitsknoten weiterleitet. Die Gesamtzahl der Arbeitsknoten in allen Zonen, zu denen der Load Balancer leitet, 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.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   Optional. Eine vom Kunden verwaltete Sicherheitsgruppe, die dem VPC-Loadbalancer hinzugefügt wird. Wenn Sie nicht die IBM-verwaltete Sicherheitsgruppe verwenden möchten, geben Sie eine Sicherheitsgruppe an, die Sie besitzen und verwalten. Diese Option entfernt die IBM-verwaltete Sicherheitsgruppe und ersetzt sie durch die von Ihnen angegebene Sicherheitsgruppe. Wenn Sie die Anmerkung von einem vorhandenen Load Balancer entfernen, wird die von Ihnen hinzugefügte Sicherheitsgruppe durch die IBM-verwaltete Sicherheitsgruppe ersetzt. Sie können diesen Vermerk jederzeit hinzufügen oder entfernen. Sie sind für die Verwaltung Ihrer Sicherheitsgruppe verantwortlich und halten sie auf dem neuesten Stand.

5. Erstellen Sie den Kubernetes-Service vom Typ LoadBalancer in Ihrem Cluster.

   oc apply -f <filename>.yaml -n <namespace>
   

6. Überprüfen Sie, ob der Kubernetes Service vom Typ LoadBalancer in Ihrem Cluster erfolgreich erstellt wurde. Wenn der Service erstellt wurde, enthält das Feld LoadBalancer Ingress eine externe IP-Adresse, die von der VPC-NLB zugeordnet wird.

Die Bereitstellung der VPC-NLB in Ihrer VPC dauert einige Minuten. Die externe IP-Adresse des Kubernetes-Service vom Typ LoadBalancer weist möglicherweise den Status pending auf, bis die VPC-NLB vollständig eingerichtet ist.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Beispiel für eine CLI-Ausgabe für einen privaten `LoadBalancer` -Service:
```sh {: screen}
NAME:                     myvpcnlb
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     10.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Warning  SyncLoadBalancerFailed           13m (x5 over 15m)    service-controller  Error syncing load balancer: failed to ensure load balancer: kube-bqcssbbd0bsui62odcdg-2d93b07decf641d2ad3f9c2985122ec1 for service default/myvpcnlb is busy: offline/create_pending
Normal   EnsuringLoadBalancer             9m27s (x7 over 15m)  service-controller  Ensuring load balancer
Normal   EnsuredLoadBalancer              9m20s                service-controller  Ensured load balancer
Normal   CloudVPCLoadBalancerNormalEvent  8m17s                ibm-cloud-provider  Event on cloud load balancer myvpcnlb for service default/myvpcnlb with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

7. Überprüfen Sie, ob die VPC-NLB in Ihrer VPC erfolgreich erstellt wurde. Überprüfen Sie, ob die VPC-NLB in der Ausgabe für Operating Status den Wert online und für Provision Status den Wert active aufweist.

   ibmcloud is load-balancers
   

   In der folgenden CLI-Beispielausgabe wird die erstellte VPC-NLB mit dem Namen kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e für den Kubernetes-Service vom Typ LoadBalancer angezeigt:

   ID                                     Name                                                         Created          Host Name                                  Is Public   Listeners                               Operating Status   Pools                                   Private IPs              Provision Status   Public IPs                    Subnets                                Resource Group
   06496f64-a689-4693-ba23-320959b7b677   kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e   8 minutes ago    1234abcd-us-south.lb.appdomain.cloud       no         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.XXX.XXX.XXX           active             -               c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

8. Greifen Sie über Ihre Verbindung zum privaten VPC-Netzwerk auf die IP-Adresse des Kubernetes-LoadBalancer-Dienstes zu, die Sie in Schritt 6 gefunden haben, und auf Ihren App-Port im Format <external_IP>:<app_port>.

9. Optional: Wiederholen Sie diese Schritte, um einen privaten VPC-NLB in jeder Zone bereitzustellen, in der Sie Ihre App bereitstellen möchten. Anschließend können Sie die externen IP-Adressen der VPC-NLB in jeder Zone in einer DNS-Unterdomäne registrieren.

DNS-Datensatz und TLS-Zertifikat registrieren

VPC-NLBs stellen statische externe IP-Adressen bereit, über die Sie auf Ihre App zugreifen können. Zur Registrierung eines SSL-Zertifikats für Ihre App-Domäne für die Unterstützung von HTTPS können Sie eine von IBM bereitgestellte Unterdomäne erstellen oder eine eigene angepasste Domäne bereitstellen.

Sie haben zum Beispiel einen Mehrzonencluster und führen Replikate Ihrer App auf Workerknoten in jeder Zone Ihres Clusters aus. Sie erstellen genau eine VPC-NLB pro Zone, um die App-Replikate zugänglich zu machen. Anschließend können Sie die externen IP-Adressen, die von jeder VPC-NLB bereitgestellt werden, in einem DNS-Eintrag registrieren.

Nach der Erstellung einer DNS-Unterdomäne für VPC-NLBs können Sie keine nlb-dns health-monitor-Befehle verwenden, um eine angepasste Statusprüfung zu erstellen. Stattdessen wird die VPC-Standardstatusprüfung verwendet. Weitere Informationen finden Sie in der VPC-Dokumentation.

• Erstellen Sie eine VPC-NLB pro Zone für Ihre App. Stellen Sie sicher, dass Sie in Ihrem Kubernetes-Service vom Typ LoadBalancer, von dem die VPC-NLB konfiguriert wird, einen HTTPS-Port definieren.
• Um das SSL-Zertifikat für den Zugriff über HTTPS auf Ihre App verwenden zu können, muss Ihre App in der Lage sein, TLS-Verbindungen zu beenden.

Gehen Sie wie folgt vor, um VPC-NLB-IP-Adressen mit einer DNS-Unterdomäne zu registrieren:

1. Rufen Sie die externe IP-Adresse Ihrer Lastausgleichsfunktion ab.

   oc get svc -o wide
   

   Beispielausgabe

   NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)            AGE      SELECTOR
   ...
   myapp-vpc-nlb-jp-tok-3    LoadBalancer   172.21.xxx.xxx   169.xx.xxx.xx     8080:30532/TCP     1d       run=webserver
   

2. Erstellen Sie eine angepasste oder von IBM bereitgestellte DNS-Unterdomäne für die IP-Adresse.

   • Angepasste Domäne:

     1. Registrieren Sie in Zusammenarbeit mit Ihrem DNS-Provider (DNS = Domain Name Service) oder mit dem IBM Cloud-DNS eine angepasste Domäne.
     2. Definieren Sie einen Aliasnamen für Ihre angepasste Domäne, indem Sie die IP-Adressen der Lastausgleichsfunktionen als A-Datensätze angeben.

   • Von IBM bereitgestellte Unterdomäne: Mit nlb-dns-Befehlen können Sie eine Unterdomäne mit einem SSL-Zertifikat für die IP-Adressen generieren. IBM Cloud übernimmt für Sie die Generierung und Verwaltung des Platzhalter-SSL-Zertifikats für die Unterdomäne.

     1. Erstellen Sie eine DNS-Unterdomäne und ein SSL-Zertifikat.

        ibmcloud oc nlb-dns create vpc-gen2 --type public --cluster <cluster_name_or_id> --ip <vpc_nlb1_ip> --ip <vpc_nlb2_ip> --ip <vpc_nlb3_ip>
        

     2. Überprüfen Sie, ob die Unterdomäne erstellt wurde. Weitere Informationen finden Sie unter Informationen zum Unterdomänenformat.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        Beispielausgabe

        Subdomain                                                                               IP(s)                                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     169.46.xx.x,169.48.xxx.xx,169.48.xxx.xx      None             created                   <certificate>
        

3. Öffnen Sie einen Web-Browser und geben Sie die URL für den Zugriff auf Ihre App über die Unterdomäne ein.

Wenn Sie das SSL-Zertifikat für den Zugriff auf Ihre App über HTTPS verwenden möchten, stellen Sie sicher, dass in Ihrem Kubernetes-Service vom Typ LoadBalancer ein HTTPS-Port definiert ist. Sie können überprüfen, ob Anforderungen ordnungsgemäß über den HTTPS-Port weitergeleitet werden, indem Sie curl -v --insecure https://<domain> ausführen. Ein Verbindungsfehler weist darauf hin, dass kein HTTPS-Port für den Service geöffnet ist. Stellen Sie außerdem sicher, dass TLS-Verbindungen von Ihrer Anwendung beendet werden können. Sie können überprüfen, ob Ihre App TLS ordnungsgemäß beendet, indem Sie curl -v https://<domain> ausführen. Ein Zertifikatsfehler gibt an, dass Ihre App TLS-Verbindungen nicht korrekt beendet.

Öffentliche oder private VPC-ALB einrichten

Vorbereitende Schritte

• Vergewissern Sie sich, dass Sie über die Writer- oder **Manager-**IBM CloudIAM-Service-Zugriffsrolle für den Namensbereich verfügen, in dem Sie den Kubernetes-LoadBalancer-Service für den VPC NLB bereitstellen.
• Rufen Sie Ihren Red Hat OpenShift-Cluster auf.
• Installieren Sie zum Anzeigen von VPC-ALBs das Plug-in infrastructure-service. Das Präfix für die Ausführung von Befehlen ist ibmcloud is.

  ibmcloud plugin install infrastructure-service
  

Damit Ihre App öffentliche oder private Anforderungen empfangen kann:

1. Stellen Sie die App im Cluster bereit. Stellen Sie sicher, dass Sie im Metadatenabschnitt der Konfigurationsdatei für die Bereitstellung eine Bezeichnung hinzufügen. Mit dieser angepassten Bezeichnung werden alle Pods gekennzeichnet, in denen Ihre App ausgeführt wird und die in den Lastausgleich einbezogen werden sollen.

2. Erstellen Sie eine YAML-Konfigurationsdatei für Ihren Kubernetes Service vom Typ LoadBalancer und geben Sie der Datei den Namen myloadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     name: myloadbalancer
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
    type: LoadBalancer
    selector:
       <selector_key>: <selector_value>
    ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   Optional. Schließen Sie einen eindeutigen Namen ein, um Ihre VPC-Lastausgleichsfunktion persistent zu machen. Persistente VPC-Lastausgleichsfunktionen werden nicht gelöscht, wenn der Cluster, zu dem sie gehören, gelöscht wird. Weitere Informationen finden Sie unter Persistente VPC-Lastausgleichsfunktionen.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"

   Optional: Aktivieren Sie das PROXY-Protokoll. Die Lastausgleichsfunktion übergibt Clientverbindungsinformationen, einschließlich der Client-IP-Adresse, der Proxy-Server-IP-Adresse und der beiden Portnummern, in Anforderungsheadern an Ihre Back-End-App. Dabei ist zu beachten, dass Ihre Back-End-App so konfiguriert sein muss, dass sie das PROXY-Protokoll akzeptiert. Beispielsweise können Sie eine NGINX-Anwendung so konfigurieren, dass sie das PROXY-Protokoll akzeptiert, indem Sie die folgenden Schritte ausführen.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type

   Annotation zur Angabe eines Service, der öffentliche oder private Anforderungen akzeptiert. Wenn Sie diese Annotation nicht einschließen, wird eine öffentliche LoadBalancer erstellt.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   Anmerkung zur Festlegung eines Selektors für Worker-Knoten-Labels. Kennzeichnen Sie die Workerknoten, die Datenverkehr empfangen sollen, indem Sie sich für einen der unterstützten Schlüssel für Bezeichnungsselektoren entscheiden. Dabei ist zu beachten, dass Sie nur einen einzigen Bezeichnungsselektor in die Annotation einschließen können und dass der Selektor im Format "key=value" angegeben werden muss. Wird diese Annotation nicht angegeben, werden alle Workerknoten, die sich in derselben Zone wie Ihr Cluster befinden, so konfiguriert, dass sie Datenverkehr von der VPC-ALB empfangen. Ist diese Annotation angegeben, hat sie Vorrang vor der Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-zone und die Bezeichnung dedicated: edge für Workerknoten wird ignoriert.

   Die folgenden Schlüssel sind zulässig: - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   Anmerkung zur Angabe eines oder mehrerer Subnetze, in denen der VPC-ALB-Dienst bereitgestellt wird. Ist diese Annotation angegeben, hat sie Vorrang vor der Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-zone. Dabei ist zu beachten, dass Sie ein Teilnetz in derselben VPC angeben können, bei dem es sich nicht um eines der Teilnetze handelt, mit dem Ihr Cluster verbunden ist. In diesem Fall kann die VPC-ALB, auch wenn sie in einem anderen Teilnetz in derselben VPC bereitgestellt wird, dennoch Datenverkehr an Ihre Workerknoten in den Clusterteilnetzen derselben Zone weiterleiten. Um Teilnetze in allen Ressourcengruppen anzuzeigen, führen Sie ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone> aus.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-zone

   Annotation zur Angabe einer VPC-Zone, der Ihr Cluster zugeordnet ist. Wenn Sie eine Zone in dieser Annotation angeben, werden zwei Prozesse ausgeführt.

   1. Die VPC-ALB wird in demselben Teilnetz der betreffenden Zone bereitgestellt, mit dem auch Ihre Workerknoten verbunden sind.
   2. Nur die Workerknoten in Ihrem Cluster in dieser Zone werden so konfiguriert, dass sie Datenverkehr von der VPC-ALB empfangen.

   Zum Anzeigen von Zonen führen Sie ibmcloud oc zone ls --provider vpc-gen2 aus.

   Wenn Sie die Lastausgleichsfunktion in einer bestimmten Zone platzieren möchten, müssen Sie diese Annotation beim Erstellen der Lastausgleichsfunktion angeben. Wenn Sie diese Annotation später in eine andere Zone ändern, wird die Lastausgleichsfunktion selbst nicht in die neue Zone verschoben. Die Lastausgleichsfunktion wird jedoch so neu konfiguriert, dass Datenverkehr nur an Workerknoten in der neuen Zone gesendet wird.

   Wenn die Bezeichnung dedicated: edge auf Workerknoten festgelegt ist und Sie diese Annotation angeben, werden nur Edge-Knoten in der angegebenen Zone für den Empfang von Datenverkehr konfiguriert. Edge-Knoten in anderen Zonen und Nicht-Edge-Knoten in der angegebenen Zone empfangen keinen Datenverkehr von der Lastausgleichsfunktion.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   Optional: Diese Anmerkung legt das Statusprüfungsprotokoll für die VPC-Lastausgleichsressource fest, die dem Kubernetes zugeordnet ist. Normalerweise wird das Protokoll der VPC-LB-Statusprüfung durch den Wert der Einstellung externalTrafficPolicy in der Spezifikation des Kubernetes-Service für die Lastausgleichsfunktion bestimmt. Diese Annotation überschreibt diese Logik. Diese Annotation ändert nicht das Verhalten von Kubernetesund insbesondere von 'kube-proxy' in Bezug auf die verschiedenen Einstellungen von externalTrafficPolicy.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   Optional. Der Port TCP, der für die Zustandsprüfungen verwendet wird. Diese Annotation gilt nur, wenn auch ibm-load-balancer-cloud-provider-vpc-health-check-protocol angegeben ist.

   • Liegt der angegebene TCP-Port außerhalb des Portbereichs für Kubernetes-Knoten (30.000–32.767), muss die auf die Cluster-Worker-Knoten angewendete VPC-Sicherheitsgruppe angepasst werden, um eingehenden Datenverkehr auf diesem Port zuzulassen.
   • Wird diese Anmerkung auf einen Kubernetes-Load-Balancer-Dienst angewendet, der mit einem VPC-ALB verknüpft ist, müssen die ausgehenden Regeln der dem VPC-ALB zugewiesenen Sicherheitsgruppe geändert werden, um ausgehenden Datenverkehr zum angegebenen TCP-Port zuzulassen.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   Optional. Der Health-Check- URL spfad für HTTP und HTTPS-Health-Checks. Diese Annotation gilt nur, wenn ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist.

   • Der Pfad URL muss im Format eines Origin-Form-Anfrageziels vorliegen.
   • Wenn diese Annotation nicht angegeben ist und die Annotation ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist, wird der Standardwert / angewendet.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   Optional. Die Anzahl der Sekunden, die zwischen Statusprüfungsversuchen gewartet werden soll. Standardmäßig ist dieser Wert auf 5 gesetzt und hat ein Minimum von 2 und ein Maximum von 60. Dieser Wert muss größer als der Wert ibm-load-balancer-cloud-provider-vpc-health-check-timeout sein, der standardmäßig auf 2 gesetzt ist.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   Optional. Die Anzahl der Sekunden, die auf eine Antwort auf eine Statusprüfung gewartet wird. Standardmäßig ist dieser Wert auf 2 gesetzt und hat ein Minimum von 1 und ein Maximum von 59. Dieser Wert muss kleiner als die ibm-load-balancer-cloud-provider-vpc-health-check-delay sein, die standardmäßig auf 5 gesetzt ist.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   Die maximale Anzahl der Wiederholungen der Statusprüfung für die VPC-Lastausgleichsfunktion. Standardmäßig ist dieser Wert auf 2 gesetzt und hat ein Minimum von 1 und ein Maximum von 10.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout

   Optional. Das Zeitlimit für inaktive Verbindungen des Listeners in Sekunden. Das Standardinaktivitätszeitlimit hängt von Ihren Kontoeinstellungen ab. Normalerweise lautet dieser Wert 50. Einige Konten, die in der Zulassungsliste aufgeführt sind, haben jedoch größere Zeitlimiteinstellungen. Wenn Sie die Annotation nicht festlegen, verwenden Ihre Lastausgleichsfunktionen die Zeitlimiteinstellung in Ihrem Konto. Sie können das Zeitlimit explizit angeben, indem Sie diese Annotation festlegen. Der Mindestwert ist 50. Das Maximum beträgt 7200.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

   Optional. Kann nur für private VPC ALBs in Version angewendet werden4.15 oder später. Die DNS-Einträge, die diesem Load Balancer zugeordnet werden instance sollen. Weitere Informationen finden Sie unter Registrieren eines privaten DNS-Eintrags.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

   Optional. Kann nur für private VPC ALBs in Version angewendet werden4.15 oder später. Die DNS-Einträge, die diesem Load Balancer zugeordnet werden zone sollen. Weitere Informationen finden Sie unter Registrieren eines privaten DNS-Eintrags.

   selector

   Der Bezeichnungsschlüssel (<selector_key>) und der Wert (<selector_value>), die Sie im Abschnitt spec.template.metadata.labels Ihrer YAML-Datei für die App-Bereitstellung verwendet haben. Mit dieser angepassten Bezeichnung werden alle Pods gekennzeichnet, in denen Ihre App ausgeführt wird und die in den Lastausgleich einbezogen werden sollen.

   port

   Der Port, den der Service überwacht.

   targetPort

   Optional: Der Port, an den der Datenverkehr vom Service weitergeleitet wird. Die im Pod ausgeführte Anwendung muss auf eingehenden TCP-Datenverkehr an diesem Zielport warten. Der Zielport wird häufig statisch in dem Image definiert, das im Anwendungspod ausgeführt wird. Der im Pod konfigurierte Zielport unterscheidet sich vom Knotenport für den Service und kann sich auch von dem externen Port unterscheiden, der in der VPC-Lastausgleichsfunktion konfiguriert ist.

   externalTrafficPolicy

   Erforderlich. Geben Sie Local oder Cluster an.

   Setzen Sie die Einstellung auf, um Local die Quell-IP-Adresse von Client-Anfragen an Ihre Apps zu bewahren. Diese Einstellung verhindert, dass der eingehende Datenverkehr an einen anderen Knoten weitergeleitet wird. Diese Option konfiguriert auch HTTP-Statusprüfungen. Bei Load Balancern für UDP service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp ist die erforderlich, wenn Sie die Option Cluster wählen. Weitere Informationen finden Sie unter Konfigurieren von TCP-Zustandsprüfungen für UDP-Lastverteiler.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   Optional. Die Anzahl der Arbeitsknoten pro Zone, zu denen der Load Balancer leitet. Der Standardwert ist '8'. Bei einem Cluster mit Arbeitsknoten in drei Zonen führt dies dazu, dass der Load Balancer an insgesamt 24 Arbeitsknoten weiterleitet. Die Gesamtzahl der Arbeitsknoten in allen Zonen, zu denen der Load Balancer leitet, 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.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   Optional. Eine vom Kunden verwaltete Sicherheitsgruppe, die dem VPC-Loadbalancer hinzugefügt wird. Wenn Sie nicht die IBM-verwaltete Sicherheitsgruppe verwenden möchten, geben Sie eine Sicherheitsgruppe an, die Sie besitzen und verwalten. Diese Option entfernt die IBM-verwaltete Sicherheitsgruppe und ersetzt sie durch die von Ihnen angegebene Sicherheitsgruppe. Wenn Sie die Anmerkung von einem vorhandenen Load Balancer entfernen, wird die von Ihnen hinzugefügte Sicherheitsgruppe durch die IBM-verwaltete Sicherheitsgruppe ersetzt. Sie können diesen Vermerk jederzeit hinzufügen oder entfernen. Sie sind für die Verwaltung Ihrer Sicherheitsgruppe verantwortlich und halten sie auf dem neuesten Stand.

3. Erstellen Sie den Kubernetes-Service vom Typ LoadBalancer in Ihrem Cluster.

   oc apply -f myloadbalancer.yaml -n <namespace>
   

4. Überprüfen Sie, ob der Kubernetes Service vom Typ LoadBalancer in Ihrem Cluster erfolgreich erstellt wurde. Wenn der Service erstellt wurde, enthält das Feld LoadBalancer Ingress einen Hostnamen, der von der VPC-ALB zugeordnet wird.

Die Bereitstellung der VPC-ALB in Ihrer VPC dauert einige Minuten. Sie können erst unter Verwendung des Hostnamens Ihres Kubernetes-LoadBalancer-Service auf Ihre App zugreifen, wenn die VPC-ALB vollständig bereitgestellt wurde.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
CLI-Beispielausgabe für einen öffentlichen `LoadBalancer`-Service:
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

5. Überprüfen Sie, ob die VPC-ALB in Ihrer VPC erfolgreich erstellt wurde. Überprüfen Sie, ob die VPC-ALB in der Ausgabe für Operating Status den Wert online und für Provision Status den Wert active aufweist.

   Benennen Sie keine VPC-ALBs um, die automatisch für LoadBalancer-Services erstellt wurden. Wenn Sie eine VPC-Lastausgleichsfunktion für Anwendungen umbenennen, erstellt Red Hat OpenShift on IBM Cloud automatisch eine weitere VPC-Lastausgleichsfunktion für Anwendungen für den LoadBalancer-Service.

   ibmcloud is load-balancers
   

   In der folgenden CLI-Beispielausgabe wird die erstellte VPC-ALB mit dem Namen kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 für den Kubernetes-Service vom Typ LoadBalancer angezeigt:

   ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
   r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default
   

6. Wenn Sie einen öffentlichen LoadBalancer-Service erstellt haben, rufen Sie den Hostnamen des Kubernetes-Service vom Typ LoadBalancer (siehe Schritt 4), der von der VPC-ALB zugeordnet wird, mit Curl auf. Beispiel:

   curl 06496f64-us-south.lb.appdomain.cloud:8080
   

   Beispielausgabe

   Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!
   

   Wenn Sie einen privaten LoadBalancer-Service erstellt haben, müssen Sie mit Ihrem privaten VPC-Netz verbunden sein,, um den Hostnamen mit dem Curl-Befehl aufrufen zu können.

Löschen Sie nicht die Teilnetze, die Sie Ihrem Cluster bei der Clustererstellung oder beim Hinzufügen von Workerknoten in einer Zone zugeordnet haben. Wenn Sie ein von Ihrem Cluster verwendetes VPC-Teilnetz löschen, können bei allen Lastausgleichsfunktionen, die IP-Adressen aus dem Teilnetz verwenden, Probleme auftreten, und Sie können möglicherweise keine neuen Lastausgleichsfunktionen erstellen.

VPC-ALBs und NLBs, die nicht an Kubernetes oder OpenShift-Cluster gebunden sind, können direkt über ibmcloud is-Befehle oder im Abschnitt VPC-Infrastruktur in der Konsole aktualisiert werden. Ändern Sie beispielsweise den Port eines Front-End-Listeners oder das Zeitlimit für die Statusprüfung. Bei VPC-Load-Balancer, die mit Kubernetes- oder OpenShift-Clustern verknüpft sind, müssen Änderungen jedoch über Annotationen in der Ingress-Konfiguration vorgenommen werden. Der IBM Cloud-Anbieter führt regelmäßig eine Neusynchronisierung mit allen zugehörigen VPC-ALBs und NLBs durch, um sicherzustellen, dass der laufende Load Balancer der erwarteten Konfiguration des Ingress entspricht. Wenn Sie also Änderungen an einer solchen Lastausgleichsfunktion direkt über VPC vornehmen, anstatt Ingress-Annotationen zu verwenden, werden diese Änderungen zurückgesetzt.

DNS-Datensatz und TLS-Zertifikat registrieren

Application Load Balancer for VPC (VPC ALB) stellt einen HTTP-Standardhostnamen im Format 1234abcd-<region>.lb.appdomain.cloud bereit, über den Sie auf Ihre App zugreifen können. Wenn Sie jedoch ein TLS-Zertifikat für Ihre App-Domäne wünschen, um HTTPS zu unterstützen, können Sie für öffentliche wie auch für private VPC-ALBs eine von IBM bereitgestellte Unterdomäne erstellen oder eine eigene angepasste Domäne verwenden.

Nachdem Sie eine DNS-Unterdomäne für einen VPC-ALB-Hostnamen erstellt haben, können Sie keine nlb-dns health-monitor-Befehle zum Erstellen einer angepassten Statusprüfung verwenden. Stattdessen wird die VPC-Standardstatusprüfung für Lastausgleichsfunktionen verwendet, die für den Standard-Hostnamen der VPC-ALB bereitgestellt wird. Weitere Informationen finden Sie in der VPC-Dokumentation.

Vorbereitende Schritte

• Richten Sie eine VPC-ALB ein. Stellen Sie sicher, dass Sie in Ihrem Kubernetes-Service vom Typ LoadBalancer, von dem die VPC-ALB konfiguriert wird, einen HTTPS-Port definieren.
• Um das TLS-Zertifikat für den Zugriff über HTTPS auf Ihre App verwenden zu können, muss Ihre Anwendung in der Lage sein, TLS-Verbindungen zu beenden.

Um einen VPC-ALB-Hostnamen mit einer DNS-Unterdomäne zu registrieren:

1. Rufen Sie den Hostnamen für Ihre VPC-ALB ab, indem Sie den Befehl get svc ausführen. Suchen Sie in der Ausgabe in der Spalte EXTERNAL-IP nach dem Hostnamen. Zum Beispiel 1234abcd-us-south.lb.appdomain.cloud.

   oc get svc -o wide
   

   Beispielausgabe

   NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
   ...
   webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver
   

2. Erstellen Sie eine angepasste oder von IBM bereitgestellte DNS-Unterdomäne für den Hostnamen der Lastausgleichsfunktion.

   • Benutzerdefinierte Domain: Geben Sie Ihre eigene benutzerdefinierte Domain an und weisen Sie ihr einen Alias zu, indem Sie die externe IP-Adresse des Load Balancers im Format eines 1234abcd-us-south.lb.appdomain.cloud Canonical Name-Eintrags (CNAME) angeben.

     1. Registrieren Sie in Zusammenarbeit mit Ihrem DNS-Provider (DNS = Domain Name Service) oder mit dem IBM Cloud-DNS eine angepasste Domäne.
     2. Definieren Sie einen Alias für Ihre benutzerdefinierte Domain, indem Sie die externe IP-Adresse des Load Balancers als Canonical Name-Eintrag (CNAME) angeben. Im folgenden Beispiel ist die Lastausgleichsfunktion mit der externen IP 1234abcd-us-south.lb.appdomain.cloud unter www.your-custom-domain.com erreichbar.

     Host/Service

     Das Präfix, unter dem Sie Ihre App aufrufen möchten, z. B. www.

     Ressourcentyp

     Wählen Sie CNAME aus.

     TTL

     Wählen Sie eine Lebensdauer aus.

     Wert/Ziel

     Die externe IP der LoadBalancer, die Sie zuvor abgerufen haben Beispiel: 1234abcd-us-south.lb.appdomain.cloud.. Wenn Sie IBM Cloud DNS verwenden, stellen Sie sicher, dass Sie einen abschließenden Punkt eingeben.

   • Von IBMbereitgestellte Unterdomäne: Mit nlb-dns-Befehlen können Sie eine Unterdomäne mit einem TLS-Zertifikat für den Hostnamen der VPC-ALB generieren. IBM Cloud übernimmt die Generierung und Verwaltung des TLS-Platzhalterzertifikats für die Unterdomäne für Sie.

     1. Erstellen Sie eine DNS-Unterdomäne und ein TLS-Zertifikat.

        ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_id> --lb-host <vpc_lb_hostname> --type (public|private)
        

     2. Überprüfen Sie, ob die Unterdomäne erstellt wurde. Weitere Informationen finden Sie unter Informationen zum Unterdomänenformat.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        Beispielausgabe

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
        

3. Wenn Sie eine Subdomain für einen öffentlichen VPC-ALB erstellt haben, öffnen Sie einen Webbrowser und geben Sie URL ein, um über die Subdomain auf Ihre App zuzugreifen, wie im Beispiel gezeigt www.your-custom-domain.com. Wenn Sie eine Unterdomäne für eine private VPC-ALB erstellt haben, müssen Sie mit Ihrem privaten VPC-Netz verbunden sein, um den Zugriff auf Ihre Unterdomäne testen zu können.

Wenn Sie das TLS-Zertifikat für den Zugriff auf Ihre App über HTTPS verwenden möchten, stellen Sie sicher, dass in Ihrem Kubernetes Service vom Typ LoadBalancer ein HTTPS-Port definiert ist. Sie können überprüfen, ob Anforderungen ordnungsgemäß über den HTTPS-Port weitergeleitet werden, indem Sie curl -v --insecure https://<domain> ausführen. Ein Verbindungsfehler weist darauf hin, dass kein HTTPS-Port für den Service geöffnet ist. Stellen Sie außerdem sicher, dass TLS-Verbindungen von Ihrer Anwendung beendet werden können. Sie können überprüfen, ob Ihre App TLS ordnungsgemäß beendet, indem Sie curl -v https://<domain> ausführen. Ein Zertifikatsfehler gibt an, dass Ihre App TLS-Verbindungen nicht korrekt beendet.

Registrieren eines privaten DNS-Eintrags für ein privates VPC ALB

In der Version4.15 oder später können Sie die folgenden optionalen Annotationen verwenden, um einen eigenen DNS zu verknüpfen instance welches einen benutzerdefinierten DNS bereitstellt zone mit einem privaten VPC ALB. Hierzu müssen die beiden optionalen Annotationen gesetzt werden. Wenn sie nicht angegeben sind, dann DNS A Datensätze für diesen Load Balancer hostname Eigenschaft wird zur öffentlichen DNS-Zone hinzugefügt lb.appdomain.cloud.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn" :
Die DNS-Einträge, die diesem Load Balancer zugeordnet werden instance sollen. Die angegebene Instanz kann sich je nach IAM-Richtlinien in einer anderen Region oder einem anderen Konto befinden. Mögliche Werte: 9 ≤ Länge ≤ 512

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id" :
Die DNS-Einträge, die diesem Load Balancer zugeordnet werden zone sollen. Die angegebene Zone kann sich je nach IAM-Richtlinien in einer anderen Region oder einem anderen Konto befinden. Mögliche Werte: 1 ≤ Länge ≤ 128, der Wert muss dem regulären Ausdruck [a-z0-9-]^*[a-z0-9]$ entsprechen

Bevor Sie diese Funktion nutzen können, müssen Sie Folgendes als Voraussetzung tun:

• Erstellen Sie die DNS-Zone, die an einen Load Balancer gebunden werden kann
• Aktivieren Sie die Service-to-Service-Autorisierung zwischen VPC LBs undDNS Services
• Fügen Sie das VPC des Clusters zu den zulässigen Netzwerken der Zone hinzu

Ausführliche Informationen finden Sie in den Dokumenten Integration eines Anwendungs-Load-Balancers mit IBM Cloud DNS Services und Hinzufügen einer VPC als zugelassenes Netzwerk zur DNS-Zone.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

VPC-Lastausgleichsfunktion von einem Cluster abhängen

VPC-Lastverteiler sind mit der LoadBalancer Dienstdefinition Kubernetes verknüpft, mit der sie erstellt wurden. Um eine persistente VPC-Lastausgleichsfunktion von einem Cluster abzuhängen, müssen Sie die Verbindung zum LoadBalancer-Service unterbrechen, indem Sie die VPC-Lastausgleichsfunktion umbenennen oder die Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name aus der ursprünglichen LoadBalancer-Servicedefinition entfernen. Sie können auch eine persistente VPC-Lastausgleichsfunktion von einem Cluster abhängen, indem Sie den Cluster löschen.

Wenn Sie die Annotation entfernen, wird der ursprüngliche LoadBalancer-Service zurückgesetzt und eine nicht persistente VPC-Lastausgleichsfunktion im ursprünglichen Cluster erstellt. Diese nicht persistente VPC-Lastausgleichsfunktion folgt der Namenskonvention kube-<cluster_ID>-<kubernetes_lb_service_UID>.

VPC-Lastausgleichsfunktion einem Cluster zuordnen

Nachdem ein persistenter VPC-Load-Balancer von einem Cluster getrennt wurde, können Sie ihn an einen anderen Cluster anbinden, indem Sie eine neue KubernetesLoadBalancer-Dienstdefinition erstellen, die auf den VPC-Load-Balancer verweist.

Wenn Sie einen neuen LoadBalancer-Service im neuen Cluster erstellen, können Sie mithilfe der Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name den Namen der VPC-Lastausgleichsfunktion angeben, die Sie zuordnen wollen.

Wenn Sie den Service LoadBalancer erstellen, müssen der Typ der VPC-Lastausgleichsfunktion (ALB, NLB) und der IP-Typ (öffentlich, privat) den Spezifikationen im LoadBalancer-Service entsprechen. Beispiel: Ein vorhandener LoadBalancer-Service auf dem neuen Cluster, der einen NLB-Typ angibt, kann nicht verwendet werden, um dem Cluster eine VPC-ALB zuzuordnen. Die Annotationen, die den Lastausgleichsfunktionstyp und den IP-Typ angeben, sind service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features bzw. service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type.

Die im LoadBalancer-Service angegebenen Port-und Knotenports müssen nicht mit denen übereinstimmen, mit denen die VPC-Lastausgleichsfunktion erstellt wurde. Die VPC-Lastausgleichsfunktion rekonfiguriert mit den Portdefinitionen des LoadBalancer-Service, dem sie im neuen Cluster zugeordnet ist.

Statusprüfungen für VPC-Lastausgleichsfunktionen anpassen

Für mehr Kontrolle über die Statusprüfungen Ihrer VPC-Lastausgleichsfunktion können Sie optionale Annotationen verwenden, um Ihre Statusprüfungen mit erweiterten Konfigurationen für Testintervalle, Zeitlimits und Wiederholungen anzupassen. Sie können diese Anpassungen jederzeit ändern oder entfernen.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

Optional: Diese Anmerkung legt das Statusprüfungsprotokoll für die VPC-Lastausgleichsressource fest, die dem Kubernetes zugeordnet ist. Normalerweise wird das Protokoll der VPC-LB-Statusprüfung durch den Wert der Einstellung externalTrafficPolicy in der Spezifikation des Kubernetes-Service für die Lastausgleichsfunktion bestimmt. Diese Annotation überschreibt diese Logik. Diese Annotation ändert nicht das Verhalten von Kubernetesund insbesondere von 'kube-proxy' in Bezug auf die verschiedenen Einstellungen von externalTrafficPolicy.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

Optional. Der Port TCP, der für die Zustandsprüfungen verwendet wird. Diese Annotation gilt nur, wenn auch ibm-load-balancer-cloud-provider-vpc-health-check-protocol angegeben ist.

• Liegt der angegebene TCP-Port außerhalb des Portbereichs für Kubernetes-Knoten (30.000–32.767), muss die auf die Cluster-Worker-Knoten angewendete VPC-Sicherheitsgruppe angepasst werden, um eingehenden Datenverkehr auf diesem Port zuzulassen.
• Wird diese Anmerkung auf einen Kubernetes-Load-Balancer-Dienst angewendet, der mit einem VPC-ALB verknüpft ist, müssen die ausgehenden Regeln der dem VPC-ALB zugewiesenen Sicherheitsgruppe geändert werden, um ausgehenden Datenverkehr zum angegebenen TCP-Port zuzulassen.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

Optional. Der Health-Check- URL spfad für HTTP und HTTPS-Health-Checks. Diese Annotation gilt nur, wenn ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist.

• Der Pfad URL muss im Format eines Origin-Form-Anfrageziels vorliegen.
• Wenn diese Annotation nicht angegeben ist und die Annotation ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist, wird der Standardwert / angewendet.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

Optional. Die Anzahl der Sekunden, die zwischen Statusprüfungsversuchen gewartet werden soll. Standardmäßig ist dieser Wert auf 5 gesetzt und hat ein Minimum von 2 und ein Maximum von 60. Dieser Wert muss größer als der Wert ibm-load-balancer-cloud-provider-vpc-health-check-timeout sein, der standardmäßig auf 2 gesetzt ist.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

Optional. Die Anzahl der Sekunden, die auf eine Antwort auf eine Statusprüfung gewartet wird. Standardmäßig ist dieser Wert auf 2 gesetzt und hat ein Minimum von 1 und ein Maximum von 59. Dieser Wert muss kleiner als der Wert ibm-load-balancer-cloud-provider-vpc-health-check-delay sein, der standardmäßig auf 5 gesetzt ist.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

Die maximale Anzahl der Wiederholungen der Statusprüfung für die VPC-Lastausgleichsfunktion. Standardmäßig ist dieser Wert auf 2 gesetzt und hat ein Minimum von 1 und ein Maximum von 10.

TCP-Statusprüfungen für UDP-Lastausgleichsfunktionen aktivieren

Da es keine UDP-Statusprüfungen gibt, muss für UDP-Lastausgleichsfunktionen, die TCP-Statusprüfungen verwenden, ein zusätzlicher TCP-Port mit der Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp angegeben werden.

Sie können den TCP-Knotenport für eine andere Lastausgleichsfunktion oder einen anderen Knotenport angeben, die bzw. der in Ihrem Cluster ausgeführt wird. Wenn sich der Knotenport jedoch außerhalb des 30000-32767-Bereichs befindet, müssen Sie Sicherheitsgruppe des VPC-Clusters kube-<cluster-ID> ändern, um eingehenden Datenverkehr bis zum angegebenen Port zuzulassen.

Beachten Sie: Wenn der angegebene Portwert für einen Dienst gilt, der unerwartet ausfällt oder dessen Portwert neu konfiguriert wird, funktionieren die TCP-Zustandsprüfungen nicht mehr, bis der Dienst wieder verfügbar ist oder Sie die Anmerkung service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp mit einem neuen Portwert für TCP neu konfigurieren. Um dies zu vermeiden, können Sie den kubelet Port 10250 angeben, bei dem es sich um einen statischen Portwert handelt, bei dem keine Serviceunterbrechungen auftreten. Sie müssen jedoch Sicherheitsgruppe des VPC-Clusters ändern kube-<cluster-ID> angeben, um eingehenden Datenverkehr vom kubelet-Port zu akzeptieren.

Möchten Sie die Komplexität vermeiden, zusätzliche TCP-Ports für Zustandsprüfungen in einem UDP-Load-Balancer angeben zu müssen? Setzen Sie externalTrafficPolicy auf Local, um HTTP-Statusprüfungen zu verwenden, die keine zusätzlichen Portspezifikationen erfordern.