Verwaltung von VPC-Lastverteilern

Nehmen Sie Änderungen an Ihren vorhandenen VPC-Loadbalancern vor.

Benennen Sie keine VPC NLBs oder ALBs um. Das Umbenennen eines VPC-Load-Balancers führt zu einem Fehler beim Dienst LoadBalancer Kubernetes, was Ihre Workloads beeinträchtigen könnte.

Dauerhafte VPC-Lastverteiler

Standardmäßig werden VPC-Loadbalancer gelöscht, wenn der Cluster, dem sie zugeordnet sind, gelöscht wird. Wenn Sie jedoch eine LoadBalancer-Dienstdefinition erstellen, können Sie Ihren Load Balancer persistent machen, damit er auch nach dem Löschen Ihres Clusters verfügbar bleibt. Ein persistenter VPC-Loadbalancer kann auf einen anderen Cluster angewendet werden, nachdem der vorherige Cluster gelöscht wurde.

VPC-Load-Balancer-Namen werden standardmäßig als kube-<cluster_ID>-<kubernetes_lb_service_UID> formatiert. Wenn ein Cluster gelöscht wird, gibt dieses Namensformat die zugehörigen Load Balancer an, die dann ebenfalls gelöscht werden. Um sicherzustellen, dass Ihr Load Balancer nicht gelöscht wird, wenn Sie einen Cluster löschen, fügen Sie die service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name-Anmerkung in Ihre LoadBalancer-Dienstdefinition ein, um Ihrem Load Balancer einen eindeutigen Namen zu geben. Der Load Balancer-Name muss innerhalb Ihrer VPC eindeutig sein und darf nur alphanumerische Kleinbuchstaben und Bindestriche enthalten (-). Die Anmerkung kann auf alle VPC-Load-Balancer-Typen angewendet werden.

Sie sind dafür verantwortlich, persistente VPC-Loadbalancer zu löschen, wenn sie nicht mehr benötigt werden. Um einen dauerhaften VPC-Load-Balancer zu löschen, löschen Sie die Kubernetes LoadBalancer-Dienstdefinition, mit der der VPC-Load-Balancer verbunden ist.

Verschieben eines VPC-Loadbalancers von einem Cluster zu einem anderen

Persistente VPC-Load-Balancer können von einem VPC-Cluster abgetrennt und dann einem anderen hinzugefügt werden. Der neue Cluster muss sich in der gleichen VPC befinden wie der ursprüngliche Cluster.

Lösen eines VPC-Lastverteilers von einem Cluster

VPC-Loadbalancer sind mit der Kubernetes LoadBalancer-Dienstdefinition verknüpft, mit der sie erstellt wurden. Um einen persistenten VPC-Loadbalancer von einem Cluster zu trennen, müssen Sie die Verbindung mit dem LoadBalancer-Dienst unterbrechen. Dadurch wird der LoadBalancer-Dienst unbrauchbar und kann sicher gelöscht werden. Der VPC-Loadbalancer kann dann einem anderen Cluster zugeordnet werden.

Um die Verbindung zwischen dem VPC-Loadbalancer und dem LoadBalancer-Dienst zu unterbrechen, können Sie entweder den VPC-Loadbalancer umbenennen oder die service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name-Anmerkung aus der ursprünglichen LoadBalancer-Dienstdefinition entfernen. Beachten Sie, dass dies der einzige Fall ist, in dem Sie einen VPC-Loadbalancer umbenennen sollten, da dies einen Fehler für die Kubernetes-Ressource erzeugt. Wenn Ihr Ziel jedoch darin besteht, den VPC-Load Balancer auf einem anderen Cluster zu verwenden, wird dieser Fehler Ihre Arbeitslast nicht beeinträchtigen. Benennen Sie den VPC-Loadbalancer nicht um, wenn Sie den Loadbalancer auf demselben Cluster behalten möchten.

Anhängen eines VPC-Loadbalancers an einen Cluster

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-Dienst auf dem neuen Cluster erstellen, können Sie die service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name-Anmerkung verwenden, um den Namen des VPC-Load-Balancers anzugeben, den Sie hinzufügen möchten.

Wenn Sie den LoadBalancer-Dienst erstellen, müssen der VPC-Loadbalancer-Typ (ALB, NLB) und der IP-Typ (öffentlich, privat) mit den Angaben im LoadBalancer-Dienst übereinstimmen. So kann beispielsweise ein vorhandener LoadBalancer-Dienst auf dem neuen Cluster, der einen NLB-Typ angibt, nicht verwendet werden, um einen VPC ALB an den Cluster anzuhängen. Die Anmerkungen, die den Load Balancer-Typ und den IP-Typ angeben, sind service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features und service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type.

Die im LoadBalancer-Dienst angegebenen Ports und Knotenports müssen nicht mit denen übereinstimmen, mit denen der VPC-Loadbalancer erstellt wurde. Der VPC-Load-Balancer konfiguriert sich mit den Port-Definitionen des LoadBalancer-Dienstes neu, mit dem er im neuen Cluster verbunden ist.

Statusprüfungen für Lastausgleichsfunktionen

VPC-Load-Balancer werden automatisch mit Zustandsprüfungen konfiguriert, die Sie mit der externalTrafficPolicy-Anmerkung konfigurieren. Sie können zusätzliche Anmerkungen verwenden, um Zustandsprüfungen auf Ihren Load Balancern anzupassen.

  • Wenn externalTrafficPolicy auf Cluster gesetzt wurde, werden TCP-Statusprüfungen angewendet. Wenn Sie eine UDP-Lastausgleichsfunktion konfigurieren, müssen Sie zusätzliche Portangaben machen.
  • Wenn externalTrafficPolicy auf Local gesetzt wurde, werden HTTP-Statusprüfungen angewendet. Eingehender Datenverkehr wird nur an den Anwendungs-Pod weitergeleitet, der sich auf diesem speziellen Knoten befindet. Wenn es auf dem betreffenden Knoten keinen Anwendungs-Pod gibt, wird der eingehende Verkehr verworfen.

Die Einstellung externalTrafficPolicy: Local kann dazu führen, dass die Gesundheitsprüfungen auf den Worker Nodes des Load Balancer fehlschlagen. Normalerweise ist dieses Ergebnis das erwartete Verhalten und deutet nicht unbedingt auf ein Problem hin, da der Datenverkehr absichtlich unterbrochen wird, wenn der Load Balancer versucht, eine Verbindung zu einem Knoten herzustellen, der nicht über einen Anwendungs-Pod verfügt. Weitere Informationen finden Sie unter Warum schlagen die Zustandsprüfungen des VPC-Lastverteilers auf meinen Arbeitsknoten fehl?.

Anpassen von Zustandsprüfungen für VPC-Lastverteiler

Um mehr Kontrolle über Ihre VPC-Load-Balancer-Zustandsprüfungen zu erhalten, können Sie optionale Anmerkungen verwenden, um Ihre Zustandsprüfungen mit erweiterten Konfigurationen für Testintervalle, Timeouts und Wiederholungsversuche 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 Protokoll für die Zustandsprüfung der VPC-Loadbalancer-Ressource fest, die mit dem Kubernetes-Loadbalancer-Dienst verbunden ist. Normalerweise wird das VPC LB-Zustandsprüfungsprotokoll durch den Wert der externalTrafficPolicy-Einstellung in der Kubernetes-Load-Balancer-Dienstspezifikation bestimmt. Diese Anmerkung setzt diese Logik außer Kraft. Diese Anmerkung ändert nicht, wie Kubernetes, und insbesondere kube-proxy, sich in Bezug auf die verschiedenen Einstellungen von externalTrafficPolicy verhält.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port
Optional. Der Port TCP, der für die Zustandsprüfungen verwendet wird. Dieser Vermerk 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.
  • Wenn diese Anmerkung auf einen Kubernetes-Load-Balancer-Dienst angewendet wird, 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 Pfad für die Gesundheitsprüfung URL für HTTP und HTTPs-Gesundheitsprüfungen. Diese Bemerkung gilt nur, wenn ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist.
  • Der Pfad URL muss das Format "Ursprung-Formular-Anfrage-Ziel" haben.
  • Wenn diese Anmerkung nicht angegeben wird und die ibm-load-balancer-cloud-provider-vpc-health-check-protocol-Anmerkung auf http oder https gesetzt ist, wird der Standardwert / verwendet.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay
Optional. Die Anzahl der Sekunden, die zwischen den Gesundheitsprüfungen gewartet wird. Standardmäßig ist dieser Wert auf 5 gesetzt und hat ein Minimum von 2 und ein Maximum von 60. Dieser Wert muss größer sein als der ibm-load-balancer-cloud-provider-vpc-health-check-timeout-Wert, 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 Gesundheitsprü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 sein als der ibm-load-balancer-cloud-provider-vpc-health-check-delay-Wert, 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 Zustandsprüfung für den VPC-Loadbalancer. 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. Bei der Cluster- 4.14-Version und früheren Versionen müssen Sie, wenn der Knotenport außerhalb des 30000-32767 Bereichs liegt, die VPC-Cluster-Sicherheitsgruppe anpassen, kube-<cluster-ID> um eingehenden Datenverkehr an den 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 Zustandsprüfungen für TCP nicht mehr, bis der Dienst wieder verfügbar ist oder Sie die Annotation 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. Bei Cluster-Versionen und 4.14 früheren Versionen müssen Sie jedoch den eingehenden Datenverkehr vom Port kubelet Sicherheitsgruppe des VPC-Clusters ändern kube-<cluster-ID> zulassen.

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

