Konfigurowanie publicznego standardowego równoważnika obciążenia w Azure Kubernetes Service (AKS)

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ą standardowego modułu równoważenia obciążenia można:

Ważne

W danym momencie można użyć tylko jednej opcji wychodzącego adresu IP (zarządzanych adresów IP, własnego adresu IP lub prefiksu IP).

Zanim rozpoczniesz

Aby utworzyć i wdrożyć usługę równoważenia obciążenia w usłudze AKS, wykonaj kroki opisane w artykule Korzystanie z publicznego modułu równoważenia obciążenia w warstwie Standard w Azure Kubernetes Service (AKS).

Zmień typ puli przychodzącej

Do węzłów AKS w pulach zaplecza modułu równoważenia obciążenia można odwoływać się za pomocą ich konfiguracji IP (członkostwo oparte na zestawach skalowania maszyn wirtualnych) lub wyłącznie za pomocą ich adresu IP. Członkostwo w puli zaplecza oparte na adresach IP zapewnia wyższą wydajność podczas aktualizowania usług i aprowizacji modułów równoważenia obciążenia, szczególnie w przypadku dużych liczby węzłów. W połączeniu z NAT Gateway lub typami ruchu wychodzącego z routingiem zdefiniowanym przez użytkownika aprowizowanie nowych węzłów i usług przebiega wydajniej.

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

  • nodeIPConfiguration: Dziedziczny typ członkostwa w puli oparty na konfiguracji IP dla Virtual Machine Scale Sets.
  • nodeIP: typ członkostwa oparty na adresach IP.

Wymagania dotyczące zmiany typu puli przychodzącej

Przed zmianą typu puli przychodzącej upewnij się, że spełnisz następujące wymagania:

  • Klaster usługi AKS musi być w wersji 1.23 lub nowszej.
  • Klaster AKS musi używać standardowych modułów równoważenia obciążenia i zestawów skalowania maszyn wirtualnych.
  • Jeśli używasz usługi Azure Private Link Service, używasz typu nodeIPConfiguration puli zaplecza. Private Link Service nie obsługuje pul zaplecza modułu równoważenia obciążenia opartych na adresach IP.

Utwórz klaster AKS z członkostwem w puli ruchu przychodzącego opartym na adresie IP za pomocą polecenia az aks create z parametrem --load-balancer-backend-pool-type=nodeIP.

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-backend-pool-type=nodeIP \
    --generate-ssh-keys

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

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 frontowe + parametry + pula zaplecza

Reguła wychodząca konfiguruje NAT dla wszystkich maszyn wirtualnych zidentyfikowanych przez pulę backendu do tłumaczenia na front-end. Parametry zapewniają większą kontrolę nad algorytmem wychodzącego NAT.

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ą konfigurację. Można użyć wielu adresów IP, aby zaplanować scenariusze na dużą skalę i zminimalizować zasady dotyczące ruchu wychodzącego w celu ograniczenia wzorców zagrożonych wyczerpaniem SNAT. Każdy adres IP udostępniany przez frontend zapewnia 64k portów tymczasowych dla równoważnika obciążenia do użycia jako porty 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 .

Ważne

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

Zmiany reguł ruchu wychodzącego wprowadzone bezpośrednio w zasobie równoważnika obciążenia są usuwane za każdym razem, gdy klaster zostaje zrekonfigurowany, na przykład po zatrzymaniu, ponownym uruchomieniu, uaktualnieniu lub skalowaniu.

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

Aby uzyskać więcej informacji, zobacz reguły wychodzące dla Azure Load Balancer.

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

Utwórz nowy klaster AKS z określoną liczbą zarządzanych publicznych adresów IP dla ruchu wychodzącego za pomocą polecenia az aks create z parametrem --load-balancer-managed-outbound-ip-count. W poniższym przykładzie ustawiono liczbę zarządzanych publicznych adresów IP dla ruchu wychodzącego na dwa.

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-managed-outbound-ip-count 2 \
    --generate-ssh-keys

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

W przypadku korzystania z standardowego modułu równoważenia obciążenia SKU, klaster AKS automatycznie tworzy publiczny adres IP w grupie zasobów w infrastrukturze zarządzanej przez AKS i przypisuje go domyślnie 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. Twoje niestandardowe adresy IP można również zaktualizować we właściwościach równoważnika obciążenia istniejącego klastra.

Wymagania dotyczące używania własnych publicznych adresów IP lub prefiksów dla ruchu wychodzącego

Przed udostępnieniem własnych publicznych adresów IP lub prefiksów dla ruchu wychodzącego upewnij się, że spełnisz następujące wymagania:

  • Musisz utworzyć i posiadać niestandardowe publiczne adresy IP. Nie można ponownie użyć zarządzanych publicznych adresów IP utworzonych przez usługę AKS jako "przynieś własny niestandardowy adres IP", ponieważ może to powodować konflikty zarządzania.
  • Upewnij się, że tożsamość klastra AKS ma uprawnienia dostępu do wychodzącego adresu IP zgodnie z wymaganą listą uprawnień do 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.

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

Utwórz nowy klaster AKS z własnymi publicznymi adresami IP dla ruchu wychodzącego za pomocą polecenia az aks create z parametrem --load-balancer-outbound-ips. Zastąp wartości zastępcze własnymi.

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-outbound-ips $PUBLIC_IP_ID1,$PUBLIC_IP_ID2 \
    --generate-ssh-keys

Podaj własne prefiksy publicznych adresów IP dla ruchu wychodzącego

Utwórz nowy klaster usługi AKS z własnymi prefiksami publicznych adresów IP dla ruchu wychodzącego za pomocą polecenia az aks create z parametrem --load-balancer-outbound-ip-prefixes. Zastąp wartości zastępcze własnymi.

az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --load-balancer-outbound-ip-prefixes $PUBLIC_IP_PREFIX_ID1,$PUBLIC_IP_PREFIX_ID2 \
    --generate-ssh-keys

Konfigurowanie przydzielonych portów wychodzących

Ważne

Jeśli masz aplikacje w klastrze, które mogą nawiązać dużą liczbę połączeń z niewielką liczbą miejsc docelowych na publicznych adresach IP, takich jak wiele wystąpień aplikacji frontendowej łączącej się z bazą danych, może dojść do wyczerpania portów SNAT. Wyczerpanie portów SNAT występuje, gdy aplikacji zabraknie portów wychodzących, aby ustanowić połączenie 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 AKS ustawia parametr AllocatedOutboundPorts swojego load balancera na 0, co umożliwia automatyczne przypisywanie portów wychodzących na podstawie wielkości puli zaplecza podczas tworzenia klastra. Na przykład, jeśli klaster ma 50 lub mniej węzłów, do każdego węzła przydzielono 1024 porty. Ta wartość umożliwia skalowanie do maksymalnej liczby węzłów klastra bez konieczności ponownej konfiguracji sieci, ale może sprawić, że wyczerpanie portów SNAT będzie bardziej powszechne w miarę dodawania większej liczby węzłów. Wraz ze wzrostem liczby węzłów w klastrze, dostępnych portów na węzeł jest mniej. Zwiększenie liczby węzłów przez granice na wykresie (na przykład przejście z 50 do 51 węzłów lub 100 do 101) może zakłócać łączność, ponieważ porty SNAT przydzielone do istniejących węzłów są ograniczone, aby umożliwić więcej węzłów. Zalecamy użycie jawnej wartości dla AllocatedOutboundPorts.

Wyświetlanie bieżących przydzielonych portów wychodzących

Pobierz wartość AllocatedOutboundPorts dla modułu równoważenia obciążenia klastra AKS, używając polecenia az network lb outbound-rule list.

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

Następujące 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

Obliczanie i weryfikowanie wymaganych portów wychodzących i adresów IP

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

Zagadnienia dotyczące obliczania portów wychodzących i adresów IP

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.
  • Musisz uwzględnić węzły, które mogą zostać dodane w ramach uaktualnień, w tym liczbę węzłów określonych przy użyciu wartości maxCount i maxSurge.

Przykłady obliczania portów wychodzących i adresów IP

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 maxSurge wartości, pomnóż porty wychodzące na każdy węzeł przez twoją 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 awaryjne * 4000 portów na węzeł = 8000 portów potrzebnych dla węzłów awaryjnych podczas aktualizacji.
  • 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 tym przykładzie pokazano, że klaster ma nadmiarową pojemność 48 000 portów, co jest wystarczające do obsługi 8000 portów wymaganych do zwiększenia liczby węzłów podczas uaktualniania.

Ustawianie przydzielonych portów wychodzących i wychodzących adresów IP

Po obliczeniu wymaganych portów i adresów IP przy użyciu formuły 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>zastosuj te wartości przy użyciu metod 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.

Utwórz nowy klaster usługi AKS z określonymi portami wychodzącymi i adresami IP przy użyciu az aks create polecenia . Poniższy przykład ustawia parametr --load-balancer-managed-outbound-ip-count na 7, a parametr --load-balancer-outbound-ports na 4000:

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000 \
    --generate-ssh-keys

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

Ostrzeżenie

Zmiana wartości parametrów AllocatedOutboundPorts i IdleTimeoutInMinutes może znacząco zmienić sposób działania reguły ruchu wychodzącego w module równoważenia obciążenia. Zobacz Troubleshoot SNAT i przejrzyj reguły wychodzącego ruchu równoważnika obciążenia i połączenia wychodzące w Azure przed zaktualizowaniem tych wartości, aby w pełni zrozumieć wpływ zmian.

Gdy wyczerpią się zasoby portów SNAT, przepływy wychodzące przestaną działać, dopóki istniejące przepływy nie zwolnią portów SNAT. Moduł równoważenia obciążenia odzyskuje porty SNAT po zamknięciu połączenia, 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 bezczynnych połączeń. 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.

Uwaga / Notatka

30-minutowy limit czasu bezczynności ma zastosowanie do reguły ruchu wychodzącego modułu równoważenia obciążenia i określa moment, w którym bezczynne połączenia wychodzące zwalniają porty SNAT. Ten limit czasu jest niezależny od adnotacji service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout, która konfiguruje limit czasu bezczynności przychodzących połączeń TCP dla pojedynczej usługi LoadBalancer Kubernetes i ma wartość domyślną i minimalną wynoszącą 4 minuty.

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 mechanizmów TCP keepalive 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 rozpoczynały keepalives protokołu TCP. Istnieją podobne pojęcia dotyczące warstwy aplikacji, w tym konfiguracje klient-serwer bazy danych. Sprawdź stronę serwerową, aby dowiedzieć się, jakie opcje istnieją dla keepalives 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. Aby uzyskać więcej informacji, zobacz resetowanie TCP na modułach równoważenia obciążenia Azure.

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 typu SKU Standard używanego 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.

Utwórz nowy klaster AKS z określonym limitem czasu bezczynności za pomocą polecenia az aks create z parametrem --load-balancer-idle-timeout. Poniższy przykład ustawia limit czasu bezczynności na 4 minuty:

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-idle-timeout 4 \
    --generate-ssh-keys

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

W poniższym manifeście określono loadBalancerSourceRanges 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 jest aktualizowana, aby zezwalała na przychodzący ruch zewnętrzny tylko z zakresu MY_EXTERNAL_IP_RANGE. 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 / Notatka

Podczas ograniczania ruchu przychodzącego należy pamiętać o następujących informacjach:

  • Jeśli musisz zezwolić zarówno na bloki CIDR, jak i tagi usługi Azure, usuń właściwość loadBalancerSourceRanges oraz dodaj adnotacje service.beta.kubernetes.io/azure-allowed-ip-ranges i/lub service.beta.kubernetes.io/azure-allowed-service-tags Load Balancer. Ta konfiguracja stosuje filtrowanie wyłącznie na poziomie grupy zabezpieczeń sieciowych (NSG) i pomija reguły kube-proxy na poziomie hosta. Jeśli ustawisz właściwość loadBalancerSourceRanges wraz z adnotacją azure-allowed-service-tags, AKS zgłasza błąd podczas próby zastosowania specyfikacji.
  • Przychodzący ruch zewnętrzny przepływa z równoważnika obciążenia do sieci wirtualnej (VNet) dla klastra 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 Grupa zabezpieczeń sieci używa tagu serwisowego typu LoadBalancer, aby zezwolić na ruch z równoważnika obciążenia."
  • Do loadBalancerSourceRanges należy dodać CIDR zasobnika, jeśli istnieją zasobniki, które muszą uzyskać dostęp do adresu IP usługi Load Balancer dla klastrów z wersją Kubernetes 1.25 lub nowszą.

Utrzymanie adresu IP klienta w połączeniach przychodzących

Domyślnie, usługa typu w Kubernetes i AKS nie utrwala adresu IP klienta w połączeniu z zasobnikiem. Źródłowy adres IP w pakiecie dostarczonym do pod staje się prywatnym adresem IP węzła. Aby zachować adres IP klienta, musisz ustawić service.spec.externalTrafficPolicy na local w 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

Dostosowywanie modułu równoważenia obciążenia przy użyciu adnotacji platformy Kubernetes

Poniższe adnotacje konfigurują sposób obsługi ruchu przychodzącego dla usług Kubernetes LoadBalancer w AKS.

Nazwa adnotacji Zaakceptowane wartości Zachowanie
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 ustawiony, wartość domyślna to 'public'.
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-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-allowed-ip-ranges lista dozwolonych zakresów adresów IP Określ listę dozwolonych zakresów adresów IP 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. Wartość maksymalna to 100. 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 dozwolonych zakresów adresów IP (wersja zapoznawcza)

Możesz użyć adnotacji azure-allowed-service-tags i azure-allowed-ip-ranges, aby połączyć bloki CIDR i tagi usługi Azure na równoważniku obciążenia. Dodaj service.beta.kubernetes.io/azure-allowed-ip-ranges z rozdzielaną przecinkami listą prefiksów adresów IP i dodaj service.beta.kubernetes.io/azure-allowed-service-tags z co najmniej jednym tagiem usługi Azure. Dostawca usług w chmurze usługi AKS scala obie wartości w jedną regułę NSG, więc ruch jest filtrowany centralnie w NSG, zapewniając centralny punkt kontroli NSG dla adresów IP i tagów usług.

Możesz nadal używać loadBalancerSourceRanges właściwości w przypadkach, w których ograniczenia oparte na protokole CIDR są wymuszane zarówno w sieciowej grupie zabezpieczeń, jak i na hoście. Nie można użyć tej właściwości z adnotacją azure-allowed-service-tags . Jeśli oba te elementy są określone, AKS zgłasza błąd podczas próby aplikacji specyfikacji usługi równoważenia obciążenia.

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

Następujące adnotacje są obsługiwane w celu dostosowania zachowania sondy kondycji modułu równoważenia obciążenia:

Adnotacja Wartość Description
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Interwał sondy kondycji Odstęp czasu w sekundach między próbami sondowania. Wartość domyślna to 5 sekund.
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Minimalna liczba niezdrowych odpowiedzi sondy zdrowia Liczba kolejnych niepowodzeń sondy, po której backend jest uznawany za niezdrowy. Wartość domyślna to 2 sondy.
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Ścieżka żądania kontroli kondycji W przypadku sond HTTP lub HTTPS określ ścieżkę rozpoczynającą się od /, na przykład /healthz.
service.beta.kubernetes.io/port_{port}_no_lb_rule true/false {port} to numer portu usługi. W przypadku ustawienia wartości trueparametru nie są generowane żadne reguły modułu równoważenia obciążenia ani sondy kondycji dla tego portu. Usługa kontroli kondycji nie powinna być widoczna w publicznym Internecie.
service.beta.kubernetes.io/port_{port}_no_probe_rule true/false {port} to numer portu usługi. W przypadku ustawienia wartości trueparametru nie są generowane żadne reguły sondy kondycji dla tego portu.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protokół sondy kondycji {port} to numer portu usługi. Jasny protokół sondy sprawdzającej stan 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 zdrowotnej dla portu usługi {port}, zastępują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 niezdrowych odpowiedzi sondy zdrowia {port} to numer portu usługi.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Ścieżka żądania kontroli kondycji {port} to numer portu usługi.

Uwaga / Notatka

Usługa AKS obsługuje teraz udostępnione sondy stanu zdrowia dla externalTrafficPolicy: Cluster Usługi. Aby dowiedzieć się więcej, zobacz Użyj udostępnione sondy kondycji dla externalTrafficPolicy: Cluster Services (wersja zapoznawcza) w Azure Kubernetes Service (AKS).

Domyślne zachowanie sondy kontrolnej kondycji systemu

Obecnie domyślny protokół sondy kondycji różni się pomiędzy usługami z różnymi protokołami transportu i aplikacji, adnotacjami oraz politykami dotyczącymi ruchu zewnętrznego.

  • W przypadku usług lokalnych będą używane protokoły HTTP i /healthz. Sonda kondycji wykona zapytanie NodeHealthPort , a nie rzeczywistą usługę zaplecza.
  • W przypadku usług TCP klastra będzie używany protokół TCP.
  • W przypadku usług UDP klastra nie ma sond zdrowotnych.

Uwaga / Notatka

W przypadku usług lokalnych z włączoną integracją PLS i protokołem proxy PLS domyślna sonda kondycji HTTP i /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.

Oznaczenie ścieżki żądania sondy zdrowotności

Użyj adnotacji usługi service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path, aby określić ścieżkę żądania sondy kondycji. W przypadku obsługiwanych wersji AKS element spec.ports.appProtocol określa protokół sondy. Gdy parametr appProtocol ma wartość http lub https, domyślna ścieżka żądania sondowania to /.

Należy pamiętać, że ścieżka żądania zostanie zignorowana podczas korzystania z protokołu TCP lub gdy spec.ports.appProtocol jest puste. Poniższa tabela zawiera podsumowanie domyślnego zachowania sondy kondycji:

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 LB Ścieżka żądania sondy LB
standard lokalny any any any http /healthz
standard klaster udp any any null null
standard klaster tcp (ignored) tcp null
standard klaster tcp tcp (ignored) tcp null
standard klaster tcp http/https http/https /
standard klaster tcp http/https /custom-path http/https /custom-path
standard klaster tcp nieobsługiwany protokół /custom-path tcp null
Interwał sondy kondycji i liczba adnotacji sond

Użyj adnotacji usługi service.beta.kubernetes.io/azure-load-balancer-health-probe-interval i service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe, aby dostosować konfigurację sondy kondycji. Jeśli nie ustawisz service.beta.kubernetes.io/azure-load-balancer-health-probe-interval, zostanie zastosowana wartość domyślna 5 sekund. Jeśli nie ustawisz service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probeparametru , zostanie zastosowana domyślna wartość 2 sond.

Niestandardowa sonda kondycji Load Balancer dla portu

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

Poniższa tabela zawiera podsumowanie adnotacji specyficznych dla portu, które mogą służyć do zastępowania globalnych adnotacji sondy stanu zdrowia dla określonego portu w usłudze.

Adnotacja specyficzna dla portu Adnotacja sondy globalnej Zachowanie
service.beta.kubernetes.io/port_{port}_no_lb_rule N/A (nie jest równoważna globalnie) Jeśli ustawiono wartość true, nie są generowane żadne reguły modułu równoważenia obciążenia ani sondy.
service.beta.kubernetes.io/port_{port}_no_probe_rule N/A (nie jest równoważna globalnie) Jeśli ustawiono wartość true, nie są generowane żadne reguły sondowania.
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/A (nie jest równoważna globalnie) Ustawia protokół sondy kondycji dla tego portu usługi (na przykład: Http, Https, Tcp).
service.beta.kubernetes.io/port_{port}_health-probe_port N/A (nie jest równoważna globalnie) Ustawia port sondy zdrowia dla tego portu usługi (na przykład: 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 określa ścieżkę żądania sondy zdrowia (domyślnie /).
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Liczba kolejnych niepowodzeń sondy zanim port zostanie uznany za niezdrowy.
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 sondowania.

Wyklucz pulę węzłów z zaplecza Load Balancer

W niektórych scenariuszach można uniemożliwić dołączenie puli węzłów do zaplecza modułu równoważenia obciążenia. W tym celu zastosuj etykietę node.kubernetes.io/exclude-from-external-load-balancers=true do puli węzłów.

Etykieta node.kubernetes.io/exclude-from-external-load-balancers=true określa, czy węzły usługi AKS w puli węzłów znajdują się w puli zaplecza Azure Load Balancer.

Uwaga / Notatka

Mimo że etykieta znajduje się w poszczególnych węzłach, należy ją zastosować na poziomie puli węzłów, aby zapewnić trwałość długoterminową.

az aks nodepool update \
    --resource-group $RESOURCE_GROUP \
    --cluster-name $CLUSTER_NAME \
    --name $NODEPOOL_NAME \
    --labels node.kubernetes.io/exclude-from-external-load-balancers=true

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

  • Last updated on