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

  • Cikk

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.

Fontos

Ha a kimenő kapcsolat biztosításához saját átjárót, tűzfalat vagy proxyt szeretne használni, kihagyhatja a terheléselosztó kimenő készletének és a megfelelő előtér-IP-címnek a létrehozását a UserDefinedRouting (UDR) kimenő típus használatával. A kimenő típus határozza meg a fürt kimenő metódusát, és alapértelmezés szerint a beírást LoadBalancer.

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:

Fontos

A LoadBalancerIP tulajdonság hozzáadása a terheléselosztó YAML-jegyzékéhez elavult a felsőbb rétegbeli Kubernetes után. Bár 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, javasoljuk inkább a szolgáltatásjegyzetek beállítását .

  • 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    52.156.88.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:        52.156.88.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.

Fontos

Egy adott időpontban csak egy kimenő IP-cím (felügyelt IP-címek, saját IP-cím vagy IP-előtag) használható.

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

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

Figyelmeztetés

Ez a művelet átmeneti fennakadást okoz a fürt bejövő szolgáltatásforgalmában. A sok csomóponttal rendelkező nagyobb fürtök hatásideje nő.

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.

Fontos

Nem javasoljuk, hogy az Azure Portal használatával végezze el a kimenő szabálymódosításokat. A módosítások végrehajtásakor az AKS-fürtön kell végighaladnia, és nem közvetlenül a Load Balancer-erőforráson.

A közvetlenül a Load Balancer-erőforráson végrehajtott kimenő szabálymódosítások törlődnek, amikor a fürt összeegyeztethető, például leállítva, elindítva, frissítve vagy skálázva.

Használja az Azure CLI-t a példákban látható módon. A cli-parancsokkal végrehajtott az aks kimenő szabálymódosítások a fürt állásideje alatt állandóak.

További információ: Azure Load Balancer kimenő szabályok.

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>

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>

A lefoglalt kimenő portok konfigurálása

Fontos

Ha olyan alkalmazásokkal rendelkezik a fürtön, amelyek nagy számú kapcsolatot létesíthetnek kis célkészletekkel, például egy adatbázishoz csatlakozó előtéralkalmazás számos példányát, előfordulhat, hogy sNAT-portkimerülés tapasztalható. Az SNAT-portok kimerülése akkor fordul elő, ha egy alkalmazás elfogy a kimenő portokból, hogy kapcsolatot létesítsen egy másik alkalmazással vagy gazdagéppel. Ha olyan forgatókönyve van, amely sNAT-portkimerülésre hajlamos, javasoljuk, hogy növelje a kiosztott kimenő portokat és a kimenő előtérbeli IP-címeket a terheléselosztón.

Az SNAT-ről további információt az SNAT használata kimenő kapcsolatokhoz című témakörben talál.

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. A fürt csomópontjainak számának növekedésével csomópontonként kevesebb port érhető el.

Fontos

A rendszer 1024 portot határoz meg, függetlenül attól, hogy a rendszer hozzáadja-e az előtérbeli IP-címeket, ha a csomópont mérete kisebb vagy egyenlő 50-nél (1–50).

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, amelyeket a frissítések részeként lehet hozzáadni, beleértve a maxSurge értékeken keresztül megadott csomópontok számát is.

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.

Fontos

A kimenő portok és IP-címek számának kiszámítása után ellenőrizze, hogy rendelkezik-e további kimenő portkapacitással a csomópontok frissítés közbeni túlfeszültségének kezeléséhez. Fontos, hogy elegendő többletportot foglaljon le a frissítéshez és más műveletekhez szükséges további csomópontokhoz. Az AKS alapértelmezés szerint egy puffercsomópontra vált a frissítési műveletekhez. Ha maxSurge értékeket használ, szorozza meg a csomópontonkénti kimenő portokat a maxSurge értékkel a szükséges portok számának meghatározásához. Ha például azt számítja ki, hogy csomópontonként 4000 portra van szüksége, amely 7 IP-címmel rendelkezik egy legfeljebb 100 csomópontot tartalmazó fürtön, és legfeljebb 2-et:

  • 2 túlfeszültség-csomópont * csomópontonként 4000 port = 8000 port szükséges a csomópontok frissítés közbeni túlfeszültségéhez.
  • Csomópontonként 100 csomópont * 4000 port = 400 000 port szükséges a fürthöz.
  • 7 IP-cím * IP-címenként 64000 port = 448 000 port érhető el a fürt számára.

A fenti példa azt mutatja, hogy a fürt kapacitása 48 000, ami elegendő a csomópontok frissítés közbeni túlfeszültségéhez szükséges 8000 port kezeléséhez.

Az értékek kiszámítása és ellenőrzése után alkalmazhatja ezeket az értékeket load-balancer-outbound-portsload-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 keepalivesapplication-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.

Fontos

Az AKS alapértelmezés szerint engedélyezi a TCP-alaphelyzetbe állítást tétlen állapotban. Javasoljuk, hogy tartsa meg ezt a konfigurációt, és használja ki az alkalmazás kiszámíthatóbb viselkedése érdekében a forgatókönyvekben.

A TCP RST-t csak a TCP-kapcsolat során küldi el a rendszer, a RENDSZER LÉTREHOZOTT állapotban. Itt talál további információt.

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.

Figyelmeztetés

A AllocatedOutboundPorts és az IdleTimeoutInMinutes értékeinek módosítása jelentősen megváltoztathatja a terheléselosztó kimenő szabályának viselkedését, ezért nem szabad könnyedén elvégezni. Mielőtt frissítené ezeket az értékeket, tekintse át az SNAT hibaelhárítási szakaszát , és tekintse át a Load Balancer kimenő szabályait és kimenő kapcsolatait az Azure-ban , mielőtt frissítené ezeket az értékeket a módosítások hatásának teljes körű megértéséhez.

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.

Feljegyzés

  • A bejövő forgalom a terheléselosztótól az AKS-fürt virtuális hálózatára áramlik. A virtuális hálózat rendelkezik egy hálózati biztonsági csoportmal (NSG), amely lehetővé teszi a terheléselosztóból érkező összes bejövő forgalmat. Ez az NSG egy LoadBalancer típusú szolgáltatáscímkét használ a terheléselosztóból érkező forgalom engedélyezéséhez.
  • A pod CIDR-jét hozzá kell adni a loadBalancerSourceRangeshez, ha vannak podok, amelyeknek hozzá kell férniük a szolgáltatás LoadBalancer IP-címéhez az 1.25-ös vagy újabb verziójú fürtök esetében.

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ú LoadBalancerszolgá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.

Feljegyzés

A PLS-integrációt és a PLS proxyprotokollt engedélyező helyi szolgáltatások esetében az alapértelmezett HTTP+/healthz állapotadat-mintavétel nem működik. Így az állapotadat-mintavétel ugyanúgy testre szabható, mint a fürtszolgáltatások, hogy támogassák ezt a forgatókönyvet.

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.