Přehled síťových konfigurací pro automatické zřizování uzlů (NAP) ve službě Azure Kubernetes Service (AKS)

Tento článek obsahuje přehled požadavků na konfiguraci sítě a doporučení pro clustery Azure Kubernetes Service (AKS) pomocí automatického zřizování uzlů (NAP). Zahrnuje podporované konfigurace, výchozí chování podsítě, nastavení řízení přístupu na základě role (RBAC) a aspekty ciDR (Classless Inter-Domain Routing).

Přehled automatického zřizování uzlů v AKS najdete v tématu Přehled automatického zřizování uzlů (NAP) ve službě Azure Kubernetes Service (AKS).

Podporované síťové konfigurace pro architekturu NAP

Při vyhodnocování podpory sítí pro architekturu NAP zvažte režim správy IP adres (IPAM), síťový modul plug-in, rovinu dat sítě a zásady sítě. Následující tabulka popisuje možnosti podporované architekturou NAP:

Konfigurační vrstva Option Podpora NAP
IPAM Překrytí Azure CNI Podporováno
IPAM Podsíť uzlu Azure CNI Podporováno
IPAM Podsíť podů Azure CNI s dynamickým přidělováním IP adres Nepodporováno
Síťový modul plug-in Kubenet Nepodporováno
Datová rovina Azure CNI Powered by Cilium Podporováno v podporovaném režimu Azure CNI IPAM
Zásady sítě Calico Nepodporováno

Použijte Azure CNI Overlay s datovou rovinou Azure CNI využívající Cilium. Cilium poskytuje pokročilé síťové funkce a je optimalizovaný pro výkon s architekturou NAP.

Konfigurace podsítí pro architekturu NAP

Nastavte volitelné pole vnetSubnetID v prostředku AKSNodeClass pro konfiguraci vlastní podsítě, kterou Karpenter používá k zřizování uzlů NAP. Pokud nezadáte vnetSubnetID, Karpenter použije výchozí podsíť nakonfigurovanou během instalace, což je obvykle podsíť určená parametrem --vnet-subnet-id při vytváření clusteru AKS.

Architektura NAP automaticky nasadí, nakonfiguruje a spravuje Karpenter ve vašem clusteru AKS a je založená na opensourcových projektech poskytovatelů Karpenter a AKS Karpenter .

AKSNodeClass prostředky ve vašem clusteru AKS můžou každé určovat jiné vnetSubnetID, což umožňuje smíšenou konfiguraci podsítí napříč fondy uzlů. Třídy uzlů, které nezadávají vnetSubnetID , používají výchozí konfiguraci podsítě clusteru.

Chování posunu podsítě

Karpenter sleduje změny konfigurace podsítě a detekuje odchyl, když se modifikují vnetSubnetID v AKSNodeClass. Pochopení tohoto chování je důležité při správě vlastních konfigurací sítě.

U clusterů, které používají vlastní virtuální síť, způsobí změna vnetSubnetID z jedné platné podsítě na jinou, že se stávající uzly přidružené k AKSNodeClass odchýlí. Karpenter vytváří náhradní uzly v nové podsíti a řízeně odstavuje driftované uzly podle NodePool limitů narušení.

Před změnou vnetSubnetIDse ujistěte, že identita clusteru má požadovaná oprávnění k nové podsíti a že podsíť má dostatek dostupných IP adres pro náhradní uzly. Rozpočty narušení podů a anotace karpenter.sh/do-not-disrupt mohou zpozdit dobrovolné nahrazení driftu.

Důležité

Virtuální sítě spravované AKS nepodporují vlastní podsítě. Používejte vnetSubnetID jenom s vlastní virtuální sítí, kterou spravujete.

Rozsahy CIDR clusteru AKS pro architekturu NAP

Když pomocí vnetSubnetID konfigurujete vlastní síť, musíte rozumět rozsahům CIDR vašeho clusteru a spravovat je, abyste se vyhnuli síťovým konfliktům. Na rozdíl od tradičních fondů uzlů AKS, které vytvoříte prostřednictvím šablon Azure Resource Manager (ARM), Karpenter použije vlastní definice prostředků (CRD), které zřizují uzly okamžitě bez rozšířeného ověření, které ARM poskytuje.

Důležité informace o CIDR pro vlastní konfigurace podsítí architektury NAP

Při konfiguraci vnetSubnetIDmusíte:

  • Ověření kompatibility CIDR: Ujistěte se, že vlastní podsítě nejsou v konfliktu s existujícími rozsahy CIDR.
  • Plánování kapacity IP: Vypočítejte požadovaný počet IP adres pro očekávané škálování.
  • Ověření připojení: Otestujte síťové trasy a pravidla skupin zabezpečení.
  • Monitorování využití: Sledování využití podsítě a plánování růstu
  • Konfigurace dokumentu: Udržujte záznamy rozhodnutí o návrhu sítě.

Běžné konflikty CIDR

Při používání vlastních podsítí s architekturou NAP mějte na paměti následující běžné konfliktní scénáře CIDR:

Následující příklady ukazují rozsahy CIDR podsítě, které jsou v konfliktu s podem clusteru a službami CIDR, spolu s konfigurací, která zabrání těmto konfliktům. Pomocí těchto vzorů ověřte rozsahy podsítí před konfigurací vnetSubnetID.

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

Nastavení RBAC pro vlastní konfigurace podsítě

Pokud používáte vlastní konfigurace podsítí s architekturou NAP, musíte zajistit, aby Karpenter měl potřebná oprávnění ke čtení informací o podsíti a připojení uzlů k zadaným podsítím. To vyžaduje nastavení odpovídajících oprávnění RBAC pro spravovanou identitu clusteru.

Osoba spouštějící následující příkazy musí mít oprávnění vytvářet požadovanou definici role a přiřazení rolí, například roli Správce řízení přístupu na základě role. Neudělujte identitě clusteru oprávnění k zápisu přiřazení role, pokud nepotřebuje vytvářet přiřazení rolí pro jiný scénář.

Získejte ID objektu zabezpečení pro spravovanou identitu clusteru. Použijte příkaz odpovídající typu identity clusteru:

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

Existují dva hlavní přístupy k nastavení těchto oprávnění: Přiřaďte široká oprávnění virtuální sítě nebopřiřaďte oprávnění k podsíti s vymezeným oborem.

Tento přístup je nejvýraznější a uděluje identitě clusteru oprávnění ke čtení a připojení jakékoli podsítě v rámci hlavní virtuální sítě a poskytuje přístup přispěvatele sítě.

Důležité

Role Přispěvatel k síti uděluje Microsoft.Network/*, což identitě clusteru umožňuje vytvářet, upravovat a odstraňovat síťové prostředky v rámci přiřazeného rozsahu virtuální sítě. Před použitím role v produkčním prostředí zkontrolujte tento přístup, protože architektura NAP pro tento scénář vyžaduje pouze oprávnění ke čtení a připojení podsítě.

Výhody a důležité informace

Následující tabulka popisuje kompromisy při přiřazování role Přispěvatel sítě v oboru virtuální sítě.

Výhody rozsáhlých oprávnění virtuální sítě Důležité informace o širokých oprávněních virtuální sítě
• Zjednodušuje správu oprávnění.
• Eliminuje potřebu aktualizovat oprávnění při přidávání nových podsítí.
• Funguje dobře pro prostředí s jedním tenantem.
• Funkce, když předplatné dosáhne maximálního počtu vlastních rolí.		 • Poskytuje širší oprávnění, než je nezbytně nutné.
• Nemusí splňovat přísné požadavky na zabezpečení.

Požadovaná oprávnění

Pokud chcete přiřadit široká oprávnění virtuální sítě, udělte spravované identitě clusteru následující oprávnění pro virtuální síť:

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Network Contributor" \
  --scope $VNET_ID

Úplný příklad nastavení vlastních sítí a přiřazování širokých oprávnění virtuální sítě najdete v tématu Nastavení vlastní virtuální sítě – Většina ukázkových skriptů RBAC.

Příklad konfigurace vlastních podsítí

Následující příklad ukazuje, jak nakonfigurovat vlastní podsíť pro uzly NAP pomocí vnetSubnetID pole v AKSNodeClass prostředku:

Nastavte pole spec.vnetSubnetID na úplné ID prostředku Azure cílové podsítě ve formátu /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

Následující příklad ukazuje, jak používat více tříd uzlů s různými konfiguracemi podsítě:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Zásady podpory Bring Your Own CNI (BYO CNI)

Karpenter pro Azure umožňuje používat vlastní konfigurace BYO CNI (Container Network Interface) a řídí se stejnými zásadami podpory jako AKS. BYO CNI nezpůsobí, že bude podporovaná konfigurace, kterou NAP uvádí jako nepodporovanou, například kubenet nebo Calico. Pokud používáte vlastní CNI, podpora řešení potíží související se sítí je mimo rozsah pro všechny smlouvy o úrovni služeb nebo záruky.

Podrobnosti o oboru podpory

Následující informace popisují, co je a není podporováno při použití funkce BYO CNI s Karpenterem:

  • Podporováno: Problémy s funkcemi a integrací specifickými pro Karpenter při použití konfigurací CNI ve stylu „přines si vlastní“ (BYO).
  • Nepodporuje se: Problémy se sítí specifické pro CNI, problémy s konfigurací nebo řešení potíží při používání modulů plug-in CNI třetích stran.

Další kroky

Další informace o automatickém zřizování uzlů v AKS najdete v následujících článcích:

  • Last updated on