Osvědčené postupy pro pokročilé funkce plánování ve službě Azure Kubernetes Service (AKS)
Při správě clusterů ve službě Azure Kubernetes Service (AKS) často potřebujete izolovat týmy a úlohy. Pokročilé funkce poskytované plánovačem Kubernetes umožňují řídit:
- Které pody je možné naplánovat na určitých uzlech.
- Jak lze aplikace s více pody správně distribuovat napříč clusterem.
Tento článek s osvědčenými postupy se zaměřuje na pokročilé funkce plánování Kubernetes pro operátory clusteru. V tomto článku získáte informace o těchto tématech:
- Pomocí taintů a tolerance omezte, jaké pody je možné naplánovat na uzlech.
- Upřednostnit pody, které se mají spouštět na určitých uzlech s selektory uzlů nebo spřažením uzlů.
- Rozdělte nebo seskupte pody spřažením mezi pody nebo spřažením proti spřažení.
- Omezte plánování úloh, které vyžadují GPU pouze na uzlech s chedulovatelnými gpu.
Zadání vyhrazených uzlů s využitím vad a tolerancí
Pokyny k osvědčeným postupům:
Omezte přístup pro aplikace náročné na prostředky, jako jsou kontrolery příchozího přenosu dat, na konkrétní uzly. Udržujte prostředky uzlů dostupné pro úlohy, které je vyžadují, a nepovolují plánování jiných úloh na uzlech.
Při vytváření clusteru AKS můžete nasazovat uzly s podporou GPU nebo velkým počtem výkonných procesorů. Další informace naleznete v tématu Použití GPU v AKS. Tyto uzly můžete použít pro velké úlohy zpracování dat, jako je strojové učení (ML) nebo umělá inteligence (AI).
Vzhledem k tomu, že nasazení tohoto hardwaru prostředků uzlu je obvykle nákladné, omezte úlohy, které je možné na těchto uzlech naplánovat. Místo toho vyhradit některé uzly v clusteru tak, aby spouštěly služby příchozího přenosu dat a zabránily jiným úlohám.
Tato podpora pro různé uzly je poskytována pomocí více fondů uzlů. Cluster AKS podporuje jeden nebo více fondů uzlů.
Plánovač Kubernetes používá tainty a tolerance k omezení úloh, které se můžou spouštět na uzlech.
- Pomocí taintu u uzlu označíte pouze konkrétní pody, na které je možné naplánovat.
- Pak u podu použijte tolerance , což jim umožní tolerovat taint uzlu.
Když nasadíte pod do clusteru AKS, Kubernetes plánuje jenom pody na uzlech, jejichž taint odpovídá tolerance. Vady a tolerance spolupracují, aby se zajistilo, že pody nebudou naplánované na nevhodné uzly. Jeden nebo více taintů se použije na uzel a označí uzel tak, aby nepřijme žádné pody, které netolerují tainty.
Předpokládejme například, že jste do clusteru AKS přidali fond uzlů pro uzly s podporou GPU. Definujete název, například gpu, a pak hodnotu pro plánování. Nastavením této hodnoty na NoSchedule omezíte plánovač Kubernetes na plánování podů s nedefinovanými tolerancemi na uzlu.
az aks nodepool add \
--resource-group myResourceGroup \
--cluster-name myAKSCluster \
--name taintnp \
--node-taints sku=gpu:NoSchedule \
--no-wait
Pomocí taintu použitého na uzly ve fondu uzlů definujete tolerance ve specifikaci podu, která umožňuje plánování na uzlech. Následující příklad definuje a effect: NoSchedule
toleruje sku: gpu
taint použitý u fondu uzlů v předchozím kroku:
kind: Pod
apiVersion: v1
metadata:
name: app
spec:
containers:
- name: app
image: <your-workload>:gpu
resources:
requests:
cpu: 0.5
memory: 2Gi
limits:
cpu: 4.0
memory: 16Gi
tolerations:
- key: "sku"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
Když se tento pod nasadí pomocí kubectl apply -f gpu-toleration.yaml
, Kubernetes může úspěšně naplánovat pod na uzlech s použitým taintem. Tato logická izolace umožňuje řídit přístup k prostředkům v clusteru.
Když použijete tainty, spolupracujte s vývojáři aplikací a vlastníky, abyste jim umožnili definovat požadované tolerance v jejich nasazeních.
Další informace o použití více fondů uzlů v AKS naleznete v tématu Vytvoření více fondů uzlů pro cluster v AKS.
Chování taintů a tolerance v AKS
Při upgradu fondu uzlů v AKS se tainty a tolerance řídí nastaveným vzorem při jejich použití na nové uzly:
Výchozí clustery, které používají škálovací sady virtuálních počítačů Azure
Fond uzlů můžete nakreslit z rozhraní API AKS, aby nově škálované uzly přijímaly tainty uzlů zadané rozhraním API.
Předpokládejme:
- Začnete clusterem se dvěma uzly: node1 a node2.
- Upgradujete fond uzlů.
- Vytvoří se dva další uzly: node3 a node4.
- Tainty jsou předány v uvedeném pořadí.
- Původní uzel1 a uzel2 se odstraní.
Clustery bez podpory škálovacích sad virtuálních počítačů
Znovu předpokládejme:
- Máte cluster se dvěma uzly: node1 a node2.
- Upgradujete fond uzlů.
- Vytvoří se další uzel: node3.
- Tainty z uzlu1 se použijí na uzel 3.
- uzel1 se odstraní.
- Vytvoří se nový uzel1 , který nahradí původní uzel1.
- Tainty node2 se použijí na nový uzel1.
- uzel2 se odstraní.
Uzel1 se v podstatě stane uzlem 3 a uzel2 se stane novým uzlem1.
Když škálujete fond uzlů v AKS, tainty a tolerance se nepřenesou podle návrhu.
Řízení plánování podů s využitím selektorů a spřažení uzlů
Pokyny k osvědčeným postupům
Řízení plánování podů na uzlech pomocí selektorů uzlů, spřažení uzlů nebo spřažení mezi pody. Tato nastavení umožňují plánovači Kubernetes logicky izolovat úlohy, jako je hardware v uzlu.
Taints a tolerace logicky izolují prostředky s pevnou odlehčením. Pokud pod netoleruje taint uzlu, není na uzlu naplánovaný.
Alternativně můžete použít selektory uzlů. Uzly označíte například tak, že označíte místně připojené úložiště SSD nebo velké množství paměti a pak v specifikaci podu definujete selektor uzlu. Kubernetes tyto pody naplánuje na odpovídající uzel.
Na rozdíl od tolerance je možné pody bez odpovídajícího selektoru uzlů pořád naplánovat na označených uzlech. Toto chování umožňuje využívat nepoužívané prostředky na uzlech, ale upřednostňuje pody, které definují odpovídající selektor uzlů.
Podívejme se na příklad uzlů s velkým množstvím paměti. Tyto uzly upřednostňují pody, které požadují velké množství paměti. Aby se zajistilo, že prostředky nebudou nečinné, umožní také spuštění jiných podů. Následující příklad příkazu přidá fond uzlů s popiskem hardware=highmem do myAKSCluster v myResourceGroup. Všechny uzly v tomto fondu uzlů mají tento popisek.
az aks nodepool add \
--resource-group myResourceGroup \
--cluster-name myAKSCluster \
--name labelnp \
--node-count 1 \
--labels hardware=highmem \
--no-wait
Specifikace podu nodeSelector
pak přidá vlastnost pro definování selektoru uzlu, který odpovídá popisku nastavenému na uzlu:
kind: Pod
apiVersion: v1
metadata:
name: app
spec:
containers:
- name: app
image: <your-workload>:gpu
resources:
requests:
cpu: 0.5
memory: 2Gi
limits:
cpu: 4.0
memory: 16Gi
nodeSelector:
hardware: highmem
Při použití těchto možností plánovače spolupracujte s vývojáři aplikací a vlastníky, aby jim umožnili správně definovat specifikace podů.
Další informace o používání selektorů uzlů najdete v tématu Přiřazení podů k uzlům.
Spřažení uzlů
Selektor uzlu je základní řešení pro přiřazování podů k danému uzlu. Spřažení uzlů poskytuje větší flexibilitu a umožňuje definovat, co se stane, když se pod nedá spárovat s uzlem. Můžete provádět následující akce:
- Vyžaduje , aby plánovač Kubernetes odpovídal podu s označeným hostitelem. Nebo:
- Preferujte shodu, ale povolte naplánování podu na jiném hostiteli, pokud není k dispozici žádná shoda.
Následující příklad nastaví spřažení uzlu na requiredDuringSchedulingIgnoredDuringExecution. Toto spřažení vyžaduje, aby plán Kubernetes používal uzel s odpovídajícím popiskem. Pokud není k dispozici žádný uzel, pod musí počkat, až bude plánování pokračovat. Pokud chcete povolit naplánování podu na jiném uzlu, můžete místo toho nastavit hodnotu na upřednostňovanou hodnotuDuringSchedulingIgnoreDuringExecution:
kind: Pod
apiVersion: v1
metadata:
name: app
spec:
containers:
- name: app
image: <your-workload>:gpu
resources:
requests:
cpu: 0.5
memory: 2Gi
limits:
cpu: 4.0
memory: 16Gi
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: hardware
operator: In
values:
- highmem
Část IgnoredDuringExecution v nastavení označuje, že pod by neměl být vyřazen z uzlu, pokud se změní popisky uzlů. Plánovač Kubernetes používá pouze aktualizované popisky uzlů pro naplánované nové pody, nikoli pody, které už jsou na uzlech naplánované.
Další informace naleznete v tématu Spřažení a anti-spřažení.
Spřažení mezi pody a anti-spřažení
Jedním z konečných přístupů pro plánovač Kubernetes k logické izolaci úloh je použití spřažení mezi pody nebo spřažení proti spřažení. Tato nastavení definují, že pody by buď neměly , nebo by měly být naplánované na uzlu, který má existující odpovídající pod. Plánovač Kubernetes se ve výchozím nastavení pokouší naplánovat více podů v sadě replik napříč uzly. Můžete definovat konkrétnější pravidla týkající se tohoto chování.
Máte například webovou aplikaci, která také používá Azure Cache for Redis.
- K vyžádání toho, aby plánovač Kubernetes distribuoval repliky mezi uzly, použijete pravidla anti-spřažení podů.
- Pravidla spřažení slouží k zajištění, že je každá komponenta webové aplikace naplánovaná na stejném hostiteli jako odpovídající mezipaměť.
Distribuce podů mezi uzly vypadá jako v následujícím příkladu:
Uzel 1 | Uzel 2 | Uzel 3 |
---|---|---|
webapp-1 | webapp-2 | webapp-3 |
cache-1 | cache-2 | cache-3 |
Spřažení mezi pody a spřažení proti spřažení poskytují složitější nasazení než selektory uzlů nebo spřažení uzlů. S nasazením logicky izolujete prostředky a řídíte, jak Kubernetes plánuje pody na uzlech.
Úplný příklad této webové aplikace s příkladem Azure Cache for Redis najdete v tématu Co-locate pods na stejném uzlu.
Další kroky
Tento článek se zaměřuje na pokročilé funkce plánovače Kubernetes. Další informace o operacích clusteru v AKS najdete v následujících osvědčených postupech:
Azure Kubernetes Service