Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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
Architektura NAP podporuje následující síťové konfigurace:
Doporučujeme používat Azure CNI s cilium. Cilium poskytuje pokročilé síťové funkce a je optimalizovaný pro výkon s architekturou NAP.
Nepodporované síťové konfigurace pro architekturu NAP
Architektura NAP nepodporuje následující síťové konfigurace:
- Zásady sítě Calico
- Dynamické přidělování IP adres
Konfigurace podsítí pro architekturu NAP
Architektura NAP automaticky nasadí, nakonfiguruje a spravuje Karpenter v clusterech AKS a je založená na opensourcových projektech poskytovatelů Karpenter a AKS Karpenter . Pomocí AKSNodeClass zdrojů můžete zadat vlastní konfigurace podsítě pro uzly NAP v rámci skupin fondů uzlů nastavením volitelného pole vnetSubnetID a Karpenter použije podsíť, kterou zadáte pro zřizování uzlů. Pokud nezadáte podsíť, Karpenter použije výchozí podsíť nakonfigurovanou během instalace Karpenteru. Tato výchozí podsíť je obvykle stejná podsíť zadaná během vytváření clusteru AKS s parametrem --vnet-subnet-idaz aks create v příkazu.
Tento přístup umožňuje mít kombinaci tříd uzlů, s některými, které používají vlastní podsítě pro konkrétní úlohy, a jiné s použitím výchozí konfigurace 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ě.
Změna vnetSubnetID z jedné platné podsítě na jinou platnou podsíť není podporovanou operací. Pokud změníte vnetSubnetID tak, aby ukazoval na jinou platnou podsíť, Karpenter to zjistí jako odchylku podsítě a zabrání přidělování uzlů, dokud se problém nevyřeší vrácením vnetSubnetID na původní podsíť. Toto chování zajišťuje, aby uzly byly zřízeny pouze v zamýšlených podsítích a zachovaly integritu sítě a zabezpečení. Existují však výjimky tohoto pravidla. Můžete upravit vnetSubnetID pouze v následujících scénářích:
- Oprava chybného ID podsítě, jehož důsledkem není možné přidělit uzel.
- Oprava neplatného odkazu na podsíť, která způsobuje chyby konfigurace.
- Aktualizace identifikátoru podsítě, která odkazuje na neexistující nebo nepřístupnou podsíť.
Vysvětlení rozsahů ciDR (Classless Inter-Domain Routing) clusteru AKS
Při konfiguraci vlastních sítí s vnetSubnetID se zodpovídáte za pochopení a správu rozsahů CIDR clusteru, abyste se vyhnuli síťovým konfliktům. Na rozdíl od tradičních fondů uzlů AKS vytvořených prostřednictvím šablon ARM Karpenter používá vlastní definice prostředků (CRDs), 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í
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:
# 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.
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é
Před použitím tohoto přístupu na produkční cluster prozkoumejte roli Přispěvatel sítě.
Výhody a důležité informace
Následující tabulka popisuje výhody a aspekty přiřazování rozsáhlých oprávnění virtuální sítě:
| Výhody | Úvahy |
|---|---|
| • 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 cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)
# 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 $CLUSTER_IDENTITY \
--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:
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
name: custom-networking
spec:
vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$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/$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/$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 to podle stejných zásad podpory jako AKS. To znamená, že při použití vlastního CNI je podpora řešení potíží související se sítí mimo rozsah všech smluv o úrovni služeb nebo záruk.
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: