Vorbereitende Schritte

1. 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.
2. Rufen Sie Ihren Red Hat OpenShift-Cluster auf.
3. 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
   

4. Für private VPC NLBs: Stellen Sie eine Verbindung zu Ihrem privaten VPC-Netzwerk her, z. B. über eine VPC VPN-Verbindung.
5. Für private VPC NLBs: Aktivieren Sie Ihre Anwendung für den Empfang privater Netzwerkanfragen.
   1. Erstellen Sie ein VPC-Subnetz, das ausschließlich für Ihren VPC-NLB vorgesehen 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. 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. Nachdem Sie das Subnetz bereitgestellt haben, notieren Sie seine ID.
   2. Wenn sich der Client, der über den VPC-NLB eine Verbindung zu Ihrer App herstellt, außerhalb der VPC und der Zone Ihres dedizierten VPC-Subnetzes befindet, müssen Sie eine benutzerdefinierte Ingress-Routing-Tabelle erstellen. Weitere Informationen finden Sie in der Tabelle unter den bekannten Einschränkungen und unter Über Routing-Tabellen und Routen. Wählen Sie eine der folgenden Verkehrsquellen für Ihre benutzerdefinierte Ingress-Routing-Tabelle: Für Datenverkehr aus einem lokalen Netzwerk wählen Sie Direktverbindung. Für Datenverkehr aus einer anderen VPC oder aus der klassischen Infrastruktur wählen Sie Transit-Gateway. Für Datenverkehr aus einer anderen Zone innerhalb derselben VPC wählen Sie VPC-Zone. Weitere Informationen finden Sie unter Einrichten der VPC VPN-Konnektivität.

Konfigurieren Sie den Dienst LoadBalancer

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. Geben Sie in der YAML-Datei den Vermerk service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type entweder als "public" oder "private" an. Der Abschnitt annotations in der Beispieldatei enthält nur einige verfügbare Anmerkungen. Eine vollständige Liste der erforderlichen und optionalen VPC NLB-Anmerkungen finden Sie unter Anmerkungen und Spezifikationen.

   Damit Ihr VPC NLB leicht identifizierbar ist, sollten Sie den Dienst 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: "public"
       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>"
   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.
   

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

   oc apply -f <filename>.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 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>
```
CLI-Beispielausgabe für einen öffentlichen `LoadBalancer`-Service:
```sh {: screen}
NAME:                     myapp-vpc-nlb-us-east
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     169.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.
```

5. Ü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       yes         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.241.0.7               active             169.63.99.184                 c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

6. Greifen Sie auf die IP-Adresse des Kubernetes-LoadBalancer-Service zu, die Sie in Schritt 4 ermittelt haben. und auf den Port Ihrer App im Format <external_IP>:<app_port>.

7. Optional: Wiederholen Sie diese Schritte, um eine öffentliche VPC-NLB in jeder Zone bereitzustellen, in der Ihre App verfügbar gemacht werden soll. Anschließend können Sie die externen IP-Adressen der VPC-NLB in jeder Zone in einer DNS-Unterdomäne registrieren.

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 VPC-NLBs, die IP-Adressen aus dem Teilnetz verwenden, Probleme auftreten, und Sie können möglicherweise keine neuen Lastausgleichsfunktionen erstellen.

Einrichten eines öffentlichen NLB unter Verwendung eines Portbereichs

Portbereiche können in öffentlichen NLBs verwendet werden, wenn ein Dienst von einem einzigen Hostnamen aus gehostet werden muss, der mehrere Backend-Anwendungen hat, die jeweils auf einer separaten Portnummer warten. Um Portbereiche in Ihrem Kubernetes-Cluster zu verwenden, müssen einige manuelle Konfigurationen vorgenommen werden. Zunächst muss die Option ibm-load-balancer-cloud-provider-vpc-port-range eingestellt werden. Sie kann einen oder mehrere Bereiche enthalten, die jeweils durch ein Komma getrennt sind. Der Wert spec.ports.port muss ebenfalls auf den Mindestwert im Anschlussbereich eingestellt werden.

Im folgenden Beispiel wird ein Anschlussbereich von 30000-30010 verwendet.

Nodeport-Dienste müssen für jeden Einsatz, bei dem der NLB-Dienst die Anfrage weiterleitet, manuell erstellt werden. Die Portnummer jedes dieser Nodeport-Dienste muss innerhalb des Portbereichs liegen, der im NLB-Dienst konfiguriert ist.

Im folgenden Beispieldiagramm wird ein Nodeport-Dienst mit Port 30000 für Einsatz 1 und ein Nodeport-Dienst mit Port 30001 für Einsatz 2 erstellt.

Der Benutzer stellt eine Anfrage an Port 30001 des NLB, der den Portbereich enthält. Diese Anfrage wird an den VPC-NLB-Dienst gerichtet, der die Anfrage an den Nodeport-Dienst im Cluster weiterleitet, der ebenfalls auf Port 30001 hört, in diesem Fall für Einsatz 2. Der Nodeport-Dienst leitet die Anfrage dann an den Zielport der ausgewählten Pods von Einsatz 2 weiter.

Erstellen Sie einen NLB, der einen Portbereich verwendet, anhand des folgenden Beispiels. Die Selektor- und Backend-Pods müssen mit dem Lastausgleichsdienst für den Portbereich verknüpft werden, damit die Zustandsprüfungen erfolgreich sind und die Daten an die Ports im Portbereich geliefert werden. Um den Portbereich zu nutzen, müssen Sie zusätzliche NodePort Dienste erstellen, deren Portwerte in dem Bereich liegen, der durch den Load Balancer-Dienst definiert ist.

1. Speichern Sie die folgende Beispielkonfiguration LoadBalancer 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 Dienst.

   oc apply -f loadbalancer.yaml
   

3. Erstellen Sie einen NodePort-Dienst mit Anschlusswerten, die in dem Anschlussbereich liegen, der in der zuvor erstellten LoadBalancer angegeben ist.

   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. Um auf einen Port zuzugreifen, der in dem von NLB bereitgestellten Bereich liegt.

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

   • 30003 = Ist ein Knotenport im Bereich, der auf eine Anfrage antwortet
   • Andere Ports in diesem Bereich reagieren nicht, es sei denn, es werden zusätzliche Knotenportdienste erstellt.

Erforderliche Vermerke und Spezifikationen

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

Anleitung zum Erstellen eines VPC-NLB. Wenn Sie diesen Vermerk nicht einfügen und nlb angeben, wird standardmäßig ein VPC ALB erstellt.

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

(Erforderlich für private NLBs) Anmerkung zur Angabe eines Dienstes, der private Anfragen akzeptiert. Wenn diese Anmerkung nicht enthalten ist, wird ein öffentlicher VPC NLB erstellt.

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

(Erforderlich für private NLBs, optional für öffentliche NLBs) Anmerkung zur Angabe des dedizierten Subnetzes, in dem die VPC NLB eingesetzt wird. 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_ID --zone ZONE aus.

externalTrafficPolicy

Geben Sie Local oder Cluster an.

Definieren Sie diesen Parameter mit Local, um die Quellen-IP-Adresse von Clientanforderungen an Ihre Apps beizubehalten. Diese Einstellung verhindert, dass der eingehende Verkehr an einen anderen Knoten weitergeleitet wird. Diese Option konfiguriert auch HTTP-Statusprüfungen.

Wenn der Wert Cluster festgelegt ist, wird DSR nur über den ersten Workerknoten implementiert, an den die VPC-NLB die eingehende Anforderung zu Anfang weiterleitet. Nachdem die eingehende Anfrage eingetroffen ist, wird sie an einen Arbeitsknoten weitergeleitet, der den App-Pod enthält, der sich in einer anderen Zone befinden kann. 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 vom Typ „ UDP “ ist der „ service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp “ erforderlich, wenn Sie die Option „ Cluster “ wählen. Weitere Informationen finden Sie unter „ Konfigurieren von TCP-Zustandsprüfungen für UDP-Lastverteiler “.

Optionale Anmerkungen und Spezifikationen

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

Geben Sie einen eindeutigen Namen an, um Ihren VPC-Loadbalancer beständig zu machen. Persistente VPC-Loadbalancer werden nicht gelöscht, wenn der Cluster, zu dem sie gehören, gelöscht wird. Weitere Informationen finden Sie unter Persistente VPC-Loadbalancer. Dieser Vermerk kann nur bei der Erstellung des Load Balancers gesetzt werden. Sie kann nicht in einem Aktualisierungsvorgang verwendet werden.

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

Annotation zur Angabe einer VPC-Zone, der Ihr Cluster zugeordnet ist. Die VPC-NLB wird in demselben Teilnetz der betreffenden Zone bereitgestellt, mit dem auch Ihre Workerknoten verbunden sind. Wenn Sie diese Anmerkung später in eine andere Zone ändern, wird die VPC-NLB nicht in die neue Zone verschoben. Wenn Sie diese Anmerkung oder die service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets annotation nicht angeben, wird die VPC NLB in der optimalsten Zone bereitgestellt (z. B. in einer Zone mit Arbeitsknoten im Zustand Ready ). Wenn das Label dedicated: edge auf Worker-Knoten gesetzt ist und Sie diese Anmerkung angeben, werden nur Edge-Knoten in der angegebenen Zone so konfiguriert, dass sie Datenverkehr empfangen. Edge-Knoten in anderen Zonen und Nicht-Edge-Knoten in der angegebenen Zone empfangen keinen Datenverkehr von der Lastausgleichsfunktion. Führen Sie zum Anzeigen von Zonen den Befehl ibmcloud ks zone ls --provider vpc-gen2 aus.

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

Anmerkung zur Festlegung eines Selektors für Worker-Knoten-Labels. Sie können bestimmte Arbeitsknoten in Ihrem Cluster für den Empfang von Datenverkehr konfigurieren, indem Sie Label-Selektorschlüssel angeben. Sie dürfen nur einen Label-Selektor in die Anmerkung aufnehmen, und dieser Selektor muss im Format "key=value" angegeben werden. Wenn diese Anmerkung nicht angegeben ist, sind alle Worker-Knoten in Ihrem Cluster so konfiguriert, dass sie Datenverkehr vom VPC-NLB empfangen. Diese Anmerkung hat Vorrang vor der Anmerkung service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, und alle Labels dedicated: edge auf Worker-Knoten werden ignoriert. Um den Datenverkehr auf eine bestimmte Zone zu beschränken, können Sie diese Anmerkung verwenden, um Arbeitsknoten in dieser Zone anzugeben. Beachten Sie, dass das Festlegen eines neuen Labels auf einem Cluster-Arbeitsknoten den Arbeitsknoten nicht automatisch für den Empfang von Datenverkehr konfiguriert; Sie müssen den VPC NLB neu erstellen oder aktualisieren, damit der neu gelabelte Arbeitsknoten Datenverkehr empfangen kann.

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

Der TCP-Knotenport, der für TCP-Zustandsprüfungen in einem UDP-Lastenausgleicher verwendet werden soll. 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

Diese Anmerkung legt das Protokoll für die Zustandsprüfung der VPC-Load-Balancer-Ressource fest, die mit dem Kubernetes Load-Balancer-Dienst verbunden ist. Verfügbare Optionen sind http, https, oder tcp. Normalerweise wird das VPC LB-Zustandsprüfungsprotokoll durch den Wert der externalTrafficPolicy-Einstellung in der Kubernetes Load Balancer-Service-Spezifikation bestimmt. Mit dieser Anmerkung wird diese Logik jedoch außer Kraft gesetzt. Diese Anmerkung ändert nichts daran, wie sich Kubernetes und insbesondere kube-proxy in Bezug auf die verschiedenen Einstellungen von externalTrafficPolicy verhält.

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

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 der „ 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. Weitere Informationen finden Sie unter Verstehen von standardmäßig sicheren Cluster-VPC-Netzwerken und Erstellen und Verwalten von VPC-Sicherheitsgruppen.

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

Der Pfad für die Gesundheitsprüfung URL für HTTP und HTTPs Gesundheitsprüfungen. Dieser Vermerk gilt nur, wenn ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist. Der Pfad URL muss das Format eines origin-form request target haben. Wenn dieser Vermerk nicht angegeben wird und der Vermerk ibm-load-balancer-cloud-provider-vpc-health-check-protocol 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 eingestellt und hat ein Minimum von 2 und ein Maximum von 60. Dieser Wert muss größer sein als der Wert ibm-load-balancer-cloud-provider-vpc-health-check-timeout, der standardmäßig auf 2 eingestellt 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 eingestellt und hat ein Minimum von 1 und ein Maximum von 59. Dieser Wert muss kleiner sein als der Wert ibm-load-balancer-cloud-provider-vpc-health-check-delay, der standardmäßig auf 5 eingestellt 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 eingestellt und hat ein Minimum von 1 und ein Maximum von 10.

service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"

Versionen- 4.16 oder höher.

Registrieren Sie die IP-Adresse des Load Balancers mit der angegebenen Ingress-Domäne. Wenn die angegebene Domäne nicht existiert, wird eine Domäne erstellt, die den internen, von IBM verwalteten Anbieter (IBM NS1) verwendet. Um eine neue Domäne zu erstellen, muss der Name in allen vorhandenen Domänen (nicht nur in denen Ihres Clusters) eindeutig sein. Durch das Löschen des Load Balancer-Dienstes wird die IP-Adresse aus der Domäne entfernt. Durch das Entfernen der Anmerkung wird die IP-Adresse jedoch nicht aus der Domäne entfernt.

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 Worker-Knoten in drei Zonen führt dies dazu, dass der Load Balancer die Last auf insgesamt 24 Worker-Knoten verteilt. 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

Versionen 1.30 und höher.

Optional. Eine vom Kunden verwaltete Sicherheitsgruppe, die dem VPC-Loadbalancer hinzugefügt wird. Wenn Sie die Sicherheitsgruppe IBM-managed nicht verwenden möchten, geben Sie eine Sicherheitsgruppe an, die Sie besitzen und verwalten. Diese Option entfernt die Sicherheitsgruppe IBM-managed 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 Sicherheitsgruppe IBM-managed 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.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic

Verfügbar für Cluster, die Secure by Default ausführen. Anmerkung, um Sicherheitsgruppen für jede IP-Adresse eines ALB zu erstellen, die mit einem von Ihnen angegebenen externen Port verbunden ist. Diese Regeln werden in der Sicherheitsgruppe des Clusters erstellt. Geben Sie gültige externe Ports in einer kommagetrennten Liste an, z. B. 80,443. Wenn in diesem Beispiel jeder öffentliche ALB, der mit jedem externen Portwert verbunden ist, zwei IP-Adressen hat, wird eine ausgehende Regel pro IP-Adresse erstellt, was insgesamt 4 neue Regeln ergibt. Sie können diesen Vermerk jederzeit hinzufügen oder entfernen.

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 ist oft statisch im Image definiert, das im Anwendungs-Pod läuft. Der im Pod konfigurierte Zielport unterscheidet sich vom Knotenport für den Dienst und kann sich auch vom externen Port unterscheiden, der auf der VPC LB konfiguriert ist.