Nyilvános standard terheléselosztó használata az Azure Kubernetes Service-ben (AKS)

Az Azure Load Balancer az Open Systems-összekapcsolási (OSI) modell 4. rétegében működik, amely mind a bejövő, mind a kimenő forgatókönyveket támogatja. Elosztja azokat a bejövő folyamatokat, amelyek a terheléselosztó előteréhez érkeznek a háttérkészlet példányaihoz.

Az AKS-sel integrált nyilvános terheléselosztó két célt szolgál:

1. Kimenő kapcsolatok biztosítása az AKS virtuális hálózat fürtcsomópontjaihoz a privát IP-címnek a kimenő készlet nyilvános IP-cím részének fordításával.
2. Az alkalmazásokhoz való hozzáférés biztosítása a Kubernetes-szolgáltatásokon LoadBalancerkeresztül, lehetővé téve az alkalmazások egyszerű méretezését és magas rendelkezésre állású szolgáltatások létrehozását.

Belső (vagy privát) terheléselosztót akkor használ a rendszer, ha csak a privát IP-címek engedélyezettek előtérként. A belső terheléselosztók a virtuális hálózaton belüli forgalom terheléselosztására szolgálnak. A terheléselosztó előtere egy helyszíni hálózatról is elérhető hibrid forgatókönyv esetén.

Ez a cikk egy nyilvános terheléselosztóval való integrációt ismerteti az AKS-en. A belső terheléselosztó integrációjáról lásd: Belső terheléselosztó használata az AKS-ben.

Mielőtt elkezdené

• Az Azure Load Balancer két termékváltozatban érhető el: Alapszintű és Standard. A standard termékváltozat alapértelmezés szerint AKS-fürt létrehozásakor használatos. A standard termékváltozat hozzáférést biztosít a hozzáadott funkciókhoz, például egy nagyobb háttérkészlethez, több csomópontkészlethez, rendelkezésre állási zónákhoz, és alapértelmezés szerint biztonságos. Ez az AKS-hez ajánlott terheléselosztó termékváltozat. Az alapszintű és a standard termékváltozatokkal kapcsolatos további információkért lásd az Azure Load Balancer termékváltozatának összehasonlítását.
• A Kubernetes-szolgáltatások támogatott, típussal LoadBalancerellátott jegyzeteinek teljes listáját lásd : LoadBalancer-széljegyzetek.
• Ez a cikk feltételezi, hogy rendelkezik egy AKS-fürttel az Azure Load Balancer standard termékváltozatával. Ha AKS-fürtre van szüksége, létrehozhat egyet az Azure CLI, az Azure PowerShell vagy az Azure Portal használatával.
• Az AKS kezeli az ügynökcsomópontok életciklusát és műveleteit. Az ügynökcsomópontokhoz társított IaaS-erőforrások módosítása nem támogatott. Egy nem támogatott műveletre példa a terheléselosztó erőforráscsoportjának manuális módosítása.

A nyilvános standard terheléselosztó használata

Miután létrehozott egy kimenő típusú LoadBalancer AKS-fürtöt (alapértelmezett), a fürt készen áll a terheléselosztó használatára a szolgáltatások elérhetővé fogadására.

Hozzon létre egy szolgáltatásjegyzéket, public-svc.yamlamely létrehoz egy típusú közszolgáltatást LoadBalancer.

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

A terheléselosztó IP-címének megadása

Ha egy adott IP-címet szeretne használni a terheléselosztóval, kétféleképpen használhatja:

• Szolgáltatásjegyzetek beállítása: IPv4-címekhez és service.beta.kubernetes.io/azure-load-balancer-ipv6 IPv6-címekhez használhatóservice.beta.kubernetes.io/azure-load-balancer-ipv4.
• Adja hozzá a LoadBalancerIP tulajdonságot a terheléselosztó YAML-jegyzékéhez: Adja hozzá a Service.Spec.LoadBalancerIP tulajdonságot a terheléselosztó YAML-jegyzékéhez. Ez a mező elavult a felsőbb rétegbeli Kubernetes után, és nem támogatja a kettős vermet. A jelenlegi használat változatlan marad, és a meglévő szolgáltatások várhatóan módosítás nélkül fognak működni.

A szolgáltatásjegyzék üzembe helyezése

Helyezze üzembe a nyilvános szolgáltatási jegyzékfájlt kubectl apply a YAML-jegyzék használatával, és adja meg a nevét.

kubectl apply -f public-svc.yaml

Az Azure Load Balancer egy új nyilvános IP-címmel van konfigurálva, amely az új szolgáltatás előtt áll. Mivel az Azure Load Balancer több előtérbeli IP-címvel is rendelkezhet, minden üzembe helyezett új szolgáltatás egy új dedikált előtérbeli IP-címet kap, amely egyedileg érhető el.

Győződjön meg arról, hogy a szolgáltatás létrejött, és a terheléselosztó az alábbi paranccsal van konfigurálva.

kubectl get service public-svc

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

A szolgáltatás részleteinek megtekintésekor a szolgáltatáshoz létrehozott nyilvános IP-cím megjelenik a terheléselosztón a KÜLSŐ-IP oszlopban. Eltarthat néhány percig, amíg az IP-cím függőben lévőről <> tényleges nyilvános IP-címre változik.

A szolgáltatással kapcsolatos részletesebb információkért használja az alábbi parancsot.

kubectl describe service public-svc

A következő példakimenet a kimenet sűrített verziója a futtatás kubectl describe serviceután. A LoadBalancer Bejövő forgalom a szolgáltatás által közzétett külső IP-címet jeleníti meg. Az IP-cím a belső címeket jeleníti meg.

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

A nyilvános standard terheléselosztó konfigurálása

A standard nyilvános terheléselosztó különböző beállításait testre szabhatja a fürt létrehozásakor vagy a fürt frissítésével. Ezek a testreszabási lehetőségek lehetővé teszik a számítási feladatok igényeinek megfelelő terheléselosztó létrehozását. A standard terheléselosztóval a következőt teheti:

• A felügyelt kimenő IP-címek számának beállítása vagy méretezése.
• Saját egyéni kimenő IP-címeket vagy kimenő IP-előtagot hozhat.
• Testre szabhatja a kiosztott kimenő portok számát a fürt minden csomópontján.
• Konfigurálja az üresjárati kapcsolatok időtúllépési beállítását.

A bejövő készlet típusának módosítása

Az AKS-csomópontok a terheléselosztó háttérkészleteiben hivatkozhatnak az IP-konfigurációjuk (Azure Virtual Machine Scale Sets-alapú tagságuk) vagy csak az IP-címük alapján. Az IP-címalapú háttérkészlet-tagság használata nagyobb hatékonyságot biztosít a szolgáltatások frissítésekor és a terheléselosztók kiépítésekor, különösen magas csomópontszám esetén. Mostantól támogatott az új fürtök kiépítése IP-alapú háttérkészletekkel és meglévő fürtök konvertálásával. A NAT-átjáróval vagy a felhasználó által definiált útválasztási kimenő forgalomtípusokkal kombinálva az új csomópontok és szolgáltatások kiépítése nagyobb teljesítményű.

Két különböző készlettagságtípus érhető el:

• nodeIPConfiguration - örökölt virtuálisgép-méretezési csoportok IP-konfigurációalapú készlettagság típusa
• nodeIP - IP-alapú tagság típusa

Követelmények

• Az AKS-fürtnek 1.23-es vagy újabb verziónak kell lennie.
• Az AKS-fürtnek szabványos terheléselosztókat és virtuálisgép-méretezési csoportokat kell használnia.

Új AKS-fürt létrehozása IP-alapú bejövő készlet tagsággal

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

Meglévő AKS-fürt frissítése IP-alapú bejövő készlettagság használatára

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

Felügyelt kimenő nyilvános IP-címek számának skálázása

Az Azure Load Balancer kimenő és bejövő kapcsolatot biztosít egy virtuális hálózatról. A kimenő szabályok megkönnyítik a hálózati címfordítás konfigurálását a nyilvános standard terheléselosztóhoz.

A kimenő szabályok ugyanazt a szintaxist követik, mint a terheléselosztás és a bejövő NAT-szabályok:

előtérbeli IP-címek + paraméterek + háttérkészlet

A kimenő szabály konfigurálja a kimenő NAT-t a háttérkészlet által azonosított összes virtuális géphez, hogy az előtérre legyen lefordítva. A paraméterek nagyobb ellenőrzést biztosítanak a kimenő NAT-algoritmus felett.

Bár egy kimenő szabályt egyetlen nyilvános IP-címmel is használhat, a kimenő szabályok kiválóan használhatók a kimenő NAT skálázására, mivel megkönnyítik a konfigurációs terheket. Több IP-címmel tervezhet nagy léptékű forgatókönyveket és kimenő szabályokat az SNAT-kimerülési minták mérsékléséhez. Minden előtér által megadott IP-cím 64 000 rövid élettartamú portot biztosít a terheléselosztó számára, hogy SNAT-portként használhassa.

Ha standard termékváltozatú terheléselosztót használ felügyelt kimenő nyilvános IP-címekkel (amelyek alapértelmezés szerint vannak létrehozva), a paraméterrel --load-balancer-managed-outbound-ip-count skálázhatja a felügyelt kimenő nyilvános IP-címek számát.

Meglévő fürt frissítéséhez használja az alábbi parancsot. Ezt a paramétert úgy is beállíthatja, hogy több felügyelt kimenő nyilvános IP-cím legyen.

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

A fenti példa 2-re állítja a felügyelt kimenő nyilvános IP-címek számát a myREsourceGroup myAKSCluster fürtjében.

A fürt létrehozásakor a felügyelt kimenő nyilvános IP-címek kezdeti számát is beállíthatja a --load-balancer-managed-outbound-ip-count paraméter hozzáfűzésével és a kívánt értékre állításával. A felügyelt kimenő nyilvános IP-címek alapértelmezett száma 1.

Saját kimenő nyilvános IP-címek vagy előtagok megadása

Standard termékváltozatú terheléselosztó használatakor az AKS-fürt automatikusan létrehoz egy nyilvános IP-címet az AKS által felügyelt infrastruktúra erőforráscsoportjában, és alapértelmezés szerint hozzárendeli azt a terheléselosztó kimenő készletéhez.

Az AKS által létrehozott nyilvános IP-cím egy AKS által felügyelt erőforrás, ami azt jelenti, hogy az AKS felügyeli a nyilvános IP-cím életciklusát, és nem igényel felhasználói műveletet közvetlenül a nyilvános IP-erőforráson. Másik lehetőségként hozzárendelheti saját egyéni nyilvános IP-címét vagy nyilvános IP-előtagját a fürt létrehozásakor. Az egyéni IP-címek egy meglévő fürt terheléselosztó tulajdonságain is frissíthetők.

A saját nyilvános IP-cím vagy előtag használatára vonatkozó követelmények a következők:

• A felhasználóknak egyéni nyilvános IP-címeket kell létrehozniuk és sajátjuknak kell lenniük. Az AKS által létrehozott felügyelt nyilvános IP-címek nem használhatók újra "saját egyéni IP-címként", mert felügyeleti ütközéseket okozhatnak.
• Győződjön meg arról, hogy az AKS-fürt identitása (szolgáltatásnév vagy felügyelt identitás) rendelkezik engedéllyel a kimenő IP-cím eléréséhez a szükséges nyilvános IP-engedélyek listájának megfelelően.
• Győződjön meg arról, hogy megfelel a kimenő IP-címek vagy kimenő IP-előtagok konfigurálásához szükséges előfeltételeknek és korlátozásoknak.

A fürt frissítése saját kimenő nyilvános IP-címmel

az network public-ip show A parancs használatával listázhatja a nyilvános IP-címek azonosítóit.

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

A fenti parancs megjeleníti a myPublicIP nyilvános IP-cím azonosítóját a myResourceGroup erőforráscsoportban.

az aks update A paraméterrel rendelkező load-balancer-outbound-ips paranccsal frissítse a fürtöt a nyilvános IP-címekkel.

Az alábbi példa a paramétert load-balancer-outbound-ips használja az előző parancs azonosítóival.

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

A fürt frissítése saját kimenő nyilvános IP-előtaggal

A normál termékváltozat terheléselosztójával nyilvános IP-előtagokat is használhat a kimenő forgalomhoz. Az alábbi példa az az network public-ip prefix show parancsot használja a nyilvános IP-előtagok azonosítóinak listázásához.

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

A fenti parancs a myResourceGroup erőforráscsoport myPublicIPPrefix nyilvános IP-előtagjának azonosítóját jeleníti meg.

Az alábbi példa a load-balancer-outbound-ip-prefixes paramétert használja az előző parancs azonosítóival.

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

A fürt létrehozása saját nyilvános IP-címmel vagy előtagokkal

A fürt létrehozásakor saját IP-címeket vagy IP-előtagokat hozhat létre a kimenő forgalomhoz, hogy támogassa az olyan forgatókönyveket, mint a kimenő végpontok hozzáadása egy engedélyezési listához. Ha saját nyilvános IP-címeket és IP-előtagokat szeretne definiálni a fürt létrehozásakor, az előző parancsban látható paramétereket kell hozzáfűznie.

az aks create A paraméterrel rendelkező load-balancer-outbound-ips paranccsal hozzon létre egy új fürtöt saját nyilvános IP-címeivel.

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

az aks create A paraméterrel rendelkező load-balancer-outbound-ip-prefixes paranccsal hozzon létre egy új fürtöt saját nyilvános IP-előtagokkal.

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

A lefoglalt kimenő portok konfigurálása

Az AKS alapértelmezés szerint a Terheléselosztón a AllocatedOutboundPorts értéket állítja be, amely lehetővé teszi az automatikus kimenő port-hozzárendelést a háttérkészlet mérete alapján a fürt létrehozásakor.0 Ha például egy fürtnek 50 vagy kevesebb csomópontja van, minden csomóponthoz 1024 port van lefoglalva. Ez az érték lehetővé teszi a fürt maximális csomópontszámára való skálázást a hálózat újrakonfigurálása nélkül, de az SNAT-portok kimerülését gyakoribbá teheti a további csomópontok hozzáadásakor. A fürt csomópontjainak számának növekedésével csomópontonként kevesebb port érhető el. A csomópontok számának növelése a diagram határain (például 50-ről 51 csomópontra vagy 100-ról 101-re) zavaró lehet a kapcsolat szempontjából, mivel a meglévő csomópontokhoz lefoglalt SNAT-portok száma csökken, hogy több csomópontot lehessen használni. A AllocatedOutboundPorts explicit értékének használata az alább látható módon ajánlott.

Az AKS-fürt terheléselosztójának AllocatedOutboundPorts értékének megjelenítéséhez használja az network lb outbound-rule lista következőt: .

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

Az alábbi példakimenet azt mutatja, hogy a háttérkészlet méretén alapuló automatikus kimenő port-hozzárendelés engedélyezve van a fürt számára.

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

Ha egy adott értéket szeretne konfigurálni a AllocatedOutboundPorts és a kimenő IP-cím számára egy fürt létrehozásakor vagy frissítésekor, használja és load-balancer-outbound-ipsload-balancer-managed-outbound-ip-counthasználja load-balancer-outbound-ports vagy , vagyload-balancer-outbound-ip-prefixes. Egy adott érték beállítása vagy a kimenő portok vagy kimenő IP-címek meglévő értékének növelése előtt ki kell számítania a kimenő portok és IP-címek megfelelő számát. Ehhez a számításhoz használja a következő egyenletet a legközelebbi egész számra kerekítve: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

A kimenő portok és IP-címek számának kiszámításakor és az értékek beállításakor tartsa szem előtt a következő információkat:

• A csomópontonkénti kimenő portok száma a beállított érték alapján van javítva.
• A kimenő portok értékének 8-nak kell lennie.
• További IP-címek hozzáadása nem ad hozzá több portot egyetlen csomóponthoz sem, de több csomópont számára biztosít kapacitást a fürtben.
• Figyelembe kell vennie azokat a csomópontokat, amelyek a frissítések részeként hozzáadhatók, beleértve a maxCount és a maxSurge értékeken keresztül megadott csomópontok számát.

Az alábbi példák bemutatják, hogy a megadott értékek hogyan befolyásolják a kimenő portok és IP-címek számát:

• Ha az alapértelmezett értékeket használja, és a fürt 48 csomópontot tartalmaz, minden csomóponthoz 1024 port érhető el.
• Ha az alapértelmezett értékeket használja, és a fürt 48 és 52 csomópont között skálázódik, minden csomópont frissül 1024 portról 512 elérhető portra.
• Ha a kimenő portok száma 1000, a kimenő IP-címek száma pedig 2, akkor a fürt legfeljebb 128 csomópontot támogathat: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
• Ha a kimenő portok száma 1000, a kimenő IP-címek száma pedig 7, akkor a fürt legfeljebb 448 csomópontot támogathat: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
• Ha a kimenő portok száma 4000, a kimenő IP-címek száma pedig 2, akkor a fürt legfeljebb 32 csomópontot támogathat: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
• Ha a kimenő portok száma 4000, a kimenő IP-címek száma pedig 7, akkor a fürt legfeljebb 112 csomópontot támogathat: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Az értékek kiszámítása és ellenőrzése után alkalmazhatja ezeket az értékeket load-balancer-outbound-ports load-balancer-managed-outbound-ip-countload-balancer-outbound-ipsload-balancer-outbound-ip-prefixes a fürtök létrehozásakor vagy frissítésekor.

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

A terheléselosztó tétlen időtúllépésének konfigurálása

Ha az SNAT-port erőforrásai kimerültek, a kimenő folyamatok mindaddig sikertelenek lesznek, amíg a meglévő folyamatok nem oldják fel az SNAT-portokat. A terheléselosztó a folyamat bezárásakor visszanyeri az SNAT-portokat, az AKS által konfigurált terheléselosztó pedig 30 perces tétlenségi időtúllépést használ az SNAT-portok inaktív folyamatokból való kivonásához.

Az átvitel (például) használatával is frissítheti az üresjárati folyamatot, TCP keepalives application-layer keepalivesés szükség esetén alaphelyzetbe állíthatja ezt az üresjárati időtúllépést. Ezt az időtúllépést az alábbi példa alapján konfigurálhatja.

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

Ha arra számít, hogy számos rövid élettartamú kapcsolattal rendelkezik, és nem rendelkezik olyan hosszú élettartamú kapcsolattal, amelyek hosszú ideig tétlenek lehetnek, például a használat kubectl proxy vagy kubectl port-forwarda használat során, fontolja meg alacsony időtúllépési érték, például 4 perc használatát. TCP-fenntartó használata esetén elegendő engedélyezni őket a kapcsolat egyik oldalán. Elegendő például csak a kiszolgálóoldalon engedélyezni őket a folyamat tétlen időzítőjének alaphelyzetbe állításához. Nem szükséges, hogy mindkét fél elindítsa a TCP-megőrzést. Hasonló fogalmak léteznek az alkalmazásréteghez, beleértve az adatbázis ügyfél-kiszolgáló konfigurációit is. Ellenőrizze a kiszolgálóoldalon, hogy milyen lehetőségek állnak rendelkezésre az alkalmazásspecifikus megőrzési lehetőségekhez.

Ha az IdleTimeoutInMinutes értéket az alapértelmezett 30 percnél eltérő értékre állítja be, fontolja meg, hogy mennyi ideig kell a számítási feladatoknak kimenő kapcsolatra szükségük. Azt is vegye figyelembe, hogy az AKS-en kívül használt standard termékváltozatú terheléselosztó alapértelmezett időtúllépési értéke 4 perc. Az IdleTimeoutInMinutes érték, amely pontosabban tükrözi az adott AKS-számítási feladatot, csökkentheti az SNAT-kimerültséget, amelyet a már nem használt kapcsolatok összekapcsolása okoz.

Adott IP-tartományok bejövő forgalmának korlátozása

Az alábbi jegyzék a loadBalancerSourceRanges használatával határoz meg egy új IP-tartományt a bejövő külső forgalomhoz.

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

Ez a példa frissíti a szabályt, hogy csak a tartományból engedélyezze a MY_EXTERNAL_IP_RANGE bejövő külső forgalmat. Ha a belső alhálózat IP-címére cseréli MY_EXTERNAL_IP_RANGE , a forgalom csak a fürt belső IP-címére korlátozódik. Ha a forgalom a fürt belső IP-címére korlátozódik, a Kubernetes-fürtön kívüli ügyfelek nem tudnak hozzáférni a terheléselosztóhoz.

Az ügyfél IP-címének karbantartása bejövő kapcsolatokon

Alapértelmezés szerint a Kubernetesben és az AKS-ben egy típusú LoadBalancer szolgáltatás nem megőrzi az ügyfél IP-címét a podhoz való kapcsolaton. A podnak kézbesített csomag forrás IP-címe a csomópont privát IP-címe lesz. Az ügyfél IP-címének fenntartásához local be kell állítania service.spec.externalTrafficPolicy a szolgáltatásdefiníciót. Az alábbi jegyzék egy példát mutat be.

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

Testreszabások Kubernetes-széljegyzetekkel

Az alábbi széljegyzetek a típussal LoadBalancerrendelkező Kubernetes-szolgáltatások esetében támogatottak, és csak a bejövő folyamatokra vonatkoznak.

Jegyzet	Érték	Leírás
service.beta.kubernetes.io/azure-load-balancer-internal	true vagy false	Adja meg, hogy a terheléselosztó belső legyen-e. Ha nincs beállítva, az alapértelmezés szerint nyilvános lesz.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet	Az alhálózat neve	Adja meg, hogy a belső terheléselosztó melyik alhálózathoz legyen kötve. Ha nincs beállítva, alapértelmezés szerint a felhőkonfigurációs fájlban konfigurált alhálózat lesz.
service.beta.kubernetes.io/azure-dns-label-name	A DNS-címke neve nyilvános IP-címeken	Adja meg a nyilvános szolgáltatás DNS-címkéjének nevét. Ha üres sztringre van állítva, a rendszer nem használja a nyilvános IP-cím DNS-bejegyzését.
service.beta.kubernetes.io/azure-shared-securityrule	true vagy false	Adja meg, hogy a szolgáltatás egy potenciálisan megosztott Azure-biztonsági szabályon keresztül legyen felfedve a szolgáltatás expozíciójának növelése érdekében, az Azure kiterjesztett biztonsági szabályainak hálózati biztonsági csoportokban való használatával.
service.beta.kubernetes.io/azure-load-balancer-resource-group	Az erőforráscsoport neve	Adja meg a terheléselosztó nyilvános IP-címeinek erőforráscsoportját, amelyek nem ugyanabban az erőforráscsoportban szerepelnek, mint a fürtinfrastruktúra (csomóponterőforrás-csoport).
service.beta.kubernetes.io/azure-allowed-service-tags	Engedélyezett szolgáltatáscímkék listája	Adja meg az engedélyezett szolgáltatáscímkék vesszővel elválasztott listáját.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout	TCP tétlen időtúllépések percekben	Adja meg a tcp-kapcsolat tétlen időtúllépéseinek percekben megadott idejét a terheléselosztón. Az alapértelmezett és minimális érték 4. A maximális érték 30. Az értéknek egész számnak kell lennie.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset	true vagy false	Adja meg, hogy a terheléselosztó letiltsa-e a TCP-alaphelyzetbe állítást tétlen időtúllépéskor.
service.beta.kubernetes.io/azure-load-balancer-ipv4	IPv4-cím	Adja meg a terheléselosztóhoz rendelendő IPv4-címet.
service.beta.kubernetes.io/azure-load-balancer-ipv6	IPv6-cím	Adja meg a terheléselosztóhoz rendelendő IPv6-címet.

A terheléselosztó állapotmintájának testreszabása

Jegyzet	Érték	Leírás
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	Állapotadat-mintavétel időköze
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Az állapotadat-mintavétel nem megfelelő válaszainak minimális száma
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Az állapotadat-mintavétel elérési útjának kérése
service.beta.kubernetes.io/port_{port}_no_lb_rule	igaz/hamis	A(z) {port} szolgáltatásportszám. Ha igaz értékre van állítva, a rendszer nem hoz létre terheléselosztási szabályt vagy állapotadat-mintavételi szabályt ehhez a porthoz. Az állapot-ellenőrző szolgáltatás nem érhető el a nyilvános interneten (pl. istio/megbízott állapot-ellenőrző szolgáltatás)
service.beta.kubernetes.io/port_{port}_no_probe_rule	igaz/hamis	A(z) {port} szolgáltatásportszám. Ha igaz értékre van állítva, a rendszer nem hoz létre állapotadat-mintavételi szabályt ehhez a porthoz.
service.beta.kubernetes.io/port_{port}_health-probe_protocol	Állapotadat-mintavételi protokoll	A(z) {port} szolgáltatásportszám. Explicit protokoll a(z) {port} szolgáltatásport állapotadat-mintavételéhez, ha be van állítva, felül kell bírálni a port.appProtocol értéket.
service.beta.kubernetes.io/port_{port}_health-probe_port	portszám vagy portnév a szolgáltatásjegyzékben	A(z) {port} szolgáltatásportszám. Explicit port a(z) {port} szolgáltatásport állapotadat-mintavételéhez, felülírva az alapértelmezett értéket.
service.beta.kubernetes.io/port_{port}_health-probe_interval	Állapotadat-mintavétel időköze	A(z) {port} szolgáltatásportszám.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	Az állapotadat-mintavétel nem megfelelő válaszainak minimális száma	A(z) {port} szolgáltatásportszám.
service.beta.kubernetes.io/port_{port}_health-probe_request-path	Az állapotadat-mintavétel elérési útjának kérése	A(z) {port} szolgáltatásportszám.

