Azure Kubernetes Service'te (AKS) düğüm otomatik sağlama (NAP) düğümleri için düğüm kesintisi ilkelerini yapılandırma

Bu makalede, Azure Kubernetes Service (AKS) düğümü otomatik sağlama (NAP) düğümleri için düğüm kesintisi ilkelerinin nasıl yapılandırılması açıklanır ve kesintinin kaynak kullanımını ve maliyet verimliliğini iyileştirmek için nasıl çalıştığı açıklanır.

NAP, kümenizi şu şekilde iyileştirir:

• Az kullanılan düğümleri kaldırma veya değiştirme.
• Maliyetleri azaltmak için iş yüklerini birleştirme.
• Kesinti bütçelerine ve bakım pencerelerine saygı duyma.
• Gerektiğinde el ile denetim sağlama.

Başlamadan önce

• NAP'nin nasıl çalıştığını ayrıntılarıyla açıklayan AKS'de düğüm otomatik sağlamaya (NAP) genel bakış makalesini okuyun.
• Azure Kubernetes Service'te (AKS) düğüm otomatik sağlama (NAP) için ağ yapılandırmalarına genel bakış'ı okuyun.

NAP düğümlerinde düğüm kesintisi nasıl işler?

Karpenter, sağladığı her düğüm ve düğüm talebine bir Kubernetes sonlandırıcısı ayarlar. Sonlandırıcı, düğüm nesnesinin silinmesini engellerken, Sonlandırma Denetleyicisi düğümü taint'leyip boşaltır ve ardından temel düğüm talebini kaldırır.

Düğümlerinizdeki iş yükleri ölçeği azaltıldığında NAP, düğüm havuzu belirtiminde kesinti kurallarını kullanarak bu düğümlerin ne zaman ve nasıl kaldırılacağına karar verir ve iş yüklerinizi verimlilik için yeniden zamanlayabilir.

Düğüm kesintisi yöntemleri

NAP, kesintiye uygun düğümleri otomatik olarak tespit eder ve gerektiğinde yedekleri devreye sokar. Süre Sonu, Birleştirme ve Kayma gibi otomatik yöntemler, el ile yöntemler veya dış sistemler aracılığıyla kesintiyi tetikleyebilirsiniz.

Süre Sonu

Son kullanma tarihi, NAP düğümlerinizin azami yaşını ayarlamanıza olanak tanır. Düğümler süresi doldu olarak işaretlenir ve düğüm havuzunun spec.disruption.expireAfter değeri için belirttiğiniz yaşa ulaşıldıktan sonra kesintiye uğrar.

Örnek süre sonu yapılandırması

Aşağıdaki örnekte NAP düğümleri için süre sonunun 24 saat olarak nasıl ayarlanacağı gösterilmektedir:

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

Consolidation

NAP, düğümlerin ne zaman boş veya az kullanıldığından kaldırılabildiğini ya da düğümlerin ne zaman daha düşük fiyatlı çeşitlerle değiştirilebileceğini belirleyerek küme maliyetini etkin bir şekilde azaltmaya çalışır. Bu işleme Birleştirme adı verilir. NAP, en iyi pod yerleşimi için düğümleri silmek veya değiştirmek için öncelikle Birleştirme'yi kullanır.

NAP, kaynak kullanımını iyileştirmek için aşağıdaki birleştirme türlerini gerçekleştirir:

• Boş düğüm birleştirme: Boş düğümleri paralel olarak siler.
• Çok düğümlü birleştirme: Birden çok düğümü silip muhtemelen tek bir değiştirme başlatır.
• Tek düğüm konsolidasyonu: Tek bir düğümü siler ve muhtemelen bir değiştirme başlatır.

Düğüm havuzu belirtimindeki spec.disruption.consolidationPolicy alanı aracılığıyla, WhenEmpty veya WhenEmptyOrUnderUtilized ayarlarını kullanarak birleştirmeyi tetikleyebilirsiniz. Ayrıca, NAP'nin birleştirme fırsatını keşfettikten sonra düğümde kesinti yapmadan önce ne kadar süre bekleyeceğini belirleyen zamana dayalı bir koşul olan consolidateAfter alanını da ayarlayabilirsiniz.

Örnek birleştirme yapılandırması

Aşağıdaki örnekte NAP'nin düğümler boş olduğunda birleştirilecek şekilde nasıl yapılandırılması ve düğümü kesintiye uğratmadan önce birleştirme fırsatı keşfedildikten sonra 30 saniye beklemesi gösterilmektedir:

  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

Sürüklenme

Kayma, kaynaklarda yapılan değişiklikleri NodePool/AKSNodeClass ele alır. içindeki NodeClaimTemplateSpec/AKSNodeClassSpec değerler, ayarlandıkları şekilde yansıtılır. İlişkili NodeClaim içindeki değerler NodePool/AKSNodeClass değerleriyle eşleşmiyorsa, NodeClaim sapmış olarak tespit edilir. Karpenter, podlarla yukarı akış deployment.spec.template bağıntısına benzer şekilde, sapmayı kontrol etmek için NodePool karmasıyla ilişkili /AKSNodeClassNodeClaimTemplateSpec öğesine ek açıklama ekler. Karpenter, aşağıdaki senaryolarda durum koşulunu kaldırır Drifted :

• Özellik Drift kontrol mekanizması etkinleştirilmemiş ancak NodeClaim kayma göstermiş.
• NodeClaim sürüklenmemiştir, ancak durum koşuluna sahiptir.

Karpenter veya bulut sağlayıcısı arabirimi, değişiklikler tarafındanNodeClaim/Instance/NodePool/tetiklenen AKSNodeClass bulabilir.

Sürüklenmede özel durumlar

Özel durumlarda, kayma birden çok değere karşılık gelebilir ve farklı şekilde işlenmesi gerekir. Çözümlenen alanlardaki kayma, Özel Kaynak Tanımlarında (CRD) değişiklik yapılmadan kaymanın gerçekleştiği veya CRD değişikliklerinin kaymayla sonuçlanmadığı durumlar oluşturabilir.

Örneğin, bir NodeClaim değeri varsa node.kubernetes.io/instance-type: Standard_D2s_v3 ve gereksinimler node.kubernetes.io/instance-type In [Standard_D2s_v3]'den node.kubernetes.io/instance-type In [Standard_D2s_v3, Standard_D4s_v3]'e değiştiğinde, NodeClaim değeri yeni gereksinimlerle hala uyumludur, bu yüzden değişiklik göstermez. Buna karşılık, bir NodeClaim bir NodeClaimimageFamily kullanır, ancak spec.imageFamily alanı değişirse, Karpenter NodeClaim'i kaymış olarak algılar ve düğümü bu belirtime uygun hale getirmek için döndürür.

Önemli

Karpenter, alt ağ yapılandırma değişikliklerini izler ve bir AKSNodeClass içindeki vnetSubnetID değiştirildiğinde sapmayı algılar. Özel ağ yapılandırmalarını yönetirken bu davranışı anlamak kritik önem taşır. Daha fazla bilgi için bkz . Alt ağ kayma davranışı.

Daha fazla bilgi için bkz Drift Design.

Fesih için ek süre

Düğüm havuzu belirtimindeki spec.template.spec.terminationGracePeriod alanını kullanarak NAP düğümleri için sonlandırma için müsaade edilen süreyi ayarlayabilirsiniz. Bu ayar, Karpenter'ın podların düzgün bir şekilde sonlandırılmasını ne kadar bekleyeceğini yapılandırmanıza olanak tanır. Bu ayar bir pod'un terminationGracePeriodSeconds ayarından üstündür ve PodDisruptionBudgets ve karpenter.sh/do-not-disrupt ek açıklamayı geçersiz kılar.

Örnek sonlandırma ek süre yapılandırması

Aşağıdaki örnek, NAP düğümleri için 30 saniyelik bir sonlandırma geçiş süresinin nasıl ayarlanacağını göstermektedir.

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

Kesinti bütçeleri

Düğüm havuzu belirtimindeki spec.disruption.budgets alanını değiştirerek Karpenter kesintisini sınırlandırabilirsiniz. Bu ayarı tanımsız bırakırsanız, Karpenter varsayılan olarak ile nodes: 10%bir bütçeye sahip olur. Bütçeler herhangi bir nedenle silinen düğümleri dikkate alır ve Karpenter'ın yalnızca süre sonu, kayma, boşluk ve birleştirme yoluyla gönüllü kesintilere uğramasını engeller.

Bütçenin düğümlerin kesintiye uğramasını engelleyip engellemediğini hesaplarken Karpenter, düğüm havuzuna ait toplam düğümleri sayar ve ardından silinen düğümleri ve olan NotReadydüğümleri çıkarır. Bütçe gibi 20%bir yüzde değeriyle yapılandırılmışsa, Karpenter izin verilen kesintilerin sayısını olarak allowed_disruptions = roundup(total * percentage) - total_deleting - total_notreadyhesaplar. Düğüm havuzundaki birden çok bütçe için Karpenter, bütçelerin her birinin en düşük (en kısıtlayıcı) değerini alır.

Zamanlama ve süre alanları

Bütçeleri kullanırken, isteğe bağlı olarak schedule ve duration alanlarını ayarlayarak zaman tabanlı bütçeler oluşturabilirsiniz. Bu alanlar, kesinti sınırları daha katı olduğunda bakım pencereleri veya belirli zaman çerçeveleri tanımlamanızı sağlar.

• Schedule, @yearly, @monthly, @weekly, @daily, @hourly gibi özel makrolarla cron işlevi söz dizimini kullanır.
• Süre, , 10h5mveya 30mgibi 160hbileşik sürelere izin verir. Süre ve Zamanlama birlikte tanımlanmalıdır.

Zamanlama ve süre örnekleri

Bakım penceresi bütçesi

İş saatleri içinde kesintileri önleyin:

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

Yalnızca hafta sonu kesintileri

Yalnızca hafta sonları kesintilere izin verin:

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

Aşamalı dağıtım bütçesi

Kesinti oranlarını artırmaya izin ver:

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

Bütçe yapılandırma örnekleri

Aşağıdaki NodePool belirtimi, üç bütçeyle yapılandırılmıştır.

• İlk bütçe, düğüm havuzuna ait 20% düğümün aynı anda kesintiye uğramasını sağlar.
• İkinci bütçe bir tavan görevi görür ve yalnızca 25'ten fazla düğüm olduğunda beş kesintiye izin verir.
• Son bütçe, her günün ilk 10 dakikası boyunca kesintileri engeller.

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

Manuel düğüm kesintisi

kubectl veya NodePool kaynaklarını silerek NAP düğümlerini manuel olarak kesintiye uğratabilirsiniz.

kubectl ile düğümleri kaldırma

komutunu kullanarak kubectl delete node düğümleri el ile kaldırabilirsiniz. Etiketleri kullanarak belirli düğümleri, NAP ile yönetilen tüm düğümleri veya belirli bir düğüm havuzundan düğümleri silebilirsiniz, örneğin:

# 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

Kaynakları silme NodePool

NodePool, bir sahip referansı aracılığıyla NodeClaims 'e sahiptir. NAP, ilişkili NodePoolöğesini sildiğinizde basamaklı silme yoluyla düğümleri düzgün bir şekilde sonlandırır.

Ek açıklamaları kullanarak kesintiyi denetleme

Ek açıklamaları kullanarak belirli podlar, düğümler veya tüm düğüm havuzları için kesintiyi engelleyebilir veya devre dışı bırakabilirsiniz.

Pod denetimleri

NAP'nin belirli podları kesintiye uğratmasını engellemek için karpenter.sh/do-not-disrupt: "true" açıklamasını ayarlayın.

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

Bu ek açıklama Süre Sonu, Konsolidasyon ve Kayma için gönüllü kesintiyi önler. Ancak, dış sistemlerden kaynaklanan kesintileri veya kubectlNodePool silinmesi yoluyla el ile kesintileri engellemez.

Düğüm kontrolleri

NAP'nin belirli düğümleri kesintiye uğratmasını engelle:

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

Düğüm havuzu kontrolleri

NodePool içindeki tüm düğümler için kesintileri devre dışı bırakın.

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

Sonraki Adımlar

AKS'de düğüm otomatik sağlama hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• AKS'de otomatik düğüm provizyonu için ağı yapılandırma
• AKS'de düğüm otomatik sağlama için düğüm havuzlarını yapılandırma
• AKS'de özel bir sanal ağda otomatik düğüm sağlama kümesi oluşturma