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:
- 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.
- Az alkalmazásokhoz való hozzáférés biztosítása a Kubernetes-szolgáltatásokon
LoadBalancer
keresztü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
LoadBalancer
ellá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.yaml
amely 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 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 service
utá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.
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ípusanodeIP
- 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
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> \
--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
Fontos
Ha olyan alkalmazásokkal rendelkezik a fürtön, amelyek nagy számú kapcsolatot létesíthetnek a nyilvános IP-címeken található kis célkészletekkel, például egy adatbázishoz csatlakozó előtéralkalmazás számos példányával, előfordulhat, hogy az SNAT-portok kimerültek. 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. 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 list
a 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-ips
load-balancer-managed-outbound-ip-count
haszná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>
.
Fontos
Ha több kimenő IP-címet ad hozzá egy fürthöz, az nem biztosít több rendelkezésre álló SNAT-portot a csomópontokhoz, kivéve, ha a AllocatedOutboundPorts értéke nem nulla. Ha a AllocatedOutboundPorts értéke az alapértelmezett értéknél 0
marad, a csomópontok SNAT-portjai továbbra is be lesznek állítva a Load Balancer dokumentációjának táblázatában, és a további IP-címek további portjai nem lesznek használatban.
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
.
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-ports
load-balancer-managed-outbound-ip-count
load-balancer-outbound-ips
load-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-forward
a 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ú 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 LoadBalancer
rendelkező 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.
- 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
- fürt TCP-szolgáltatásai esetében a TCP lesz használva.
- 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
haservice.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
- 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.
- Vizsgálja meg, hogy az alkalmazás hogyan hoz létre kimenő kapcsolatot (például kódvizsgálatot vagy csomagrögzítést).
- Á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.
- Értékelje ki, hogy követik-e a megfelelő mintákat .
- 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.
Azure Kubernetes Service