Az itt leírtak szerint a Tcp, a Http és a Https három protokollt támogat a Terheléselosztó szolgáltatás által.

Az állapotadat-mintavétel alapértelmezett protokollja jelenleg különböző átviteli protokollokkal, alkalmazásprotokollokkal, széljegyzetekkel és külső forgalmi szabályzatokkal rendelkező szolgáltatások között változik.

1. a helyi szolgáltatások esetében HTTP és /healthz lesz használva. Az állapotadat-mintavétel a NodeHealthPortot kérdezi le a tényleges háttérszolgáltatás helyett
2. fürt TCP-szolgáltatásai esetében a TCP lesz használva.
3. fürt UDP-szolgáltatásaihoz nincs állapotadat-mintavétel.

Az 1.20-as verzió óta szolgáltatásjegyzetet service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path vezet be az állapotadat-mintavétel viselkedésének meghatározásához.

• Az =1.23 fürtök <esetében a rendszer csak akkor használja mintavételi protokollként, spec.ports.appProtocol ha service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path az is be van állítva.
• Az 1.24-s fürtök >esetében a mintavételi protokollt használják, spec.ports.appProtocol és / alapértelmezett mintavételi kérelemútvonalként használják (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path más kérési útvonalra lehet váltani).

Vegye figyelembe, hogy a kérelem elérési útja a TCP használatakor figyelmen kívül lesz hagyva, vagy üres spec.ports.appProtocol . Pontosabban:

loadbalancer termékváltozat	externalTrafficPolicy	spec.ports.Protocol	spec.ports.AppProtocol	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	LB-mintavételi protokoll	Terheléselosztási mintavételi kérelem elérési útja
normál	helyi	bármelyik	bármelyik	bármelyik	http	/healthz
normál	fürt	Udp	bármelyik	bármelyik	null	null
normál	fürt	tcp		(figyelmen kívül hagyva)	tcp	null
normál	fürt	tcp	tcp	(figyelmen kívül hagyva)	tcp	null
normál	fürt	tcp	http/https		TCP(<=1.23) vagy http/https(>=1.24)	null(<=1,23) vagy /(>=1,24)
normál	fürt	tcp	http/https	/custom-path	http/https	/custom-path
normál	fürt	tcp	nem támogatott protokoll	/custom-path	tcp	null
alapvető	helyi	bármelyik	bármelyik	bármelyik	http	/healthz
alapvető	fürt	tcp		(figyelmen kívül hagyva)	tcp	null
alapvető	fürt	tcp	tcp	(figyelmen kívül hagyva)	tcp	null
alapvető	fürt	tcp	http		TCP(<=1.23) vagy http/https(>=1.24)	null(<=1,23) vagy /(>=1,24)
alapvető	fürt	tcp	http	/custom-path	http	/custom-path
alapvető	fürt	tcp	nem támogatott protokoll	/custom-path	tcp	null

Az 1.21-es verzió óta két szolgáltatásjegyzet service.beta.kubernetes.io/azure-load-balancer-health-probe-interval jelent meg, amelyek load-balancer-health-probe-num-of-probe testre szabják az állapotadat-mintavétel konfigurációját. Ha service.beta.kubernetes.io/azure-load-balancer-health-probe-interval nincs beállítva, a rendszer az 5-ös alapértelmezett értéket alkalmazza. Ha load-balancer-health-probe-num-of-probe nincs beállítva, a rendszer a 2 alapértelmezett értéket alkalmazza. És a teljes mintavételnek 120 másodpercnél kevesebbnek kell lennie.

Egyéni Load Balancer állapotadat-mintavétel a porthoz

A szolgáltatás különböző portjai különböző állapotadat-mintavételi konfigurációkat igényelhetnek. Ennek oka lehet a szolgáltatástervezés (például egy több portot vezérlő egyetlen állapotvégpont), vagy a Kubernetes olyan funkciói, mint a MixedProtocolLBService.

Az alábbi széljegyzetek a mintavételi konfiguráció szolgáltatásportonkénti testreszabására használhatók.

portspecifikus széljegyzet	globális mintavételi széljegyzet	Használat
service.beta.kubernetes.io/port_{port}_no_lb_rule	N/A (globálisan nincs egyenértékű)	ha igaz érték van beállítva, a rendszer nem hoz létre terheléselosztási szabályokat és mintavételi szabályokat
service.beta.kubernetes.io/port_{port}_no_probe_rule	N/A (globálisan nincs egyenértékű)	ha igaz érték van beállítva, a rendszer nem hoz létre mintavételi szabályokat
service.beta.kubernetes.io/port_{port}_health-probe_protocol	N/A (globálisan nincs egyenértékű)	A szolgáltatásport állapotadat-mintavételi protokolljának beállítása (pl. Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port	N/A (globálisan nincs egyenértékű)	A szolgáltatásport állapotadat-mintavételi portjának beállítása (pl. 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Http vagy Https esetén adja meg az állapotadat-mintavételi kérelem elérési útját. Alapértelmezett érték: /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Az egymást követő mintavételi hibák száma, mielőtt a port nem megfelelőnek minősül
service.beta.kubernetes.io/port_{port}_health-probe_interval	service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	A mintavételi kísérletek közötti idő

A következő jegyzékfájl esetében a port httpsserver mintavételi szabálya eltér a httpserver-hez használttól, mert a port httpsserverhez megadott széljegyzetek vannak megadva.

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

Ebben a jegyzékben a https-portok egy másik csomópontportot használnak, egy HTTP-készültségi ellenőrzést az 10256-os porton a /healthz(a kube-proxy healthz végpontján).

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

Ebben a jegyzékben a https-portok egy másik állapotadat-mintavételi végpontot használnak, egy HTTP-készültségi ellenőrzést a 30000-s porton a /healthz/ready címen.

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

Az SNAT hibaelhárítása

Ha tudja, hogy sok kimenő TCP- vagy UDP-kapcsolatot indít el ugyanahhoz a cél IP-címhez és porthoz, és megfigyeli, hogy a kimenő kapcsolatok sikertelenek, vagy a támogatás értesíti Önt arról, hogy kimeríti az SNAT-portokat (a PAT által használt rövid élettartamú portokat), számos általános megoldással rendelkezik. Tekintse át ezeket a lehetőségeket, és döntse el, mi a legjobb a forgatókönyvéhez. Lehetséges, hogy egy vagy több segíthet a forgatókönyv kezelésében. Részletes információkért tekintse át a kimenő kapcsolatok hibaelhárítási útmutatójában.

Az SNAT-kimerültség kiváltó oka gyakran az, hogy a kimenő kapcsolatok létrehozásának, felügyeletének vagy konfigurálható időzítőinek az alapértelmezett értékükről való módosításakor a rendszer antimintát hoz létre. Alaposan olvassa át ezt a szakaszt.

Lépések

1. Ellenőrizze, hogy a kapcsolatok hosszú ideig tétlenek maradnak-e, és az alapértelmezett tétlenségi időtúllépésre támaszkodik a port felszabadítása érdekében. Ha igen, előfordulhat, hogy a forgatókönyv esetében csökkenteni kell az alapértelmezett 30 perces időtúllépést.
2. Vizsgálja meg, hogy az alkalmazás hogyan hoz létre kimenő kapcsolatot (például kódvizsgálatot vagy csomagrögzítést).
3. Állapítsa meg, hogy ez a tevékenység várt viselkedés-e, vagy hogy az alkalmazás helytelenül működik-e. Az Eredmények alátámasztásához használjon metrikákat és naplókat az Azure Monitorban. Használja például a "Sikertelen" kategóriát az SNAT-kapcsolatok metrikáihoz.
4. Értékelje ki, hogy követik-e a megfelelő mintákat .
5. Annak kiértékelése, hogy az SNAT-portok kimerülését csökkenteni kell-e több kimenő IP-címmel és több lefoglalt kimenő porttal.

Tervezési minták

Ha lehetséges, használja ki a kapcsolat újrafelhasználását és a kapcsolatkészletezést. Ezek a minták segítenek elkerülni az erőforrás-kimerülési problémákat, és kiszámítható viselkedést eredményeznek. Ezeknek a mintáknak a primitívjei számos fejlesztési kódtárban és keretrendszerben megtalálhatók.

• Az atomi kérések (kapcsolatonként egy kérés) általában nem megfelelő kialakítási választás. Az ilyen mintázatok korlátozzák a skálázást, csökkentik a teljesítményt és csökkentik a megbízhatóságot. Ehelyett használja újra a HTTP/S kapcsolatokat a kapcsolatok és a társított SNAT-portok számának csökkentése érdekében. Az alkalmazás skálázása nő, és a teljesítmény javul a kézfogás, a terhelés és a titkosítási műveletek költségeinek csökkentése miatt a TLS használatakor.
• Ha fürtön kívüli/egyéni DNS-t vagy egyéni upstream-kiszolgálókat használ a coreDNS-en, vegye figyelembe, hogy a DNS számos egyedi folyamatot eredményezhet köteten, ha az ügyfél nem gyorsítótáraozza a DNS-feloldók eredményét. Az egyéni DNS-kiszolgálók használata helyett először a coreDNS testreszabását és a megfelelő gyorsítótárazási érték meghatározását végezze el.
• Az UDP-folyamatok (például DNS-keresések) lefoglalják az SNAT-portokat az üresjárati időtúllépés során. Minél hosszabb az üresjárati időtúllépés, annál nagyobb a nyomás az SNAT-portokra. Használjon rövid tétlenségi időtúllépést (például 4 percet).
• Kapcsolatkészletek használatával alakíthatja a kapcsolatkötetet.
• Soha ne hagyjon fel csendesen egy TCP-folyamatot, és támaszkodjon a TCP-időzítőkre a folyamat megtisztításához. Ha nem engedélyezi a TCP-nek a kapcsolat explicit bezárását, az állapot a köztes rendszerekben és végpontokon lesz lefoglalva, és az SNAT-portokat más kapcsolatok esetében elérhetetlenné teszi. Ez a minta alkalmazáshibákat és SNAT-kimerülést okozhat.
• Ne módosítsa az operációsrendszer-szintű TCP-szoros kapcsolódó időzítőértékeket anélkül, hogy jártos lenne a hatásban. Amíg a TCP-verem helyreáll, az alkalmazás teljesítménye negatívan befolyásolhatja, ha egy kapcsolat végpontjai nem egyeznek az elvárásokkal. Az időzítők módosítása általában egy mögöttes tervezési probléma jele. Tekintse át a következő javaslatokat.

Váltás alapszintű termékváltozat terheléselosztóról standard termékváltozatra

Ha már rendelkezik alapszintű termékváltozatú terheléselosztóval rendelkező fürttel, fontos viselkedésbeli különbségeket kell figyelembe vennie a standard termékváltozat terheléselosztójára való migráláskor.

A fürtök áttelepítéséhez például gyakori eljárás a kék/zöld környezet létrehozása a load-balancer-sku fürt típusa alapján, és csak a fürt létrehozásakor határozható meg. Az alapszintű termékváltozat terheléselosztói azonban alapszintű termékváltozatú IP-címeket használnak, amelyek nem kompatibilisek a standard termékváltozat terheléselosztóival. A standard termékváltozat terheléselosztóinak standard termékváltozatú IP-címeket kell megadniuk. Amikor fürtöket migrál a terheléselosztó termékváltozatainak frissítésére, új IP-címre van szükség egy kompatibilis IP-cím termékváltozatával.

A fürtök migrálásának további szempontjait a migrálással kapcsolatos dokumentációnkban találja.

Korlátozások

A következő korlátozások érvényesek a standard termékváltozattal rendelkező terheléselosztót támogató AKS-fürtök létrehozásakor és kezelésekor:

• Legalább egy nyilvános IP-cím vagy IP-előtag szükséges az AKS-fürtből kimenő forgalom engedélyezéséhez. Nyilvános IP- vagy IP-előtag szükséges a vezérlősík és az ügynökcsomópontok közötti kapcsolat fenntartásához, valamint az AKS korábbi verzióival való kompatibilitás fenntartásához. A nyilvános IP-címek vagy IP-előtagok standard termékváltozatú terheléselosztóval való megadására az alábbi lehetőségek állnak rendelkezésre:
  • Adja meg a saját nyilvános IP-címeit.
  • Adja meg a saját nyilvános IP-előtagjait.
  • Adjon meg egy legfeljebb 100-as számot, hogy az AKS-fürt az AKS-fürtvel azonos erőforráscsoportban hozza létre azt a sok standard termékváltozatú nyilvános IP-címet. Ezt az erőforráscsoportot általában az elején MC_ nevezik el. Az AKS hozzárendeli a nyilvános IP-címet a standard termékváltozat terheléselosztóhoz. Alapértelmezés szerint egy nyilvános IP-cím automatikusan az AKS-fürttel azonos erőforráscsoportban jön létre, ha nincs megadva nyilvános IP-cím, nyilvános IP-előtag vagy IP-címek száma. Emellett engedélyeznie kell a nyilvános címeket, és kerülnie kell az IP-címek létrehozását tiltó Azure-szabályzatok létrehozását.
• Az AKS által létrehozott nyilvános IP-címek nem használhatók újra egyéni, saját nyilvános IP-címekként. A felhasználóknak létre kell hozniuk és kezelnie kell az összes egyéni IP-címet.
• A terheléselosztó termékváltozata csak az AKS-fürt létrehozásakor határozható meg. A terheléselosztó termékváltozata az AKS-fürt létrehozását követően nem módosítható.
• Egyetlen fürtben csak egy típusú terheléselosztó termékváltozatot (alapszintű vagy standard) használhat.
• A standard termékváltozat terheléselosztói csak a standard termékváltozat IP-címeit támogatják.

Következő lépések

A Kubernetes-szolgáltatásokkal kapcsolatos további információkért tekintse meg a Kubernetes-szolgáltatások dokumentációját.

A belső terheléselosztó bejövő forgalomhoz való használatáról további információt az AKS belső terheléselosztó dokumentációjában talál.