Az Azure CNI Overlay hálózatkezelésének konfigurálása az Azure Kubernetes Service-ben (AKS)

  • Cikk

A hagyományos Azure Container Networking Interface (CNI) minden podhoz hozzárendel egy VNet IP-címet. Ezt az IP-címet minden csomópont egy előre fenntartott IP-címkészletéből vagy egy podokhoz fenntartott külön alhálózatból rendeli hozzá. Ez a megközelítés IP-címtervezést igényel, és a kimerültség kezeléséhez vezethet, ami nehézségeket okoz a fürtök skálázásában az alkalmazás igényeinek növekedésével.

Az Azure CNI Overlay használatával a fürtcsomópontok egy Azure-beli virtuális hálózat (VNet) alhálózatán lesznek üzembe helyezve. A podok egy privát CIDR-ből származó IP-címek, logikailag eltérnek a csomópontokat üzemeltető virtuális hálózattól. A fürt pod- és csomópontforgalma átfedési hálózatot használ. A hálózati címfordítás (NAT) a csomópont IP-címét használja a fürtön kívüli erőforrások eléréséhez. Ez a megoldás jelentős mennyiségű virtuális hálózati IP-címet takarít meg, és lehetővé teszi a fürt nagy méretűre való skálázását. További előnye, hogy a privát CIDR-t újra felhasználhatja a különböző AKS-fürtökben, ami kibővíti az Azure Kubernetes Service (AKS) tárolóalapú alkalmazásai számára rendelkezésre álló IP-területet.

Átfedéses hálózatkezelés áttekintése

Az átfedéses hálózatkezelésben csak a Kubernetes-fürtcsomópontok vannak hozzárendelve IP-címekhez az alhálózatokból. A podok a fürt létrehozásakor megadott privát CIDR-ből fogadnak IP-címeket. Minden csomóponthoz ugyanabból /24 a CIDR-ből kifaragott címtér van hozzárendelve. A fürtök méretezésekor létrehozott további csomópontok automatikusan kapnak /24 címtereket ugyanabból a CIDR-ből. Az Azure CNI ip-címeket rendel a podokhoz erről a /24 területről.

Külön útválasztási tartomány jön létre a pod privát CIDR-területének Azure Networking stackjében, amely átfedési hálózatot hoz létre a podok közötti közvetlen kommunikációhoz. Nincs szükség egyéni útvonalak kiépítésére a fürt alhálózatán, és nem kell beágyazási módszert használni a podok közötti forgalom bújtatásához, amely a podok közötti kapcsolati teljesítményt nyújtja a virtuális hálózaton lévő virtuális gépekhez hasonló podok között. A podokon futó számítási feladatok nem is tudják, hogy a hálózati címek kezelése folyamatban van.

Két csomópontot ábrázoló diagram, amelyek mindegyike három podgal rendelkezik, amelyek mindegyike átfedéses hálózaton fut. A fürtön kívüli végpontokra történő podforgalom NAT-on keresztül van irányítva.

A fürtön kívüli végpontokkal( például a helyszíni és a társhálózattal rendelkező virtuális hálózatokkal) folytatott kommunikáció a csomópont IP-címének NAT-on keresztüli használatával történik. Az Azure CNI lefordítja a forgalom forrás IP-címét (a pod átfedési IP-címét) a virtuális gép elsődleges IP-címére, amely lehetővé teszi, hogy az Azure Hálózatkezelési verem a forgalmat a célhoz irányozza. A fürtn kívüli végpontok nem tudnak közvetlenül csatlakozni egy podhoz. A pod alkalmazását Kubernetes Load Balancer-szolgáltatásként kell közzétennie, hogy elérhető legyen a virtuális hálózaton.

A standard termékváltozatú Load Balancer vagy a felügyelt NAT-átjáró használatával kimenő (kimenő) kapcsolatot biztosíthat az internethez overlay podokhoz. A kimenő forgalmat úgy is szabályozhatja, hogy a fürt alhálózatán a felhasználó által megadott útvonalakkal egy tűzfalra irányítja.

Konfigurálhatja a fürthöz való bejövő kapcsolatot egy bejövőforgalom-vezérlővel, például Nginx vagy HTTP-alkalmazás útválasztásával. A bejövő kapcsolatok nem konfigurálhatók Azure-alkalmazás Gateway használatával. További részletekért tekintse meg az Azure CNI-átfedés korlátozásait.

Különbségek a Kubenet és az Azure CNI átfedése között

Az Azure CNI Overlay-hez hasonlóan a Kubenet ip-címeket rendel a podokhoz a virtuális hálózattól logikailag eltérő címtérből, de skálázási és egyéb korlátozásokkal rendelkezik. Az alábbi táblázat részletes összehasonlítást nyújt a Kubenet és az Azure CNI Overlay között. Ha IP-hiány miatt nem szeretne virtuális hálózati IP-címeket hozzárendelni a podokhoz, javasoljuk az Azure CNI Overlay használatát.

Terület Azure CNI Overlay Kubenet
Fürtméretezés 5000 csomópont és 250 pod/csomópont 400 csomópont és 250 pod/csomópont
Hálózati konfiguráció Egyszerű – nincs szükség további konfigurációkra a podok hálózatkezeléséhez Összetett – útválasztási táblákat és UDR-eket igényel a fürt alhálózatán a podok hálózatkezeléséhez
Pod-kapcsolat teljesítménye Teljesítmény egy virtuális hálózatban lévő virtuális gépekkel egyenértékben Az extra ugrás késést eredményez
Kubernetes hálózati házirendek Azure Hálózati szabályzatok, Calico, Cilium Calico
Támogatott operációsrendszer-platformok Linux és Windows Server 2022, 2019 Csak Linux

IP-cím tervezése

  • Fürtcsomópontok: Az AKS-fürt beállításakor győződjön meg arról, hogy a virtuális hálózat alhálózatai elegendő helyet foglalnak a jövőbeli skálázáshoz. Az egyes csomópontkészleteket hozzárendelheti egy dedikált alhálózathoz. Egy /24alhálózat legfeljebb 251 csomópontot képes elférni, mivel az első három IP-cím felügyeleti feladatokhoz van fenntartva.
  • Podok: Az Átfedési megoldás a fürt létrehozásakor megadott magánhálózati CIDR-ből minden csomóponthoz hozzárendel egy /24 címteret a podokhoz. A /24 méret rögzített, és nem növelhető vagy csökkenthető. Egy csomóponton legfeljebb 250 pod futtatható. A podcímtér tervezésekor győződjön meg arról, hogy a magánhálózati CIDR elég nagy ahhoz, hogy címtereket biztosítson /24 az új csomópontokhoz a fürt jövőbeli bővítésének támogatásához.
    • A podok IP-címtartományának tervezésekor vegye figyelembe a következő tényezőket:
      • Ugyanazt a pod CIDR-helyet több független AKS-fürtön is használhatja ugyanazon a virtuális hálózaton.
      • A pod CIDR-területe nem lehet átfedésben a fürt alhálózati tartományával.
      • A pod CIDR-területe nem fedheti át a közvetlenül csatlakoztatott hálózatokat (például virtuális hálózatok közötti társviszony-létesítést, ExpressRoute-t vagy VPN-t). Ha a külső forgalom forrás IP-címei a podCIDR tartományban vannak, a fürttel való kommunikációhoz az SNAT-en keresztül egy nem átfedésben lévő IP-címre kell fordítást igényelnie.
  • Kubernetes szolgáltatáscímtartomány: A CIDR szolgáltatáscím mérete a létrehozni kívánt fürtszolgáltatások számától függ. Kisebbnek kell lennie, mint /12. Ez a tartomány nem lehet átfedésben a pod CIDR-tartományával, a fürt alhálózati tartományával és a társhálózatokban és a helyszíni hálózatokban használt IP-tartománnyal.
  • Kubernetes DNS-szolgáltatás IP-címe: Ez az IP-cím a fürtszolgáltatás felderítése által használt Kubernetes-szolgáltatás címtartományán belül található. Ne használja az első IP-címet a címtartományban, mivel ezt a címet használja a kubernetes.default.svc.cluster.local címhez.

Hálózati biztonsági csoportok

Az Azure CNI Overlay-t tartalmazó pod-pod-forgalom nincs beágyazva, és az alhálózati hálózati biztonsági csoport szabályait alkalmazza a rendszer. Ha az alhálózati NSG megtagadási szabályokat tartalmaz, amelyek hatással lennének a pod CIDR-forgalmára, győződjön meg arról, hogy a megfelelő fürtfunkció biztosítása érdekében a következő szabályok vannak érvényben (az AKS-kimenő forgalomra vonatkozó összes követelmény mellett):

  • Forgalom a csomópont CIDR-ből a csomóponti CIDR-be az összes porton és protokollon
  • Forgalom a csomópont CIDR-ből a pod CIDR-be az összes porton és protokollon (a szolgáltatásforgalom útválasztásához szükséges)
  • A pod CIDR-ről a pod CIDR-ére irányuló forgalom minden porton és protokollon (a podról podra és podra irányuló szolgáltatásforgalomhoz szükséges, beleértve a DNS-t is)

A podról a pod CIDR-blokkján kívüli bármely helyre érkező forgalom az SNAT-t használja a forrás IP-címének azon csomópont IP-címére való beállításához, ahol a pod fut.

Ha korlátozni szeretné a fürt számítási feladatai közötti forgalmat, javasoljuk, hogy használjon hálózati házirendeket.

Podok maximális száma csomópontonként

A podok csomópontonkénti maximális számát a fürt létrehozásakor vagy új csomópontkészlet hozzáadásakor konfigurálhatja. Az Azure CNI Overlay alapértelmezett értéke 250. Az Azure CNI-átfedésben megadható maximális érték 250, a minimális érték pedig 10. A csomópontkészlet létrehozásakor konfigurált csomópontonkénti podok maximális száma csak az adott csomópontkészlet csomópontjaira vonatkozik.

Használandó hálózati modell kiválasztása

Az Azure CNI két IP-címzési lehetőséget kínál a podokhoz: a hagyományos konfiguráció, amely virtuális hálózati IP-címeket rendel a podokhoz és az átfedéses hálózatkezeléshez. Az AKS-fürthöz a rugalmasság és a speciális konfigurációs igények közötti egyensúly a választás. Az alábbi szempontok segítenek felvázolni, hogy az egyes hálózati modellek mikor lehetnek a legmegfelelőbbek.

Átfedéses hálózatkezelés használata a következő esetekben:

  • Nagy számú podra szeretne méretezni, de korlátozott IP-címterülettel rendelkezik a virtuális hálózaton.
  • A pod kommunikációjának nagy része a fürtön belül van.
  • Nincs szükség speciális AKS-funkciókra, például virtuális csomópontokra.

Használja a hagyományos virtuális hálózat lehetőséget a következő esetekben:

  • Rendelkezik elérhető IP-címtérrel.
  • A podok közötti kommunikáció legnagyobb része a fürtön kívüli erőforrások felé történik.
  • A fürtön kívüli erőforrásoknak közvetlenül kell elérniük a podokat.
  • Speciális AKS-funkciókra, például virtuális csomópontokra van szüksége.

Korlátozások az Azure CNI-átfedéssel

Az Azure CNI Overlay a következő korlátozásokkal rendelkezik:

  • Nem használhatja az Application Gatewayt bejövőforgalom-vezérlőként (AGIC) egy átfedéses fürthöz.
  • A virtuálisgép-rendelkezésre állási csoportok (VMAS) nem támogatottak az átfedéshez.
  • A csomópontkészletekben nem használhat DCsv2 sorozatú virtuális gépeket. A bizalmas számítástechnikai követelmények teljesítéséhez fontolja meg inkább a DCasv5 vagy DCadsv5 sorozatú bizalmas virtuális gépek használatát.
  • Ha saját alhálózatot használ a fürt üzembe helyezéséhez, az alhálózat, a virtuális hálózat és a virtuális hálózatot tartalmazó erőforráscsoport neve legfeljebb 63 karakter hosszúságú lehet. Ez abból a tényből ered, hogy ezek a nevek címkékként lesznek használva az AKS-feldolgozó csomópontokban, ezért a Kubernetes címkeszintaxisára vonatkozó szabályok vonatkoznak rá.

Átfedési fürtök beállítása

Feljegyzés

Az argumentum használatához a CLI 2.48.0-s vagy újabb verziójával kell rendelkeznie --network-plugin-mode . Windows esetén telepítve kell lennie a legújabb aks-preview Azure CLI-bővítménynek, és követnie kell az alábbi utasításokat.

Hozzon létre egy fürtöt az Azure CNI Overlay használatával a az aks create paranccsal. Ügyeljen arra, hogy az argumentum --network-plugin-mode használatával adjon meg egy átfedési fürtöt. Ha a pod CIDR nincs megadva, az AKS egy alapértelmezett helyet rendel hozzá: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

Új csomópontkészlet hozzáadása egy dedikált alhálózathoz

Miután létrehozott egy fürtöt az Azure CNI Overlay használatával, létrehozhat egy másik csomópontkészletet, és hozzárendelheti a csomópontokat ugyanazon virtuális hálózat új alhálózatához. Ez a megközelítés akkor lehet hasznos, ha a gazdagép bejövő vagy kimenő IP-címeit szeretné szabályozni ugyanazon virtuális hálózat vagy társhálózati virtuális hálózat céljai felé.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Meglévő fürt frissítése CNI-átfedésre

Feljegyzés

Meglévő Azure CNI-fürtöt frissíthet átfedésre, ha a fürt megfelel az alábbi feltételeknek:

  • A fürt a Kubernetes 1.22-es verzióján van.
  • Nem használja a dinamikus pod IP-foglalási funkcióját.
  • Nincs engedélyezve hálózati házirend. A hálózati házirend-motor a frissítés előtt eltávolítható, lásd : Az Azure Network Policy Manager vagy a Calico eltávolítása
  • Nem használ windowsos csomópontkészleteket dockerrel tároló-futtatókörnyezetként.

Feljegyzés

Mivel az ARM-hez még nem támogatott az útválasztási tartomány, a CNI-átfedés még nem támogatott ARM-alapú (ARM64) processzorcsomópontokon.

Feljegyzés

A meglévő fürt CNI-átfedésre való frissítése nem visszafordítható folyamat.

Figyelmeztetés

A Windows operációs rendszer 20348.1668-ás buildje előtt korlátozás lépett fel a Windows Overlay podok esetében, amelyek helytelenül sNATing csomagokat adnak a gazdagép hálózati podjairól, ami hátrányosabb hatással volt az Overlay-re frissített fürtökre. A probléma elkerülése érdekében használja a 20348.1668-nál nagyobb vagy egyenlő Windows operációsrendszer-buildet.

Figyelmeztetés

Ha egyéni Azure-ip-masq-agent konfigurációt használ olyan további IP-tartományok hozzáadásához, amelyek nem tartalmazhatnak podokból származó SNAT-csomagokat, az Azure CNI Overlayre való frissítés megszakíthatja az ezekhez a tartományokhoz való kapcsolódást. A pod IP-címei az átfedési területről nem lesznek elérhetők a fürtcsomópontokon kívül. Emellett a megfelelően régi fürtök esetében előfordulhat, hogy az Azure-ip-masq-agent egy korábbi verziójából maradt ConfigMap. Ha a névvel ellátott azure-ip-masq-agent-configConfigMap létezik, és nem szándékosan a helyén van, a frissítési parancs futtatása előtt törölni kell. Ha nem egyéni ip-masq-agent konfigurációt használ, csak a ConfigMap létezhet az azure-ip-masq-agent-config-reconciled Azure ip-masq-agent Config esetében Térképek és ez automatikusan frissül a frissítési folyamat során.

A frissítési folyamat aktiválja az egyes csomópontkészleteket, hogy egyidejűleg újraképeződjenek. Az egyes csomópontkészletek külön frissítése átfedésre nem támogatott. A fürt hálózatának megszakadása hasonló a csomópontok lemezképének frissítéséhez vagy a Kubernetes verziófrissítéséhez, ahol a csomópontkészlet minden csomópontja újra van rendszerképben.

Azure CNI-fürt frissítése

Frissítsen egy meglévő Azure CNI-fürtöt az Overlay parancs használatával az aks update történő használatára.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

A --pod-cidr paraméterre az örökölt CNI-ről való frissítéskor van szükség, mert a podoknak ip-címeket kell lekérniük egy új átfedési területről, amely nem fedi át a meglévő csomópont alhálózatát. A pod CIDR-címe sem fedheti át a csomópontkészletek virtuális hálózati címét. Ha például a virtuális hálózat címe 10.0.0.0/8, és a csomópontok a 10.240.0.0/16 alhálózatban találhatók, akkor --pod-cidr a 10.0.0.0/8-val vagy a fürt meglévő CIDR szolgáltatásával nem lehet átfedésben.

Kubenet-fürt frissítése

Frissítsen egy meglévő Kubenet-fürtöt az Azure CNI Overlay parancs használatával az aks update való használatára.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay

Mivel a fürt már használ privát CIDR-t olyan podokhoz, amelyek nem fedik egymást a virtuális hálózat IP-címterével, nem kell megadnia a --pod-cidr paramétert, és a Pod CIDR ugyanaz marad.

Feljegyzés

A Kubenetről a CNI Overlayre való frissítéskor az útvonaltáblára már nincs szükség a pod útválasztásához. Ha a fürt egy ügyfél által megadott útvonaltáblát használ, az áttelepítési művelet során automatikusan törlődnek azok az útvonalak, amelyeket a podforgalom a megfelelő csomópontra való irányításához használt. Ha a fürt felügyelt útvonaltáblát használ (az útvonaltáblát az AKS hozta létre, és a csomópont erőforráscsoportjában él), akkor az útvonaltábla az áttelepítés részeként törlődik.

Kettős veremű hálózatkezelés

Az AKS-fürtöket kettős verem módban is üzembe helyezheti, ha átfedéses hálózatkezelést és kétveremes Azure-beli virtuális hálózatot használ. Ebben a konfigurációban a csomópontok IPv4- és IPv6-címet is kapnak az Azure-beli virtuális hálózati alhálózatról. A podok egy IPv4- és IPv6-címet is kapnak egy logikailag eltérő címtérről a csomópontok Azure-beli virtuális hálózati alhálózatára. A hálózati címfordítás (NAT) konfigurálása lehetővé teszi, hogy a podok hozzáférjenek az Azure-beli virtuális hálózat erőforrásaihoz. A forgalom forrás IP-címe nat'd a csomópont elsődleges IP-címére ugyanahhoz a családhoz (IPv4-ről IPv4-re és IPv6-ról IPv6-ra).

Előfeltételek

  • Az Azure CLI 2.48.0-s vagy újabb verziójának telepítve kell lennie.
  • A Kubernetes 1.26.3-os vagy újabb verziója.

Korlátozások

A kettős veremes hálózatkezelés nem támogatja az alábbi funkciókat:

  • Windows-csomópontsorok
  • Azure hálózati szabályzatok
  • Calico hálózati szabályzatok
  • NAT-átjáró
  • Virtuális csomópontok bővítmény

Kettős veremű AKS-fürt üzembe helyezése

A kettős veremű fürtök támogatásához a következő attribútumok tartoznak:

  • --ip-families: A fürtön engedélyezendő IP-családok vesszővel tagolt listáját veszi fel.
    • Csak ipv4 vagy ipv4,ipv6 támogatott.
  • --pod-cidrs: A CIDR jelölési IP-tartományainak vesszővel tagolt listáját veszi fel a pod IP-címeinek hozzárendeléséhez.
    • A listában szereplő tartományok számának és sorrendjének meg kell egyeznie a megadott --ip-familiesértékkel.
    • Ha nincs megadva érték, a rendszer az alapértelmezett értéket 10.244.0.0/16,fd12:3456:789a::/64 használja.
  • --service-cidrs: A CIDR-jelölési IP-tartományok vesszővel tagolt listáját veszi fel a szolgáltatás IP-címeinek hozzárendeléséhez.
    • A listában szereplő tartományok számának és sorrendjének meg kell egyeznie a megadott --ip-familiesértékkel.
    • Ha nincs megadva érték, a rendszer az alapértelmezett értéket 10.0.0.0/16,fd12:3456:789a:1::/108 használja.
    • A hozzárendelt --service-cidrs IPv6-alhálózat legfeljebb /108 lehet.

Kettős veremű AKS-fürt létrehozása

  1. Hozzon létre egy Azure-erőforráscsoportot a fürthöz az [az group create][az-group-create] paranccsal.

    az group create -l <region> -n <resourceGroupName>

  2. Hozzon létre egy kettős veremű AKS-fürtöt a az aks create parancs használatával, amelynek paramétere a --ip-families következő.ipv4,ipv6

    az aks create -l <region> -g <resourceGroupName> -n <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

Példa számítási feladat létrehozása

A fürt létrehozása után üzembe helyezheti a számítási feladatokat. Ez a cikk végigvezeti egy NGINX-webkiszolgáló számítási feladatának üzembe helyezésén.

NGINX-webkiszolgáló üzembe helyezése

Az alkalmazás-útválasztási bővítmény az AKS-fürtök bejövő forgalmának ajánlott módja. Az alkalmazás-útválasztási bővítményről és egy alkalmazás bővítményrel való üzembe helyezéséről további információt az alkalmazás-útválasztási bővítményrel rendelkező felügyelt NGINX-bejövő forgalom című témakörben talál.

A számítási feladat felfedése egy LoadBalancer típusszolgáltatáson keresztül

Fontos

Az AKS-ben jelenleg két korlátozás vonatkozik az IPv6-szolgáltatásokra.

  • Az Azure Load Balancer egy kapcsolat helyi címéről küld állapotmintákat az IPv6-célhelyekre. Az Azure Linux-csomópontkészletekben ez a forgalom nem irányítható podra, ezért a forgalom sikertelen üzembe helyezésű externalTrafficPolicy: Cluster IPv6-szolgáltatásokba áramlik. Az IPv6-szolgáltatásokat üzembe kell helyezni externalTrafficPolicy: Local, ami a csomóponton lévő mintavételre való reagálást okozza kube-proxy .
  • A Kubernetes 1.27-es verziója előtt csak a szolgáltatás első IP-címe lesz kiépítve a terheléselosztó számára, így a kettős veremű szolgáltatás csak az elsőként felsorolt IP-család nyilvános IP-címét kapja meg. Ha egy üzembe helyezéshez két stackes szolgáltatást szeretne biztosítani, hozzon létre két szolgáltatást, amely ugyanazt a választót célozza, egyet az IPv4-hez, egyet pedig az IPv6-hoz. Ez már nem korlátozás a Kubernetes 1.27 vagy újabb verziójában.

  1. Tegye elérhetővé az NGINX-üzembe helyezést a kubectl expose deployment nginx paranccsal.

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    Megjelenik egy kimenet, amely azt mutatja, hogy a szolgáltatások közzé lettek téve.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. Az üzembe helyezés és a LoadBalancer szolgáltatások teljes kiépítése után kérje le a szolgáltatások IP-címét a kubectl get services parancs használatával.

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. Ellenőrizze a funkciókat egy IPv6-kompatibilis gazdagép parancssori webes kérésében. Az Azure Cloud Shell nem IPv6-kompatibilis.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

Következő lépések

Ha meg szeretné tudni, hogyan használhatja az AKS-t a saját Tárolóhálózati adapter (CNI) beépülő modullal, olvassa el a Saját tárolóhálózati adapter (CNI) beépülő modulját.