Osvědčené postupy pro pokročilé funkce plánování ve službě Azure Kubernetes Service (AKS)

Článek
08/05/2023

Při správě clusterů v 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 se dají naplánovat na určitých uzlech.
Jak se dají aplikace s více pody správně distribuovat napříč clusterem.

Tento článek o osvědčených postupech 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, které pody se dají 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 se spřažením mezi pody nebo antispřažením.
Omezte plánování úloh, které vyžadují GPU jenom na uzlech s chedulovatelnými grafickými procesory.

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 neumožněte 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 najdete v tématu Použití gpu v AKS. Tyto uzly můžete použít pro úlohy zpracování velkých objemů 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, aby spouštět služby příchozího přenosu dat a zabránily další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é můžou běžet na uzlech.

Použijte u uzlu taint , který označuje, že se na nich dají naplánovat jenom konkrétní pody.
Pak u podu použijte toleraci , která jim umožní tolerovat taint uzlu.

Když nasadíte pod do clusteru AKS, Kubernetes naplánuje pody jenom na uzlech, jejichž taint odpovídá tolerance. Taints a tolerance spolupracují, aby zajistily, že pody nejsou naplánované na nevhodné uzly. Na uzel se použije jeden nebo více taintů, které uzel označí tak, aby nepřijímal žá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í této hodnoty na NoSchedule omezí plánovač Kubernetes v plánování podů s nedefinovanou tolerací na uzlu.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name taintnp \
    --node-taints sku=gpu:NoSchedule \
    --no-wait

Při použití taintu na uzly ve fondu uzlů definujete toleranci ve specifikaci podů, která umožňuje plánování na uzlech. Následující příklad definuje sku: gpu a effect: NoSchedule , který toleruje taint použitý na fond uzlů v předchozím kroku:

kind: Pod
apiVersion: v1
metadata:
  name: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo: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.yamlnástroje , 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 rámci clusteru.

Když použijete tainty, ve spolupráci s vývojáři a vlastníky aplikací jim umožní definovat požadované tolerance ve svých nasazeních.

Další informace o použití více fondů uzlů v AKS najdete 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 používají na nové uzly podle nastaveného vzoru:

Výchozí clustery, které používají Azure Virtual Machine Scale Sets

Fond uzlů z rozhraní API AKS můžete použít k tomu, aby nově škálované uzly přijímaly zadaná rozhraní API tainty uzlů.

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 dále.
Původní uzel node1 a node2 se odstraní.

Clustery bez podpory Virtual Machine Scale Sets

Znovu předpokládejme, že:

Máte cluster se dvěma uzly: node1 a node2.
Upgradujete fond uzlů.
Vytvoří se další uzel: node3.
Tainty z node1 se použijí na node3.
uzel node1 je odstraněn.
Vytvoří se nový uzel1 , který nahradí původní uzel1.
Na nový uzel1 se použijí tainty node2.
uzel node2 je odstraněn.

V podstatě se uzel1 změní na uzel 3 a uzel2 se stane novým uzlem1.

Když škálujete fond uzlů v AKS, tainty a tolerance se záměrně nepřenesou.

Ří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, například podle hardwaru v uzlu.

Taints a tolerace logicky izolují prostředky s tvrdým omezením. Pokud pod netoleruje taint uzlu, není na uzlu naplánovaný.

Případně můžete použít selektory uzlů. Například označíte uzly tak, že označíte místně připojené úložiště SSD nebo velké množství paměti, a pak ve specifikaci podu definujete selektor uzlů. Kubernetes naplánuje tyto pody na odpovídající uzel.

Na rozdíl od tolerance je možné pody bez odpovídajícího selektoru uzlů stále plánovat na označených uzlech. Toto chování umožňuje využívání nepoužívaných prostředků 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žňují spouštění dalších podů. Následující příklad příkazu přidá fond uzlů s popiskem hardware=highmem do myAKSCluster v myResourceGroup. Tento popisek mají všechny uzly v tomto fondu uzlů.

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: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  nodeSelector:
      hardware: highmem

Když použijete tyto možnosti plánovače, ve spolupráci s vývojáři a vlastníky aplikací jim umožníte 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 uzlů 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ž pod není možné spárovat s uzlem. Můžete:

Vyžaduje , aby plánovač Kubernetes odpovídal podu s označeným hostitelem. Nebo:
Upřednostněte 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, musí pod počkat, než bude plánování pokračovat. Pokud chcete povolit plánování podu na jiném uzlu, můžete místo toho nastavit hodnotu na upřednostňovanouhodnotu DuringSchedulingIgnoreDuringExecution:

kind: Pod
apiVersion: v1
metadata:
  name: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo: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 nastavení IgnoredDuringExecution indikuje, ž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 nové pody, které se plánují, nikoli pro pody, které jsou na uzlech už naplánované.

Další informace najdete v tématu Spřažení a ochrana proti spřažení.

Spřažení mezi pody a antispřažení

Jedním z posledních přístupů plánovače Kubernetes k logické izolaci úloh je použití spřažení mezi pody nebo antispř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. Ve výchozím nastavení se plánovač Kubernetes pokusí 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.

Pravidla ochrany proti spřažení podů použijete k vyžádání, aby plánovač Kubernetes distribuoval repliky mezi uzly.
Pomocí pravidel spřažení zajistíte, že každá komponenta webové aplikace je 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
mezipaměť-1	mezipaměť-2	cache-3

Spřažení mezi pody a ochrana 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 Azure Cache for Redis příkladu najdete v tématu Společné umístění podů na stejném uzlu.

Další kroky

Tento článek se zaměřil 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: