Używanie publicznego standardowego modułu równoważenia obciążenia w usłudze Azure Kubernetes Service (AKS)

Usługa Azure Load Balancer działa w warstwie 4 modelu Open SystemsConnect (OSI), który obsługuje zarówno scenariusze ruchu przychodzącego, jak i wychodzącego. Dystrybuuje przepływy przychodzące, które docierają do frontonu modułu równoważenia obciążenia do wystąpień puli zaplecza.

Publiczny moduł równoważenia obciążenia zintegrowany z usługą AKS służy do dwóch celów:

1. Aby zapewnić połączenia wychodzące z węzłami klastra wewnątrz sieci wirtualnej usługi AKS, tłumacząc prywatny adres IP na część publicznego adresu IP w puli wychodzącej.
2. Aby zapewnić dostęp do aplikacji za pośrednictwem usług typu LoadBalancerKubernetes, umożliwia łatwe skalowanie aplikacji i tworzenie usług o wysokiej dostępności.

Wewnętrzny (lub prywatny) moduł równoważenia obciążenia jest używany, gdy tylko prywatne adresy IP są dozwolone jako fronton. Wewnętrzne moduły równoważenia obciążenia służą do równoważenia obciążenia ruchu wewnątrz sieci wirtualnej. Dostęp do frontonu modułu równoważenia obciążenia można również uzyskać z sieci lokalnej w scenariuszu hybrydowym.

W tym artykule opisano integrację z publicznym modułem równoważenia obciążenia w usłudze AKS. Aby uzyskać informacje na temat integracji wewnętrznego modułu równoważenia obciążenia, zobacz Używanie wewnętrznego modułu równoważenia obciążenia w usłudze AKS.

Zanim rozpoczniesz

• Usługa Azure Load Balancer jest dostępna w dwóch jednostkach SKU: Podstawowa i Standardowa. Jednostka SKU w warstwie Standardowa jest używana domyślnie podczas tworzenia klastra usługi AKS. Jednostka SKU w warstwie Standardowa zapewnia dostęp do dodanych funkcji, takich jak większa pula zaplecza, wiele pul węzłów, Strefy dostępności i jest domyślnie bezpieczna. Jest to zalecana jednostka SKU modułu równoważenia obciążenia dla usługi AKS. Aby uzyskać więcej informacji na temat jednostek SKU w warstwie Podstawowa i Standardowa, zobacz Porównanie jednostek SKU usługi Azure Load Balancer.
• Aby uzyskać pełną listę obsługiwanych adnotacji dla usług Kubernetes z typem LoadBalancer, zobacz Adnotacje modułu LoadBalancer.
• W tym artykule założono, że masz klaster usługi AKS z usługą Azure Load Balancer w warstwie Standardowa . Jeśli potrzebujesz klastra usługi AKS, możesz go utworzyć przy użyciu interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub witryny Azure Portal.
• Usługa AKS zarządza cyklem życia i operacjami węzłów agenta. Modyfikowanie zasobów IaaS skojarzonych z węzłami agenta nie jest obsługiwane. Przykładem nieobsługiwanej operacji jest ręczne wprowadzanie zmian w grupie zasobów modułu równoważenia obciążenia.

Ważne

Jeśli wolisz używać własnej bramy, zapory lub serwera proxy w celu zapewnienia połączenia wychodzącego, możesz pominąć tworzenie puli wychodzącej modułu równoważenia obciążenia i odpowiedniego adresu IP frontonu przy użyciu typu wychodzącego jako UserDefinedRouting (UDR). Typ ruchu wychodzącego definiuje metodę ruchu wychodzącego dla klastra i domyślnie określa typ LoadBalancer.

Korzystanie z publicznego modułu równoważenia obciążenia w warstwie Standardowa

Po utworzeniu klastra usługi AKS z typem LoadBalancer ruchu wychodzącego (ustawienie domyślne) klaster jest gotowy do udostępnienia usług za pomocą modułu równoważenia obciążenia.

Utwórz manifest usługi o nazwie public-svc.yaml, który tworzy usługę publiczną typu LoadBalancer.

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

Określanie adresu IP modułu równoważenia obciążenia

Jeśli chcesz użyć określonego adresu IP z modułem równoważenia obciążenia, istnieją dwa sposoby:

Ważne

Dodanie właściwości LoadBalancerIP do manifestu YAML modułu równoważenia obciążenia jest przestarzałe po nadrzędnym rozwiązaniu Kubernetes. Chociaż bieżące użycie pozostaje takie same, a istniejące usługi powinny działać bez modyfikacji, zdecydowanie zalecamy ustawienie adnotacji usługi.

• Ustawianie adnotacji usługi: użyj dla service.beta.kubernetes.io/azure-load-balancer-ipv4 adresu IPv4 i service.beta.kubernetes.io/azure-load-balancer-ipv6 adresu IPv6.
• Dodaj właściwość LoadBalancerIP do manifestu YAML modułu równoważenia obciążenia: dodaj właściwość Service.Spec.LoadBalancerIP do manifestu YAML modułu równoważenia obciążenia. To pole jest przestarzałe po nadrzędnym rozwiązaniu Kubernetes i nie może obsługiwać podwójnego stosu. Bieżące użycie pozostaje takie same, a istniejące usługi powinny działać bez modyfikacji.

Wdrażanie manifestu usługi

Wdróż manifest usługi publicznej przy użyciu polecenia kubectl apply i określ nazwę manifestu YAML.

kubectl apply -f public-svc.yaml

Usługa Azure Load Balancer jest skonfigurowana przy użyciu nowego publicznego adresu IP, który jest frontonem nowej usługi. Ponieważ usługa Azure Load Balancer może mieć wiele adresów IP frontonu, każda nowa wdrażana usługa uzyskuje unikatowy dostęp do nowego dedykowanego adresu IP frontonu.

Upewnij się, że usługa została utworzona, a moduł równoważenia obciążenia został skonfigurowany przy użyciu następującego polecenia.

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

Podczas wyświetlania szczegółów usługi publiczny adres IP utworzony dla tej usługi w module równoważenia obciążenia jest wyświetlany w kolumnie EXTERNAL-IP . Zmiana adresu IP z <oczekiwania> na rzeczywisty publiczny adres IP może potrwać kilka minut.

Aby uzyskać bardziej szczegółowe informacje o usłudze, użyj następującego polecenia.

kubectl describe service public-svc

Poniższe przykładowe dane wyjściowe to skrócona wersja danych wyjściowych po uruchomieniu polecenia kubectl describe service. Ruch przychodzący modułu LoadBalancer pokazuje zewnętrzny adres IP uwidoczniony przez usługę. Adres IP pokazuje adresy wewnętrzne.

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

Konfigurowanie publicznego modułu równoważenia obciążenia w warstwie Standardowa

Możesz dostosować różne ustawienia dla standardowego publicznego modułu równoważenia obciążenia w czasie tworzenia klastra lub przez zaktualizowanie klastra. Te opcje dostosowywania umożliwiają utworzenie modułu równoważenia obciążenia spełniającego potrzeby związane z obciążeniem. Za pomocą modułu równoważenia obciążenia w warstwie Standardowa można wykonywać następujące czynności:

• Ustaw lub skaluj liczbę zarządzanych wychodzących adresów IP.
• Używanie własnych niestandardowych adresów IP ruchu wychodzącego lub prefiksu wychodzącego adresu IP.
• Dostosuj liczbę przydzielonych portów wychodzących do każdego węzła w klastrze.
• Skonfiguruj ustawienie limitu czasu dla bezczynnych połączeń.

Ważne

W danym momencie można użyć tylko jednej opcji adresów IP dla ruchu wychodzącego (zarządzane adresy IP, bring your own IP lub prefiksu IP).

Zmienianie typu puli przychodzącej

Do węzłów usługi AKS można odwoływać się w pulach zaplecza modułu równoważenia obciążenia przez konfigurację adresu IP (członkostwo oparte na usłudze Azure Virtual Machine Scale Sets) lub tylko za pomocą ich adresu IP. Użycie członkostwa w puli zaplecza opartego na adresach IP zapewnia większą wydajność podczas aktualizowania usług i aprowizacji modułów równoważenia obciążenia, szczególnie w przypadku dużej liczby węzłów. Aprowizowanie nowych klastrów przy użyciu pul zaplecza opartych na adresach IP i konwertowanie istniejących klastrów jest teraz obsługiwane. W połączeniu z bramą translatora adresów sieciowych lub typami ruchu wychodzącego zdefiniowanego przez użytkownika aprowizowanie nowych węzłów i usług jest bardziej wydajne.

Dostępne są dwa różne typy członkostwa w puli:

• nodeIPConfiguration — starszy typ członkostwa puli opartej na adresach IP zestawów skalowania maszyn wirtualnych
• nodeIP - Typ członkostwa opartego na adresach IP

Wymagania

• Klaster usługi AKS musi być w wersji 1.23 lub nowszej.
• Klaster usługi AKS musi używać standardowych modułów równoważenia obciążenia i zestawów skalowania maszyn wirtualnych.

Tworzenie nowego klastra usługi AKS z członkostwem w puli przychodzącej opartej na adresach IP

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

Aktualizowanie istniejącego klastra usługi AKS w celu korzystania z członkostwa w puli przychodzącej opartej na adresach IP

Ostrzeżenie

Ta operacja powoduje tymczasowe zakłócenia ruchu przychodzącego usługi w klastrze. Czas wpływu zwiększa się wraz z większymi klastrami, które mają wiele węzłów.

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

Skalowanie liczby zarządzanych publicznych adresów IP wychodzących

Usługa Azure Load Balancer zapewnia łączność wychodzącą i przychodzącą z sieci wirtualnej. Reguły ruchu wychodzącego ułatwiają konfigurowanie tłumaczenia adresów sieciowych dla publicznego standardowego modułu równoważenia obciążenia.

Reguły ruchu wychodzącego są zgodne z tą samą składnią co równoważenie obciążenia i reguły NAT dla ruchu przychodzącego:

Adresy IP frontonu i parametry i pula zaplecza

Reguła ruchu wychodzącego konfiguruje translator adresów sieciowych dla wszystkich maszyn wirtualnych zidentyfikowanych przez pulę zaplecza do tłumaczenia na fronton. Parametry zapewniają większą kontrolę nad algorytmem NAT ruchu wychodzącego.

Chociaż można użyć reguły ruchu wychodzącego z pojedynczym publicznym adresem IP, reguły ruchu wychodzącego doskonale nadają się do skalowania translatora adresów sieciowych wychodzących, ponieważ ułatwiają one obciążenie konfiguracją. Można użyć wielu adresów IP, aby zaplanować scenariusze na dużą skalę i reguły ruchu wychodzącego w celu ograniczenia podatnych na wyczerpanie SNAT wzorców. Każdy adres IP dostarczony przez fronton zapewnia 64k portów efemerycznych dla modułu równoważenia obciążenia do użycia jako portów SNAT.

W przypadku korzystania z modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa z zarządzanymi publicznymi adresami IP wychodzącymi (które są tworzone domyślnie), można skalować liczbę zarządzanych publicznych adresów IP wychodzących przy użyciu parametru --load-balancer-managed-outbound-ip-count .

Użyj następującego polecenia, aby zaktualizować istniejący klaster. Można również ustawić ten parametr tak, aby mieć wiele zarządzanych publicznych adresów IP ruchu wychodzącego.

Ważne

Nie zalecamy używania witryny Azure Portal do wprowadzania żadnych zmian reguł ruchu wychodzącego. Podczas wprowadzania tych zmian należy przejść przez klaster usługi AKS, a nie bezpośrednio w zasobie usługi Load Balancer.

Zmiany reguły ruchu wychodzącego wprowadzone bezpośrednio w zasobie usługi Load Balancer są usuwane za każdym razem, gdy klaster zostanie uzgodniony, na przykład po zatrzymaniu, uruchomieniu, uaktualnieniu lub skalowaniu.

Użyj interfejsu wiersza polecenia platformy Azure, jak pokazano w przykładach. Zmiany reguły ruchu wychodzącego wprowadzone przy użyciu az aks poleceń interfejsu wiersza polecenia są trwałe w ramach przestoju klastra.

Aby uzyskać więcej informacji, zobacz Reguły ruchu wychodzącego usługi Azure Load Balancer.

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

W powyższym przykładzie ustawiono liczbę zarządzanych publicznych adresów IP ruchu wychodzącego na 2 dla klastra myAKSCluster w grupie myResourceGroup.

W czasie tworzenia klastra można również ustawić początkową liczbę zarządzanych publicznych adresów IP wychodzących, dołączając parametr i ustawiając --load-balancer-managed-outbound-ip-count go na żądaną wartość. Domyślna liczba zarządzanych publicznych adresów IP dla ruchu wychodzącego to 1.

Podaj własne publiczne adresy IP lub prefiksy dla ruchu wychodzącego

W przypadku korzystania z modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa klaster usługi AKS automatycznie tworzy publiczny adres IP w grupie zasobów infrastruktury zarządzanej przez usługę AKS i domyślnie przypisuje go do puli wychodzącej modułu równoważenia obciążenia.

Publiczny adres IP utworzony przez usługę AKS jest zasobem zarządzanym przez usługę AKS, co oznacza, że usługa AKS zarządza cyklem życia tego publicznego adresu IP i nie wymaga akcji użytkownika bezpośrednio w zasobie publicznego adresu IP. Alternatywnie możesz przypisać własny niestandardowy publiczny adres IP lub prefiks publicznego adresu IP w czasie tworzenia klastra. Niestandardowe adresy IP można również zaktualizować we właściwościach modułu równoważenia obciążenia istniejącego klastra.

Wymagania dotyczące używania własnego publicznego adresu IP lub prefiksu obejmują:

• Użytkownicy muszą tworzyć i posiadać niestandardowe publiczne adresy IP. Zarządzane publiczne adresy IP utworzone przez usługę AKS nie mogą być ponownie używane jako "przynieś własny niestandardowy adres IP", ponieważ mogą powodować konflikty zarządzania.
• Upewnij się, że tożsamość klastra usługi AKS (jednostka usługi lub tożsamość zarządzana) ma uprawnienia dostępu do wychodzącego adresu IP zgodnie z wymaganą listą uprawnień publicznego adresu IP.
• Upewnij się, że spełnisz wymagania wstępne i ograniczenia niezbędne do skonfigurowania wychodzących adresów IP lub prefiksów adresów IP dla ruchu wychodzącego.

Aktualizowanie klastra przy użyciu własnego publicznego adresu IP ruchu wychodzącego

Użyj polecenia , az network public-ip show aby wyświetlić listę identyfikatorów publicznych adresów IP.

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

Powyższe polecenie pokazuje identyfikator publicznego adresu IP myPublicIP w grupie zasobów myResourceGroup .

az aks update Użyj polecenia z parametrem load-balancer-outbound-ips , aby zaktualizować klaster za pomocą publicznych adresów IP.

W poniższym przykładzie użyto parametru load-balancer-outbound-ips z identyfikatorami z poprzedniego polecenia.

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

Aktualizowanie klastra przy użyciu własnego prefiksu publicznego adresu IP dla ruchu wychodzącego

Możesz również użyć publicznych prefiksów adresów IP dla ruchu wychodzącego z modułem równoważenia obciążenia jednostki SKU w warstwie Standardowa . W poniższym przykładzie użyto polecenia az network public-ip prefix show , aby wyświetlić listę identyfikatorów prefiksów publicznych adresów IP.

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

Powyższe polecenie pokazuje identyfikator publicznego prefiksu IP myPublicIPPrefix w grupie zasobów myResourceGroup .

W poniższym przykładzie użyto parametru load-balancer-outbound-ip-prefixes z identyfikatorami z poprzedniego polecenia.

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

Tworzenie klastra przy użyciu własnego publicznego adresu IP lub prefiksów

Podczas tworzenia klastra możesz wprowadzić własne adresy IP lub prefiksy adresów IP dla ruchu wychodzącego w celu obsługi scenariuszy, takich jak dodawanie punktów końcowych ruchu wychodzącego do listy dozwolonych. Aby zdefiniować własne publiczne adresy IP i prefiksy IP w czasie tworzenia klastra, dołącz te same parametry pokazane w poprzednim poleceniu.

az aks create Użyj polecenia z parametrem , load-balancer-outbound-ips aby utworzyć nowy klaster z własnymi publicznymi adresami IP.

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

az aks create Użyj polecenia z parametrem , load-balancer-outbound-ip-prefixes aby utworzyć nowy klaster z własnymi prefiksami publicznych adresów IP.

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

Konfigurowanie przydzielonych portów wychodzących

Ważne

Jeśli masz aplikacje w klastrze, które mogą ustanowić dużą liczbę połączeń z małym zestawem miejsc docelowych, takich jak wiele wystąpień aplikacji frontonu łączącej się z bazą danych, może wystąpić scenariusz podatny na wyczerpanie portów SNAT. Wyczerpanie portów SNAT występuje, gdy aplikacja kończy się z portów wychodzących do użycia w celu nawiązania połączenia z inną aplikacją lub hostem. Jeśli istnieje scenariusz podatny na wyczerpanie portów SNAT, zdecydowanie zalecamy zwiększenie przydzielonych portów wychodzących i wychodzących adresów IP frontonu w module równoważenia obciążenia.

Aby uzyskać więcej informacji na temat protokołu SNAT, zobacz Use SNAT for outbound connections (Używanie protokołu SNAT dla połączeń wychodzących).

Domyślnie usługa AKS ustawia wartość AllocatedOutboundPorts dla modułu równoważenia obciążenia na 0wartość , co umożliwia automatyczne przypisywanie portów wychodzących na podstawie rozmiaru puli zaplecza podczas tworzenia klastra. Jeśli na przykład klaster ma co najmniej 50 węzłów, do każdego węzła przydzielono 1024 porty. Wraz ze wzrostem liczby węzłów w klastrze liczba dostępnych portów na węzeł.

Ważne

Istnieje sztywny limit 1024 portów niezależnie od tego, czy adresy IP frontonu są dodawane, gdy rozmiar węzła jest mniejszy lub równy 50 (1–50).

Aby wyświetlić wartość AllocatedOutboundPorts dla modułu równoważenia obciążenia klastra usługi AKS, użyj polecenia az network lb outbound-rule list.

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

Poniższe przykładowe dane wyjściowe pokazują, że automatyczne przypisanie portu wychodzącego na podstawie rozmiaru puli zaplecza jest włączone dla klastra.

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

Aby skonfigurować określoną wartość dla wartości AllocatedOutboundPorts i wychodzącego adresu IP podczas tworzenia lub aktualizowania klastra, użyj polecenia load-balancer-outbound-ports i load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipslub load-balancer-outbound-ip-prefixes. Przed ustawieniem określonej wartości lub zwiększenie istniejącej wartości dla portów wychodzących lub wychodzących adresów IP należy obliczyć odpowiednią liczbę portów wychodzących i adresów IP. Użyj następującego równania dla tego obliczenia zaokrąglonego do najbliższej liczby całkowitej: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Podczas obliczania liczby portów wychodzących i adresów IP oraz ustawiania wartości należy pamiętać o następujących informacjach:

• Liczba portów wychodzących na węzeł jest stała na podstawie ustawionej wartości.
• Wartość portów wychodzących musi być wielokrotną 8.
• Dodanie większej liczby adresów IP nie powoduje dodania większej liczby portów do żadnego węzła, ale zapewnia pojemność dla większej liczby węzłów w klastrze.
• Należy uwzględnić węzły, które mogą zostać dodane w ramach uaktualnień, w tym liczbę węzłów określonych za pomocą wartości maxSurge.

W poniższych przykładach pokazano, jak ustawione wartości wpływają na liczbę portów wychodzących i adresów IP:

• Jeśli są używane wartości domyślne, a klaster ma 48 węzłów, każdy węzeł ma dostępne 1024 porty.
• Jeśli są używane wartości domyślne, a klaster skaluje się z 48 do 52 węzłów, każdy węzeł jest aktualizowany z 1024 portów dostępnych do 512 dostępnych portów.
• Jeśli liczba portów wychodzących jest ustawiona na 1000, a liczba wychodzących adresów IP jest ustawiona na 2, klaster może obsługiwać maksymalnie 128 węzłów: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
• Jeśli liczba portów wychodzących jest ustawiona na 1000, a liczba wychodzących adresów IP jest ustawiona na 7, klaster może obsługiwać maksymalnie 448 węzłów: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
• Jeśli liczba portów wychodzących jest ustawiona na 4000, a liczba wychodzących adresów IP jest ustawiona na 2, klaster może obsługiwać maksymalnie 32 węzły: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
• Jeśli liczba portów wychodzących jest ustawiona na 4000, a liczba wychodzących adresów IP jest ustawiona na 7, klaster może obsługiwać maksymalnie 112 węzłów: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Ważne

Po obliczeniu liczby portów wychodzących i adresów IP sprawdź, czy masz dodatkową pojemność portu wychodzącego, aby obsłużyć wzrost liczby węzłów podczas uaktualniania. Niezwykle ważne jest przydzielenie wystarczającej nadmiarowej liczby portów dla dodatkowych węzłów potrzebnych do uaktualnienia i innych operacji. Usługa AKS domyślnie używa jednego węzła buforu na potrzeby operacji uaktualniania. Jeśli używasz wartości maxSurge, pomnóż porty wychodzące na węzeł przez wartość maxSurge, aby określić wymaganą liczbę portów. Jeśli na przykład obliczysz, że potrzebujesz 4000 portów na węzeł z 7 adresami IP w klastrze z maksymalnie 100 węzłami i maksymalnym wzrostem wynoszącym 2:

• 2 węzły przepięcia * 4000 portów na węzeł = 8000 portów wymaganych do wzrostu węzła podczas uaktualniania.
• 100 węzłów * 4000 portów na węzeł = 400 000 portów wymaganych dla klastra.
• 7 adresów IP * 64000 portów na adres IP = 448 000 portów dostępnych dla klastra.

W powyższym przykładzie pokazano, że klaster ma nadmiarową pojemność 48 000 portów, co jest wystarczające do obsługi 8000 portów wymaganych do wzrostu węzła podczas uaktualniania.

Po obliczeniu i zweryfikowaniu wartości można zastosować te wartości przy użyciu wartości load-balancer-outbound-ports i load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipslub load-balancer-outbound-ip-prefixes podczas tworzenia lub aktualizowania klastra.

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

Konfigurowanie limitu czasu bezczynności modułu równoważenia obciążenia

Po wyczerpaniu zasobów portów SNAT przepływy wychodzące kończą się niepowodzeniem, dopóki istniejące przepływy nie zwolnią portów SNAT. Moduł równoważenia obciążenia odzyskuje porty SNAT po zamknięciu przepływu, a skonfigurowany przez usługę AKS moduł równoważenia obciążenia używa 30-minutowego limitu czasu bezczynności na potrzeby odzyskiwania portów SNAT z przepływów bezczynnych.

Możesz również użyć transportu (na przykład TCP keepalives lub application-layer keepalives), aby odświeżyć przepływ bezczynności i zresetować ten limit czasu bezczynności, jeśli to konieczne. Ten limit czasu można skonfigurować zgodnie z poniższym przykładem.

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

Jeśli oczekujesz, że masz wiele krótkotrwałych połączeń i nie masz długotrwałych połączeń, które mogą mieć długi czas bezczynności, na przykład przy użyciu kubectl proxy lub kubectl port-forward, rozważ użycie niskiej wartości limitu czasu, takiej jak 4 minuty. W przypadku korzystania z elementów utrzymania tcp wystarczy włączyć je po jednej stronie połączenia. Na przykład wystarczy włączyć je po stronie serwera tylko w celu zresetowania czasomierza bezczynności przepływu. Nie jest konieczne, aby obie strony uruchamiały keepalives PROTOKOŁU TCP. Istnieją podobne pojęcia dotyczące warstwy aplikacji, w tym konfiguracje klient-serwer bazy danych. Sprawdź stronę serwera, aby dowiedzieć się, jakie opcje istnieją dla zachowań specyficznych dla aplikacji.

Ważne

Usługa AKS domyślnie włącza resetowanie protokołu TCP w stanie bezczynności. Zalecamy zachowanie tej konfiguracji i wykorzystanie jej w celu zapewnienia bardziej przewidywalnego zachowania aplikacji w scenariuszach.

Protokół TCP RST jest wysyłany tylko podczas połączenia TCP w stanie ESTABLISHED. Więcej informacji na ten temat znajduje się tutaj.

Podczas ustawiania wartości IdleTimeoutInMinutes na inną wartość niż domyślna 30 minut należy wziąć pod uwagę, jak długo obciążenia potrzebują połączenia wychodzącego. Należy również wziąć pod uwagę, że domyślna wartość limitu czasu dla modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa używana poza usługą AKS wynosi 4 minuty. Wartość IdleTimeoutInMinutes, która dokładniej odzwierciedla określone obciążenie usługi AKS, może pomóc zmniejszyć wyczerpanie SNAT spowodowane przez wiązanie połączeń, które nie są już używane.

Ostrzeżenie

Zmiana wartości dla wartości AllocatedOutboundPorts i IdleTimeoutInMinutes może znacząco zmienić zachowanie reguły ruchu wychodzącego dla modułu równoważenia obciążenia i nie powinno być wykonywane lekko. Zapoznaj się z sekcją Rozwiązywanie problemów z usługą SNAT i przejrzyj reguły ruchu wychodzącego i połączeń wychodzących usługi Load Balancer na platformie Azure przed zaktualizowaniem tych wartości, aby w pełni zrozumieć wpływ zmian.

Ograniczanie ruchu przychodzącego do określonych zakresów adresów IP

Poniższy manifest używa modułu loadBalancerSourceRanges, aby określić nowy zakres adresów IP dla przychodzącego ruchu zewnętrznego.

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

W tym przykładzie reguła aktualizuje regułę tak, aby zezwalała na przychodzący ruch zewnętrzny tylko z MY_EXTERNAL_IP_RANGE zakresu. W przypadku zamiany MY_EXTERNAL_IP_RANGE na wewnętrzny adres IP podsieci ruch jest ograniczony tylko do wewnętrznych adresów IP klastra. Jeśli ruch jest ograniczony do wewnętrznych adresów IP klastra, klienci spoza klastra Kubernetes nie mogą uzyskać dostępu do modułu równoważenia obciążenia.

Uwaga

• Przychodzący ruch zewnętrzny przepływa z modułu równoważenia obciążenia do sieci wirtualnej dla klastra usługi AKS. Sieć wirtualna ma sieciową grupę zabezpieczeń, która zezwala na cały ruch przychodzący z modułu równoważenia obciążenia. Ta sieciowa grupa zabezpieczeń używa tagu usługi typu LoadBalancer , aby zezwolić na ruch z modułu równoważenia obciążenia.
• Zasobnik CIDR należy dodać do elementu loadBalancerSourceRanges, jeśli istnieją zasobniki wymagające dostępu do adresu IP modułu LoadBalancer usługi dla klastrów w wersji 1.25 lub nowszej.

Obsługa adresu IP klienta w połączeniach przychodzących

Domyślnie usługa typu LoadBalancerKubernetes i w usłudze AKS nie utrwala adresu IP klienta w połączeniu z zasobnikiem. Źródłowy adres IP pakietu dostarczonego do zasobnika staje się prywatnym adresem IP węzła. Aby zachować adres IP klienta, musisz ustawić wartość service.spec.externalTrafficPolicy w local definicji usługi. Poniższy manifest przedstawia przykład.

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

Dostosowania za pomocą adnotacji kubernetes

Następujące adnotacje są obsługiwane w przypadku usług Kubernetes o typie LoadBalanceri dotyczą tylko przepływów PRZYCHODZĄCYch .

Annotation	Wartość	Opis
service.beta.kubernetes.io/azure-load-balancer-internal	true lub false	Określ, czy moduł równoważenia obciążenia powinien być wewnętrzny. Jeśli nie zostanie ustawiona, zostanie ustawiona wartość domyślna na publiczną.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet	Nazwa podsieci	Określ podsieć, z którą ma być powiązany wewnętrzny moduł równoważenia obciążenia. Jeśli nie zostanie ustawiona, zostanie ona domyślnie ustawiona na podsieć skonfigurowaną w pliku konfiguracji chmury.
service.beta.kubernetes.io/azure-dns-label-name	Nazwa etykiety DNS na publicznych adresach IP	Określ nazwę etykiety DNS dla usługi publicznej. Jeśli jest on ustawiony na pusty ciąg, wpis DNS w publicznym adresie IP nie jest używany.
service.beta.kubernetes.io/azure-shared-securityrule	true lub false	Określ uwidacznianie usługi za pośrednictwem potencjalnie udostępnionej reguły zabezpieczeń platformy Azure w celu zwiększenia narażenia na usługę przy użyciu rozszerzonych reguł zabezpieczeń platformy Azure w sieciowych grupach zabezpieczeń.
service.beta.kubernetes.io/azure-load-balancer-resource-group	Nazwa grupy zasobów	Określ grupę zasobów publicznych adresów IP modułu równoważenia obciążenia, które nie są w tej samej grupie zasobów co infrastruktura klastra (grupa zasobów węzła).
service.beta.kubernetes.io/azure-allowed-service-tags	Lista dozwolonych tagów usługi	Określ listę dozwolonych tagów usługi rozdzielonych przecinkami .
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout	Limity czasu bezczynności protokołu TCP w minutach	Określ czas w minutach przekroczenia limitu czasu bezczynności połączenia TCP w module równoważenia obciążenia. Wartość domyślna i minimalna to 4. Maksymalna wartość to 30. Wartość musi być liczbą całkowitą.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset	true lub false	Określ, czy moduł równoważenia obciążenia powinien wyłączyć resetowanie protokołu TCP w przypadku limitu czasu bezczynności.
service.beta.kubernetes.io/azure-load-balancer-ipv4	Adres IPv4	Określ adres IPv4, który ma zostać przypisany do modułu równoważenia obciążenia.
service.beta.kubernetes.io/azure-load-balancer-ipv6	Adres IPv6	Określ adres IPv6, który ma zostać przypisany do modułu równoważenia obciążenia.

Dostosowywanie sondy kondycji modułu równoważenia obciążenia

Annotation	Wartość	Opis
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	Interwał sondy kondycji
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Minimalna liczba odpowiedzi sondy kondycji w złej kondycji
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Ścieżka żądania sondy kondycji
service.beta.kubernetes.io/port_{port}_no_lb_rule	prawda/fałsz	{port} to numer portu usługi. W przypadku ustawienia wartości true nie jest generowana żadna reguła modułu równoważenia obciążenia ani reguła sondy kondycji dla tego portu. Usługa kontroli kondycji nie powinna być widoczna w publicznym Internecie (np. istio/usługa sprawdzania kondycji wysłana)
service.beta.kubernetes.io/port_{port}_no_probe_rule	prawda/fałsz	{port} to numer portu usługi. W przypadku ustawienia wartości true nie jest generowana żadna reguła sondy kondycji dla tego portu.
service.beta.kubernetes.io/port_{port}_health-probe_protocol	Protokół sondy kondycji	{port} to numer portu usługi. Jawny protokół sondy kondycji dla portu usługi {port}, przesłaniając port.appProtocol w przypadku ustawienia.
service.beta.kubernetes.io/port_{port}_health-probe_port	numer portu lub nazwa portu w manifeście usługi	{port} to numer portu usługi. Jawny port sondy kondycji dla portu usługi {port}, przesłaniając wartość domyślną.
service.beta.kubernetes.io/port_{port}_health-probe_interval	Interwał sondy kondycji	{port} to numer portu usługi.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	Minimalna liczba odpowiedzi sondy kondycji w złej kondycji	{port} to numer portu usługi.
service.beta.kubernetes.io/port_{port}_health-probe_request-path	Ścieżka żądania sondy kondycji	{port} to numer portu usługi.

Zgodnie z opisem w tym miejscu protokoły Tcp, Http i Https są trzema protokołami obsługiwanymi przez usługę modułu równoważenia obciążenia.

Obecnie domyślny protokół sondy kondycji różni się między usługami z różnymi protokołami transportu, protokołami aplikacji, adnotacjami i zasadami ruchu zewnętrznego.

1. w przypadku usług lokalnych używane będą protokoły HTTP i /healthz. Sonda kondycji wykona zapytanie dotyczące węzłaHealthPort, a nie rzeczywistej usługi zaplecza
2. w przypadku usług TCP klastra używany jest protokół TCP.
3. w przypadku usług UDP klastra nie ma sond kondycji.

Uwaga

W przypadku usług lokalnych z włączoną integracją PLS i protokołem proxy PLS domyślna sonda kondycji HTTP+/healthz nie działa. W związku z tym sonda kondycji może być dostosowywana w taki sam sposób, jak usługi klastra do obsługi tego scenariusza.

Od wersji 1.20 adnotacja service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path usługi jest wprowadzana w celu określenia zachowania sondy kondycji.

• W przypadku klastrów <=1.23 spec.ports.appProtocol będzie używany tylko jako protokół sondy, gdy service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path jest również ustawiony.
• W przypadku klastrów >1.24 spec.ports.appProtocol będzie używany jako protokół sondy i / będzie używany jako domyślna ścieżka żądania sondy (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path może służyć do zmiany na inną ścieżkę żądania).

Należy pamiętać, że ścieżka żądania zostanie zignorowana podczas korzystania z protokołu TCP lub parametru jest pusta spec.ports.appProtocol . W szczególności:

jednostka SKU modułu równoważenia obciążenia	externalTrafficPolicy	spec.ports.Protocol	spec.ports.AppProtocol	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Protokół sondy modułu równoważenia obciążenia	Ścieżka żądania sondy modułu równoważenia obciążenia
standardowa	local	dowolny	dowolny	dowolny	http	/healthz
standardowa	cluster	Udp	dowolny	dowolny	null	null
standardowa	cluster	tcp		(ignorowane)	tcp	null
standardowa	cluster	tcp	tcp	(ignorowane)	tcp	null
standardowa	cluster	tcp	http/https		TCP(<=1.23) lub http/https(>=1.24)	null(<=1.23) lub /(>=1.24)
standardowa	cluster	tcp	http/https	/custom-path	http/https	/custom-path
standardowa	cluster	tcp	nieobsługiwany protokół	/custom-path	tcp	null
Podstawowe	local	dowolny	dowolny	dowolny	http	/healthz
Podstawowe	cluster	tcp		(ignorowane)	tcp	null
Podstawowe	cluster	tcp	tcp	(ignorowane)	tcp	null
Podstawowe	cluster	tcp	http		TCP(<=1.23) lub http/https(>=1.24)	null(<=1.23) lub /(>=1.24)
Podstawowe	cluster	tcp	http	/custom-path	http	/custom-path
Podstawowe	cluster	tcp	nieobsługiwany protokół	/custom-path	tcp	null

Od wersji 1.21 wprowadzono dwie adnotacje service.beta.kubernetes.io/azure-load-balancer-health-probe-interval usługi, load-balancer-health-probe-num-of-probe które dostosowują konfigurację sondy kondycji. Jeśli service.beta.kubernetes.io/azure-load-balancer-health-probe-interval nie zostanie ustawiona, zostanie zastosowana wartość domyślna 5. Jeśli load-balancer-health-probe-num-of-probe nie zostanie ustawiona, zostanie zastosowana wartość domyślna 2. Całkowita sonda powinna być mniejsza niż 120 sekund.

Niestandardowa sonda kondycji modułu równoważenia obciążenia dla portu

Różne porty w usłudze mogą wymagać różnych konfiguracji sondy kondycji. Może to być spowodowane projektem usługi (takim jak pojedynczy punkt końcowy kondycji kontrolujący wiele portów) lub funkcjami kubernetes, takimi jak MixedProtocolLBService.

Poniższe adnotacje mogą służyć do dostosowywania konfiguracji sondy na port usługi.

adnotacja specyficzna dla portu	adnotacja sondy globalnej	Użycie
service.beta.kubernetes.io/port_{port}_no_lb_rule	N/A (nie jest równoważna globalnie)	jeśli ustawiono wartość true, nie zostaną wygenerowane żadne reguły modułu równoważenia obciążenia i reguły sondy
service.beta.kubernetes.io/port_{port}_no_probe_rule	N/A (nie jest równoważna globalnie)	jeśli ustawiono wartość true, nie zostaną wygenerowane żadne reguły sondy
service.beta.kubernetes.io/port_{port}_health-probe_protocol	N/A (nie jest równoważna globalnie)	Ustaw protokół sondy kondycji dla tego portu usługi (np. Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port	N/A (nie jest równoważna globalnie)	Ustawia port sondy kondycji dla tego portu usługi (np. 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	W przypadku protokołu Http lub Https ustawia ścieżkę żądania sondy kondycji. Wartości domyślne do /
service.beta.kubernetes.io/port_{port}_health-probe_num-sondy	service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Liczba kolejnych niepowodzeń sondy przed rozważenie złej kondycji portu
service.beta.kubernetes.io/port_{port}_health-probe_interval	service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	Ilość czasu między próbami sondy

W przypadku następującego manifestu reguła sondy dla portu httpsserver różni się od tej dla serwera httpserver, ponieważ określono adnotacje dla serwera httpsserver portów.

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

W tym manifeście porty https używają innego portu węzła, sprawdzania gotowości PROTOKOŁU HTTP na porcie 10256 na /healthz(healthz endpoint of 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

W tym manifeście porty https używają innego punktu końcowego sondy kondycji, sprawdzania gotowości PROTOKOŁU HTTP na porcie 30000 na /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

Rozwiązywanie problemów z protokołem SNAT

Jeśli wiesz, że uruchamiasz wiele wychodzących połączeń TCP lub UDP z tym samym docelowym adresem IP i portem, a zauważysz, że kończy się niepowodzeniem połączeń wychodzących lub obsługa powiadamia o wyczerpaniu portów SNAT (wstępnie przeniesionych portów efemerycznych używanych przez pat), masz kilka ogólnych opcji ograniczania ryzyka. Przejrzyj te opcje i zdecyduj, co jest najlepsze dla danego scenariusza. Możliwe, że co najmniej jeden może pomóc w zarządzaniu scenariuszem. Aby uzyskać szczegółowe informacje, zapoznaj się z przewodnikiem rozwiązywania problemów z połączeniami wychodzącym.

Główną przyczyną wyczerpania SNAT jest często antywzór dotyczący tego, jak jest ustanawiana łączność wychodząca, zarządzana lub konfigurowalna czasomierze zmienia się z ich wartości domyślnych. Uważnie przejrzyj tę sekcję.

Kroki

1. Sprawdź, czy połączenia pozostają bezczynne przez długi czas i polegają na domyślnym upłynął limit czasu bezczynności w celu zwolnienia tego portu. Jeśli tak, może być konieczne zmniejszenie domyślnego limitu czasu 30 minut dla danego scenariusza.
2. Sprawdź, jak aplikacja tworzy łączność wychodzącą (na przykład przegląd kodu lub przechwytywanie pakietów).
3. Ustal, czy to działanie jest oczekiwane, czy aplikacja działa nieprawidłowo. Użyj metryk i dzienników w usłudze Azure Monitor, aby uzasadnić wyniki. Na przykład użyj kategorii "Niepowodzenie" dla metryki połączeń SNAT.
4. Oceń, czy są przestrzegane odpowiednie wzorce .
5. Sprawdź, czy wyczerpanie portów SNAT powinno zostać złagodzone przy użyciu większej liczby wychodzących adresów IP i większej liczby przydzielonych portów wychodzących.

Wzorce projektowe

Korzystaj z ponownego użycia połączenia i buforowania połączeń, jeśli jest to możliwe. Te wzorce pomagają uniknąć problemów z wyczerpaniem zasobów i spowodować przewidywalne zachowanie. Elementy pierwotne dla tych wzorców można znaleźć w wielu bibliotekach i strukturach programistycznych.

• Żądania niepodzielne (jedno żądanie na połączenie) zazwyczaj nie są dobrym wyborem projektowym. Takie anty-wzorce ograniczają skalę, zmniejszają wydajność i zmniejszają niezawodność. Zamiast tego użyj ponownie połączeń HTTP/S, aby zmniejszyć liczbę połączeń i skojarzonych portów SNAT. Skalowanie aplikacji zwiększa się i poprawia wydajność z powodu zmniejszonych uścisków dłoni, narzutów i kosztów operacji kryptograficznych podczas korzystania z protokołu TLS.
• Jeśli korzystasz z klastra/niestandardowego serwera DNS lub niestandardowych serwerów nadrzędnych w podstawowej sieciDNS, pamiętaj, że usługa DNS może wprowadzać wiele indywidualnych przepływów na woluminie, gdy klient nie buforuje wyniku rozpoznawania nazw DNS. Pamiętaj, aby najpierw dostosować coreDNS zamiast używać niestandardowych serwerów DNS i zdefiniować dobrą wartość buforowania.
• Przepływy UDP (na przykład wyszukiwania DNS) przydzielają porty SNAT podczas limitu czasu bezczynności. Im dłuższy limit czasu bezczynności, tym większe jest wykorzystanie portów SNAT. Użyj krótkiego limitu czasu bezczynności (na przykład 4 minuty).
• Użyj pul połączeń, aby kształtować wolumin połączenia.
• Nigdy nie porzucaj przepływu TCP w trybie dyskretnym i polegaj na czasomierzach TCP w celu oczyszczenia przepływu. Jeśli nie zezwolisz na jawne zamknięcie połączenia przez protokół TCP, stan pozostanie przydzielony w systemach pośrednich i punktach końcowych i sprawia, że porty SNAT są niedostępne dla innych połączeń. Ten wzorzec może wyzwalać błędy aplikacji i wyczerpanie SNAT.
• Nie zmieniaj wartości czasomierza związanego z zamknięciem protokołu TCP na poziomie systemu operacyjnego bez specjalistycznej wiedzy na temat wpływu. Podczas odzyskiwania stosu TCP wydajność aplikacji może mieć negatywny wpływ, gdy punkty końcowe połączenia mają niezgodne oczekiwania. Zmiana czasomierzy jest zwykle oznaką podstawowego problemu projektowego. Zapoznaj się z poniższymi zaleceniami.

Przenoszenie z podstawowego modułu równoważenia obciążenia jednostki SKU do jednostki SKU w warstwie Standardowa

Jeśli masz istniejący klaster z modułem równoważenia obciążenia jednostki SKU w warstwie Podstawowa , podczas migracji do modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa należy pamiętać o ważnych różnicach behawioralnych.

Na przykład tworzenie niebieskich/zielonych wdrożeń w celu migracji klastrów jest powszechną praktyką, biorąc pod uwagę load-balancer-sku typ klastra i można je zdefiniować tylko w czasie tworzenia klastra. Jednak moduły równoważenia obciążenia jednostki SKU w warstwie Podstawowa używają adresów IP jednostek SKU w warstwie Podstawowa, które nie są zgodne z modułami równoważenia obciążenia jednostki SKU w warstwie Standardowa. Moduły równoważenia obciążenia jednostki SKU w warstwie Standardowa wymagają adresów IP jednostek SKU w warstwie Standardowa. Podczas migrowania klastrów do uaktualniania jednostek SKU modułu równoważenia obciążenia wymagany jest nowy adres IP z zgodną jednostkę SKU adresu IP.

Aby uzyskać więcej informacji na temat migrowania klastrów, zapoznaj się z naszą dokumentacją dotyczącą zagadnień dotyczących migracji.

Ograniczenia

Podczas tworzenia klastrów usługi AKS i zarządzania nimi obowiązują następujące ograniczenia, które obsługują moduł równoważenia obciążenia przy użyciu jednostki SKU w warstwie Standardowa :

• Do zezwalania na ruch wychodzący z klastra usługi AKS wymagany jest co najmniej jeden publiczny adres IP lub prefiks adresu IP. Publiczny adres IP lub prefiks IP jest wymagany do utrzymania łączności między płaszczyzną sterowania a węzłami agenta oraz utrzymania zgodności z poprzednimi wersjami usługi AKS. Dostępne są następujące opcje określania publicznych adresów IP lub prefiksów adresów IP przy użyciu modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa :
  • Podaj własne publiczne adresy IP.
  • Podaj własne prefiksy publicznego adresu IP.
  • Określ liczbę do 100, aby umożliwić klastrowi usługi AKS utworzenie wielu publicznych adresów IP jednostki SKU w warstwie Standardowa w tej samej grupie zasobów co klaster usługi AKS. Ta grupa zasobów jest zwykle nazwana przy użyciu MC_ na początku. Usługa AKS przypisuje publiczny adres IP do modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa . Domyślnie jeden publiczny adres IP jest automatycznie tworzony w tej samej grupie zasobów co klaster usługi AKS, jeśli nie określono publicznego adresu IP, prefiksu publicznego adresu IP lub liczby adresów IP. Należy również zezwolić na publiczne adresy i uniknąć tworzenia zasad platformy Azure, które zakazują tworzenia adresów IP.
• Publiczny adres IP utworzony przez usługę AKS nie może być ponownie używany jako niestandardowy publiczny adres IP. Użytkownicy muszą tworzyć wszystkie niestandardowe adresy IP i zarządzać nimi.
• Definiowanie jednostki SKU modułu równoważenia obciążenia można wykonać tylko podczas tworzenia klastra usługi AKS. Nie można zmienić jednostki SKU modułu równoważenia obciążenia po utworzeniu klastra usługi AKS.
• W jednym klastrze można używać tylko jednego typu jednostki SKU modułu równoważenia obciążenia (Podstawowa lub Standardowa).
• Moduły równoważenia obciążenia jednostki SKU w warstwie Standardowa obsługują tylko adresy IP jednostek SKU w warstwie Standardowa.

Następne kroki

Aby dowiedzieć się więcej na temat usług Kubernetes, zobacz dokumentację usług Kubernetes.

Aby dowiedzieć się więcej na temat korzystania z wewnętrznego modułu równoważenia obciążenia dla ruchu przychodzącego, zobacz dokumentację wewnętrznego modułu równoważenia obciążenia usługi AKS.