Konfigurowanie polityk zakłóceń węzłów dla węzłów automatycznego aprowizowania w usłudze Azure Kubernetes Service (AKS)

W tym artykule wyjaśniono, jak skonfigurować zasady zakłóceń dla węzłów usługi Azure Kubernetes Service (AKS) aprowizowanych automatycznie (NAP) oraz szczegółowo omówiono, jak zakłócenia w działaniu mogą optymalizować wykorzystanie zasobów i efektywność kosztową.

NAP optymalizuje klaster przez:

• Usuwanie lub zastępowanie nie w pełni wykorzystanych węzłów.
• Konsolidacja obciążeń w celu zmniejszenia kosztów.
• Przestrzeganie budżetów przerw i okien konserwacji.
• Zapewnienie ręcznej kontroli w razie potrzeby.

Zanim rozpoczniesz

• Przeczytaj artykuł Omówienie automatycznej aprowizacji węzłów (NAP) w usłudze AKS, który zawiera szczegółowe informacje o tym, jak działa NAP.
• Zapoznaj się z omówieniem konfiguracji sieci na potrzeby automatycznej aprowizacji węzłów (NAP) w usłudze Azure Kubernetes Service (AKS).

Jak działają zakłócenia na węzłach NAP?

Karpenter ustawia finalizator Kubernetes na każdym węźle oraz na każdym żądaniu węzła, które aprowizuje. Finalizator blokuje usunięcie obiektu węzła, podczas gdy kontroler kończenia jest skażony i opróżnia węzeł przed usunięciem oświadczenia węzła bazowego.

Gdy obciążenia w węzłach są skalowane w dół, Node Auto-Provisioning (NAP) używa reguł zakłóceń w specyfikacji puli zasobów węzłów, aby zdecydować, kiedy i jak usunąć te węzły i potencjalnie ponownie rozplanować obciążenia w celu zwiększenia wydajności.

Metody zakłóceń węzłów

Ochrona dostępu do sieci automatycznie odnajduje węzły kwalifikujące się do zakłóceń i uruchamia zamienniki w razie potrzeby. Zakłócenia można wyzwalać za pomocą zautomatyzowanych metod, takich jak wygaśnięcie, konsolidacja i dryf, metody ręczne lub systemy zewnętrzne.

Wygaśnięcie

Ustawienie maksymalnego okresu ważności umożliwia określenie maksymalnego wieku Twoich węzłów NAP. Węzły są oznaczone jako wygasłe i zakłócane po osiągnięciu wieku określonego dla wartości puli węzłów spec.disruption.expireAfter .

Przykładowa konfiguracja wygasania

W poniższym przykładzie pokazano, jak ustawić czas wygaśnięcia węzłów ochrony dostępu do sieci na 24 godziny:

spec:
  disruption:
    expireAfter: 24h  # Expire nodes after 24 hours

Consolidation

NAP działa, aby aktywnie zmniejszyć koszty klastra, identyfikując, kiedy węzły można usunąć, ponieważ są puste lub są niewykorzystane, lub kiedy węzły mogą zostać zastąpione tańszymi wariantami. Ten proces jest nazywany konsolidacją. Sieć ochrony dostępu (NAP) głównie używa procesu "Konsolidacja" do usuwania lub zastępowania węzłów, aby optymalnie rozmieścić pody.

NAP wykonuje następujące typy konsolidacji w celu optymalizacji wykorzystania zasobów:

• Konsolidacja pustych węzłów: usuwa wszystkie puste węzły równolegle.
• Konsolidacja z wieloma węzłami: usuwa wiele węzłów, co może prowadzić do uruchomienia pojedynczego zastępczego węzła.
• Konsolidacja jednego węzła: usuwa pojedynczy węzeł, prawdopodobnie uruchamiając jego zamiennik.

Konsolidację można wyzwolić za pomocą pola spec.disruption.consolidationPolicy w specyfikacji puli węzłów przy użyciu WhenEmpty lub WhenEmptyOrUnderUtilized ustawień. Można również ustawić pole consolidateAfter, które jest warunkiem opartym na czasie określającym, jak długo NAP czeka po odkryciu możliwości konsolidacji przed zakłóceniem węzła.

Przykładowa konfiguracja konsolidacji

W poniższym przykładzie pokazano, jak skonfigurować NAP w celu skonsolidowania węzłów, gdy są puste, oraz jak poczekać 30 sekund po odkryciu możliwości konsolidacji przed zakłóceniem pracy węzła:

  disruption:
    # Describes which types of nodes NAP should consider for consolidation
    # `WhenEmptyOrUnderUtilized`: NAP considers all nodes for consolidation and attempts to remove or replace nodes when it discovers that the node is empty or underutilized and could be changed to reduce cost
    # `WhenEmpty`: NAP only considers nodes for consolidation that don't contain any workload pods
    
    consolidationPolicy: WhenEmpty

    # The amount of time NAP should wait after discovering a consolidation decision
    # Currently, you can only set this value when the consolidation policy is `WhenEmpty`
    # You can choose to disable consolidation entirely by setting the string value `Never`
    consolidateAfter: 30s

Dryfować

Drift obsługuje zmiany w zasobach NodePool/AKSNodeClass . Wartości w obiekcie NodeClaimTemplateSpec/AKSNodeClassSpec są odzwierciedlane w taki sam sposób, jak są ustawione. Element NodeClaim jest uznawany za odchylony, jeśli wartości powiązane NodePool/AKSNodeClass nie pasują do wartości w obiekcie NodeClaim. Podobnie jak relacja nadrzędna deployment.spec.template z zasobnikami, Karpenter annotuje skojarzone NodePool/AKSNodeClass ze skrótem NodeClaimTemplateSpec, aby sprawdzić dryf. Karpenter usuwa warunek stanu Drifted w następujących scenariuszach:

• Bramka Drift funkcji nie jest włączona, ale NodeClaim jest dryfowana.
• Parametr NodeClaim nie jest przesunięty, ale ma określony status.

Karpenter lub interfejs dostawcy usług w chmurze mogą wykryć specjalne przypadki wywołane przez NodeClaim/Instance/NodePool/AKSNodeClasszmiany.

Przypadki specjalne na temat driftu

W specjalnych przypadkach dryf może odpowiadać wielu wartościom i musi być obsługiwany inaczej. Dryfowanie w ustalonych polach może tworzyć przypadki, w których dryf występuje bez zmian w niestandardowych definicjach zasobów (CRD) lub w których zmiany CRD nie powodują dryfu.

Jeśli na przykład element NodeClaim ma node.kubernetes.io/instance-type: Standard_D2s_v3, a wymagania zmieniają się z node.kubernetes.io/instance-type In [Standard_D2s_v3] na node.kubernetes.io/instance-type In [Standard_D2s_v3, Standard_D4s_v3], parametr NodeClaim nie jest zmieniony, ponieważ jego wartość jest nadal zgodna z nowymi wymaganiami. Z drugiej strony, jeśli NodeClaim używa NodeClaimimageFamily, ale następują zmiany w polu spec.imageFamily, Karpenter wykrywa, że NodeClaimuległ dryfowi i obraca węzeł, aby dostosować się do tej specyfikacji.

Ważne

Karpenter monitoruje zmiany konfiguracji podsieci i wykrywa dryf, gdy vnetSubnetID w AKSNodeClass jest zmodyfikowany. Zrozumienie tego zachowania ma kluczowe znaczenie podczas zarządzania niestandardowymi konfiguracjami sieci. Aby uzyskać więcej informacji, zapoznaj się z Zachowaniem dryfu podsieci.

Aby uzyskać więcej informacji, zobacz Drift Design.

Okres prolongaty zakończenia

Można ustawić okres karencji zakończenia dla węzłów NAP za pomocą pola spec.template.spec.terminationGracePeriod w specyfikacji puli węzłów. To ustawienie umożliwia skonfigurowanie, jak długo Karpenter czeka na łagodne zakończenie podów. To ustawienie ma pierwszeństwo przed terminationGracePeriodSeconds zasobnikiem i pomija PodDisruptionBudgets oraz adnotację karpenter.sh/do-not-disrupt.

Przykładowa konfiguracja okresu prolongaty zakończenia

W poniższym przykładzie pokazano, jak ustawić okres karencji zakończenia równy 30 sekund dla węzłów NAP.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      terminationGracePeriod: 30s

Budżety zakłóceń

Możesz ograniczyć częstotliwość zakłóceń Karpentera, modyfikując pole spec.disruption.budgets w specyfikacji puli węzłów. Jeśli to ustawienie pozostawisz niezdefiniowane, Karpenter domyślnie działa z jednym budżetem nodes: 10%. Budżety uwzględniają węzły, które są usuwane z jakiegokolwiek powodu, i jedynie uniemożliwiają narzędziu Karpenter zarządzanie dobrowolnymi zakłóceniami związanymi z wygaśnięciem, dryfem, pustkami i konsolidacją.

Podczas obliczania, czy budżet uniemożliwia zakłócenia węzłów, Karpenter sumuje łączną liczbę węzłów należących do puli węzłów, a następnie odejmuje węzły, które są usuwane oraz węzły, które są NotReady. Jeśli budżet jest skonfigurowany z wartością procentową, taką jak 20%, Karpenter oblicza liczbę dozwolonych zakłóceń jako allowed_disruptions = roundup(total * percentage) - total_deleting - total_notready. W przypadku wielu budżetów w puli węzłów Karpenter przyjmuje minimalną (najbardziej restrykcyjną) wartość każdego z budżetów.

Pola Harmonogramu i czasu trwania

