Udostępnij za pośrednictwem

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 platformy 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 razem z koligacją między zasobnikami lub anty-koligacją.
  • Ogranicz planowanie obciążeń, które wymagają procesorów GPU tylko w węzłach z schedulowalnymi 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 wdrażać węzły z obsługą procesora GPU lub dużą liczbą zaawansowanych procesorów CPU. Aby uzyskać więcej informacji, zobacz 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, ogranicz 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 Platformy 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, co pozwoli im tolerować defekt 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 zapewnić, że zasobniki nie są zaplanowane w odniesieniu do nieodpowiednich węzłów. 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 Wartość 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 elementy sku: gpu i effect: NoSchedule w celu tolerowania defektu zastosowanego do puli węzłów w poprzednim 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"

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 aplikacji i właścicielami, 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 zestawów skalowania maszyn wirtualnych platformy Azure

Pulę węzłów z interfejsu API usługi AKS można zaintować, aby nowo skalowane węzły w poziomie odbierał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. Te defekty są przekazywane odpowiednio.
  5. Oryginalny węzeł1 i węzeł2 zostaną usunięte.

Obsługa klastrów bez zestawów skalowania maszyn wirtualnych

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 , który zostanie zamieniony na oryginalny węzeł1.
  7. Węzły2 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.

Skalowanie puli węzłów w usłudze AKS nie jest 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ń

Kontrolowanie planowania 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.

Taints i tolerancje logicznie izolują 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. Na przykład węzły etykiety wskazują lokalnie dołączony magazyn SSD lub dużą ilość pamięci, a następnie zdefiniuj 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 mogą być nadal zaplanowane na węzłach oznaczonych etykietami. 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 o dużej ilości pamięci. Te węzły ustalają priorytety zasobników, które żądają dużej ilości pamięci. Aby upewnić się, że zasoby nie są bezczynne, umożliwiają również uruchamianie innych zasobników. Poniższe przykładowe polecenie dodaje pulę węzłów z etykietą hardware=highmem do 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: 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

W przypadku korzystania z tych opcji harmonogramu skontaktuj się 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. Masz następujące możliwości:

  • 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 nie jest dostępne dopasowanie.

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 umożliwić zaplanowanie zasobnika w innym węźle, możesz ustawić wartość na preferowanąwartość DuringSchedulingIgnoreDuringExecution:

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

Część IgnoredDuringExecution ustawienia wskazuje, że zasobnik nie powinien być eksmitowany z węzła, jeśli etykiety węzła się zmienią. 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

Jednym z ostatecznych podejść do harmonogramu Kubernetes w celu logicznego izolowania obciążeń jest użycie koligacji między zasobnikami lub koligacji anty-pod. 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 w węzłach. Można zdefiniować bardziej szczegółowe reguły dotyczące tego zachowania.

Na przykład masz aplikację internetową, która korzysta również z usługi Azure Cache for Redis.

  • Reguły anty-koligacji zasobników służą do żądania, aby harmonogram Kubernetes dystrybuował repliki między węzłami.
  • Reguły koligacji są używane, aby upewnić się, ż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 przeciw koligacji zapewniają bardziej złożone wdrożenie niż selektory węzłów lub koligację węzłów. Wdrożenie pozwala logicznie izolować zasoby i kontrolować sposób planowania zasobników na węzłach przez platformę Kubernetes.

Pełny przykład tej aplikacji internetowej z usługą Azure Cache for Redis można znaleźć w temacie Co-locate zasobniki 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: