Megosztás a következőn keresztül:

Kubenet-hálózatkezelés használata saját IP-címtartományokkal az Azure Kubernetes Service-ben (AKS)

  • Cikk

Az AKS-fürtök kubenetet használnak, és alapértelmezés szerint létrehoznak egy Azure-beli virtuális hálózatot és alhálózatot. A kubenet használata esetén a csomópontok az Azure-beli virtuális hálózat alhálózatáról kapnak IP-címet. A podok IP-címe a csomópontok Azure-beli virtuális hálózati alhálózatától logikailag eltérő címtérből származik. A hálózati címfordítás (NAT) ezután konfigurálva van, hogy a podok elérjék az Azure-beli virtuális hálózat erőforrásait. A forgalom forrás IP-címe a nat'd a csomópont elsődleges IP-címére. Ez a megközelítés jelentősen csökkenti a podok használatához szükséges ip-címek számát a hálózati térben.

Az Azure Container Networking Interface (CNI) használatával minden pod egy IP-címet kap az alhálózatról, és közvetlenül elérhető. Ezeket az IP-címeket előre kell megtervezni, és egyedinek kell lenniük a hálózati térben. Minden csomópont rendelkezik egy konfigurációs paraméterrel a támogatott podok maximális számához. A csomópontonkénti IP-címek egyenértékű száma ezután előre lefoglalva lesz az adott csomópont számára. Ez a megközelítés több tervezést igényel, és gyakran az IP-címek kimerüléséhez vagy a fürtök nagyobb alhálózatban való újraépítéséhez vezet az alkalmazás igényeinek növekedésével. A fürtlétrehozáskor vagy új csomópontkészletek létrehozásakor konfigurálhatja a csomópontokon üzembe helyezhető maximális podokat. Ha nem adja meg maxPods az új csomópontkészletek létrehozásakor, a kubenet alapértelmezett értéke 110 lesz.

Ez a cikk bemutatja, hogyan hozhat létre és használhat virtuális hálózati alhálózatot egy AKS-fürthöz kubenet-hálózat használatával. A hálózati lehetőségekről és szempontokról további információt a Kubernetes és az AKS hálózati fogalmaiban talál.

Előfeltételek

  • Az AKS-fürt virtuális hálózatának engedélyeznie kell a kimenő internetkapcsolatot.
  • Ne hozzon létre több AKS-fürtöt ugyanabban az alhálózatban.
  • Az AKS-fürtök nem használhatják 169.254.0.0/16172.30.0.0/16172.31.0.0/16192.0.2.0/24 a Kubernetes szolgáltatás címtartományát, podcímtartományát vagy fürt virtuális hálózati címtartományát. A tartomány nem frissíthető a fürt létrehozása után.
  • Az AKS-fürt által használt fürtidentitásnak legalább hálózati közreműködői szerepkörrel kell rendelkeznie a virtuális hálózaton belüli alhálózaton. A parancssori felület segít automatikusan beállítani a szerepkör-hozzárendelést. Ha ARM-sablont vagy más ügyfeleket használ, manuálisan kell beállítania a szerepkör-hozzárendelést. A fürt identitásának létrehozásához és engedélyeinek hozzárendeléséhez rendelkeznie kell a megfelelő engedélyekkel, például az előfizetés tulajdonosával. Ha a beépített hálózati közreműködői szerepkör helyett egyéni szerepkört szeretne definiálni, a következő engedélyekre van szüksége:
    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read

Figyelmeztetés

A Windows Server-csomópontkészletek használatához az Azure CNI-t kell használnia. A kubenet hálózati modell nem érhető el Windows Server-tárolókhoz.

Mielőtt elkezdené

Telepítenie és konfigurálnia kell az Azure CLI 2.0.65-ös vagy újabb verzióját. A verzió azonosításához futtassa a következőt: az --version. Ha telepíteni vagy frissíteni szeretne: Az Azure CLI telepítése.

A kubenet saját alhálózattal való hálózatkezelésének áttekintése

Számos környezetben meghatározott virtuális hálózatokat és alhálózatokat lefoglalt IP-címtartományokkal, és ezeket az erőforrásokat több szolgáltatás és alkalmazás támogatására használja. A hálózati kapcsolat biztosításához az AKS-fürtök használhatják a kubenetet (alapszintű hálózatkezelés) vagy az Azure CNI-t (speciális hálózatkezelés).

A kubenettel csak a csomópontok kapnak IP-címet a virtuális hálózati alhálózatban. A podok nem tudnak közvetlenül kommunikálni egymással. Ehelyett a felhasználó által definiált útválasztás (UDR) és az IP-továbbítás kezeli a csomópontok közötti podok közötti kapcsolatot. Az UDR-eket és az IP-továbbítási konfigurációt alapértelmezés szerint az AKS szolgáltatás hozza létre és tartja karban, de igény szerint saját útvonaltáblát is használhat az egyéni útvonalkezeléshez . Podokat is üzembe helyezhet egy olyan szolgáltatás mögött, amely hozzárendelt IP-címet kap, és terheléselosztást biztosít az alkalmazás forgalmának. Az alábbi ábra azt mutatja be, hogy az AKS-csomópontok hogyan kapnak IP-címet a virtuális hálózati alhálózatban, a podokban azonban nem:

Kubenet hálózati modell AKS-fürttel

egy UDR-ben legfeljebb 400 útvonalat Azure-támogatás, így nem lehet 400 csomópontnál nagyobb AKS-fürt. A kubenet nem támogatja az AKS virtuális csomópontokat és az Azure Network Policiest. A Calico hálózati házirendjei támogatottak.

Az Azure CNI-vel minden pod egy IP-címet kap az IP-alhálózatban, és közvetlenül kommunikálhat más podokkal és szolgáltatásokkal. A fürtök olyan nagyok lehetnek, mint a megadott IP-címtartomány. Azonban előre meg kell terveznie az IP-címtartományt, és az összes IP-címet az AKS-csomópontok a támogatott podok maximális száma alapján fogják használni. Az Azure CNI támogatja az olyan speciális hálózati funkciókat és forgatókönyveket, mint a virtuális csomópontok vagy a hálózati szabályzatok (az Azure vagy a Calico).

A kubenet korlátozásai és szempontjai

Feljegyzés

Egyes rendszer podok, például a fürtön belüli konnectivity a gazdacsomópont IP-címét használják, nem pedig az átfedéses címtérből származó IP-címet. A rendszer podjai csak a csomópont IP-címét használják, a virtuális hálózatról származó IP-címet nem.

IP-cím rendelkezésre állása és kimerültsége

Az Azure CNI-vel kapcsolatos gyakori probléma, hogy a hozzárendelt IP-címtartomány túl kicsi ahhoz, hogy több csomópontot adjon hozzá a fürt méretezése vagy frissítése során. Előfordulhat, hogy a hálózati csapat nem tud elég nagy IP-címtartományt kibocsátani a várt alkalmazásigények kielégítéséhez.

Kompromisszumként létrehozhat egy olyan AKS-fürtöt, amely kubenetet használ, és egy meglévő virtuális hálózati alhálózathoz csatlakozik. Ez a módszer lehetővé teszi, hogy a csomópontok meghatározott IP-címeket kapjanak anélkül, hogy nagy számú IP-címet kellene lefoglalni a fürtben futtatható lehetséges podok számára. A Kubenet használatával sokkal kisebb IP-címtartományt használhat, és nagy fürtöket és alkalmazásigényeket támogathat. Ha például egy /27 IP-címtartomány van az alhálózaton, futtathat egy 20–25 csomópontos fürtöt, amely elegendő helyet biztosít a méretezéshez vagy a frissítéshez. Ez a fürtméret legfeljebb 2200–2750 podot támogat (csomópontonként alapértelmezetten legfeljebb 110 pod). Az AKS-ben a kubenettel konfigurálható podok maximális száma csomópontonként 250.

Az alábbi alapszámítások a hálózati modellek különbségét hasonlítják össze:

  • kubenet: Egy egyszerű /24 IP-címtartomány legfeljebb 251 csomópontot támogat a fürtben. Minden Azure-beli virtuális hálózati alhálózat fenntartja az első három IP-címet a felügyeleti műveletekhez. Ez a csomópontszám legfeljebb 27 610 podot támogat, csomópontonként alapértelmezetten legfeljebb 110 podot.
  • Azure CNI: Ugyanez az alapszintű /24 alhálózati tartomány legfeljebb nyolc csomópontot támogat a fürtben. Ez a csomópontszám legfeljebb 240 podot támogat, csomópontonként alapértelmezetten legfeljebb 30 podot.

Feljegyzés

Ezek a maximumok nem veszik figyelembe a frissítési és méretezési műveleteket. A gyakorlatban nem futtatható az alhálózati IP-címtartomány által támogatott csomópontok maximális száma. A skálázási vagy frissítési műveletekhez néhány IP-címet el kell hagynia.

Virtuális hálózatok közötti társviszony-létesítés és ExpressRoute-kapcsolatok

A helyszíni kapcsolat biztosításához a Kubenet és az Azure-CNI hálózati megközelítések egyaránt használhatják az Azure-beli virtuális hálózatok közötti társviszony-létesítést vagy az ExpressRoute-kapcsolatokat. Gondosan tervezze meg az IP-címtartományokat az átfedés és a helytelen forgalom útválasztásának megakadályozása érdekében. Számos helyszíni hálózat például az ExpressRoute-kapcsolaton keresztül meghirdetett 10.0.0.0/8 címtartományt használja. Javasoljuk, hogy hozzon létre AKS-fürtöket a címtartományon kívüli Azure-beli virtuális hálózati alhálózatokban, például a 172.16.0.0/16-os számon.

Válassza ki a használni kívánt hálózati modellt

Az alábbi szempontok segítenek felvázolni, hogy az egyes hálózati modellek mikor lehetnek a legmegfelelőbbek:

A kubenet használata a következő esetekben:

  • Korlátozott IP-címterülettel rendelkezik.
  • 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 vagy Azure Network Policyre.

Az Azure CNI használata 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.
  • Nem szeretné kezelni a podkapcsolat felhasználó által definiált útvonalait.
  • Speciális AKS-funkciókra, például virtuális csomópontokra vagy Azure Network Policyre van szüksége.

A használni kívánt hálózati modell kiválasztásával kapcsolatos további információkért tekintse meg a hálózati modellek és támogatási hatókörük összehasonlítását ismertető témakört.

Virtuális hálózat és alhálózat létrehozása

  1. Hozzon létre egy erőforráscsoportot a az group create paranccsal.

    az group create --name myResourceGroup --location eastus

  2. Ha nem rendelkezik meglévő virtuális hálózattal és alhálózattal, hozza létre ezeket a hálózati erőforrásokat a az network vnet create paranccsal. Az alábbi példaparancs létrehoz egy myAKSVnet nevű virtuális hálózatot a 192.168.0.0/16 címelőtaggal és egy myAKSSubnet nevű alhálózattal a 192.168.1.0/24 címelőtaggal:

    az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24 \
    --location eastus

  3. Kérje le az alhálózati erőforrás-azonosítót a az network vnet subnet show parancs használatával, és tárolja későbbi használatra elnevezett SUBNET_ID változóként.

    SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

AKS-fürt létrehozása a virtuális hálózaton

AKS-fürt létrehozása rendszer által hozzárendelt felügyelt identitásokkal

Feljegyzés

Rendszer által hozzárendelt identitás használatakor az Azure CLI a hálózati közreműködői szerepkört a rendszer által hozzárendelt identitásnak adja a fürt létrehozása után. Ha ARM-sablont vagy más ügyfeleket használ, ehelyett a felhasználó által hozzárendelt felügyelt identitást kell használnia .

  • A parancs használatával az aks create hozzon létre egy AKS-fürtöt rendszer által hozzárendelt felügyelt identitásokkal.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --vnet-subnet-id $SUBNET_ID \
    --generate-ssh-keys

    Üzembehelyezési paraméterek:

    • A --service-cidr nem kötelező. Ez a cím egy IP-cím hozzárendelésére szolgál az AKS-fürt belső szolgáltatásaihoz. Ennek az IP-címtartománynak olyan címtérnek kell lennie, amely nincs a hálózati környezetben máshol használva, beleértve a helyszíni hálózati tartományokat is, ha csatlakozik vagy csatlakozni szeretne az Azure-beli virtuális hálózatokhoz Express Route vagy helyek közötti VPN-kapcsolat használatával. Az alapértelmezett érték 10.0.0.0/16.
    • A --dns-service-ip nem kötelező. A címnek a szolgáltatás IP-címtartományának .10-nek kell lennie. Az alapértelmezett érték 10.0.0.10.
    • --pod-cidr nem kötelező. Ennek a címnek olyan nagy címtérnek kell lennie, amely nincs a hálózati környezet más részein használva. Ez a tartomány minden helyszíni hálózati tartományt magában foglal, ha Express Route vagy helyek közötti VPN-kapcsolat használatával csatlakozik vagy csatlakozni kíván az Azure-beli virtuális hálózatokhoz. Az alapértelmezett érték 10.244.0.0/16.
      • Ennek a címtartománynak elég nagynak kell lennie ahhoz, hogy elférjen a várhatóan felskálázni kívánt csomópontok száma. Ezt a címtartományt a fürt üzembe helyezése után nem módosíthatja.
      • A pod IP-címtartományával /24 címteret rendelhet a fürt minden csomóponthoz. A következő példában a 10.244.0.0/16 -pod-cidr az első csomópontot 10.244.0.0/24-et, a második csomópontot 10.244.1.0/24-et, a harmadik csomópontot pedig a 10.244.2.0/24-et rendeli hozzá.
      • A fürt méretezése vagy frissítése során az Azure-platform továbbra is pod IP-címtartományt rendel minden új csomóponthoz.

AKS-fürt létrehozása felhasználó által hozzárendelt felügyelt identitással

Felügyelt identitás létrehozása

  • Felügyelt identitás létrehozása a az identity paranccsal. Ha már rendelkezik felügyelt identitással, keresse meg az egyszerű azonosítót a az identity show --ids <identity-resource-id> parancs használatával.

    az identity create --name myIdentity --resource-group myResourceGroup

    A kimenetnek a következő példakimenethez kell hasonlítania:

    {                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Szerepkör-hozzárendelés hozzáadása felügyelt identitáshoz

Ha az Azure CLI-t használja, a rendszer automatikusan hozzáadja a szerepkört, és kihagyhatja ezt a lépést. Ha ARM-sablont vagy más ügyfeleket használ, a fürt által felügyelt identitás egyszerű azonosítójával kell elvégeznie egy szerepkör-hozzárendelést.

  • Kérje le a virtuális hálózati erőforrás-azonosítót a az network vnet show parancs használatával, és tárolja egy névvel ellátott VNET_IDváltozóként.

    VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

  • Rendelje hozzá a felügyelt identitást az AKS-fürt hálózati közreműködői engedélyéhez a virtuális hálózaton a az role assignment create paranccsal, és adja meg a< principalId azonosítót>.

    az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

# Example command
az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

Feljegyzés

A fürt Azure által használt felügyelt identitásához adott engedély feltöltése akár 60 percet is igénybe vehet.

AKS-fürt létrehozása

  • Hozzon létre egy AKS-fürtöt a az aks create paranccsal, és adja meg a vezérlősík felügyelt identitás erőforrás-azonosítóját az assign-identity argumentumhoz a felhasználó által hozzárendelt felügyelt identitás hozzárendeléséhez.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --assign-identity <identity-resource-id> \
    --generate-ssh-keys

AKS-fürt létrehozásakor a rendszer automatikusan létrehoz egy hálózati biztonsági csoportot és útvonaltáblát. Ezeket a hálózati erőforrásokat az AKS vezérlősíkja kezeli. A hálózati biztonsági csoport automatikusan társítva van a csomópontokon lévő virtuális hálózati adapterekkel. Az útvonaltábla automatikusan társítva van a virtuális hálózati alhálózattal. A hálózati biztonsági csoport szabályai és útvonaltáblái automatikusan frissülnek a szolgáltatások létrehozása és elérhetővé helyezésekor.

Saját alhálózat és útvonaltábla használata a kubenettel

A kubenet esetén egy útvonaltáblának kell lennie a fürt alhálózatán. Az AKS támogatja a saját meglévő alhálózat és útvonaltábla használatát. Ha az egyéni alhálózat nem tartalmaz útvonaltáblát, az AKS létrehoz egyet, és szabályokat ad hozzá a fürt életciklusa során. Ha az egyéni alhálózat útvonaltáblát tartalmaz a fürt létrehozásakor, az AKS a fürtműveletek során nyugtázza a meglévő útvonaltáblát, és ennek megfelelően adja hozzá/frissíti a felhőszolgáltatói műveletekre vonatkozó szabályokat.

Figyelmeztetés

Az egyéni útvonaltáblán egyéni szabályokat adhat hozzá/frissíthet. A Kubernetes felhőszolgáltatója azonban hozzáadja a szabályokat, amelyeket nem lehet frissíteni vagy eltávolítani. Az olyan szabályoknak, mint a 0.0.0.0/0 , mindig létezniük kell egy adott útvonaltáblán, és le kell képezniük az internetes átjáró célját, például egy NVA-t vagy más kimenő átjárót. A szabályok frissítésekor körültekintően járjon el.

További információ az egyéni útvonaltáblák beállításáról.

A Kubenet hálózatkezeléséhez szervezett útvonaltábla-szabályok szükségesek a kérelmek sikeres átirányításához. Ennek a kialakításnak köszönhetően az útvonaltáblákat gondosan karban kell tartani minden olyan fürt esetében, amely támaszkodik rá. Több fürt nem oszthat meg útvonaltáblát, mert a különböző fürtök pod CIDR-jei átfedésbe kerülhetnek, ami váratlan és hibás útválasztási forgatókönyveket okozhat. Ha ugyanazon a virtuális hálózaton több fürtöt konfigurál, vagy egy virtuális hálózatot szentel az egyes fürtöknek, vegye figyelembe az alábbi korlátozásokat:

  • Az AKS-fürt létrehozása előtt egyéni útvonaltáblát kell társítani az alhálózathoz.
  • A társított útvonaltábla-erőforrás nem frissíthető a fürt létrehozása után. Az egyéni szabályok azonban módosíthatók az útvonaltáblán.
  • Minden AKS-fürtnek egyetlen, egyedi útvonaltáblát kell használnia a fürthöz társított összes alhálózathoz. Több fürttel rendelkező útvonaltáblát nem használhat újra, mert átfedésben lehet a pod CIDR-jeivel és az ütköző útválasztási szabályokkal.
  • A rendszer által hozzárendelt felügyelt identitások esetében csak saját alhálózatot és útvonaltáblát lehet biztosítani az Azure CLI-vel, mert az Azure CLI automatikusan hozzáadja a szerepkör-hozzárendelést. Ha ARM-sablont vagy más ügyfeleket használ, felhasználó által hozzárendelt felügyelt identitást kell használnia, engedélyeket kell hozzárendelnie a fürt létrehozása előtt, és gondoskodnia kell arról, hogy a felhasználó által hozzárendelt identitás írási engedélyekkel rendelkezzen az egyéni alhálózathoz és az egyéni útvonaltáblához.
  • Ha ugyanazt az útvonaltáblát több AKS-fürttel használja, az nem támogatott.

Feljegyzés

Ha saját virtuális hálózatot és útvonaltáblát hoz létre és használ a Kubenet hálózati beépülő modullal, konfigurálnia kell egy felhasználó által hozzárendelt felügyelt identitást a fürthöz. Rendszer által hozzárendelt felügyelt identitással nem lehet lekérni az identitásazonosítót a fürt létrehozása előtt, ami késést okoz a szerepkör-hozzárendelés során.

A rendszer által hozzárendelt és a felhasználó által hozzárendelt felügyelt identitások akkor is támogatottak, ha saját virtuális hálózatot és útvonaltáblát hoz létre és használ az Azure hálózati beépülő modullal. Kifejezetten javasoljuk, hogy byo-forgatókönyvekhez használjon felhasználó által hozzárendelt felügyelt identitást.

Útvonaltábla hozzáadása felhasználó által hozzárendelt felügyelt identitással az AKS-fürthöz

Miután létrehozott egy egyéni útvonaltáblát, és társította azt egy alhálózattal a virtuális hálózatban, létrehozhat egy új AKS-fürtöt, amely megadja az útvonaltáblát egy felhasználó által hozzárendelt felügyelt identitással. Az AKS-fürt üzembe helyezéséhez az alhálózat-azonosítót kell használnia. Ezt az alhálózatot az egyéni útvonaltáblához is hozzá kell társítani.

  1. Kérje le az alhálózat azonosítóját a az network vnet subnet list paranccsal.

    az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]

  2. Hozzon létre egy AKS-fürtöt egy olyan egyéni alhálózattal, amely előre konfigurálva van egy útvonaltáblával a az aks create parancs használatával, és megadja az értékeket és --assign-identity a --vnet-subnet-id paramétereket.

    az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --vnet-subnet-id mySubnetIDResourceID \
    --assign-identity controlPlaneIdentityResourceID \
    --generate-ssh-keys

Következő lépések

Ez a cikk bemutatta, hogyan helyezheti üzembe az AKS-fürtöt a meglévő virtuális hálózati alhálózaton. Most elkezdhet új alkalmazásokat létrehozni a Helm használatával, vagy üzembe helyezhet meglévő alkalmazásokat a Helm használatával.