Ändern des Subnetzes oder der Zone eines Load Balancers

Nachdem Sie eine VPC NLB erstellt haben, können Sie das überwachende Subnetz, mit dem sie erstellt wurde, nicht neu konfigurieren. Wenn Sie das Listening-Subnetz eines bestehenden VPC-NLB ändern möchten, müssen Sie den entsprechenden KubernetesLoadBalancer-Dienst löschen, aktualisieren und erneut anwenden.

  1. Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

  2. Listen Sie Ihre Kubernetes-Services auf und suchen Sie den Namen des LoadBalancer-Service, den Sie ändern möchten.

    oc get services

    Beispielhafte Ausgabe.

    NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                        AGE
my-load-balancer         LoadBalancer   172.21.77.198   52.118.150.107   8080:32767/TCP,443:30943/TCP   5d

  3. Suchen Sie die VPC-Lastausgleichsfunktion, die dem Kubernetes-LoadBalancer-Service entspricht.

    Namen von VPC-Lastausgleichsfunktionen haben das Format kube-<cluster_ID>-<kubernetes_lb_service_UID>. Führen Sie ibmcloud ks cluster get --cluster CLUSTER_NAME aus, um Ihre Cluster-ID anzuzeigen. Um die UID des Kubernetes-LoadBalancer-Service anzuzeigen, führen Sie oc get svc LOAD_BALANCER_NAME -o yaml aus und suchen Sie in der Ausgabe nach dem Feld metadata.uid. Die Bindestriche (-) werden aus der LoadBalancer Service-UID Kubernetes im Namen des VPC-Lastenausgleichs entfernt.

    ibmcloud is load-balancers

    Beispielhafte Ausgabe.

    ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group      
r000-5aaaa11f6-c111-111f-b2e0-1c11aaaaf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf11111111fe4ca3f11111cb   Network       subnet-1                                  true        active             online             default                                                    Application

  4. Rufen Sie die Kubernetes-LoadBalancer-Servicedefinition ab und speichern Sie die Ausgabe als YAML-Datei mit dem Namen my-lb.yaml.

    oc describe service my-load-balancer -o yaml

  5. Löschen Sie den Kubernetes-LoadBalancer-Service. Dadurch wird auch die entsprechende VPC-Lastausgleichsfunktion gelöscht.

    oc delete service my-load-balancer

  6. Aktualisieren Sie die Kubernetes-LoadBalancer-Servicedefinitionsdatei mit den Teilnetz-oder Zonenänderungen, die Sie implementieren möchten. Ändern Sie nicht den Namen des LoadBalancer-Service. Details zum Angeben von Teilnetzen oder Zonen für Netzlastausgleichsfunktionen finden Sie unter Network Load Balancer for VPC einrichten.

  7. Wenden Sie die neue Definitionsdatei LoadBalancer an.

    oc apply -f my-lb.yaml

  8. Überprüfen Sie, ob der Kubernetes-LoadBalancer-Service in Ihrem Cluster erfolgreich neu erstellt wurde. Bei der Erstellung des Dienstes wird das Feld LoadBalancer-Ingress mit einer externen IP-Adresse für den NLB ausgefüllt.

    oc describe service my-load-balancer

    Beispielhafte Ausgabe.

    NAME:                     my-load-balancer
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.X.XXX.XX
LoadBalancer Ingress:     169.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.XX.XX.XXX:8080,172.XX.XX.XX:8080,172.XX.XX.XX:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
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/my-load-balancer with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.

  9. Überprüfen Sie, ob die VPC-Lastausgleichsfunktion erneut erstellt wurde und ob das Teilnetz oder die Zone aktualisiert wurde. Beachten Sie, dass die Bereitstellung des VPC-Load-Balancers einige Minuten dauert und möglicherweise ein bestimmter Status create_pending angezeigt wird, bis die Bereitstellung vollständig abgeschlossen ist.

    ibmcloud is load-balancers

    Beispielhafte Ausgabe.

    ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group     
r006-5ecc68f6-c751-409f-b2e0-1c69babf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf03445796fe4ca3f73885cb   Network       subnet-2                                  true        active             online             default