Konfigurieren Sie die Richtlinien zur Knotenunterbrechung für automatisch bereitgestellte (NAP) Knoten im Azure Kubernetes Service (AKS).

In diesem Artikel wird erläutert, wie man Unterbrechungsrichtlinien für Nodes im Azure Kubernetes Service (AKS) im Rahmen der automatischen Node-Bereitstellung (NAP) konfiguriert und wie Unterbrechungen funktionieren, um die Ressourcenauslastung und die Kosteneffizienz zu optimieren.

NAP optimiert Ihren Cluster durch:

• Entfernen oder Ersetzen von nicht genutzten Knoten.
• Konsolidieren von Arbeitslasten zur Senkung der Kosten.
• Einhaltung von Unterbrechungsbudgets und Wartungsfenstern.
• Manuelle Steuerung bei Bedarf bereitstellen.

Bevor Sie anfangen

• Lesen Sie die Übersicht über die automatische Bereitstellung von Knoten (Node Auto-Provisioning, NAP) in AKS-Artikel , in dem die Funktionsweise von NAP beschrieben wird.
• Lesen Sie die Übersicht über Netzwerkkonfigurationen für die automatische Bereitstellung von Knoten (Node Auto-Provisioning, NAP) in Azure Kubernetes Service (AKS).

Wie funktioniert die Knotenstörung für NAP-Knoten?

Karpenter legt einen Kubernetes-Finalizer für jeden Knoten und jeden bereitgestellten Knotenanspruch fest. Der Finalizer blockiert das Löschen des Knotenobjekts, während der Terminierungscontroller den Knoten mit Taints versieht und entlädt, bevor der zugrunde liegende Knotenanspruch entfernt wird.

Wenn die Workloads auf Ihren Knoten herunterskalieren, verwendet NAP Unterbrechungsregeln in der Knotenpoolspezifikation, um zu entscheiden, wann und wie diese Knoten entfernt und ihre Workloads möglicherweise für höhere Effizienz neu geplant werden.

Methoden für Knotenunterbrechungen

NAP ermittelt automatisch Knoten, die für Unterbrechungen geeignet sind, und startet bei Bedarf Ersatzknoten. Sie können Unterbrechungen durch automatisierte Methoden wie Ablauf, Konsolidierung und Drift, manuelle Methoden oder externe Systeme auslösen.

Ablauf

Die Ablauffrist ermöglicht es Ihnen, ein maximales Alter für Ihre NAP-Knoten festzulegen. Knoten werden als abgelaufen und unterbrochen markiert, nachdem sie das von Ihnen für den Wert spec.disruption.expireAfter des Knotenpools festgelegte Alter erreicht haben.

Beispiel für die Ablauffristkonfiguration

Das folgende Beispiel zeigt, wie die Ablaufzeit für NAP-Knoten auf 24 Stunden festgelegt wird:

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

Consolidation

NAP arbeitet daran, die Clusterkosten aktiv zu reduzieren, indem ermittelt wird, wann Knoten entfernt werden können, da sie leer oder unterverlastet sind oder wenn Knoten durch niedrigere Preisvarianten ersetzt werden können. Dieser Prozess wird als Konsolidierung bezeichnet. NAP verwendet hauptsächlich Konsolidierung, um Knoten für eine optimale Pod-Platzierung zu löschen oder zu ersetzen.

NAP führt die folgenden Konsolidierungstypen aus, um die Ressourcenauslastung zu optimieren:

• Leere Knotenkonsolidierung: Löscht alle leeren Knoten parallel.
• Multi-Node-Konsolidierung: Löscht mehrere Knoten, möglicherweise wird ein einzelner Ersatzknoten gestartet.
• Konsolidierung mit einem einzelnen Knoten: Löscht jeden einzelnen Knoten, möglicherweise wird ein Ersatz gestartet.

Sie können die Konsolidierung über das spec.disruption.consolidationPolicy-Feld in der Knotenpoolspezifikation mithilfe der WhenEmpty-Einstellungen oder der WhenEmptyOrUnderUtilized-Einstellungen auslösen. Sie können auch das consolidateAfter Feld festlegen, bei dem es sich um eine zeitbasierte Bedingung handelt, die bestimmt, wie lange NAP nach dem Ermitteln einer Konsolidierungsmöglichkeit wartet, bevor der Knoten unterbrochen wird.

Beispiel für eine Konsolidierungskonfiguration

Das folgende Beispiel zeigt, wie Sie NAP so konfigurieren, dass Knoten konsolidiert werden, wenn sie leer sind, und 30 Sekunden nach dem Ermitteln einer Konsolidierungsmöglichkeit warten, bevor der Knoten unterbrochen wird:

  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

Drift

Drift verarbeitet Änderungen an den NodePool/AKSNodeClass Ressourcen. Werte in der NodeClaimTemplateSpec/AKSNodeClassSpec werden auf dieselbe Weise wiedergegeben, wie sie festgelegt wurden. NodeClaim wird als abweichend erkannt, wenn die Werte im zugehörigen NodePool/AKSNodeClass-Element nicht mit den Werten in NodeClaim übereinstimmen. Ähnlich wie die Upstream-deployment.spec.template-Beziehung zu Pods kommentiert Karpenter das zugeordnete NodePool/AKSNodeClass-Element mit einem Hash von NodeClaimTemplateSpec, um auf Drift zu prüfen. Karpenter entfernt die Drifted Statusbedingung in den folgenden Szenarien:

• Das Drift-Feature-Gate ist nicht aktiviert, aber NodeClaim weist einen Drift auf.
• NodeClaim weist keinen Drift auf, hat aber den Statuszustand.

Karpenter oder die Cloudanbieterschnittstelle kann spezielle Fälle erkennen, die durch NodeClaim/Instance/NodePool/AKSNodeClassÄnderungen ausgelöst werden.

Sonderfälle zum Thema Drift

In speziellen Fällen kann die Abweichung mehreren Werten entsprechen und muss unterschiedlich behandelt werden. Die Abweichung bei aufgelösten Feldern kann Fälle verursachen, in denen Abweichung ohne Änderungen an benutzerdefinierten Ressourcendefinitionen (Custom Resource Definitions, CRDs) auftritt oder wenn CRD-Änderungen keine Abweichung verursachen.

Wenn NodeClaim vom Typ node.kubernetes.io/instance-type: Standard_D2s_v3 ist und sich Anforderungen von node.kubernetes.io/instance-type In [Standard_D2s_v3] in node.kubernetes.io/instance-type In [Standard_D2s_v3, Standard_D4s_v3] ändern, weist NodeClaim keinen Drift auf, weil der Wert weiterhin mit den neuen Anforderungen kompatibel ist. Wenn NodeClaimNodeClaimimageFamily nutzt, sich aber das Feld spec.imageFamily ändert, erkennt Karpenter hingegen NodeClaim als abgewichen und rotiert den Knoten, um diese Spezifikation zu erfüllen.

Weitere Informationen finden Sie unter Drift Design.

Kündigungsfrist

Mit dem Feld spec.template.spec.terminationGracePeriod in der Spezifikation des Knotenpools können Sie eine Beendigungsfrist für NAP-Knoten festlegen. Mit dieser Einstellung können Sie konfigurieren, wie lange Karpenter wartet, bis Pods ordnungsgemäß beendet werden. Diese Einstellung hat Vorrang vor dem terminationGracePeriodSeconds-Wert eines Pods und umgeht PodDisruptionBudgets sowie die Anmerkung karpenter.sh/do-not-disrupt.

Beispiel für die Konfiguration der Kündigungsfrist

Das folgende Beispiel zeigt, wie Sie eine Kündigungsfrist von 30 Sekunden für NAP-Knoten festlegen:

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

Unterbrechungsbudgets

Sie können die Unterbrechung von Karpenter begrenzen, indem Sie das Feld spec.disruption.budgets in der Knotenpoolspezifikation ändern. Wenn Sie diese Einstellung nicht definiert lassen, verwendet Karpenter standardmäßig ein Budget mit nodes: 10%. Budgets berücksichtigen Knoten, die aus irgendeinem Grund gelöscht werden, und verhindern nur freiwillige Unterbrechungen durch Ablauf, Drift, Leere und Konsolidierung in Karpenter.

Bei der Berechnung, ob ein Budget Knoten vor Unterbrechungen schützt, zählt Karpenter die Gesamtknoten, die zu einem Knotenpool gehören, und zieht dann Knoten ab, die gelöscht werden, sowie Knoten im Status NotReady. Wenn das Budget mit einem Prozentwert konfiguriert ist, z 20%. B. berechnet Karpenter die Anzahl der zulässigen Unterbrechungen als allowed_disruptions = roundup(total * percentage) - total_deleting - total_notready. Für mehrere Budgets in einem Knotenpool nimmt Karpenter den minimalen (restriktivsten) Wert jedes Budgets ein.

Felder "Zeitplan" und "Dauer"

Wenn Sie Budgets verwenden, können Sie optional die Felder schedule und duration festlegen, um zeitbasierte Budgets zu erstellen. Mit diesen Feldern können Sie Wartungsfenster oder bestimmte Zeitrahmen definieren, wenn Unterbrechungsgrenzwerte strenger sind.

• Schedule verwendet Cronauftragsyntax mit speziellen Makros wie @yearly, , @monthly, @weekly, @daily. @hourly
• Dauer ermöglicht zusammengesetzte Dauern wie 10h5m, 30m oder 160h. Dauer und Zeitplan müssen zusammen definiert werden.

Beispiele für Zeitplan und Dauer

Wartungsfenster-Budget

Verhindern von Unterbrechungen während der Geschäftszeiten:

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

Unterbrechungen nur am Wochenende

Nur Unterbrechungen an Wochenenden zulassen:

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

Budget für schrittweises Rollout

Erhöhung der Unterbrechungsraten zulassen:

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

Beispiele für die Budgetkonfiguration

Die folgende NodePool Spezifikation hat drei Budgets konfiguriert:

• Das erste Budget erlaubt, dass 20% der dem Knotenpool zugehörigen Knoten gleichzeitig gestört werden können.
• Das zweite Budget fungiert als Obergrenze, was nur fünf Unterbrechungen zulässt, wenn mehr als 25 Knoten vorhanden sind.
• Das letzte Budget blockiert Unterbrechungen während der ersten 10 Minuten jeden Tages.

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

Manuelle Knotenunterbrechung

Sie können NAP-Knoten manuell unterbrechen, indem Sie kubectl verwenden oder NodePool Ressourcen löschen.

Entfernen von Knoten mit Kubectl

Sie können Knoten mithilfe des kubectl delete node Befehls manuell entfernen. Sie können bestimmte Knoten, alle napverwalteten Knoten oder Knoten aus einem bestimmten Knotenpool löschen, indem Sie beispielsweise Bezeichnungen verwenden:

# 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

Ressourcen löschen NodePool

NodePool besitzt NodeClaims durch einen Besitzerverweis. NAP beendet Knoten ordnungsgemäß durch kaskadierende Löschung, wenn Sie das zugehörige NodePool-Element löschen.

Unterbrechungen kontrollieren mithilfe von Anmerkungen

Sie können Unterbrechungen für bestimmte Pods, Knoten oder ganze Knotenpools mithilfe von Anmerkungen blockieren oder deaktivieren.

Pod-Steuerelemente

Verhindern Sie, dass NAP bestimmte Pods unterbricht, indem Sie die karpenter.sh/do-not-disrupt: "true"-Annotation festlegen:

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

Diese Anmerkung verhindert freiwillige Unterbrechungen für Ablauf, Konsolidierung und Drift. Sie verhindert jedoch keine Unterbrechung durch externe Systeme oder manuelle Unterbrechung durch kubectl- oder NodePool-Löschung.

Knotensteuerungen

Verhindern, dass NAP bestimmte Knoten stört:

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

Steuerelemente des Knotenpools

Störungen für alle Knoten in einem NodePool deaktivieren.

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

Nächste Schritte

Weitere Informationen zur automatischen Bereitstellung von Knoten in AKS finden Sie in den folgenden Artikeln:

• Konfigurieren von Netzwerken für die automatische Bereitstellung von Knoten auf AKS
• Konfigurieren von Knotenpools für die automatische Bereitstellung von Knoten auf AKS
• Erstellen eines Clusters mit automatischer Bereitstellung von Knoten in einem benutzerdefinierten virtuellen Netzwerk in AKS