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.
- Melden Sie sich bei der IBM Cloud -Konsole an.
- Klicken Sie in der Menüleiste auf Support, klicken Sie auf die Registerkarte Fälle verwalten und klicken Sie auf Neuen Fall erstellen.
- Geben Sie in die Fallfelder die folgenden Informationen ein: Thema: Netzbereitstellung Unterthema: Classic-VLAN
- 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. - 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
unddoNotTrack: true
zum AbschnittpreDNAT: true
hinzufügen und aus dem Abschnittspec
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.
-
Erstellen Sie eine Servicekonfigurationsdatei namens
myloadbalancer.yaml
(Beispiel). -
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
- oderpublic
-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 Abschnittspec.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
-
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 vonkube-proxy
über Iptables-Regeln auf Workerknoten in Ihrem Cluster implementiert. Weitere Informationen finden Sie in der Kubernetes. -
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.
-
Öffnen Sie Ihren bevorzugten Web-Browser.
-
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.
-
Erstellen Sie eine Servicekonfigurationsdatei namens
myloadbalancer.yaml
(Beispiel). -
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
- oderpublic
-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 Abschnittspec.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.
-
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 vonkube-proxy
über Iptables-Regeln auf Workerknoten in Ihrem Cluster implementiert. Weitere Informationen finden Sie in der Kubernetes. -
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.
-
Öffnen Sie Ihren bevorzugten Web-Browser.
-
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 Abschnittspec
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
)
- Geringste Verbindung (
- 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
)
- Gewichtete geringste Verbindung (