W przypadku korzystania z budżetów można opcjonalnie ustawić pola schedule i duration w celu utworzenia budżetów opartych na czasie. Te pola umożliwiają zdefiniowanie okien obsługi lub określonych przedziałów czasowych, gdy limity zakłóceń są bardziej rygorystyczne.

• Harmonogram używa składni cron job ze specjalnymi makrami, takimi jak @yearly, @monthly, @weekly, @daily, @hourly.
• Czas trwania umożliwia złożone czasy trwania, takie jak 10h5m, 30mlub 160h. Czas trwania i harmonogram muszą być zdefiniowane razem.

Przykłady harmonogramu i czasu trwania

Budżet okna konserwacyjnego

Zapobiegaj zakłóceniom w godzinach pracy:

budgets:
- nodes: "0"
  schedule: "0 9 * * 1-5"  # 9 AM Monday-Friday
  duration: 8h             # For 8 hours

Zakłócenia tylko w weekend

Zezwalaj tylko na zakłócenia w weekendy:

budgets:
- nodes: "50%"
  schedule: "0 0 * * 6"    # Saturday midnight
  duration: 48h            # All weekend
- nodes: "0"               # Block all other times

Stopniowo wdrażany budżet

Zezwalaj na zwiększenie współczynników zakłóceń:

budgets:
- nodes: "1"
  schedule: "0 2 * * *"    # 2 AM daily
  duration: 2h
- nodes: "3"
  schedule: "0 4 * * *"    # 4 AM daily
  duration: 4h

Przykłady konfiguracji budżetu

NodePool Poniższa specyfikacja ma skonfigurowane trzy budżety:

• Pierwszy budżet pozwala na zakłócenie 20% węzłów puli węzłów na raz.
• Drugi budżet działa jako pułap, umożliwiając tylko pięć przerw, gdy istnieje więcej niż 25 węzłów.
• Ostatni budżet blokuje zakłócenia w ciągu pierwszych 10 minut każdego dnia.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    expireAfter: 720h # 30 * 24h = 720h
    budgets:
    - nodes: "20%"      # Allow 20% of nodes to be disrupted
    - nodes: "5"        # Cap at maximum 5 nodes
    - nodes: "0"        # Block all disruptions during maintenance window
      schedule: "@daily" # Scheduled daily
      duration: 10m # Duration of 10 minutes

Ręczne przerwanie węzła

Możesz ręcznie zakłócić funkcjonowanie węzłów NAP przy użyciu kubectl lub przez usunięcie NodePool zasobów.

Usuwanie węzłów za pomocą narzędzia kubectl

Węzły można usunąć ręcznie za pomocą kubectl delete node polecenia . Możesz usunąć określone węzły, wszystkie węzły zarządzane przez NAP lub węzły z określonej puli węzłów, używając etykiet, na przykład:

# Delete a specific node
kubectl delete node $NODE_NAME

# Delete all NAP-managed nodes
kubectl delete nodes -l karpenter.sh/nodepool

# Delete nodes from a specific nodepool
kubectl delete nodes -l karpenter.sh/nodepool=$NODEPOOL_NAME

Usuwanie NodePool zasobów

NodePool posiada NodeClaims poprzez referencję właściciela. NAP delikatnie kończy węzły poprzez kaskadowe usuwanie, gdy usuniesz skojarzony element NodePool.

Kontrolowanie zakłóceń przy użyciu adnotacji

Możesz zablokować lub wyłączyć zakłócenia dla konkretnych zasobników, węzłów lub całych puli węzłów, używając adnotacji.

Kontrolki Pod

Aby zablokować NAP przed zakłóceniem działania niektórych zasobników, ustaw adnotację karpenter.sh/do-not-disrupt: "true".

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    metadata:
      annotations:
        karpenter.sh/do-not-disrupt: "true"

Ta adnotacja uniemożliwia dobrowolne zakłócenia wygasania, konsolidacji i dryfu. Nie zapobiega to jednak zakłóceniom pochodzącym z zewnętrznych systemów ani zakłóceniom poprzez usunięcie kubectl lub NodePool.

Kontrolki węzłów

Blokuj program Ochrona dostępu do sieci (NAP) przed zakłócaniem działania określonych węzłów.

apiVersion: v1
kind: Node
metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

Kontrola puli węzłów

Wyłącz zakłócenia dla wszystkich węzłów w obiekcie NodePool:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    metadata:
      annotations:
        karpenter.sh/do-not-disrupt: "true"

Dalsze kroki

Aby uzyskać więcej informacji o automatycznym aprowizowaniu węzłów w AKS, zobacz następujące artykuły:

• Konfigurowanie sieci na potrzeby automatycznej aprowizacji węzłów w usłudze AKS
• Konfigurowanie pul węzłów na potrzeby automatycznej aprowizacji węzłów w usłudze AKS
• Tworzenie klastra automatycznego aprowizowania węzłów w niestandardowej sieci wirtualnej w usłudze AKS