Delen via


Beleid voor verstoring van NAP-knooppunten configureren in Azure Kubernetes Service (AKS)

In dit artikel wordt uitgelegd hoe u beleidsregels voor onderbrekingen van knooppunten voor AKS-knooppunten (Azure Kubernetes Service) configureert en hoe onderbrekingen werken om resourcegebruik en kostenefficiëntie te optimaliseren.

NAP optimaliseert uw cluster door:

  • Te weinig gebruikte knooppunten verwijderen of vervangen.
  • Het consolideren van de workloads om de kosten te verlagen.
  • Het respecteren van onderbrekingsbudgetten en onderhoudsvensters.
  • Handmatige controle bieden wanneer dat nodig is.

Voordat u begint

Hoe werkt onderbreking van knooppunten voor NAP-knooppunten?

Karpenter stelt een Kubernetes-finalizer in op elk knooppunt en knooppunt claimt dat deze wordt uitgevoerd. De finalizer blokkeert het verwijderen van het knooppuntobject, terwijl de beëindigingscontroller taintseert en het knooppunt leegloopt voordat de onderliggende knooppuntclaim wordt verwijderd.

Wanneer de workloads op uw knooppunten omlaag worden geschaald, maakt NAP gebruik van onderbrekingsregels in de specificatie van de knooppuntgroep om te bepalen wanneer en hoe u deze knooppunten verwijdert en uw workloads mogelijk opnieuw kunt plannen voor efficiëntie.

Onderbrekingsmethoden voor knooppunten

NAP detecteert automatisch knooppunten die in aanmerking komen voor verstoringen en start vervangingen wanneer dat nodig is. U kunt onderbrekingen activeren via geautomatiseerde methoden zoals Vervaldatum, Consolidatie en Drift, handmatige methoden of externe systemen.

Vervaldatum

Met verlooptijd kunt u een maximale leeftijd instellen voor uw NAP-knooppunten. Knooppunten worden gemarkeerd als verlopen en verstoord nadat ze de leeftijd hebben bereikt die u opgeeft voor de waarde van de knooppuntgroep spec.disruption.expireAfter.

Voorbeeld van verloopconfiguratie

In het volgende voorbeeld ziet u hoe u de verlooptijd voor NAP-knooppunten instelt op 24 uur:

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

Consolidation

NAP werkt om de clusterkosten actief te verlagen door te identificeren wanneer knooppunten kunnen worden verwijderd omdat ze leeg of niet worden gebruikt, of wanneer knooppunten kunnen worden vervangen door lagere prijsvarianten. Dit proces wordt consolidatie genoemd. NAP maakt voornamelijk gebruik van consolidatie om knooppunten te verwijderen of te vervangen voor optimale plaatsing van pods.

NAP voert de volgende typen consolidatie uit om het resourcegebruik te optimaliseren:

  • Lege knooppuntconsolidatie: verwijdert gelijktijdig alle lege knooppunten.
  • Multi-nodeconsolidatie: Verwijdert meerdere knooppunten, waarbij mogelijk een enkele vervangende knooppunt wordt gestart.
  • Consolidatie van één knooppunt: verwijdert een willekeurig knooppunt, mogelijk een vervanging starten.

U kunt consolidatie activeren via het spec.disruption.consolidationPolicy veld in de specificatie van de knooppuntgroep met behulp van de WhenEmptyof WhenEmptyOrUnderUtilized instellingen. U kunt ook het consolidateAfter veld instellen. Dit is een voorwaarde op basis van tijd die bepaalt hoe lang NAP wacht na het detecteren van een consolidatiekans voordat het knooppunt wordt onderbroken.

Voorbeeldconfiguratie voor samenvoeging

In het volgende voorbeeld ziet u hoe u NAP configureert om knooppunten te consolideren wanneer ze leeg zijn en om 30 seconden te wachten na het detecteren van een consolidatiekans voordat het knooppunt wordt onderbroken:

  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

Afdrijven

Drift verwerkt wijzigingen in de NodePool/AKSNodeClass resources. Waarden in de waarden NodeClaimTemplateSpec/AKSNodeClassSpec worden op dezelfde manier weergegeven als ze zijn ingesteld. Een NodeClaim wordt gedetecteerd als afgedreven wanneer de waarden in de gekoppelde NodePool/AKSNodeClass niet overeenkomen met de waarden in de NodeClaim. Net als bij de upstream-relatie deployment.spec.template met pods annoteert Karpenter de bijbehorende NodePool/AKSNodeClass met een hash van de NodeClaimTemplateSpec om drift te controleren. Karpenter verwijdert de Drifted statusvoorwaarde in de volgende scenario's:

  • De Drift feature gate is niet ingeschakeld, maar de NodeClaim is afgeweken.
  • Het NodeClaim is niet afgedreven, maar heeft de statusconditie.

Karpenter of de cloudproviderinterface kan speciale gevallen detecteren die worden geactiveerd door NodeClaim/Instance/NodePool/AKSNodeClasswijzigingen.

Speciale gevallen bij drift

In speciale gevallen kan drift overeenkomen met meerdere waarden en moeten ze anders worden verwerkt. Drift op opgeloste velden kan gevallen veroorzaken waarbij afwijkingen optreden zonder wijzigingen in aangepaste resourcedefinities (CRD's) of waarbij CRD-wijzigingen niet leiden tot afwijkingen.

Als bijvoorbeeld een NodeClaimnode.kubernetes.io/instance-type: Standard_D2s_v3 heeft en de vereisten veranderen van node.kubernetes.io/instance-type In [Standard_D2s_v3] naar node.kubernetes.io/instance-type In [Standard_D2s_v3, Standard_D4s_v3], blijft de NodeClaim hetzelfde omdat de waarde ervan nog steeds compatibel is met de nieuwe vereisten. Omgekeerd, als een NodeClaim een NodeClaimimageFamily gebruikt, maar het spec.imageFamily veld verandert, detecteert Karpenter dat de NodeClaim is afgeweken en roteert het knooppunt om aan die specificatie te voldoen.

Belangrijk

Karpenter bewaakt wijzigingen in de subnetconfiguratie en detecteert afwijkingen wanneer de vnetSubnetID in een AKSNodeClass wordt gewijzigd. Inzicht in dit gedrag is essentieel bij het beheren van aangepaste netwerkconfiguraties. Zie Gedrag van subnetdrift voor meer informatie.

Zie Drift Design voor meer informatie.

Respijtperiode voor beëindiging

U kunt een respijtperiode voor beëindiging voor NAP-knooppunten instellen met behulp van het spec.template.spec.terminationGracePeriod veld in de specificatie van de knooppuntgroep. Met deze instelling kunt u configureren hoe lang Karpenter wacht tot pods correct worden beëindigd. Deze instelling heeft voorrang op een pod's terminationGracePeriodSeconds en omzeilt PodDisruptionBudgets en de karpenter.sh/do-not-disrupt annotatie.

Voorbeeld van de configuratie van de respijtperiode voor beëindiging

In het volgende voorbeeld ziet u hoe u een gratieperiode van 30 seconden instelt voor het beëindigen van NAP-knooppunten.

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

Budgetten voor onderbrekingen

U kunt de onderbreking van Karpenter beperken door het spec.disruption.budgets veld in de specificatie van de knooppuntgroep te wijzigen. Als u deze instelling niet gedefinieerd laat, wordt karpenter standaard ingesteld op één budget met nodes: 10%. Budgetten houden rekening met knooppunten die om welke reden dan ook worden verwijderd. Ze verhinderen alleen vrijwillige verstoringen van Karpenter door middel van verloop, drift, leegstand en consolidatie.

Bij het berekenen of een budget knooppunten tegen onderbrekingen blokkeert, telt Karpenter het totale aantal knooppunten dat eigendom is van een knooppuntenpool en trekt vervolgens de knooppunten af die worden verwijderd en die NotReady zijn. Als het budget is geconfigureerd met een percentagewaarde, zoals 20%, berekent Karpenter het aantal toegestane onderbrekingen als allowed_disruptions = roundup(total * percentage) - total_deleting - total_notready. Voor meerdere budgetten in een knooppuntgroep neemt Karpenter de minimale (meest beperkende) waarde van elk van de budgetten.

Velden voor planning en duur

Wanneer u budgetten gebruikt, kunt u desgewenst de schedule en duration velden instellen om budgetten op tijdsbasis te creëren. Met deze velden kunt u onderhoudsvensters of specifieke tijdsbestekken definiëren wanneer onderbrekingslimieten strenger zijn.

  • Planning maakt gebruik van cron-taaksyntaxis met speciale macro's zoals @yearly, @monthly, @weekly, , @daily. @hourly
  • Duur staat samengestelde duur toe, zoals 10h5m, 30mof 160h. Duur en planning moeten samen worden gedefinieerd.

Voorbeelden van planning en duur

Onderhoudsvensterbudget

Onderbrekingen voorkomen tijdens kantooruren:

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

Alleen onderbrekingen toestaan in het weekend:

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

Toename van onderbrekingssnelheden toestaan:

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

Voorbeelden van budgetconfiguratie

De volgende NodePool specificatie heeft drie budgetten geconfigureerd:

  • Met het eerste budget kunnen 20% knooppunten die eigendom zijn van de knooppuntgroep in één keer worden onderbroken.
  • Het tweede budget fungeert als een plafond, waardoor slechts vijf onderbrekingen mogelijk zijn wanneer er meer dan 25 knooppunten zijn.
  • Het laatste budget blokkeert onderbrekingen gedurende de eerste 10 minuten van elke dag.
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

Handmatige onderbreking van knooppunt

U kunt NAP-knooppunten handmatig onderbreken met kubectl of door NodePool resources te verwijderen.

Knooppunten verwijderen met kubectl

U kunt knooppunten handmatig verwijderen met behulp van de kubectl delete node opdracht. U kunt specifieke knooppunten, alle door NAP beheerde knooppunten of knooppunten uit een specifieke knooppuntgroep verwijderen met behulp van labels, bijvoorbeeld:

# 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

Verwijder NodePool resources

NodePool bezit NodeClaims via een eigenaarverwijzing. NAP beëindigt knooppunten met trapsgewijze verwijdering wanneer u het bijbehorende NodePool verwijderd.

Onderbreking van controle met behulp van aantekeningen

U kunt onderbrekingen voor specifieke pods, knooppunten of hele knooppuntgroepen blokkeren of uitschakelen met behulp van aantekeningen.

Podbesturingselementen

Voorkom dat NAP bepaalde pods verstoort door de karpenter.sh/do-not-disrupt: "true" annotatie in te stellen.

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

Deze aantekening voorkomt vrijwillige onderbreking bij verval, consolidatie en drift. Het voorkomt echter geen onderbrekingen van externe systemen of handmatige onderbrekingen via kubectl of NodePool verwijdering.

Besturingselementen voor knooppunten

Voorkomen dat NAP specifieke knooppunten verstoort.

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

Knooppuntgroep besturing

Onderbreking uitschakelen voor alle knooppunten in een NodePool:

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

Volgende stappen

Zie de volgende artikelen voor meer informatie over automatische inrichting van knooppunten in AKS: