Klassisch: DSR-Lastausgleich mit einer NLB 2.0 einrichten

NLBs der Version 2.0 können nur in klassischen Clustern und nicht in VPC-Clustern erstellt werden. Wie der Lastausgleich in VPC-Clustern erfolgt, erfahren Sie unter Apps mit Lastausgleichsfunktionen für VPC zugänglich machen.

Machen Sie einen Port zugänglich und verwenden Sie eine portierbare IP-Adresse für die Layer 4-Netzlastausgleichsfunktion (NLB), um eine containerisierte App zugänglich zu machen. Weitere Informationen zu NLBs der Version 2.0 finden Sie unter Komponenten und Architektur eines NLB der Version 2.0.

Voraussetzungen

Sie können eine vorhandene NLB der Version 1.0 nicht auf 2.0 aktualisieren. Sie müssen eine neue NLB mit der Version 2.0 erstellen. Beachten Sie, dass Sie NLBs der Version 1.0 und 2.0 gleichzeitig in einem Cluster ausführen können.

Bevor Sie eine NLB der Version 2.0 erstellen, müssen Sie die folgenden vorausgesetzten Schritte ausführen.

Damit Ihre NLB der Version 2.0 Anforderungen an App-Pods in mehreren Zonen weiterleiten kann, öffnen Sie einen Supportfall, um eine Kapazitätsaggregation für Ihre VLANs anzufordern. Diese Konfigurationseinstellung verursacht keine Netzfehler oder -ausfälle.
1. Melden Sie sich bei der IBM Cloud -Konsole an.
2. Klicken Sie in der Menüleiste auf Support, klicken Sie auf die Registerkarte Fälle verwalten und klicken Sie auf Neuen Fall erstellen.
3. Geben Sie in die Fallfelder die folgenden Informationen ein: Thema: Netzbereitstellung Unterthema: Classic-VLAN
4. Fügen Sie die folgenden Informationen zur Beschreibung hinzu: Please set up the network to allow capacity aggregation on the public and private VLANs associated with my account. This is related to /docs/containers?topic=containers-loadbalancer-v2#ipvs_provision, and is needed so I can configure NLB v2.0 LoadBalancers in my Classic Kubernetes Cluster.. Wenn Sie die Kapazitätsaggregation für bestimmte VLANs erlauben wollen, z. B. die öffentlichen VLANs für nur einen Cluster, können Sie diese VLAN-IDs in der Beschreibung angeben.
5. Klicken Sie auf Übergeben.
Aktivieren Sie eine VRF-Funktion (Virtual Router Function) für Ihr IBM Cloud-Infrastrukturkonto. Informationen zum Aktivieren von VRF finden Sie im Abschnitt VRF aktivieren. Mit dem Befehl ibmcloud account show können Sie überprüfen, ob VRF bereits aktiviert ist. Wenn Sie VRF nicht aktivieren können oder möchten, aktivieren Sie VLAN-Spanning. Wenn VRF- oder VLAN Spanning aktiviert ist, kann die NLB der Version 2.0 Pakete an verschiedene Teilnetz im Konto weiterleiten.
Wenn Sie pre-DNAT-Netzrichtlinien von Calico zum Verwalten des Datenverkehrs zu einer NLB 2.0 verwenden, müssen Sie die Felder applyOnForward: true und doNotTrack: true zum Abschnitt preDNAT: true hinzufügen und aus dem Abschnitt spec in den Richtlinien entfernen. applyOnForward: true stellt sicher, dass die Calico-Richtlinie auf den gekapselten und weitergeleiteten Datenverkehr angewendet wird. doNotTrack: true stellt sicher, dass die Workerknoten mithilfe von DSR ein Antwortpaket direkt an den Client zurückgeben können, ohne dass die Verbindung verfolgt werden muss. Wenn Sie beispielsweise eine Calico-Richtlinie verwenden, damit nur von spezifischen IP-Adressen Datenverkehr an Ihre NLB-IP-Adresse zugelassen wird, sieht die Richtlinie wie folgt aus:
```
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allowlist
spec:
  applyOnForward: true
  doNotTrack: true
  ingress:
  - action: Allow
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source:
      nets:
      - <client_address>/32
  selector: ibm.role=='worker_public'
  order: 500
  types:
  - Ingress
```

Jetzt können Sie die Schritte unter NLB der Version 2.0 in einem Mehrzonencluster konfigurieren bzw. in einem Einzelzonencluster konfigurieren ausführen.

NLB der Version 2.0 in einem Mehrzonencluster konfigurieren

Vorbereitende Schritte:

Wichtig: Erfüllen Sie die Voraussetzungen für die NLB der Version 2.0.
Um öffentliche NLBs in mehreren Zonen zu erstellen, muss mindestens ein öffentliches VLAN portierbare Teilnetze aufweisen, die in jeder Zone verfügbar sind. Um private NLBs in mehreren Zonen zu erstellen, muss mindestens ein privates VLAN portierbare Teilnetze aufweisen, die in jeder Zone verfügbar sind. Sie können Teilnetze hinzufügen, indem Sie die Schritte im Abschnitt Teilnetze für Cluster konfigurieren ausführen.
Stellen Sie sicher, dass Sie über die Writer- oder Manager IBM Cloud IAM-Service-Zugriffsrolle für den default Namespace haben.
Stellen Sie sicher, dass Sie über die erforderliche Anzahl von Workerknoten verfügen:
- Klassische Cluster: Wenn Sie den Datenaustausch im Netz auf Edge-Workerknoten beschränken, stellen Sie sicher, dass in jeder Zone mindestens zwei Edge-Workerknoten aktiviert sind, sodass die NLBs gleichmäßig bereitgestellt werden.
Wenn Clusterknoten erneut geladen werden oder wenn eine Cluster-Master-Aktualisierung ein neues keepalived-Image enthält, wird die virtuelle IP-Adresse der Lastausgleichsfunktion in die Netzschnittstelle eines neuen Knotens verschoben. In diesem Fall müssen alle langlebigen Verbindungen zu Ihrer Lastausgleichsfunktion wiederhergestellt werden. Ziehen Sie in Erwägung, eine Wiederholungslogik in Ihre Anwendung einzubauen, damit die Versuche, die Verbindung wiederherzustellen, schnell durchgeführt werden.

Gehen Sie wie folgt vor, um eine NLB der Version 2.0 in einem Mehrzonencluster einzurichten:

Stellen Sie die App im Cluster bereit. Stellen Sie sicher, dass Sie zur Bereitstellung im Metadatenabschnitt der Konfigurationsdatei 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.
Erstellen Sie einen Lastausgleichsservice für die App, die Sie über das öffentliche Internet oder ein privates Netz zugänglich machen wollen.
1. Erstellen Sie eine Servicekonfigurationsdatei namens myloadbalancer.yaml (Beispiel).
2. Definieren Sie einen Lastausgleichsservice für die App, die Sie zugänglich machen möchten. Sie können eine Zone, ein VLAN und eine IP-Adresse angeben.
```
apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
    service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
spec:
 type: LoadBalancer
 selector:
   <selector_key>: <selector_value>
 ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
 loadBalancerIP: <IP_address>
 externalTrafficPolicy: Local
```
  service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type:
  
  Annotation zur Angabe einer private- oder public-Lastausgleichsfunktion.
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-zone:
  
  Annotation zum Angeben der Zone, in der der Lastausgleichsservice bereitgestellt wird. Führen Sie zum Anzeigen von Zonen den Befehl ibmcloud ks zone ls aus.
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan:
  
  Annotation zum Angeben eines VLAN, in dem der Lastausgleichsservice bereitgestellt wird. Führen Sie zum Anzeigen von VLANs den Befehl ibmcloud ks vlan ls --zone <zone> aus.
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  
  Annotation zum Angeben einer Lastausgleichsfunktion der Version 2.0.
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler:
  
  Optional: Annotation zum Angeben eines Planungsalgorithmus. Akzeptierte Werte sind "rr" für Round-Robin (Standard) oder "sh" für Source Hashing. Weitere Informationen finden Sie unter v2.0: Planungsalgorithmen.
  
  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.
  
  port
  
  Der Port, den der Service überwacht.
  
  loadBalancerIP
  
  Optional: Um eine private NLB zu erstellen oder um eine bestimmte portierbare IP-Adresse für eine öffentliche NLB zu verwenden, geben Sie die IP-Adresse an, die Sie verwenden wollen. Die IP-Adresse muss sich in der Zone und dem VLAN befinden, die Sie in den Annotationen angeben. Wenn Sie keine IP-Adresse angeben: Wenn sich Ihr Cluster in einem öffentlichen VLAN befindet, wird eine portierbare öffentliche IP-Adresse verwendet. Die meisten Cluster befinden sich in einem öffentlichen VLAN. Wenn sich Ihr Cluster nur in einem privaten VLAN befindet, wird eine portierbare private IP-Adresse verwendet.
  
  externalTrafficPolicy: Local
  
  Wird auf Local festgelegt.
  
  Beispielkonfigurationsdatei zur Erstellung eines NLB 2.0 in dal12, der den Round-Robin-Planungsalgorithmus verwendet:
```
apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "rr"
spec:
  type: LoadBalancer
   selector:
     app: nginx
   ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
   externalTrafficPolicy: Local
```
3. Optional: Machen Sie Ihren NLB-Service nur für einen begrenzten Bereich von IP-Adressen verfügbar, indem Sie die IP-Adressen im Feld spec.loadBalancerSourceRanges angeben. loadBalancerSourceRanges wird von kube-proxy über Iptables-Regeln auf Workerknoten in Ihrem Cluster implementiert. Weitere Informationen finden Sie in der Kubernetes.
4. Erstellen Sie den Service in Ihrem Cluster.
```
kubectl apply -f myloadbalancer.yaml
```

Stellen Sie sicher, dass der NLB-Service erfolgreich erstellt wurde. Es kann einige Minuten dauern, bis der NLB-Service ordnungsgemäß erstellt wurde und die App verfügbar ist.

kubectl describe service myloadbalancer

CLI-Beispielausgabe:

NAME:                   myloadbalancer
Namespace:              default
Labels:                 <none>
Selector:               app=liberty
Type:                   LoadBalancer
Zone:                   dal10
IP:                     172.21.xxx.xxx
LoadBalancer Ingress:   169.xx.xxx.xxx
Port:                   <unset> 8080/TCP
NodePort:               <unset> 32040/TCP
Endpoints:              172.30.xxx.xxx:8080
Session Affinity:       None
Events:
    FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
    ---------    --------    -----    ----            -------------    ----     ------                      -------
    10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
    10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer

Die IP-Adresse für LoadBalancer Ingress ist die portierbare IP-Adresse, die dem NLB-Service zugewiesen wurde.

Wenn Sie eine öffentliche NLB erstellt haben, dann greifen Sie über das Internet auf Ihre App zu.
1. Öffnen Sie Ihren bevorzugten Web-Browser.
2. Geben Sie die portierbare öffentliche IP-Adresse der NLB und des Ports ein.
```
http://169.xx.xxx.xxx:8080
```
Um eine hohe Verfügbarkeit zu erreichen, wiederholen Sie die Schritte 2 bis 4, um eine NLB der Version 2.0 in jeder Zone bereitstellen, in der sich App-Instanzen befinden.
Optional: Ein NLB-Service macht Ihre App auch über die NodePort-Instanzen des Service verfügbar. Auf Knotenports (NodePorts) kann über jede öffentliche und private IP-Adresse für jeden Knoten innerhalb des Clusters zugegriffen werden. Informationen zum Blockieren des Datenverkehrs an Knotenports während der Verwendung eines NLB-Service finden Sie im Abschnitt Eingehenden Datenverkehr an Netzlastausgleichsfunktion (NLB) oder NodePort-Services steuern.

Als Nächstes können Sie eine NLB-Unterdomäne registrieren.

NLB der Version 2.0 in einem Einzelzonencluster konfigurieren

Vorbereitende Schritte:

Wichtig: Erfüllen Sie die Voraussetzungen für die NLB der Version 2.0.
Es muss eine portierbare öffentliche oder private IP-Adresse verfügbar sein, die dem NLB-Service zugewiesen werden kann. Weitere Informationen finden Sie unter Teilnetze für Cluster konfigurieren.
Stellen Sie sicher, dass Sie über die Writer- oder Manager IBM Cloud IAM-Service-Zugriffsrolle für den default Namespace haben.
Wenn Clusterknoten erneut geladen werden oder wenn eine Cluster-Master-Aktualisierung ein neues keepalived-Image enthält, wird die virtuelle IP-Adresse der Lastausgleichsfunktion in die Netzschnittstelle eines neuen Knotens verschoben. In diesem Fall müssen alle langlebigen Verbindungen zu Ihrer Lastausgleichsfunktion wiederhergestellt werden. Ziehen Sie in Erwägung, eine Wiederholungslogik in Ihre Anwendung einzubauen, damit die Versuche, die Verbindung wiederherzustellen, schnell durchgeführt werden.

Gehen Sie wie folgt vor, um einen NLB-Service der Version 2.0 in einem Einzelzonencluster zu erstellen:

Stellen Sie die App im Cluster bereit. Stellen Sie sicher, dass Sie zur Bereitstellung im Metadatenabschnitt der Konfigurationsdatei eine Bezeichnung hinzufügen. Diese Bezeichnung ist zur Identifizierung aller Pods erforderlich, in denen Ihre App ausgeführt wird, damit sie in den Lastausgleich aufgenommen werden können.
Erstellen Sie einen Lastausgleichsservice für die App, die Sie über das öffentliche Internet oder ein privates Netz zugänglich machen wollen.
1. Erstellen Sie eine Servicekonfigurationsdatei namens myloadbalancer.yaml (Beispiel).
2. Definieren Sie einen Lastausgleichsservice der Version 2.0 für die App, die Sie zugänglich machen möchten.
```
apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
spec:
  type: LoadBalancer
  selector:
    <selector_key>: <selector_value>
  ports:
   - protocol: TCP
     port: 8080
     targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
  loadBalancerIP: <IP_address>
  externalTrafficPolicy: Local
```
  service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type:
  
  Annotation zur Angabe einer private- oder public-Lastausgleichsfunktion.
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan:
  
  Optional: Annotation zum Angeben eines VLAN, in dem der Lastausgleichsservice bereitgestellt wird. Führen Sie zum Anzeigen von VLANs den Befehl ibmcloud ks vlan ls --zone <zone> aus.
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  
  Annotation zum Angeben einer Lastausgleichsfunktion der Version 2.0.
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler:
  
  Optional: Annotation zum Angeben eines Planungsalgorithmus. Akzeptierte Werte sind "rr" für Round-Robin (Standard) oder "sh" für Source Hashing. Weitere Informationen finden Sie unter v2.0: Planungsalgorithmen.
  
  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.
  
  port
  
  Der Port, den der Service überwacht.
  
  loadBalancerIP
  Optional: Um eine private NLB zu erstellen oder um eine bestimmte portierbare IP-Adresse für eine öffentliche NLB zu verwenden, geben Sie die IP-Adresse an, die Sie verwenden wollen. Die IP-Adresse muss sich in dem VLAN befinden, das Sie in den Annotationen angeben. Wenn Sie keine IP-Adresse angeben, geschieht Folgendes:
  - Wenn sich Ihr Cluster in einem öffentlichen VLAN befindet, dann wird eine portierbare öffentliche IP-Adresse verwendet. Die meisten Cluster befinden sich in einem öffentlichen VLAN.
  - Wenn sich Ihr Cluster nur in einem privaten VLAN befindet, wird eine portierbare private IP-Adresse verwendet.
  externalTrafficPolicy: Local
  
  Wird auf Local festgelegt.
3. Optional: Machen Sie Ihren NLB-Service nur für einen begrenzten Bereich von IP-Adressen verfügbar, indem Sie die IP-Adressen im Feld spec.loadBalancerSourceRanges angeben. loadBalancerSourceRanges wird von kube-proxy über Iptables-Regeln auf Workerknoten in Ihrem Cluster implementiert. Weitere Informationen finden Sie in der Kubernetes.
4. Erstellen Sie den Service in Ihrem Cluster.
```
kubectl apply -f myloadbalancer.yaml
```

Stellen Sie sicher, dass der NLB-Service erfolgreich erstellt wurde. Es kann ein paar Minuten dauern, bis der Service erstellt wurde und die App verfügbar ist.

kubectl describe service myloadbalancer

CLI-Beispielausgabe:

NAME:                   myloadbalancer
Namespace:              default
Labels:                 <none>
Selector:               app=liberty
Type:                   LoadBalancer
Location:               dal10
IP:                     172.21.xxx.xxx
LoadBalancer Ingress:   169.xx.xxx.xxx
Port:                   <unset> 8080/TCP
NodePort:               <unset> 32040/TCP
Endpoints:              172.30.xxx.xxx:8080
Session Affinity:       None
Events:
    FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
    ---------    --------    -----    ----            -------------    ----     ------                      -------
    10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
    10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer

Die IP-Adresse für LoadBalancer Ingress ist die portierbare IP-Adresse, die dem NLB-Service zugewiesen wurde.

Wenn Sie eine öffentliche NLB erstellt haben, dann greifen Sie über das Internet auf Ihre App zu.
1. Öffnen Sie Ihren bevorzugten Web-Browser.
2. Geben Sie die portierbare öffentliche IP-Adresse der NLB und des Ports ein.
```
http://169.xx.xxx.xxx:8080
```
Optional: Ein NLB-Service macht Ihre App auch über die NodePort-Instanzen des Service verfügbar. Auf Knotenports (NodePorts) kann über jede öffentliche und private IP-Adresse für jeden Knoten innerhalb des Clusters zugegriffen werden. Informationen zum Blockieren des Datenverkehrs an Knotenports während der Verwendung eines NLB-Service finden Sie im Abschnitt Eingehenden Datenverkehr an Netzlastausgleichsfunktion (NLB) oder NodePort-Services steuern.

Als Nächstes können Sie eine NLB-Unterdomäne registrieren.

Planungsalgorithmen

Planungsalgorithmen bestimmen, wie eine NLB der Version 2.0 Ihren App-Pods Netzverbindungen zuordnet. Wenn Clientanforderungen in Ihrem Cluster eingehen, leitet die NLB die Anforderungspakete auf der Basis des Planungsalgorithmus an Workerknoten weiter. To use a scheduling algorithm, specify its Keepalived short name in the scheduler annotation of your NLB service configuration file: service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "rr". In der folgenden Liste finden Sie die Planungsalgorithmen, die in IBM Cloud Kubernetes Service unterstützt werden. Wenn Sie keinen Planungsalgorithmus angeben, wird standardmäßig der Round-Robin-Algorithmus verwendet. Weitere Informationen finden Sie in der Keepalived Dokumentation.

Unterstützte Planungsalgorithmen

Umlauf (rr): Die NLB durchläuft die Liste der App-Pods, wenn Verbindungen an Workerknoten weitergeleitet werden, wobei jeder App-Pod gleich behandelt wird. Round-Robin ist der Standardplanungsalgorithmus für NLBs der Version 2.0.
Quellen-Hashing (sh): Die NLB generiert einen Hashschlüssel basierend auf der Quellen-IP-Adresse des Clientanforderungspakets. Anschließend sucht die NLB den Hashschlüssel in einer statisch zugeordneten Hashtabelle und leitet die Anforderung an den App-Pod weiter, der die Hashes dieses Bereichs verarbeitet. Dieser Algorithmus stellt sicher, dass Anforderungen von einem bestimmten Client immer an denselben App-Pod übertragen werden. Kubernetes verwendet IPtables-Regeln, die bewirken, dass Anforderungen an einen zufälligen Pod auf dem Worker gesendet werden. Um diesen Planungsalgorithmus zu verwenden, müssen Sie sicherstellen, dass pro Workerknoten nicht mehr als ein Pod Ihrer App bereitgestellt wird. Wenn jeder Pod beispielsweise die Bezeichnung run=<app_name> hat, fügen Sie die folgende Regel für Anti-Affinität zum Abschnitt spec Ihrer App-Bereitstellung hinzu:

spec:
  affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: run
            operator: In
            values:
            - <APP_NAME>
        topologyKey: kubernetes.io/hostname

Nicht unterstützte Planungsalgorithmen

Ziel-Hashing (dh)

Das Ziel des Pakets, d. h. die IP-Adresse und der Port der NLB, wird verwendet, um zu bestimmen, welcher Workerknoten die eingehende Anforderung verarbeitet. Allerdings ändern sich die IP-Adresse und der Port für NLBs in IBM Cloud Kubernetes Service nicht. Die NLB ist gezwungen, die Anforderung innerhalb desselben Workerknotens zu behalten, auf dem sie sich befindet, sodass nur die App-Pods eines einzelnen Workerknotens alle eingehenden Anforderungen verarbeiten.

Dynamische Verbindungszählalgorithmen

Die folgenden Algorithmen sind von der dynamischen Zählung der Verbindungen zwischen Clients und NLBs abhängig. Da DSR (Direct Service Return) jedoch verhindert, dass Pods von NLBs der Version 2.0 im Rückgabepaketpfad vorhanden sind, verfolgen NLBs keine eingerichteten Verbindungen.

Geringste Verbindung (lc)
Standortbasierte geringste Verbindung (lblc)
Standortbasierte geringste Verbindung mit Replikation (lblcr)
Nie in die Warteschlange stellen (nq)
Kürzeste erwartete Verzögerung (seq)

Gewichtete Pod-Algorithmen

Die folgenden Algorithmen hängen von gewichteten App-Pods ab. In IBM Cloud Kubernetes Service haben aber alle App-Pods dieselbe Gewichtung für den Lastausgleich.

Gewichtete geringste Verbindung (wlc)
Gewichteter Umlauf (wrr)