Použití sítě kubenet s vlastními rozsahy IP adres ve službě Azure Kubernetes Service (AKS)

Clustery AKS používají kubenet a ve výchozím nastavení vytvoří virtuální síť a podsíť Azure. Při použití kubenet získají uzly IP adresu z podsítě virtuální sítě Azure. Pody získají IP adresu z logicky jiného adresního prostoru do podsítě virtuální sítě Azure uzlů. Překlad síťových adres (NAT) se pak nakonfiguruje, aby pody mohly přistupovat k prostředkům ve virtuální síti Azure. Zdrojová IP adresa provozu je NAT na primární IP adresu uzlu. Tento přístup výrazně snižuje počet IP adres, které potřebujete rezervovat v síťovém prostoru, aby se pody mohly používat.

V případě rozhraní CNI (Container Networking Interface) získá každý pod z podsítě IP adresu a bude k němu možné přistupovat přímo. Tyto IP adresy musí být naplánovány předem a jedinečně v celém síťovém prostoru. Každý uzel má konfigurační parametr pro maximální počet podů, které podporuje. Ekvivalentní počet IP adres na uzel je pak vyhrazený předem pro tento uzel. Tento přístup vyžaduje větší plánování a často vede k vyčerpání IP adres nebo nutnosti znovu sestavit clustery ve větší podsíti, jak vaše aplikace roste. Při vytváření nových fondů uzlů můžete nakonfigurovat maximální nasazení podů do uzlu při vytváření clusteru nebo při vytváření nových fondů uzlů. Pokud při vytváření nových fondů uzlů nezadáte maxPods , zobrazí se výchozí hodnota 110 pro kubenet.

V tomto článku se dozvíte, jak pomocí sítí kubenet vytvořit a použít podsíť virtuální sítě pro cluster AKS. Další informace o možnostech a aspektech sítě najdete v tématu Koncepty sítě pro Kubernetes a AKS.

Požadavky

• Virtuální síť pro cluster AKS musí umožňovat odchozí připojení k internetu.
• Nevytvávejte ve stejné podsíti víc než jeden cluster AKS.
• Clustery AKS nemůžou používat 169.254.0.0/16, 172.30.0.0/16, , 172.31.0.0/16ani 192.0.2.0/24 pro rozsah adres služby Kubernetes, rozsah adres podů nebo rozsah adres virtuální sítě clusteru. Rozsah nelze po vytvoření clusteru aktualizovat.
• Identita clusteru používaná clusterem AKS musí mít alespoň roli Přispěvatel sítě v podsíti ve vaší virtuální síti. Rozhraní příkazového řádku pomáhá automaticky nastavit přiřazení role. Pokud používáte šablonu ARM nebo jiné klienty, musíte přiřazení role nastavit ručně. Abyste mohli vytvořit identitu clusteru a přiřadit jí oprávnění, musíte mít také příslušná oprávnění, například vlastník předplatného. Pokud chcete místo předdefinované role Přispěvatel sítě definovat vlastní roli , potřebujete následující oprávnění:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Než začnete

Potřebujete nainstalované a nakonfigurované Rozhraní příkazového řádku Azure CLI verze 2.0.65 nebo novější. Verzi zjistíte spuštěním příkazu az --version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.

Přehled sítí kubenet s vlastní podsítí

V mnoha prostředích jste definovali virtuální sítě a podsítě s přidělenými rozsahy IP adres a tyto prostředky používáte k podpoře více služeb a aplikací. K zajištění síťového připojení můžou clustery AKS používat kubenet (základní sítě) nebo Azure CNI (pokročilé sítě).

V případě kubenetu obdrží IP adresu v podsíti virtuální sítě jenom uzly. Pody nemůžou vzájemně komunikovat přímo. Místo toho směrování definované uživatelem a předávání IP zpracovává připojení mezi pody napříč uzly. Trasy definované uživatelem a konfigurace předávání IP se vytvářejí a spravují ve výchozím nastavení službou AKS, ale pokud chcete, můžete použít vlastní směrovací tabulku pro vlastní správu tras. Pody můžete také nasadit za službu, která přijímá přiřazenou IP adresu a vyrovnává zatížení provozu pro aplikaci. Následující diagram ukazuje, jak uzly AKS přijímají IP adresu v podsíti virtuální sítě, ale ne pody:

podpora Azure maximálně 400 tras v trasy definované uživatelem, takže cluster AKS nemůžete mít větší než 400 uzlů. Virtuální uzly AKS a zásady sítě Azure se u kubenetu nepodporují. Podporují se zásady sítě Calico.

U Azure CNI každý pod obdrží IP adresu v podsíti IP a může komunikovat přímo s jinými pody a službami. Clustery můžou být tak velké jako rozsah IP adres, který zadáte. Rozsah IP adres ale musíte naplánovat předem a všechny IP adresy využívají uzly AKS na základě maximálního počtu podů, které můžou podporovat. Azure CNI podporuje pokročilé síťové funkce a scénáře, jako jsou virtuální uzly nebo zásady sítě (Azure nebo Calico).

Omezení a aspekty kubenetu

• V návrhu kubenetu je vyžadován další segment směrování, který přidává menší latenci ke komunikaci podů.
• Směrovací tabulky a trasy definované uživatelem se vyžadují pro použití kubenetu, což zvyšuje složitost operací.
  • Další informace najdete v tématu Přizpůsobení výchozího přenosu dat clusteru pomocí uživatelem definované směrovací tabulky v AKS a přizpůsobení výchozího přenosu clusteru s odchozími typy v AKS.
• Přímé adresování podů není podporováno pro kubenet kvůli návrhu kubenetu.
• Na rozdíl od clusterů Azure CNI nemůže podsíť sdílet více clusterů kubenet.
• AKS u své podsítě nepoužije skupiny zabezpečení sítě (NSG) a neupravuje žádné skupiny zabezpečení sítě přidružené k této podsíti. Pokud zadáte vlastní podsíť a přidáte skupiny zabezpečení sítě přidružené k této podsíti, musíte zajistit, aby pravidla zabezpečení ve skupině zabezpečení sítě umožňovala provoz mezi uzlem a ciDR podů. Další podrobnosti najdete v tématu Skupiny zabezpečení sítě.
• Mezi nepodporovaná funkce kubenetu patří:
  • Zásady sítě Azure
  • Fondy uzlů Windows
  • Doplněk Virtuální uzly

Dostupnost a vyčerpání IP adres

Běžným problémem s Azure CNI je, že přiřazený rozsah IP adres je příliš malý, aby při škálování nebo upgradu clusteru přidal další uzly. Síťový tým také nemusí být schopen vydat dostatečně velký rozsah IP adres pro podporu očekávaných požadavků aplikace.

Jako kompromis můžete vytvořit cluster AKS, který používá kubenet a připojit se k existující podsíti virtuální sítě. Tento přístup umožňuje uzlům přijímat definované IP adresy, aniž by bylo nutné předem rezervovat velký počet IP adres pro všechny potenciální pody, které by mohly běžet v clusteru. Pomocí kubenetu můžete použít mnohem menší rozsah IP adres a podporovat velké clustery a požadavky aplikací. Například s rozsahem IP adres /27 ve vaší podsíti můžete spustit cluster 20–25 uzlů s dostatečným prostorem pro škálování nebo upgrade. Tato velikost clusteru může podporovat až 2 200 až 2 750 podů (s výchozím maximálním počtem 110 podů na uzel). Maximální počet podů na uzel, který můžete nakonfigurovat s kubenetem v AKS, je 250.

Následující základní výpočty porovnávají rozdíly v síťových modelech:

• kubenet: Jednoduchý rozsah IP adres /24 může podporovat až 251 uzlů v clusteru. Každá podsíť virtuální sítě Azure si vyhrazuje první tři IP adresy pro operace správy. Tento počet uzlů může podporovat až 27 610 podů s výchozím maximálním počtem 110 podů na uzel.
• Azure CNI: Stejný základní rozsah podsítě /24 může podporovat maximálně osm uzlů v clusteru. Tento počet uzlů může podporovat maximálně 240 podů s výchozím maximálním počtem 30 podů na uzel.

Partnerské vztahy virtuálních sítí a připojení ExpressRoute

K zajištění místního připojení můžou přístupy k síti kubenet i Azure-CNI používat partnerský vztah virtuálních sítí Azure nebo připojení ExpressRoute. Pečlivě naplánujte rozsahy IP adres, abyste zabránili překrývání a nesprávnému směrování provozu. Mnoho místních sítí například používá rozsah adres 10.0.0.0/8 , který se inzeruje přes připojení ExpressRoute. Doporučujeme vytvářet clustery AKS v podsítích virtuální sítě Azure mimo tento rozsah adres, například 172.16.0.0/16.

Volba síťového modelu, který se má použít

Následující aspekty vám pomůžou uvést, kdy může být každý síťový model nejvhodnější:

K použití kubenetu použijte následující:

• Máte omezený adresní prostor IP adres.
• Většina komunikace podů je v clusteru.
• Nepotřebujete pokročilé funkce AKS, jako jsou virtuální uzly nebo Azure Network Policy.

Azure CNI použijte, když:

• Máte k dispozici adresní prostor IP adres.
• Většina komunikace podů je s prostředky mimo cluster.
• Nechcete spravovat trasy definované uživatelem pro připojení podů.
• Potřebujete pokročilé funkce AKS, jako jsou virtuální uzly nebo Azure Network Policy.

Další informace, které vám pomůžou rozhodnout, který síťový model se má použít, najdete v tématu Porovnání síťových modelů a jejich rozsahu podpory.

Vytvoření virtuální sítě a podsítě

1. Pomocí příkazu vytvořte skupinu az group create prostředků.

   az group create --name myResourceGroup --location eastus
   

2. Pokud nemáte existující virtuální síť a podsíť, které chcete použít, vytvořte tyto síťové prostředky pomocí az network vnet create příkazu. Následující ukázkový příkaz vytvoří virtuální síť myAKSVnet s předponou adresy 192.168.0.0/16 a podsítí s názvem myAKSSubnet s předponou adresy 192.168.1.0/24:

   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. Získejte ID prostředku podsítě pomocí az network vnet subnet show příkazu a uložte ho jako proměnnou s názvem SUBNET_ID pro pozdější použití.

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

Vytvoření clusteru AKS ve virtuální síti

Vytvoření clusteru AKS se spravovanými identitami přiřazenými systémem

• Pomocí příkazu vytvořte cluster AKS se spravovanými identitami az aks create přiřazenými systémem.

  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 
  

  Parametry nasazení:

  • --service-cidr je volitelný. Tato adresa slouží k přiřazení interních služeb v clusteru AKS ip adresou. Tento rozsah IP adres by měl být adresní prostor, který se nepoužívá jinde v síťovém prostředí, včetně rozsahů místní sítě, pokud se připojujete nebo plánujete připojit, virtuální sítě Azure pomocí ExpressRoute nebo připojení VPN typu Site-to-Site. Výchozí hodnota je 10.0.0.0/16.
  • --dns-service-ip je volitelná. Adresa by měla být adresa .10 rozsahu IP adres vaší služby. Výchozí hodnota je 10.0.0.10.
  • --pod-cidr je volitelný. Tato adresa by měla být velký adresní prostor, který se nepoužívá jinde v síťovém prostředí. Tento rozsah zahrnuje všechny rozsahy místních sítí, pokud se připojujete nebo plánujete připojit, virtuální sítě Azure pomocí ExpressRoute nebo připojení VPN typu Site-to-Site. Výchozí hodnota je 10.244.0.0/16.
    • Tento rozsah adres musí být dostatečně velký, aby vyhovoval počtu uzlů, na které očekáváte vertikální navýšení kapacity. Po nasazení clusteru nemůžete tento rozsah adres změnit.
    • Rozsah IP adres podů slouží k přiřazení adresního prostoru /24 ke každému uzlu v clusteru. V následujícím příkladu přiřadí --pod-cidr 10.244.0.0/16 první uzel 10.244.0.0/24, druhý uzel 10.244.1.0/24 a třetí uzel 10.244.2.0/24.
    • Při škálování nebo upgradu clusteru platforma Azure nadále přiřazuje rozsah IP adres podů každému novému uzlu.

Vytvoření clusteru AKS se spravovanou identitou přiřazenou uživatelem

Vytvoření spravované identity

• Vytvořte spravovanou identitu pomocí az identity příkazu. Pokud máte existující spravovanou identitu, vyhledejte ID objektu az identity show --ids <identity-resource-id> zabezpečení pomocí příkazu.

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

  Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

  {                                  
    "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"
  }
  

Přidání přiřazení role pro spravovanou identitu

Pokud používáte Azure CLI, role se automaticky přidá a tento krok můžete přeskočit. Pokud používáte šablonu ARM nebo jiné klienty, musíte k přiřazení role použít ID objektu zabezpečení spravované identity clusteru.

• Získejte ID prostředku virtuální sítě pomocí az network vnet show příkazu a uložte ho jako proměnnou s názvem VNET_ID.

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

• Pomocí příkazu přiřaďte spravovanou identitu pro oprávnění Přispěvatel sítě clusteru AKS ve virtuální síti az role assignment create a zadejte id objektu <zabezpečení>.

  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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

Vytvoření clusteru AKS

• Vytvořte cluster AKS pomocí az aks create příkazu a zadejte ID prostředku spravované identity řídicí roviny pro argument pro assign-identity přiřazení spravované identity přiřazené uživatelem.

  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
  

Při vytváření clusteru AKS se automaticky vytvoří skupina zabezpečení sítě a směrovací tabulka. Tyto síťové prostředky spravuje řídicí rovina AKS. Skupina zabezpečení sítě se automaticky přidružuje k virtuálním síťovým kartám na vašich uzlech. Směrovací tabulka je automaticky přidružená k podsíti virtuální sítě. Pravidla skupiny zabezpečení sítě a směrovací tabulky se při vytváření a zveřejnění služeb automaticky aktualizují.

Používání vlastní podsítě a směrovací tabulky v síti kubenet

U kubenetu musí existovat směrovací tabulka v podsítích clusteru. AKS podporuje přenesení vlastní existující podsítě a směrovací tabulky. Pokud vaše vlastní podsíť neobsahuje směrovací tabulku, AKS ji pro vás vytvoří a přidá pravidla v průběhu životního cyklu clusteru. Pokud vaše vlastní podsíť obsahuje při vytváření clusteru směrovací tabulku, AKS potvrdí stávající směrovací tabulku během operací clusteru a odpovídajícím způsobem přidává/aktualizuje pravidla pro operace poskytovatele cloudu.

Přečtěte si další informace o nastavení vlastní směrovací tabulky.

Sítě Kubenet vyžadují k úspěšnému směrování požadavků uspořádaná pravidla směrovací tabulky. Vzhledem k tomuto návrhu musí být směrovací tabulky pečlivě udržovány pro každý cluster, který na něj spoléhá. Více clusterů nemůže sdílet směrovací tabulku, protože identifikátoryCID podů z různých clusterů se můžou překrývat, což způsobuje neočekávané a poškozené scénáře směrování. Při konfiguraci více clusterů ve stejné virtuální síti nebo při vyhrazování virtuální sítě ke každému clusteru zvažte následující omezení:

• Před vytvořením clusteru AKS musí být k podsíti přidružená vlastní směrovací tabulka.
• Přidružený prostředek směrovací tabulky nelze po vytvoření clusteru aktualizovat. Vlastní pravidla je však možné upravit v směrovací tabulce.
• Každý cluster AKS musí používat jednu jedinečnou směrovací tabulku pro všechny podsítě přidružené ke clusteru. Směrovací tabulku s více clustery nemůžete opakovaně používat kvůli možnému překrývání identifikátorů CIDR podů a konfliktních pravidel směrování.
• U spravované identity přiřazené systémem se podporuje pouze poskytnutí vlastní podsítě a směrovací tabulky přes Azure CLI, protože Azure CLI toto přiřazení role automaticky přidá. Pokud používáte šablonu ARM nebo jiné klienty, musíte použít spravovanou identitu přiřazenou uživatelem, přiřadit oprávnění před vytvořením clusteru a zajistit, aby identita přiřazená uživatelem má oprávnění k zápisu do vlastní podsítě a vlastní směrovací tabulky.
• Použití stejné směrovací tabulky s více clustery AKS se nepodporuje.

Přidání směrovací tabulky se spravovanou identitou přiřazenou uživatelem do clusteru AKS

Po vytvoření vlastní směrovací tabulky a jejím přidružení k podsíti ve virtuální síti můžete vytvořit nový cluster AKS určující směrovací tabulku se spravovanou identitou přiřazenou uživatelem. Musíte použít ID podsítě pro místo, kde plánujete nasadit cluster AKS. Tato podsíť musí být přidružená také k vaší vlastní směrovací tabulce.

1. Pomocí příkazu získejte ID az network vnet subnet list podsítě.

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

2. Vytvořte cluster AKS s předkonfigurovanou vlastní podsítí se směrovací tabulkou pomocí az aks create příkazu a zadáním hodnot pro parametry--vnet-subnet-id.--assign-identity

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

Další kroky

Tento článek vám ukázal, jak nasadit cluster AKS do existující podsítě virtuální sítě. Teď můžete začít vytvářet nové aplikace pomocí Nástroje Helm nebo nasazovat existující aplikace pomocí Nástroje Helm.