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. Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
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, beispielsweise über eine VPC VPN-Verbindung.
5. Für private VPC NLBs: Aktivieren Sie Ihre Anwendung, um private Netzwerkanfragen zu empfangen.
   1. Erstellen Sie ein VPC-Subnetz, das für Ihren VPC NLB bestimmt 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 der Client, der sich über die VPC NLB mit Ihrer Anwendung verbindet, außerhalb der VPC und der Zone Ihres dedizierten VPC-Subnetzes liegt, 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 LoadBalancer-Dienst

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. In der YAML-Datei geben Sie die service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type-Anmerkung 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.

   kubectl 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.

   kubectl describe svc myloadbalancer -n <namespace>
   

   CLI-Beispielausgabe für einen öffentlichen LoadBalancer-Service:

   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 gesetzt werden. Sie kann einen oder mehrere Bereiche enthalten, die jeweils durch ein Komma getrennt sind. Der spec.ports.port-Wert muss ebenfalls auf den Mindestwert im Anschlussbereich gesetzt 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 in einer 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.

   kubectl apply -f loadbalancer.yaml
   

3. Erstellen Sie einen NodePort-Dienst mit Port-Werten, die in dem Port-Bereich liegen, den Sie in dem zuvor erstellten LoadBalancer angegeben haben.

   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.

   kubectl 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 Knotenanschluss 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"

Anmerkung zur Erstellung eines VPC NLB. Wenn Sie diesen Vermerk nicht einfügen und nlb angeben, wird standardmäßig eine 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 annimmt. 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 ks subnets --provider vpc-gen2 --vpc-id <vpc> --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 UDP-Loadbalancern ist 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 Konfiguration 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 Arbeiterknoten eingestellt ist und Sie diese Anmerkung 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. 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 Angabe eines Selektors für die Beschriftung von Arbeitsknoten. Sie können bestimmte Arbeitsknoten in Ihrem Cluster für den Empfang von Datenverkehr konfigurieren, indem Sie Label-Selektorschlüssel angeben. Sie können nur einen Bezeichnungsselektor in die Anmerkung aufnehmen, und der Selektor muss im Format "key=value" angegeben werden. Wenn diese Anmerkung nicht angegeben wird, sind alle Arbeitsknoten in Ihrem Cluster so konfiguriert, dass sie Verkehr vom VPC NLB empfangen. Dieser Vermerk hat Vorrang vor dem Vermerk service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, und alle dedicated: edge Beschriftungen von Arbeitsknoten 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-Loadbalancer 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

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-Dienstspezifikation bestimmt. Mit dieser Anmerkung wird diese Logik jedoch außer Kraft gesetzt. 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

Der TCP-Port, der für die Gesundheitsprüfungen verwendet wird. Dieser Vermerk gilt nur, wenn auch ibm-load-balancer-cloud-provider-vpc-health-check-protocol angegeben ist. Wenn der angegebene TCP-Port außerhalb des Kubernetes-Knoten-Portbereichs (30.000-32.767) liegt, muss die VPC-Sicherheitsgruppe, die auf die Cluster-Arbeitsknoten angewendet wird, geändert werden, um eingehenden Verkehr auf dem Port zuzulassen. Wenn diese Anmerkung auf einen Kubernetes-Load-Balancer-Dienst angewendet wird, der mit einem VPC ALB verbunden ist, müssen die ausgehenden Regeln der Sicherheitsgruppe, die dem VPC ALB zugewiesen ist, geändert werden, um ausgehenden Verkehr zum angegebenen TCP-Port zuzulassen.

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. 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 eines origin-form request target 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, 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.

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

Version 1.30 oder höher.

Registrieren Sie die IP-Adresse des Load Balancer mit der angegebenen Ingress-Domäne. Wenn die angegebene Domäne nicht existiert, wird eine Domäne erstellt, die den internen, IBM verwalteten Anbieter (akamai) 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 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

Version 1.30 und höher.

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.

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 laufende Anwendung muss auf diesem Zielport auf eingehenden TCP-Verkehr 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.