Najlepsze rozwiązania dotyczące zaawansowanych funkcji harmonogramu w usłudze Azure Kubernetes Service (AKS)

  • Artykuł

Podczas zarządzania klastrami w usłudze Azure Kubernetes Service (AKS) często trzeba odizolować zespoły i obciążenia. Zaawansowane funkcje udostępniane przez harmonogram kubernetes umożliwiają sterowanie:

  • Które zasobniki można zaplanować w niektórych węzłach.
  • Sposób, w jaki aplikacje z wieloma zasobnikami mogą być odpowiednio dystrybuowane w klastrze.

Ten artykuł dotyczący najlepszych rozwiązań koncentruje się na zaawansowanych funkcjach planowania kubernetes dla operatorów klastra. W tym artykule omówiono sposób wykonywania następujących zadań:

  • Użyj defektów i tolerancji, aby ograniczyć harmonogram zasobników w węzłach.
  • Umożliwianie zasobnikom uruchamiania w niektórych węzłach za pomocą selektorów węzłów lub koligacji węzłów.
  • Podziel zasobniki lub grupuj je z koligacją między zasobnikami lub anty-koligacją.
  • Ogranicz planowanie obciążeń, które wymagają procesorów GPU tylko w węzłach z nieplanowalnymi procesorami GPU.

Zapewnianie dedykowanych węzłów przy użyciu defektów i tolerancji

Wskazówki dotyczące najlepszych rozwiązań:

Ogranicz dostęp do aplikacji intensywnie korzystających z zasobów, takich jak kontrolery ruchu przychodzącego, do określonych węzłów. Zachowaj dostępne zasoby węzłów dla obciążeń, które ich wymagają, i nie zezwalaj na planowanie innych obciążeń w węzłach.

Podczas tworzenia klastra usługi AKS można wdrożyć węzły z obsługą procesora GPU lub dużą liczbą zaawansowanych procesorów CPU. Aby uzyskać więcej informacji, zobacz Use GPU on AKS (Używanie procesorów GPU w usłudze AKS). Tych węzłów można używać do obsługi dużych obciążeń przetwarzania danych, takich jak uczenie maszynowe (ML) lub sztuczna inteligencja (AI).

Ponieważ ten sprzęt zasobów węzła jest zwykle kosztowny do wdrożenia, należy ograniczyć obciążenia, które można zaplanować w tych węzłach. Zamiast tego dedykuj niektóre węzły w klastrze do uruchamiania usług przychodzących i zapobiegania innym obciążeniom.

Ta obsługa różnych węzłów jest zapewniana przy użyciu wielu pul węzłów. Klaster usługi AKS obsługuje co najmniej jedną pulę węzłów.

Harmonogram Kubernetes używa defektów i tolerancji, aby ograniczyć obciążenia, które mogą być uruchamiane w węzłach.

  • Zastosuj defekt do węzła, aby wskazać, że na nich można zaplanować tylko określone zasobniki.
  • Następnie zastosuj tolerancję do zasobnika, umożliwiając im tolerowanie defektu węzła.

Podczas wdrażania zasobnika w klastrze usługi AKS platforma Kubernetes planuje tylko zasobniki w węzłach, których defekt jest zgodny z tolerancją. Defekty i tolerancje współpracują ze sobą, aby upewnić się, że zasobniki nie są zaplanowane na nieodpowiednich węzłach. Co najmniej jeden defekt jest stosowany do węzła, oznaczając węzeł tak, aby nie akceptował żadnych zasobników, które nie tolerują defektów.

Załóżmy na przykład, że dodano pulę węzłów w klastrze usługi AKS dla węzłów z obsługą procesora GPU. Należy zdefiniować nazwę, taką jak gpu, a następnie wartość planowania. Ustawienie tej wartości na noSchedule ogranicza harmonogram Kubernetes z zasobników planowania z niezdefiniowaną tolerancją w węźle.

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

Po zastosowaniu defektu do węzłów w puli węzłów należy zdefiniować tolerancję w specyfikacji zasobnika, która umożliwia planowanie w węzłach. W poniższym przykładzie zdefiniowano sku: gpu elementy i effect: NoSchedule w celu tolerowania defektu zastosowanego do puli węzłów w poprzednim 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"

