Verwenden einer öffentlichen Instanz von Load Balancer Standard in Azure Kubernetes Service (AKS)

  • Artikel

Azure Load Balancer befindet sich auf der Schicht 4 des OSI-Modells (Open Systems Interconnection), die sowohl Ein- als auch Ausgangsszenarien unterstützt. Mit dieser Lösung werden Datenflüsse, die beim Front-End des Lastenausgleichs eingehen, auf die Instanzen des Back-End-Pools verteilt.

Ein öffentlicher in AKS integrierter Lastenausgleich dient zwei Zwecken:

  1. Bereitstellen ausgehender Verbindungen mit den Clusterknoten innerhalb des virtuellen AKS-Netzwerks durch Übersetzen der privaten IP-Adresse in eine öffentliche IP-Adresse, die Teil des ausgehenden Pools ist
  2. Ermöglichen des Zugriffs auf Anwendungen über Kubernetes-Dienste vom Typ LoadBalancer für eine einfache Skalierung Ihrer Anwendungen und die Erstellung hoch verfügbarer Dienste

Ein internes (oder privates) Lastenausgleichsmodul wird verwendet, wenn nur private IP-Adressen als Front-End zulässig sind. Interne Lastenausgleichsmodule werden verwendet, um einen Lastausgleich für Datenverkehr innerhalb eines virtuellen Netzwerks vorzunehmen. Auf ein Lastenausgleichs-Front-End kann auch über ein lokales Netzwerk in einem Hybridszenario zugegriffen werden.

In diesem Artikel wird die Integration mit einem öffentlichen Lastenausgleichsmodul in AKS behandelt. Informationen zur Integration mit dem internen Lastenausgleichsmodul finden Sie unter Verwenden eines internen Lastenausgleichsmoduls in AKS.

Vorbereitung

  • Azure Load Balancer ist in zwei SKUs verfügbar: Basic und Standard. Beim Erstellen eines AKS-Clusters wird standardmäßig die SKU vom Typ Standard verwendet. Die SKU Standard ermöglicht Ihnen den Zugriff auf weitere Funktionen zu erhalten, z. B. einen größeren Back-End-Pool, Pools mit mehreren Knoten, Verfügbarkeitszonen und ist standardmäßig sicher. Dies ist die empfohlene Load Balancer-SKU für AKS. Weitere Informationen zu den SKUs Basic und Standard finden Sie unter Vergleich der Azure Load Balancer-SKUs.
  • Eine vollständige Liste der unterstützten Anmerkungen für Kubernetes-Dienste mit dem Typ LoadBalancer finden Sie unter LoadBalancer-Anmerkungen.
  • In diesem Artikel wird davon ausgegangen, dass Sie über einen AKS-Cluster mit der Azure Load Balancer-SKU Standard verfügen. Wenn Sie einen AKS-Cluster benötigen, können Sie einen mithilfe der Azure-Befehlszeilenschnittstelle, mit Azure PowerShell oder über das Azure-Portal erstellen.
  • AKS verwaltet den Lebenszyklus und die Vorgänge von Agentknoten. Änderungen an IaaS-Ressourcen, die den Agentknoten zugeordnet sind, werden nicht unterstützt. Ein Beispiel für einen nicht unterstützten Vorgang sind manuelle Änderungen an der Lastenausgleichsressourcengruppe.

Wichtig

Falls Sie lieber Ihr eigenes Gateway, eine Firewall oder einen Proxy für ausgehende Verbindungen verwenden möchten, können Sie die Erstellung des Ausgangspools für den Lastenausgleich und der entsprechenden Front-End-IP-Adresse überspringen. Fahren Sie in diesem Fall mit Anpassen des ausgehenden Clusterdatenverkehrs mit einer benutzerdefinierten Route fort. Mit dem Ausgangstyp wird die Ausgangsmethode für einen Cluster festgelegt, die standardmäßig den Typ LoadBalancer hat.

Verwenden der öffentlichen Load Balancer Standard-Instanz

Nachdem Sie einen AKS-Cluster mit dem Ausgangstyp LoadBalancer (Standardeinstellung) erstellt haben, kann der Lastenausgleich vom Cluster verwendet werden, um Dienste verfügbar zu machen.

Erstellen Sie ein Dienstmanifest namens public-svc.yaml, das einen öffentlichen Dienst vom Typ LoadBalancer erstellt.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

Angeben der IP-Adresse für den Lastenausgleich

Wenn Sie für den Lastenausgleich eine bestimmte IP-Adresse verwenden möchten, gibt es dafür zwei Möglichkeiten:

Wichtig

Das Hinzufügen der LoadBalancerIP-Eigenschaft zum YAML-Manifest des Lastenausgleichs ist nach der Upstreamversion von Kubernetes veraltet. Auch wenn der aktuelle Verbrauch unverändert bleibt und von vorhandenen Diensten erwartet wird, dass sie ohne Änderungen funktionieren, wird dringend empfohlen, stattdessen Dienstanmerkungen festzulegen.

  • Festlegen von Dienstanmerkungen: Verwenden Sie service.beta.kubernetes.io/azure-load-balancer-ipv4 für eine IPv4-Adresse und service.beta.kubernetes.io/azure-load-balancer-ipv6 für eine IPv6-Adresse.
  • Hinzufügen der LoadBalancerIP-Eigenschaft zum YAML-Manifest des Lastenausgleichs: Fügen Sie dem YAML-Manifest des Lastenausgleichs die Service.Spec.LoadBalancerIP-Eigenschaft hinzu. Dieses Feld ist ab der Upstreamversion von Kubernetes veraltet und bietet keine Unterstützung für duale Stapel. Der aktuelle Verbrauch bleibt unverändert, und es wird erwartet, dass vorhandene Dienste ohne Änderungen funktionieren.

Bereitstellen des Dienstmanifests

Stellen Sie das öffentliche Dienstmanifest mit kubectl apply bereit, und geben Sie den Namen Ihres YAML-Manifests an.

kubectl apply -f public-svc.yaml

Azure Load Balancer wird mit einer neuen öffentlichen IP-Adresse als Front-End für den neuen Dienst konfiguriert. Da Azure Load Balancer über mehrere Front-End-IP-Adressen verfügen kann, erhält jeder neue bereitgestellte Dienst eine neue dedizierte Front-End-IP-Adresse, damit der eindeutige Zugriff sichergestellt ist.

Sie können mit dem folgenden Befehl bestätigen, dass Ihr Dienst erstellt wurde und der Lastenausgleich konfiguriert ist.

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    52.156.88.187   80:32068/TCP    52s

Wenn Sie die Dienstdetails anzeigen, finden Sie die öffentliche IP-Adresse, die für diesen Dienst auf dem Lastenausgleich erstellt wurde, in der Spalte EXTERNAL-IP. Es kann einige Minuten dauern, bis sich die IP-Adresse von <ausstehend> in eine tatsächliche öffentliche IP-Adresse ändert.

Ausführlichere Informationen zu Ihrem Dienst erhalten Sie über den folgenden Befehl.

kubectl describe service public-svc

Die folgende Beispielausgabe ist eine verkürzte Version der Ausgabe nach der Ausführung von kubectl describe service. LoadBalancer Ingress zeigt die externe IP-Adresse an, die von Ihrem Dienst verfügbar gemacht wird. IP zeigt die internen Adressen an.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        52.156.88.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

Konfigurieren der öffentlichen Load Balancer Standard-Instanz

Sie können zum Zeitpunkt der Clustererstellung oder durch Aktualisieren des Clusters verschiedene Einstellungen für Ihren öffentlichen Standardlastenausgleich anpassen. Mit diesen Anpassungsoptionen können Sie einen Lastenausgleich erstellen, der Ihre Workloadanforderungen erfüllt. Mit Load Balancer Standard haben Sie folgende Möglichkeiten:

  • Festlegen oder Skalieren der Anzahl von verwalteten ausgehenden IP-Adressen
  • Verwenden von eigenen benutzerdefinierten IP-Ausgangsadressen oder entsprechenden Präfixen
  • Anpassen der Anzahl von zugeordneten ausgehenden Ports an die einzelnen Knoten des Clusters
  • Konfigurieren der Timeouteinstellung für Verbindungen im Leerlauf

Wichtig

Nur eine Option für ausgehende IP-Adressen (verwaltete IP-Adressen, Verwenden eigener IP-Adressen oder IP-Präfix) kann zu einem bestimmten Zeitpunkt verwendet werden.

Ändern des Typs des eingehenden Pools

Auf AKS-Knoten kann in den Back-End-Pools des Lastenausgleichs entweder über ihre IP-Konfiguration (auf Azure VM Scale Sets basierende Mitgliedschaft) oder ausschließlich über ihre IP-Adresse verwiesen werden. Die Verwendung der auf IP-Adressen basierenden Back-End-Pool-Mitgliedschaft sorgt für eine höhere Effizienz bei der Aktualisierung von Diensten und Bereitstellung von Lastenausgleichen, insbesondere bei einer hohen Anzahl von Knoten. Die Bereitstellung neuer Cluster mit auf IP-Adressen basierenden Back-End-Pools und die Konvertierung vorhandener Cluster wird jetzt unterstützt. In Kombination mit NAT Gateway oder benutzerdefinierten Routingausgangstypen wird die Bereitstellung neuer Knoten und Dienste erheblich verbessert.

Es stehen zwei Poolmitgliedschaftstypen zur Auswahl:

  • nodeIPConfiguration: Legacy-Pool-Mitgliedschaftstyp für Virtual Machine Scale Sets IP-Konfiguration
  • nodeIP – Auf der IP-Adresse basierender Mitgliedschaftstyp

Anforderungen

  • Der AKS-Cluster muss die Version 1.23 oder höher aufweisen.
  • Der AKS-Cluster muss standardmäßige Lastenausgleichsmodule und VM-Skalierungsgruppen verwenden.

Einschränkungen

  • Cluster, die auf der IP-Adresse basierende Back-End-Pools verwenden, sind auf 2.500 Knoten beschränkt.

Erstellen eines neuen AKS-Clusters mit auf IP-Adressen basierender Mitgliedschaft im eingehenden Pool

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Aktualisieren eines vorhandenen AKS-Clusters für die Verwendung einer auf IP-Adressen basierender Mitgliedschaft im eingehenden Pool

Warnung

Dieser Vorgang führt zu einer temporären Unterbrechung des im Cluster eingehenden Dienstdatenverkehrs. Die Dauer der Auswirkung erhöht sich bei größeren Clustern mit vielen Knoten.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Skalieren der Anzahl von verwalteten öffentlichen IP-Ausgangsadressen

Azure Load Balancer ermöglicht ein- und ausgehende Verbindungen in einem virtuellen Netzwerk. Mithilfe von Ausgangsregeln können Sie die Netzwerkadressenübersetzung (NAT) einer öffentlichen Load Balancer Standard-Instanz ganz einfach konfigurieren.

Ausgangsregeln folgen der gleichen Syntax wie Lastenausgleichs- und NAT-Regeln für eingehenden Datenverkehr:

Front-End-IP-Adressen + Parameter + Back-End-Pool

Eine Ausgangsregel konfiguriert die NAT für ausgehenden Datenverkehr für alle VMs, die vom Back-End-Pool für die Front-End-Übersetzung identifiziert wurden. Parameter ermöglichen eine umfassendere Steuerung des NAT-Algorithmus für ausgehenden Datenverkehr.

Da Sie eine Ausgangsregel mit einer einzelnen öffentlichen IP-Adresse verwenden können, eignen sich Ausgangsregeln hervorragend für die Skalierung der Netzwerkadressenübersetzung für ausgehenden Datenverkehr, da sie den Konfigurationsaufwand verringern. Sie können mehrere IP-Adressen verwenden, um umfangreiche Szenarien zu planen. Mithilfe von Ausgangsregeln lassen sich außerdem die für die SNAT-Überlastung anfälligen Muster reduzieren. Jede IP-Adresse, die von einem Front-End bereitgestellt wird, stellt 64.000 kurzlebige Ports zur Verfügung, die vom Lastenausgleich als SNAT-Ports verwendet werden können.

Wenn Sie einen Lastenausgleich mit der SKU Standard mit verwalteten ausgehenden öffentlichen IP-Adressen verwenden, die standardmäßig erstellt werden, können Sie die Anzahl verwalteter ausgehender öffentlicher IP-Adressen mit dem --load-balancer-managed-outbound-ip-count-Parameter skalieren.

Zum Aktualisieren eines vorhandenen Clusters führen Sie den folgenden Befehl aus. Sie können diesen Parameter auch auf mehrere verwaltete ausgehende öffentliche IP-Adressen festlegen.

Wichtig

Es wird nicht empfohlen, Änderungen an Ausgangsregeln über das Azure-Portal vorzunehmen. Wenn Sie diese Änderungen vornehmen, sollten Sie diese am AKS-Cluster und nicht direkt an der Lastenausgleichsressource durchführen.

Direkt an der Lastenausgleichsressource vorgenommene Änderungen an Ausgangsregeln werden entfernt, wenn der Cluster abgestimmt wird, also z. B. wenn er beendet, gestartet, aktualisiert oder skaliert wird.

Verwenden Sie die Azure-Befehlszeilenschnittstelle, wie in den Beispielen gezeigt. Änderungen an Ausgangsregeln, die mithilfe der CLI-Befehle mit az aks vorgenommen werden, sind über die gesamte Clusterdowntime hinweg dauerhaft.

Weitere Informationen finden Sie unter Azure Load Balancer-Ausgangsregeln.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

Im obigen Beispiel wird die Anzahl der verwalteten ausgehenden öffentlichen IP-Adressen für den myAKSCluster-Cluster in myResourceGroup auf 2 festgelegt.

Beim Erstellen des Clusters können Sie auch die anfängliche Anzahl von verwalteten ausgehenden öffentlichen IP-Adressen festlegen. Hierfür fügen Sie den Parameter --load-balancer-managed-outbound-ip-count an und legen ihn auf den gewünschten Wert fest. Die Standardanzahl verwalteter ausgehender öffentlicher IP-Adressen ist 1.

Verwenden von eigenen öffentlichen IP-Ausgangsadressen oder Präfixen

Bei Verwendung eines Lastenausgleichs mit der SKU Standard wird vom AKS-Cluster automatisch eine öffentliche IP-Adresse in der von AKS verwalteten Infrastrukturressourcengruppe erstellt und dem Ausgangspool des Lastenausgleichs zugewiesen.

Eine von AKS erstellte öffentliche IP-Adresse ist eine von AKS verwaltete Ressource. Das bedeutet, dass AKS den Lebenszyklus dieser öffentlichen IP-Adresse verwaltet und keine direkte Benutzeraktion für die öffentliche IP-Ressource erfordert. Alternativ können Sie Ihre eigene benutzerdefinierte öffentliche IP-Adresse bzw. das zugehörige Präfix bei der Erstellung des Clusters zuweisen. Ihre benutzerdefinierten IP-Adressen können auch in den Lastenausgleichseigenschaften eines vorhandenen Clusters aktualisiert werden.

Zu den Anforderungen für die Verwendung Ihrer eigenen öffentlichen IP-Adresse oder Ihres Präfixes gehören:

  • Benutzer müssen benutzerdefinierte öffentliche IP-Adressen erstellen und besitzen. Verwaltete öffentliche IP-Adressen, die von AKS erstellt werden, können nicht für die Bereitstellung einer eigenen benutzerdefinierten IP-Adresse wiederverwendet werden, da dies zu Verwaltungskonflikten führen kann.
  • Sie müssen sicherstellen, dass die AKS-Clusteridentität (Dienstprinzipal oder verwaltete Identität) über Berechtigungen für den Zugriff auf ausgehende IP-Adressen verfügt, und zwar gemäß der Liste der erforderlichen Berechtigungen für die öffentliche IP-Adresse.
  • Stellen Sie sicher, dass Sie die vorgegebenen Voraussetzungen und Einschränkungen erfüllen, die für die Konfiguration von ausgehenden IP-Adressen und der zugehörigen Präfixe gelten.

Aktualisieren des Clusters mit Ihrer eigenen ausgehenden öffentlichen IP-Adresse

Verwenden Sie den Befehl az network public-ip show, um die IDs Ihrer öffentlichen IP-Adressen aufzulisten.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

Der obige Befehl zeigt die ID für die öffentliche IP-Adresse myPublicIP in der Ressourcengruppe myResourceGroup an.

Verwenden Sie den Befehl az aks update mit dem Parameter load-balancer-outbound-ips , um Ihren Cluster mit Ihren öffentlichen IP-Adressen zu aktualisieren.

Im folgenden Beispiel wird der Parameter load-balancer-outbound-ips mit den IDs aus dem vorherigen Befehl verwendet.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Aktualisieren des Clusters mit Ihrem eigenen Präfix für eine ausgehende öffentliche IP-Adresse

Sie können auch öffentliche IP-Präfixe für ausgehenden Datenverkehr mit Ihrem Standard-SKU-Lastenausgleich verwenden. Im folgenden Beispiel wird der Befehl az network public-ip prefix show verwendet, um die IDs Ihrer Präfixe für öffentliche IP-Adressen aufzulisten.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

Der obige Befehl zeigt die ID für das öffentliche IP-Präfix myPublicIPPrefix in der Ressourcengruppe myResourceGroup an.

Im folgenden Beispiel wird der Parameter load-balancer-outbound-ip-prefixes mit den IDs aus dem vorherigen Befehl verwendet.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Erstellen des Clusters mit Ihren eigenen öffentlichen IP-Adressen oder Präfixen

Sie können zum Zeitpunkt der Clustererstellung Ihre eigenen IP-Adressen oder IP-Präfixe für ausgehenden Datenverkehr einbinden, um Szenarien wie das Hinzufügen von Endpunkten für ausgehenden Datenverkehr zu einer Positivliste zu unterstützen. Um Ihre eigenen öffentlichen IP-Adressen und IP-Präfixe bei der Clustererstellung zu definieren, fügen Sie die gleichen Parameter an, die im vorherigen Befehl gezeigt wurden.

Verwenden Sie den Befehl az aks create mit dem load-balancer-outbound-ips-Parameter, um einen neuen Cluster mit Ihren öffentlichen IP-Adressen zu aktualisieren.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Verwenden Sie den Befehl az aks create mit dem load-balancer-outbound-ip-prefixes-Parameter, um einen neuen Cluster mit Ihren öffentlichen IP-Präfixen zu aktualisieren.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Konfigurieren der zugeordneten ausgehenden Ports

Wichtig

Bei Anwendungen in Ihrem Cluster, die eine große Anzahl von Verbindungen mit einer kleinen Menge von Zielen herstellen können (etwa zahlreiche Instanzen einer Front-End-Anwendung, die eine Verbindung mit einer Datenbank herstellen), kann ein Szenario eintreten, das sehr anfällig für SNAT-Portauslastung ist. Die SNAT-Portauslastung tritt auf, wenn eine Anwendung nicht mehr über ausgehende Ports zum Herstellen einer Verbindung mit einer anderen Anwendung oder einem anderen Host verfügt. Bei einem Szenario, in dem SNAT-Portauslastung auftreten kann, wird dringend empfohlen, die zugeordneten ausgehenden Ports und Front-End-IP-Ausgangsadressen im Lastenausgleich zu erhöhen.

Weitere Informationen zur SNAT finden Sie unter Verwenden der SNAT für ausgehende Verbindungen.

AKS legt AllocatedOutboundPorts für den Lastenausgleich standardmäßig auf 0 fest. Dadurch wird die automatische Zuweisung ausgehender Ports basierend auf der Größe des Back-End-Pools ermöglicht, wenn Sie einen Cluster erstellen. Wenn ein Cluster beispielsweise über 50 oder weniger Knoten verfügt, werden jedem Knoten 1.024 Ports zugeordnet. Wenn sich die Anzahl der Knoten im Cluster erhöht, sind weniger Ports pro Knoten verfügbar.

Wichtig

Es gibt ein festes Limit von 1024 Ports, unabhängig davon, ob Front-End-IP-Adressen hinzugefügt werden, wenn die Knotengröße höchstens 50 (1–50) ist.

Verwenden Sie az network lb outbound-rule list, um den Wert von AllocatedOutboundPorts für den Lastenausgleich des AKS-Clusters anzuzeigen.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

Die folgende Beispielausgabe zeigt, dass die automatische Zuweisung ausgehender Ports basierend auf der Größe des Back-End-Pools für den Cluster aktiviert ist.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

Verwenden Sie load-balancer-outbound-ports und entweder load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips oder load-balancer-outbound-ip-prefixes, um einen bestimmten Wert für AllocatedOutboundPorts und die ausgehende IP-Adresse zu konfigurieren. Bevor Sie einen bestimmten Wert festlegen oder einen vorhandenen Wert für ausgehende Ports und IP-Adressen erhöhen, müssen Sie die entsprechende Anzahl ausgehender Ports und IP-Adressen berechnen. Verwenden Sie für diese Berechnung die folgende Gleichung, gerundet auf die nächste ganze Zahl: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Beachten Sie beim Berechnen der Anzahl ausgehender Ports und IP-Adressen und beim Festlegen der Werte die folgenden Informationen:

  • Die Anzahl ausgehender Ports pro Knoten hängt von dem Wert ab, den Sie festlegen, und ist feststehend.
  • Der Wert für ausgehende Ports muss ein Vielfaches von 8 sein.
  • Das Hinzufügen weiterer IP-Adressen fügt keinem Knoten weitere Ports hinzu, bietet jedoch Kapazität für mehr Knoten im Cluster.
  • Sie müssen Knoten berücksichtigen, die unter Umständen im Rahmen von Upgrades hinzugefügt werden, einschließlich der Anzahl von Knoten, die über maxSurge-Werte angegeben werden.

Die folgenden Beispiele zeigen, wie die Werte, die Sie festlegen, die Anzahl der ausgehenden Ports und IP-Adressen beeinflussen:

  • Wenn die Standardwerte verwendet werden und der Cluster über 48 Knoten verfügt, stehen jedem Knoten 1024 Ports zur Verfügung.
  • Wenn die Standardwerte verwendet werden und der Cluster von 48 auf 52 Knoten skaliert wird, wird bei jedem Knoten die Anzahl verfügbarer Ports von 1024 auf 512 aktualisiert.
  • Wenn Sie die Anzahl ausgehender Ports auf 1.000 und die Anzahl ausgehender IP-Adressen auf 2 festlegen, kann der Cluster maximal 128 Knoten unterstützen: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
  • Wenn Sie die Anzahl ausgehender Ports auf 1.000 und die Anzahl ausgehender IP-Adressen auf 7 festlegen, kann der Cluster maximal 448 Knoten unterstützen: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
  • Wenn Sie die Anzahl ausgehender Ports auf 4.000 und die Anzahl ausgehender IP-Adressen auf 2 festlegen, kann der Cluster maximal 32 Knoten unterstützen: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
  • Wenn Sie die Anzahl ausgehender Ports auf 4.000 und die Anzahl ausgehender IP-Adressen auf 7 festlegen, kann der Cluster maximal 112 Knoten unterstützen: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Wichtig

Nachdem Sie die Anzahl ausgehender Ports und IP-Adressen berechnet haben, überprüfen Sie, ob Sie über zusätzliche Kapazität für ausgehende Ports verfügen, um den Knotenanstieg während Upgrades zu bewältigen. Es ist sehr wichtig, eine ausreichende Zahl überschüssiger Ports für zusätzliche Knoten zuzuordnen, die für Upgrades und andere Vorgänge benötigt werden. AKS verwendet standardmäßig einen Pufferknoten für Upgradevorgänge. Bei Verwendung von maxSurge-Werten müssen Sie die ausgehenden Ports pro Knoten mit Ihrem maxSurge-Wert multiplizieren, um die Anzahl der erforderlichen Ports zu bestimmen. Sie haben beispielsweise berechnet, dass Sie 4.000 Ports pro Knoten mit 7 IP-Adressen in einem Cluster mit maximal 100 Knoten und einem maximalen Anstieg von 2 benötigen:

  • 2 Surge-Knoten · 4.000 Ports pro Knoten = 8.000 Ports für den Knotenanstieg während Upgrades erforderlich
  • 100 Knoten · 4.000 Ports pro Knoten = 400.000 Ports für Ihren Cluster erforderlich
  • 7 IP-Adressen · 64.000 Ports pro IP-Adresse = 448.000 Ports für Ihren Cluster verfügbar

Das obige Beispiel zeigt, dass der Cluster über eine überschüssige Kapazität von 48.000 Ports verfügt. Dies ist ausreichend, um die 8.000 Ports zu verarbeiten, die für den Knotenanstieg während Upgrades erforderlich sind.

Nachdem die Werte berechnet und überprüft wurden, können Sie diese Werte mit load-balancer-outbound-ports und entweder load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips oder load-balancer-outbound-ip-prefixes beim Erstellen oder Aktualisieren eines Clusters anwenden.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

Konfigurieren des Leerlauftimeouts für den Load Balancer

Sobald die SNAT-Portressourcen erschöpft sind, sind ausgehende Datenflüsse erst wieder möglich, wenn SNAT-Ports von vorhandenen Datenflüssen freigegeben werden. Das Lastenausgleichsmodul gibt die SNAT-Ports wieder frei, wenn der Datenflussvorgang abgeschlossen ist. Für den von AKS konfigurierten Lastenausgleich wird ein Leerlauftimeout von 30 Minuten verwendet, um SNAT-Ports für im Leerlauf befindliche Datenflüsse wieder freizugeben.

Sie können auch einen Datentransport (z. B. TCP keepalives oder application-layer keepalives) verwenden, um einen im Leerlauf befindlichen Datenfluss zu aktualisieren, und dieses Leerlauftimeout bei Bedarf zurücksetzen. Sie können dieses Timeout anhand dieses Beispiels konfigurieren.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

Erwägen Sie die Verwendung eines niedrigen Timeoutwerts, z. B. 4 Minuten, falls Sie mit vielen kurzlebigen Verbindungen rechnen – nicht mit Verbindungen, die langlebig sind und ggf. lange Leerlaufdauern aufweisen, z. B. bei der Nutzung von kubectl proxy oder kubectl port-forward. Wenn TCP-KeepAlives verwendet werden, genügt es zudem, sie auf einer Seite der Verbindung zu aktivieren. Beispielsweise reicht es aus, sie nur auf Serverseite zu aktivieren, um den Leerlauftimer des Datenflusses zurückzusetzen. Es ist nicht erforderlich, TCP-KeepAlives auf beiden Seiten zu starten. Ähnliche Konzepte gibt es für die Anwendungsschicht, einschließlich Client/Server-Konfigurationen für Datenbanken. Überprüfen Sie auf der Serverseite, welche Optionen es für anwendungsspezifische Keepalives gibt.

Wichtig

AKS ermöglicht bei Leerlauf standardmäßig die TCP-Zurücksetzung. Es wird empfohlen, diese Konfiguration beizubehalten und zu nutzen, um für Ihre Szenarien ein besser vorhersagbares Anwendungsverhalten zu erzielen.

„TCP RST“ wird nur während der TCP-Verbindung im Status „ESTABLISHED“ gesendet. Weitere Informationen hierzu finden Sie hier.

Wenn Sie IdleTimeoutInMinutes auf einen anderen Wert als den Standardwert von 30 Minuten festlegen, sollten Sie berücksichtigen, wie lange Sie für Ihre Workloads eine ausgehende Verbindung benötigen. Berücksichtigen Sie auch, dass der Standardtimeoutwert für einen Load Balancer mit der SKU Standard, der außerhalb von AKS verwendet wird, 4 Minuten beträgt. Ein IdleTimeoutInMinutes-Wert, der Ihre spezifische AKS-Workload genauer widerspiegelt, kann zu einer Verringerung der SNAT-Auslastung beitragen. Hierzu kann es kommen, wenn nicht mehr verwendete Verbindungen vorhanden sind.

Warnung

Durch Ändern der Werte für AllocatedOutboundPorts und IdleTimeoutInMinutes kann sich das Verhalten der Ausgangsregel für Ihren Lastenausgleich erheblich ändern, was daher nicht leichtfertig erfolgen sollte. Lesen Sie den Abschnitt zur Problembehandlung für SNAT, und informieren Sie sich über die Load Balancer-Ausgangsregeln und über ausgehende Verbindungen in Azure, bevor Sie diese Werte aktualisieren, um die Auswirkungen Ihrer Änderungen richtig zu verstehen.

Beschränken des eingehenden Datenverkehrs auf bestimmte IP-Adressbereiche

Im folgenden Manifest wird loadBalancerSourceRanges verwendet, um einen neuen IP-Adressbereich für eingehenden externen Datenverkehr anzugeben.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

In diesem Beispiel wird die Regel aktualisiert, um eingehenden externen Datenverkehr nur aus dem MY_EXTERNAL_IP_RANGE-Bereich zuzulassen. Wenn Sie MY_EXTERNAL_IP_RANGE durch die IP-Adresse des internen Subnetzes ersetzen, wird der Datenverkehr nur auf die internen IP-Adressen des Clusters beschränkt. Wenn der Datenverkehr auf interne Cluster-IPs beschränkt ist, können Clients außerhalb Ihres Kubernetes-Clusters nicht auf den Lastenausgleich zugreifen.

Hinweis

  • Eingehender, externer Datenverkehr wird vom Lastenausgleich an das virtuelle Netzwerk für Ihren AKS-Cluster geleitet. Das virtuelle Netzwerk verfügt über eine Netzwerksicherheitsgruppe (NSG), die den gesamten eingehenden Datenverkehr vom Lastenausgleich zulässt. Diese NSG verwendet ein Diensttag vom Typ LoadBalancer, um den Datenverkehr vom Lastenausgleich zuzulassen.
  • Pod-CIDR sollte zu „loadBalancerSourceRanges“ hinzugefügt werden, wenn Pods für Cluster mit Version 1.25 oder höher auf die LoadBalancer-IP des Diensts zugreifen müssen.

Beibehalten der IP-Adresse des Clients bei eingehenden Verbindungen

Standardmäßig behält ein Dienst vom Typ LoadBalancerin Kubernetes und in AKS die IP-Adresse des Clients für die Verbindung zum Pod nicht bei. Die Quell-IP-Adresse des Pakets, das an den Pod übermittelt wird, ist die private IP-Adresse des Knotens. Sie müssen in der Dienstdefinition service.spec.externalTrafficPolicy auf local festlegen, um die IP-Adresse des Clients beizubehalten. Das folgende Manifest zeigt ein Beispiel.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Anpassungen mit Kubernetes-Anmerkungen

Die folgenden Anmerkungen werden für Kubernetes-Dienste vom Typ LoadBalancer unterstützt und gelten nur für eingehende Datenflüsse.

Anmerkung Wert BESCHREIBUNG
service.beta.kubernetes.io/azure-load-balancer-internal true oder false Geben Sie an, ob es ein interner Lastenausgleich sein soll. Wenn keine Festlegung erfolgt, lautet der Standardwert „public“.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet Name des Subnetzes Geben Sie an, an welches Subnetz der interne Lastenausgleich gebunden werden soll. Wenn Sie nichts angeben, wird standardmäßig das in der Cloudkonfigurationsdatei konfigurierte Subnetz verwendet.
service.beta.kubernetes.io/azure-dns-label-name Name der DNS-Bezeichnung von öffentlichen IP-Adressen Geben Sie den Namen der DNS-Bezeichnung für den öffentlichen Dienst an. Wenn die Zeichenfolge leer ist, wird der DNS-Eintrag in der öffentlichen IP-Adresse nicht verwendet.
service.beta.kubernetes.io/azure-shared-securityrule true oder false Geben Sie an, wie Sie den Dienst über eine potenziell freigegebene Azure-Sicherheitsregel verfügbar machen, um die Dienstoffenlegung zu erhöhen, indem Sie ergänzte Sicherheitsregeln von Azure in Netzwerksicherheitsgruppen verwenden.
service.beta.kubernetes.io/azure-load-balancer-resource-group Name der Ressourcengruppe Geben Sie die Ressourcengruppe von öffentlichen IP-Adressen des Lastenausgleichs an, die sich nicht in derselben Ressourcengruppe wie die Clusterinfrastruktur (Knotenressourcengruppe) befinden.
service.beta.kubernetes.io/azure-allowed-service-tags Liste mit zulässigen Diensttags Geben Sie eine Liste mit den zulässigen Diensttags an (mit Kommas als Trennzeichen).
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout TCP-Leerlauftimeouts in Minuten Geben Sie die Dauer in Minuten für Leerlauftimeouts bei TCP-Verbindungen an, die für den Lastenausgleich auftreten. Der Standard- und Mindestwert ist 4. Der Höchstwert ist 30. Der Wert muss eine ganze Zahl sein.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true oder false Geben Sie an, ob das Lastenausgleichsmodul die TCP-Zurücksetzung beim Leerlauftimeout deaktivieren soll.
service.beta.kubernetes.io/azure-load-balancer-ipv4 IPv4-Adresse Geben Sie die IPv4-Adresse an, die dem Lastenausgleichsmodul zugewiesen werden soll.
service.beta.kubernetes.io/azure-load-balancer-ipv6 IPv6-Adresse Geben Sie die IPv6-Adresse an, die dem Lastenausgleichsmodul zugewiesen werden soll.

Passen Sie den Integritätstest für den Load Balancer an

Anmerkung Wert Beschreibung
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Integritätstestintervall
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Die Mindestanzahl der fehlerhaften Antworten des Integritätstests
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Anforderungspfad des Integritätstests
service.beta.kubernetes.io/port_{port}_no_lb_rule TRUE/FALSE {port} ist die Dienstportnummer. Wenn sie auf „true“ festgelegt ist, wird keine LB-Regel oder Integritätstestregel für diesen Port generiert. Der Integritätsprüfungsdienst sollte nicht für das öffentliche Internet verfügbar gemacht werden (z. B. istio/envoy Health Check Service)
service.beta.kubernetes.io/port_{port}_no_probe_rule TRUE/FALSE {port} ist die Dienstportnummer. Wenn sie auf „true“ festgelegt ist, wird keine Integritätstestregel für diesen Port generiert.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protokoll des Integritätstests {port} ist die Dienstportnummer. Explizites Protokoll für den Integritätstest für den Dienstport {port}, setzt port.appProtocol außer Kraft, falls festgelegt.
service.beta.kubernetes.io/port_{port}_health-probe_port Portnummer oder Portname im Dienstmanifest {port} ist die Dienstportnummer. Expliziter Port für den Integritätstest für den Dienstport {port}, wobei der Standardwert überschrieben wird.
service.beta.kubernetes.io/port_{port}_health-probe_interval Integritätstestintervall {port} ist die Dienstportnummer.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe Die Mindestanzahl der fehlerhaften Antworten des Integritätstests {port} ist die Dienstportnummer.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Anforderungspfad des Integritätstests {port} ist die Dienstportnummer.

Wie hier dokumentiert, sind Tcp, Http und Https drei Protokolle, die vom Lastenausgleichsdienst unterstützt werden.

Derzeit variiert das Standardprotokoll des Integritätstests zwischen Diensten mit verschiedenen Transportprotokollen, App-Protokollen, Anmerkungen und externen Datenverkehrsrichtlinien.

  1. für lokale Dienste würden HTTP und /healthz verwendet werden. Der Integritätstest fragt NodeHealthPort anstelle des tatsächlichen Back-End-Diensts ab
  2. für Cluster-TCP-Dienste würde TCP verwendet werden.
  3. für Cluster-UDP-Dienste, keine Integritätstests.

Hinweis

Für lokale Dienste mit aktivierter PLS-Integration und PLS-Proxyprotokoll funktioniert der standardmäßige HTTP+/healthz-Integritätstest nicht. Daher kann der Integritätstest auf die gleiche Weise wie Clusterdienste angepasst werden, um dieses Szenario zu unterstützen.

Seit v1.20 wird die Dienstanmerkung service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path eingeführt, um das Verhalten des Integritätstests zu bestimmen.

  • Bei Clustern <=1.23 würde spec.ports.appProtocol nur als Testprotokoll verwendet werden, wenn service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path auch festgelegt wird.
  • Für Cluster >=1.24 würde spec.ports.appProtocol als Testprotokoll und / als Standard-Testanforderungspfad verwendet werden (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path könnte verwendet werden, um zu einem anderen Anforderungspfad zu wechseln).

Beachten Sie, dass der Anforderungspfad bei Verwendung von TCP oder bei einem leeren spec.ports.appProtocol ignoriert wird. Dies gilt insbesondere in folgenden Fällen:

loadbalancer sku externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path LB-Testprotokoll LB-Testanforderungspfad
Standard Lokal Beliebig Beliebig Beliebig http /healthz
Standard cluster udp Beliebig Beliebig null null
Standard cluster tcp (ignoriert) tcp NULL
Standard cluster tcp tcp (ignoriert) tcp NULL
Standard cluster tcp http/https TCP(<=1.23) oder http/https(>=1.24) null(<=1.23) oder /(>=1.24)
Standard cluster tcp http/https /custom-path http/https /custom-path
Standard cluster tcp nicht unterstütztes Protokoll /custom-path tcp NULL
basic Lokal Beliebig Beliebig Beliebig http /healthz
basic cluster tcp (ignoriert) tcp NULL
basic cluster tcp tcp (ignoriert) tcp NULL
basic cluster tcp http TCP(<=1.23) oder http/https(>=1.24) null(<=1.23) oder /(>=1.24)
basic cluster tcp http /custom-path http /custom-path
basic cluster tcp nicht unterstütztes Protokoll /custom-path tcp NULL

Seit v1.21 werden zwei Dienstanmerkungen, service.beta.kubernetes.io/azure-load-balancer-health-probe-interval und load-balancer-health-probe-num-of-probe, eingeführt, die die Konfiguration des Integritätstests anpassen. Wenn service.beta.kubernetes.io/azure-load-balancer-health-probe-interval nicht festgelegt ist, wird der Standardwert 5 angewendet. Wenn load-balancer-health-probe-num-of-probe nicht festgelegt ist, wird der Standardwert 2 angewendet. Und der gesamte Test sollte weniger als 120 Sekunden betragen.

Benutzerdefinierter Lastenausgleichs-Integritätstest für Port

Für unterschiedliche Ports in einem Dienst können unterschiedliche Integritätstestkonfigurationen erforderlich sein. Dies kann auf das Dienstdesign zurückzuführen sein (z. B. ein einzelner Integritätsendpunkt, der mehrere Ports steuert) oder auf Kubernetes-Features wie MixedProtocolLBService.

Die folgenden Anmerkungen können zum Anpassen der Testkonfiguration pro Dienstport verwendet werden.

portspezifische Anmerkung globale Testanmerkung Verwendung
service.beta.kubernetes.io/port_{port}_no_lb_rule N/A (keine globale Entsprechung) wenn „true“ festgelegt wird, werden keine LB-Regeln und Testregeln generiert
service.beta.kubernetes.io/port_{port}_no_probe_rule N/A (keine globale Entsprechung) wenn „true“ festgelegt wird, werden keine Testregeln generiert
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/A (keine globale Entsprechung) Legen Sie das Integritätstestprotokoll für diesen Dienstport fest (z. B. Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port N/A (keine globale Entsprechung) Legt den Integritätstestport für diesen Dienstport fest (z. B. 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Legt für Http oder Https den Anforderungspfad des Integritätstests fest. Der Standardwert lautet /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Anzahl der aufeinanderfolgenden Testfehler, bevor der Port als fehlerhaft eingestuft wird
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Der Zeitraum zwischen Testversuchen

Für das folgende Manifest unterscheidet sich die Testregel für port httpsserver von der für httpserver, da Anmerkungen für port httpsserver angegeben sind.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

In diesem Manifest verwenden die HTTPS-Ports einen anderen Knotenport, eine HTTP-Bereitschaftsprüfung am Port 10256 unter /healthz(healthz-Endpunkt von kube-proxy).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

In diesem Manifest verwenden die HTTPS-Ports einen anderen Integritätstestendpunkt, eine HTTP-Bereitschaftsprüfung am Port 30000 auf /healthz/ready.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Problembehandlung für SNAT

Wenn Sie wissen, dass Sie viele ausgehende TCP- oder UDP-Verbindungen zu derselben IP-Zieladresse und demselben Port starten, und Fehler bei ausgehenden Verbindungen feststellen oder vom Support darauf hingewiesen werden, dass Sie zu viele SNAT-Ports (vorab zugeordnete kurzlebige Ports, die für PAT verwendet werden) in Anspruch nehmen, stehen Ihnen mehrere Lösungsmöglichkeiten zur Verfügung. Überprüfen Sie diese Optionen, und entscheiden Sie, welche für Ihr Szenario am besten geeignet ist. Möglicherweise kann die ein oder andere die Verwaltung dieses Szenarios vereinfachen. Ausführliche Informationen finden Sie unter Problembehandlung für Fehler bei ausgehenden Verbindungen.

Die Grundursache für eine SNAT-Auslastung ist häufig ein Antimuster bei der Einrichtung und Verwaltung der ausgehenden Konnektivität oder bei der Änderung des Standardwerts von konfigurierbaren Timern. Lesen Sie diesem Abschnitt sorgfältig.

Schritte

  1. Überprüfen Sie, ob Ihre Verbindungen längere Zeit im Leerlauf verbleiben und für die Freigabe des Ports der Standard-Leerlauftimeout genutzt wird. Wenn dies der Fall ist, müssen Sie das Standardtimeout von 30 Minuten für Ihr Szenario ggf. reduzieren.
  2. Ermitteln Sie, wie von Ihrer Anwendung ausgehende Konnektivität hergestellt wird (z. B. per Code Review oder Paketerfassung).
  3. Ermitteln Sie, ob es sich bei dieser Aktivität um ein erwartetes Verhalten handelt oder die Anwendung ein Fehlverhalten aufweist. Verwenden Sie Metriken und Protokolle in Azure Monitor, um Ihre Ergebnisse zu untermauern. Verwenden Sie beispielsweise die Kategorie „Fehler“ für die Metrik „SNAT-Verbindungen“.
  4. Prüfen Sie, ob die richtigen Muster eingehalten werden.
  5. Prüfen Sie, ob die SNAT-Portüberlastung durch zusätzliche ausgehende IP-Adressen und mehr zugeordnete ausgehende Ports beseitigt werden sollte.

Entwurfsmuster

Nutzen Sie nach Möglichkeit immer die Wiederverwendung von Verbindungen und Verbindungspools. Bei diesen Mustern werden Probleme aufgrund einer hohen Ressourcenauslastung vermieden, und es ergibt sich ein vorhersagbares Verhalten. Primitive für diese Muster finden Sie in vielen Entwicklungsbibliotheken und Frameworks.

  • Atomische Anforderungen (eine Anforderung pro Verbindung) sind meist kein guter Entwurfsansatz. Antimuster dieser Art führen zu eingeschränkter Skalierbarkeit und zu geringerer Leistung und Zuverlässigkeit. Nutzen Sie stattdessen die Wiederverwendung von HTTP/S-Verbindungen, um die Anzahl von Verbindungen und zugeordneten SNAT-Ports zu reduzieren. Die Anwendungsskalierung und die Leistung werden verbessert, weil Handshakes, Mehraufwand und Kosten für kryptografische Vorgänge reduziert werden, wenn TLS verwendet wird.
  • Berücksichtigen Sie bei Verwendung eines clusterexternen oder benutzerdefinierten DNS oder von benutzerdefinierten Upstream-Servern im coreDNS, dass vom DNS ggf. viele einzelne Datenflüsse mit großen Datenmengen genutzt werden, wenn der Client das Ergebnis der DNS-Auflösung nicht zwischenspeichert. Passen Sie das coreDNS zuerst an, anstatt benutzerdefinierte DNS-Server zu verwenden, und definieren Sie einen geeigneten Wert für die Zwischenspeicherung.
  • Bei UDP-Datenflüssen (z. B. DNS-Lookups) werden für die Dauer des Leerlauftimeouts SNAT-Ports zugeordnet. Je länger der Leerlauftimeout dauert, desto höher ist der Druck auf die SNAT-Ports. Verwenden Sie ein kurzes Leerlauftimeout (z. B. vier Minuten).
  • Nutzen Sie Verbindungspools, um Ihre Verbindungsdatenmenge zu steuern.
  • Vermeiden Sie den Abbruch eines TCP-Datenflusses im Hintergrund, und verlassen Sie sich nicht darauf, dass dies über TCP-Timer bereinigt wird. Wenn Sie die explizite Verbindungstrennung durch TCP nicht zulassen, bleibt der Zuordnungszustand bei Zwischensystemen und -endpunkten erhalten, und SNAT-Ports stehen nicht für andere Verbindungen zur Verfügung. Dieses Muster kann zu einer Auslösung von Anwendungsausfällen und zu einer SNAT-Überlastung führen.
  • Ändern Sie Timerwerte für die TCP-Verbindungstrennung auf der Betriebssystemebene nur, wenn Sie mit den Auswirkungen vertraut sind, die sich dadurch ergeben. Der TCP-Stapel wird zwar wiederhergestellt, aber Ihre Anwendungsleistung kann beeinträchtigt werden, wenn für die Endpunkte einer Verbindung unterschiedliche Erwartungen bestehen. Der Wunsch nach einer Änderung von Timern ist normalerweise ein Zeichen für ein zugrunde liegendes Entwurfsproblem. Sehen Sie sich die folgenden Empfehlungen an.

Wechseln von einem Lastenausgleich mit der SKU Basic zur SKU Standard.

Wenn Sie bereits über einen Cluster mit einem Lastenausgleich mit der SKU Basic verfügen, sind bei der Migration zur Verwendung mit einem Lastenausgleich mit der SKU Standard wichtige Verhaltensunterschiede zu beachten.

Beispielsweise ist das Erstellen von Blau/Grün-Bereitstellungen zum Migrieren von Clustern eine gängige Vorgehensweise, da der load-balancer-sku-Typ eines Clusters nur zum Zeitpunkt der Clustererstellung definiert werden kann. Allerdings verwendet ein Lastenausgleich mit der SKU Basic IP-Adressen der SKU Basic, die nicht mit einem Lastenausgleich mit der SKU Standard kompatibel sind. Ein Lastenausgleich mit der SKU Standard erfordert IP-Adressen der SKU Standard. Beim Migrieren von Clustern zum Upgraden von Lastenausgleichs-SKUs ist eine neue IP-Adresse mit einer kompatiblen IP-Adressen-SKU erforderlich.

Weitere Informationen zum Migrieren von Clustern finden Sie in der Dokumentation mit Überlegungen zur Migration.

Einschränkungen

Wenn Sie AKS-Cluster erstellen und verwalten, die einen Lastenausgleich mit der SKU Standard unterstützen, gelten folgende Einschränkungen:

  • Mindestens eine öffentliche IP-Adresse oder ein IP-Präfix ist erforderlich, um ausgehenden Datenverkehr aus dem AKS-Cluster zuzulassen. Darüber hinaus wird die öffentliche IP-Adresse oder das IP-Präfix benötigt, um die Konnektivität zwischen der Steuerungsebene und den Agent-Knoten sowie die Kompatibilität mit früheren Versionen von AKS zu gewährleisten. Sie haben die folgenden Optionen zum Angeben von öffentlichen IP-Adressen oder IP- Präfixen mit einem Standard-SKU-Lastenausgleichsmodul:
    • Geben Sie Ihre eigenen öffentlichen IP-Adressen an.
    • Geben Sie Ihre eigenen öffentlichen IP-Präfixe an.
    • Geben Sie eine Zahl bis 100 an, damit der AKS-Cluster so viele öffentliche IP-Adressen der SKU Standard in derselben Ressourcengruppe erstellen kann, in der sich der AKS-Cluster befindet. Der Name dieser Ressourcengruppe beginnt in der Regel mit MC_. AKS weist die öffentliche IP-Adresse dem Lastenausgleich mit der SKU Standard zu. Standardmäßig wird automatisch eine öffentliche IP-Adresse in derselben Ressourcengruppe wie der AKS-Cluster erstellt, wenn weder eine öffentliche IP-Adresse noch ein öffentliches IP-Präfix oder eine Anzahl von IP-Adressen angegeben wird. Sie müssen auch öffentliche Adressen zulassen und dürfen keine Azure-Richtlinie erstellen, die die Erstellung von IP-Adressen unterbindet.
  • Eine von AKS erstellte öffentliche IP-Adresse kann nicht als eigene benutzerdefinierte öffentliche IP-Adresse wiederverwendet werden. Benutzer müssen alle benutzerdefinierten IP-Adressen erstellen und verwalten.
  • Das Definieren der Lastenausgleichs-SKU kann nur durchgeführt werden, wenn Sie einen AKS-Cluster erstellen. Nach der Erstellung eines AKS-Clusters kann die Lastenausgleichs-SKU nicht mehr geändert werden.
  • Pro Cluster kann immer nur eine Art von Lastenausgleichs-SKU (Basic oder Standard) verwendet werden.
  • Ein Lastenausgleich mit der SKU Standardunterstützt nur IP-Adressen der SKU Standard.

Nächste Schritte

Weitere Informationen zu Kubernetes-Diensten finden Sie in der Dokumentation zu Kubernetes-Diensten.

Informieren Sie sich in der Dokumentation zum internen AKS-Lastenausgleich über die Verwendung eines internen Lastenausgleichs für eingehenden Datenverkehr.