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. Mezi automatizované řízené metody patří Konsolidace a Drift. Vypršení platnosti je automatizovaná vynucená metoda. Přerušení můžete aktivovat také ručními metodami nebo externími systémy.

Vypršení platnosti

Expirace je metoda nuceného vyřazení, kterou používáte k nastavení maximálního 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ě.

Note

Funkce na úrovni uzlů, které konfigurujete prostřednictvím AKSNodeClass, sledují tuto stejnou cestu posunu. Mezi tyto funkce patří LocalDNS, streamování artefaktů, režim FIPS a konfigurace kubeletu. Povolení nebo zakázání těchto funkcí nepřekonfiguruje existující uzly na místě. Karpenter nahrazuje uzly, přičemž rychlost je omezena vašimi rozpočty narušení a rozpočty narušení podů. Toto tags pole je výjimkou, protože změny tagů platí pro existující prostředky Azure bez nahrazení uzlu.

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í

Frekvenci řízeného narušení v Karpenteru můžete omezit úpravou pole spec.disruption.budgets 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 berou v úvahu uzly, které se z jakéhokoli důvodu odstraňují, a Karpenteru brání pouze v dobrovolných narušeních v důsledku driftu, prázdnosti a konsolidace.

Expirace je způsob vynuceného narušení a není omezena limity četnosti rozpočtů narušení NodePool. Rozpočty přerušení podů (PDB) můžou i nadále řídit vyřazení podů na úrovni aplikace během vyprazdňování uzlů, pokud nenakonfigurujete terminationGracePeriod, což obchází soubory PDB a poznámku karpenter.sh/do-not-disrupt .

Chcete-li omezit narušení NAP na interval údržby, nastavte expireAfter: Never a spoléhejte na drift a konsolidaci řízené rozpočtem narušení.

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 jsou @yearly, @monthly, @weekly, @daily a @hourly. Plánování používá UTC a nepodporuje jiná časová pásma.
• 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ě.

Pokud vynecháte obě pole, rozpočet je vždy aktivní. Pokud definujete obě pole, rozpočet je aktivní od každého naplánovaného času zahájení po zadanou dobu trvání. Pokud je aktivní více rozpočtů, použije se nejvíce omezující rozpočet. Další informace viz rozpočty narušení NodePoolu Karpenter.

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 dobrovolné přerušení pouze o víkendech, od soboty v 00:00 UTC do pondělí v 00:00 UTC:

budgets:
- nodes: "50%"             # Always active
- nodes: "0"
  schedule: "0 0 * * 1"    # Monday at 00:00 UTC
  duration: 120h           # Block disruptions until Saturday at 00:00 UTC

Rozpočet nulového uzlu blokuje dobrovolné přerušení po všech pět pracovních dnů. O víkendech je aktivních pouze 50 % limitu narušení, takže až 50 % uzlů v poolu uzlů může být najednou vyřazeno z provozu, a to v závislosti na výpočtu limitu narušení popsaném výše. Nepoužívejte vždy aktivní rozpočet s nulovým počtem uzlů: blokovalo by to také víkendová přerušení.

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 anotace brání dobrovolnému narušení funkcí Consolidation a Drift. Nezabrání však narušení v důsledku vypršení platnosti, narušení způsobenému externími systémy ani ručnímu narušení prostřednictvím odstranění kubectl nebo NodePool.

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