Konfigurace zásad přerušení uzlů pro uzly automatického zřizování uzlů (NAP) ve službě Azure Kubernetes Service (AKS)

Tento článek vysvětluje, jak nakonfigurovat zásady přerušení uzlů pro uzly automatického zřizování služby Azure Kubernetes Service (AKS) a podrobně popisuje, jak funguje přerušení pro optimalizaci využití prostředků a zvyšování efektivity nákladů.

Architektura NAP optimalizuje cluster pomocí:

• Odebrání nebo nahrazení nevyužitých uzlů
• Konsolidace úloh za účelem snížení nákladů
• Dodržování rozpočtů na přerušení a časových období údržby
• Poskytování ručního ovládání v případě potřeby

Než začnete

• Přečtěte si přehled automatického zřizování uzlů (NAP) v článku AKS , který podrobně popisuje fungování architektury NAP.
• Přečtěte si přehled síťových konfigurací pro automatické zřizování uzlů (NAP) ve službě Azure Kubernetes Service (AKS).

Jak funguje přerušení uzlu pro uzly NAP?

Karpenter nastaví finalizátor Kubernetes na každém uzlu a uzel ho zřídí. Finalizátor blokuje odstranění objektu uzlu, zatímco Ukončovací kontrolér aplikuje tzv. 'taint' a vyprázdní uzel před odebráním původního požadavku na uzel.

Při snížení zátěže na uzlech používá NAP pravidla přerušení ve specifikaci fondu uzlů k rozhodnutí, kdy a jak tyto uzly odebrat a případně přeplánovat vaše úlohy pro efektivitu.

Metody přerušení uzlů

NAP automaticky zjišťuje uzly vhodné pro přerušení a v případě potřeby spouští náhrady. Přerušení můžete aktivovat automatizovanými metodami, jako je vypršení platnosti, konsolidace a posun, ruční metody nebo externí systémy.

Vypršení platnosti

Vypršení platnosti umožňuje nastavit maximální stáří uzlů NAP. Uzly se označí jako prošlé a přeruší se po dosažení věku, který zadáte pro hodnotu fondu spec.disruption.expireAfter uzlů.

Příklad konfigurace vypršení platnosti

Následující příklad ukazuje, jak nastavit dobu vypršení platnosti uzlů NAP na 24 hodin:

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

Consolidation

Architektura NAP aktivně snižuje náklady na cluster tím, že identifikuje, kdy je možné uzly odebrat, protože jsou prázdné nebo nedostatečně využité, nebo když je možné uzly nahradit nižší cenou variant. Tento proces se nazývá Konsolidace. NAP primárně používá konsolidaci k odstranění nebo nahrazení uzlů pro optimální umístění podů.

Architektura NAP provádí následující typy konsolidace za účelem optimalizace využití prostředků:

• Konsolidace prázdných uzlů: Odstraňuje všechny prázdné uzly souběžně.
• Konsolidace s více uzly: Odstraní více uzlů, pravděpodobně spustí jedinou náhradu.
• Konsolidace s jedním uzlem: Odstraní jeden uzel, může spustit náhradu.

Sloučení můžete aktivovat prostřednictvím spec.disruption.consolidationPolicy pole ve specifikaci fondu uzlů pomocí WhenEmpty nebo WhenEmptyOrUnderUtilized nastavení. Můžete také nastavit consolidateAfter pole, což je podmínka založená na čase, která určuje, jak dlouho NAP čeká po zjištění příležitosti konsolidace před přerušením uzlu.

Příklad konfigurace konsolidace

Následující příklad ukazuje, jak nakonfigurovat architekturu NAP tak, aby konsolidovaly uzly, když jsou prázdné, a počkat 30 sekund po zjištění příležitosti konsolidace před narušením uzlu:

  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

posun

Drift zpracovává změny NodePool/AKSNodeClass resources. Hodnoty v objektu NodeClaimTemplateSpec/AKSNodeClassSpec se odrážejí stejným způsobem, jakým jsou nastavené. A NodeClaim je považováno za odchýlené, pokud se hodnoty v přidruženém objektu NodePool/AKSNodeClass neshodují s hodnotami v NodeClaim. Podobně jako ve vztahu směrem nahorudeployment.spec.template k podům, Karpenter anotuje přidruženou NodePool/AKSNodeClass hashovou hodnotou NodeClaimTemplateSpec, aby zkontroloval odchylku. Karpenter odebere Drifted stavovou podmínku v následujících scénářích:

• Drift Funkce brána není povolená, ale NodeClaim je odchýlená.
• Není NodeClaim posunutý, ale má stavovou podmínku.

Karpenter nebo rozhraní poskytovatele cloudu můžou objevit zvláštní případy aktivované NodeClaim/Instance/NodePool/AKSNodeClasszměnami.

Zvláštní případy posunu

Ve zvláštních případech může posun odpovídat více hodnotám a musí se zpracovávat jinak. Posun u vyřešených polí může vytvářet případy, kdy dojde k posunu bez změn vlastních definic prostředků (CRD) nebo kde změny CRD nemají za následek posun.

Například pokud NodeClaim má node.kubernetes.io/instance-type: Standard_D2s_v3 a požadavky se změní z node.kubernetes.io/instance-type In [Standard_D2s_v3] na node.kubernetes.io/instance-type In [Standard_D2s_v3, Standard_D4s_v3], NodeClaim není posunut, protože jeho hodnota je stále kompatibilní s novými požadavky. Naopak, pokud NodeClaim používá NodeClaimimageFamily pole, ale pole spec.imageFamily se změní, Karpenter zjistí, že NodeClaim je posunutý, a otočí uzel, aby splňoval tuto specifikaci.

Důležité

Karpenter sleduje změny konfigurace podsítě a detekuje odchyl, když se modifikují vnetSubnetID v AKSNodeClass. Pochopení tohoto chování je důležité při správě vlastních konfigurací sítě. Další informace najdete v tématu Chování posunu podsítě.

Další informace najdete v tématu Drift Design.

Období odkladu ukončení

Období odkladu ukončení pro uzly NAP můžete nastavit pomocí spec.template.spec.terminationGracePeriod pole ve specifikaci fondu uzlů. Toto nastavení umožňuje nakonfigurovat, jak dlouho Karpenter čeká na řádné ukončení podů. Toto nastavení má přednost před nastavením podu terminationGracePeriodSeconds a obchází PodDisruptionBudgets a karpenter.sh/do-not-disrupt anotaci.

Příklad konfigurace období odkladu ukončení

Následující příklad ukazuje, jak nastavit dobu odkladu ukončení 30 sekund pro uzly NAP:

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

Rozpočty přerušení

Přerušení Karpenteru můžete omezit úpravou spec.disruption.budgets pole ve specifikaci fondu uzlů. Pokud toto nastavení ponecháte nedefinované, Karpenter ve výchozím nastavení použije jeden rozpočet s nodes: 10%. Rozpočty považují uzly, které se z jakéhokoli důvodu odstraní, a Karpenter zablokuje pouze dobrovolným přerušením prostřednictvím vypršení platnosti, posunu, prázdnoty a konsolidace.

Při výpočtu, zda rozpočet blokuje uzly z výpadku, Karpenter spočítá celkový počet uzlů zahrnutých v poolu uzlů a poté odečte uzly, které jsou odstraňovány, a uzly, které jsou NotReady. Pokud je rozpočet nakonfigurován s procentuální hodnotou, například 20%, Karpenter vypočítá počet povolených přerušení jako allowed_disruptions = roundup(total * percentage) - total_deleting - total_notready. Pro několik rozpočtů ve fondu uzlů Karpenter vybírá minimální (nejvíce omezující) hodnotu z každého rozpočtu.

Pole harmonogramu a doby trvání

Při použití rozpočtů můžete volitelně nastavit pole schedule a duration pro vytváření rozpočtů založených na čase. Tato pole umožňují definovat časová období údržby nebo konkrétní časové rámce, pokud jsou limity přerušení přísnější.

• Schedule používá syntaxi úlohy cron se speciálními makry, jako je @yearly, @monthly, @weekly, @daily. @hourly
• Doba trvání umožňuje složené doby trvání, jako 10h5m, 30m nebo 160h. Doba trvání a plán musí být definovány společně.

Příklady plánu a doby trvání

Rozpočet časového období údržby

Zabránění přerušení během pracovní doby:

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

Přerušení pouze o víkendu

Povolit přerušení pouze o víkendech:

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

Postupné zavádění rozpočtu

Povolit zvýšení míry přerušení:

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

Příklady konfigurace rozpočtu

Pro následující NodePool specifikaci jsou nakonfigurované tři rozpočty:

• První rozpočet umožňuje přerušení 20% uzlů vlastněných fondem uzlů najednou.
• Druhý rozpočet funguje jako strop, který umožňuje pouze pět přerušení v případě, že existuje více než 25 uzlů.
• Poslední rozpočet blokuje přerušení během prvních 10 minut každého dne.

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

Ruční přerušení uzlu

Uzly NAP můžete narušit ručně pomocí kubectl nebo odstraněním prostředků NodePool.

Odebrání uzlů pomocí kubectl

Uzly můžete ručně odebrat pomocí kubectl delete node příkazu. Pomocí popisků můžete odstranit konkrétní uzly, všechny uzly spravované architekturou NAP nebo uzly z konkrétního fondu uzlů:

# 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

Odstraňte NodePool prostředky

Ten NodePool vlastní NodeClaims prostřednictvím odkazu vlastníka. Architektura NAP elegantně ukončí uzly prostřednictvím kaskádového odstranění při odstranění přidruženého NodePoolobjektu.

Řízení přerušení pomocí poznámek

Přerušení konkrétních podů, uzlů nebo celých poolů uzlů můžete zablokovat nebo zakázat pomocí anotací.

Ovládací prvky podů

Zablokujte NAP, aby nenarušoval určité pody nastavením anotace karpenter.sh/do-not-disrupt: "true":

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

Tato poznámka zabraňuje dobrovolnému přerušení platnosti, konsolidace a posunu. Nezabrání ale narušení z externích systémů nebo ručnímu narušení prostřednictvím kubectl nebo NodePool odstranění.

Ovládací prvky uzlu

Zablokovat NAP, aby nenarušoval specifické uzly:

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

Ovládací prvky fondu uzlů

Zakázat přerušení pro všechny uzly v NodePool:

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

Další kroky

Pro více informací o automatickém zřizování uzlů v AKS si přečtěte následující články:

• Konfigurace sítí pro automatické zřizování uzlů v AKS
• Konfigurace skupin uzlů pro automatické zřizování uzlů v AKS
• Vytvoření automaticky zřizovaného clusteru uzlů ve vlastní virtuální síti v AKS