Po wdrożeniu tego zasobnika przy użyciu narzędzia kubectl apply -f gpu-toleration.yamlplatforma Kubernetes może pomyślnie zaplanować zasobnik w węzłach z zastosowanym defektem. Ta izolacja logiczna umożliwia kontrolowanie dostępu do zasobów w klastrze.

Po zastosowaniu defektów skontaktuj się z deweloperami i właścicielami aplikacji, aby umożliwić im zdefiniowanie wymaganych tolerancji we wdrożeniach.

Aby uzyskać więcej informacji na temat używania wielu pul węzłów w usłudze AKS, zobacz Tworzenie wielu pul węzłów dla klastra w usłudze AKS.

Zachowanie defektów i tolerancji w usłudze AKS

Podczas uaktualniania puli węzłów w usłudze AKS defekty i tolerancje są zgodne ze wzorcem zestawu, ponieważ są one stosowane do nowych węzłów:

Domyślne klastry korzystające z usługi Azure Virtual Machine Scale Sets

Pulę węzłów z interfejsu API usługi AKS można skażone, aby nowo skalowane węzły w poziomie otrzymywały określone defekty węzłów interfejsu API.

Załóżmy:

  1. Zaczynasz od klastra z dwoma węzłami: node1 i node2.
  2. Uaktualniasz pulę węzłów.
  3. Tworzone są dwa inne węzły: node3 i node4.
  4. Defekty są przekazywane odpowiednio.
  5. Oryginalny węzeł1 i węzeł2 są usuwane.

Klastry bez obsługi Virtual Machine Scale Sets

Ponownie załóżmy, że:

  1. Masz klaster z dwoma węzłami: node1 i node2.
  2. Uaktualniasz pulę węzłów.
  3. Zostanie utworzony dodatkowy węzeł: node3.
  4. Defekty z węzła Node1 są stosowane do węzła3.
  5. Węzeł1 jest usuwany.
  6. Zostanie utworzony nowy węzeł1 do zamiany na oryginalny węzeł1.
  7. Defekty node2 są stosowane do nowego węzła1.
  8. Węzeł2 jest usuwany.

W istocie węzeł Node1 staje się węzłem3, a węzeł2 staje się nowym węzłem1.

W przypadku skalowania puli węzłów w usłudze AKS defekty i tolerancje nie są przenoszone zgodnie z projektem.

Kontrolowanie planowania zasobników przy użyciu selektorów węzłów i koligacji

Wskazówki dotyczące najlepszych rozwiązań

Steruj planowaniem zasobników w węzłach przy użyciu selektorów węzłów, koligacji węzłów lub koligacji między zasobnikami. Te ustawienia umożliwiają harmonogramowi kubernetes logiczne izolowanie obciążeń, takich jak sprzęt w węźle.

Defekty i tolerancje logicznie izolować zasoby z twardym odcięciem. Jeśli zasobnik nie toleruje defektu węzła, nie jest on zaplanowany w węźle.

Alternatywnie można użyć selektorów węzłów. Można na przykład oznaczyć węzły etykietami, aby wskazać lokalnie dołączony magazyn SSD lub dużą ilość pamięci, a następnie zdefiniować w specyfikacji zasobnika selektor węzła. Platforma Kubernetes planuje te zasobniki w pasującym węźle.

W przeciwieństwie do tolerancji zasobniki bez pasującego selektora węzłów można nadal planować na oznaczonych węzłach. To zachowanie umożliwia korzystanie z nieużywanych zasobów w węzłach, ale określa priorytety zasobników definiujących pasujący selektor węzłów.

Przyjrzyjmy się przykładowi węzłów z dużą ilością pamięci. Te węzły ustalają priorytety zasobników, które żądają dużej ilości pamięci. Aby zapewnić, że zasoby nie są w stanie bezczynności, zezwalają również na uruchamianie innych zasobników. Poniższe przykładowe polecenie dodaje pulę węzłów z etykietą hardware=highmem do grupy myAKSCluster w grupie myResourceGroup. Wszystkie węzły w tej puli węzłów mają tę etykietę.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name labelnp \
    --node-count 1 \
    --labels hardware=highmem \
    --no-wait

Następnie specyfikacja zasobnika dodaje nodeSelector właściwość w celu zdefiniowania selektora węzła zgodnego z etykietą ustawioną w węźle:

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

Gdy używasz tych opcji harmonogramu, we współpracy z deweloperami aplikacji i właścicielami, aby umożliwić im poprawne zdefiniowanie specyfikacji zasobnika.

Aby uzyskać więcej informacji na temat używania selektorów węzłów, zobacz Przypisywanie zasobników do węzłów.

Koligacja węzła

Selektor węzłów to podstawowe rozwiązanie do przypisywania zasobników do danego węzła. Koligacja węzła zapewnia większą elastyczność, co pozwala zdefiniować, co się stanie, jeśli zasobnik nie może być dopasowany do węzła. Możesz:

  • Wymagaj , aby harmonogram Kubernetes był zgodny z zasobnikiem z hostem oznaczonym etykietą. Lub:
  • Preferuj dopasowanie, ale zezwalaj zasobnikowi na zaplanowanie na innym hoście, jeśli dopasowanie nie jest dostępne.

W poniższym przykładzie ustawiono koligację węzła na wartość requiredDuringSchedulingIgnoredDuringExecution. Ta koligacja wymaga, aby harmonogram kubernetes używał węzła z pasującą etykietą. Jeśli węzeł nie jest dostępny, zasobnik musi czekać na kontynuowanie planowania. Aby zezwolić na planowanie zasobnika w innym węźle, możesz zamiast tego ustawić wartość na preferowanąwartość 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

Część IgnoredDuringExecution ustawienia wskazuje, że zasobnik nie powinien być eksmitowany z węzła, jeśli etykiety węzłów zostaną zmienione. Harmonogram platformy Kubernetes używa tylko zaktualizowanych etykiet węzłów dla zaplanowanych nowych zasobników, a nie zasobników zaplanowanych już w węzłach.

Aby uzyskać więcej informacji, zobacz Koligacja i anty-koligacja.

Koligacja między zasobnikami i anty-koligacja

Jedną z ostatecznych metod planowania platformy Kubernetes w celu logicznego izolowania obciążeń jest użycie koligacji między zasobnikami lub koligacji przeciw koligacji. Te ustawienia definiują, że zasobniki nie powinny byćzaplanowane w węźle, który ma istniejący pasujący zasobnik. Domyślnie harmonogram kubernetes próbuje zaplanować wiele zasobników w zestawie replik między węzłami. Można zdefiniować bardziej szczegółowe reguły dotyczące tego zachowania.

Na przykład masz aplikację internetową, która używa również Azure Cache for Redis.

  • Reguły koligacji zasobnika są używane do żądania, aby harmonogram Kubernetes dystrybuował repliki między węzłami.
  • Reguły koligacji służą do zapewnienia, że każdy składnik aplikacji internetowej jest zaplanowany na tym samym hoście co odpowiednia pamięć podręczna.

Rozkład zasobników między węzłami wygląda podobnie do następującego przykładu:

Węzeł 1 Węzeł 2 Węzeł 3
webapp-1 webapp-2 webapp-3
cache-1 cache-2 cache-3

Koligacja między zasobnikami i koligacja anty-zasobnika zapewniają bardziej złożone wdrożenie niż selektory węzłów lub koligację węzłów. Wdrożenie umożliwia logiczne izolowanie zasobów i kontrolowanie sposobu planowania zasobników na węzłach przez platformę Kubernetes.

Aby zapoznać się z kompletnym przykładem tej aplikacji internetowej z Azure Cache for Redis przykładzie, zobacz Współlokalizowanie zasobników w tym samym węźle.

Następne kroki

Ten artykuł koncentruje się na zaawansowanych funkcjach harmonogramu Kubernetes. Aby uzyskać więcej informacji na temat operacji klastra w usłudze AKS, zobacz następujące najlepsze rozwiązania: