Bagikan melalui

Mengonfigurasi kebijakan gangguan simpul untuk simpul provisi otomatis (NAP) di Azure Kubernetes Service (AKS)

Artikel ini menjelaskan cara mengonfigurasi kebijakan gangguan simpul untuk simpul provisi otomatis (NAP) simpul Azure Kubernetes Service (AKS) dan merinci cara kerja gangguan untuk mengoptimalkan pemanfaatan sumber daya dan efisiensi biaya.

NAP mengoptimalkan kluster Anda dengan:

  • Menghapus atau mengganti node yang kurang digunakan.
  • Mengonsolidasikan beban kerja untuk mengurangi biaya.
  • Menghormati anggaran untuk gangguan dan waktu pemeliharaan.
  • Menyediakan kontrol manual saat diperlukan.

Sebelum Anda mulai

Bagaimana cara kerja gangguan node untuk simpul NAP?

Karpenter menetapkan finalizer Kubernetes pada setiap simpul dan node mengklaim provisinya. Finalizer memblokir penghapusan objek simpul, sementara Pengontrol Penghentian menandai dan mengosongkan simpul sebelum menghapus klaim simpul yang terkait.

Ketika beban kerja pada node Anda menurun skalanya, NAP menggunakan aturan disrupsi pada spesifikasi kumpulan simpul untuk memutuskan kapan simpul-simpul tersebut harus dihapus dan bagaimana caranya, yang berpotensi untuk menjadwalkan ulang beban kerja Anda demi efisiensi.

Metode gangguan node

NAP secara otomatis menemukan node yang rentan terhadap gangguan dan mengaktifkan penggantian saat diperlukan. Anda dapat memicu gangguan melalui metode otomatis seperti Kedaluwarsa, Konsolidasi, dan Penyimpangan, metode manual, atau sistem eksternal.

kedaluwarsa

Kedaluwarsa memungkinkan Anda menetapkan usia maksimum untuk node NAP Anda. Simpul ditandai sebagai kedaluwarsa dan terputus setelah mencapai usia yang Anda tentukan untuk nilai pool simpul spec.disruption.expireAfter.

Contoh konfigurasi kedaluwarsa

Contoh berikut menunjukkan cara mengatur waktu kedaluwarsa untuk simpul NAP menjadi 24 jam:

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

Consolidation

NAP bekerja untuk secara aktif mengurangi biaya kluster dengan mengidentifikasi kapan simpul dapat dihapus karena kosong atau kurang digunakan, atau ketika node dapat diganti dengan varian harga yang lebih rendah. Proses ini disebut Konsolidasi. NAP terutama menggunakan Konsolidasi untuk menghapus atau mengganti simpul untuk penempatan pod yang optimal.

NAP melakukan jenis konsolidasi berikut untuk mengoptimalkan pemanfaatan sumber daya:

  • Konsolidasi simpul kosong: Menghapus simpul kosong secara paralel.
  • Konsolidasi multi-node: Menghapus beberapa node, mungkin meluncurkan penggantian tunggal.
  • Konsolidasi simpul tunggal: Menghapus simpul tunggal dan mungkin meluncurkan penggantinya.

Anda dapat memicu konsolidasi melalui spec.disruption.consolidationPolicy bidang dalam spesifikasi kumpulan simpul menggunakan WhenEmpty, atau pengaturan WhenEmptyOrUnderUtilized. Anda juga dapat mengatur kolom consolidateAfter, yang merupakan kondisi berbasis waktu yang menentukan berapa lama NAP menunggu setelah menemukan peluang konsolidasi, sebelum akhirnya mengganggu simpul.

Contoh konfigurasi konsolidasi

Contoh berikut menunjukkan cara mengonfigurasi NAP untuk mengonsolidasikan simpul saat kosong, dan menunggu 30 detik setelah menemukan kesempatan konsolidasi sebelum mengganggu simpul:

  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

Hanyut

Drift menangani perubahan pada sumber daya NodePool/AKSNodeClass. Nilai dalam NodeClaimTemplateSpec/AKSNodeClassSpec tercermin dengan cara yang sama seperti yang ditetapkan. NodeClaim terdeteksi sebagai melenceng jika nilai dalam NodePool/AKSNodeClass terkait tidak cocok dengan nilai dalam NodeClaim. Mirip dengan hubungan upstream deployment.spec.template dengan pod, Karpenter memberikan anotasi pada NodePool/AKSNodeClass dengan hash dari NodeClaimTemplateSpec untuk memeriksa pergeseran. Karpenter menghapus Drifted kondisi status dalam skenario berikut:

  • Gerbang fitur Drift tidak diaktifkan tetapi NodeClaim telah mengalami drift.
  • NodeClaim tidak mengalami pergeseran, tetapi memiliki kondisi status.

Karpenter atau antarmuka penyedia cloud mungkin menemukan kasus khusus yang dipicu oleh NodeClaim/Instance/NodePool/AKSNodeClassperubahan.

Kasus khusus dalam penyimpangan

Dalam kasus khusus, penyimpangan dapat sesuai dengan beberapa nilai dan harus ditangani secara berbeda. Penyimpangan pada bidang yang diselesaikan dapat membuat kasus di mana penyimpangan terjadi tanpa perubahan pada Definisi Sumber Daya Kustom (CRD), atau di mana perubahan CRD tidak mengakibatkan penyimpangan.

Misalnya, jika NodeClaim memiliki node.kubernetes.io/instance-type: Standard_D2s_v3 dan persyaratan berubah dari node.kubernetes.io/instance-type In [Standard_D2s_v3] ke node.kubernetes.io/instance-type In [Standard_D2s_v3, Standard_D4s_v3], NodeClaim tidak berubah karena nilainya masih cocok dengan persyaratan baru. Sebaliknya, jika NodeClaim menggunakan NodeClaimimageFamily, tetapi kolom spec.imageFamily berubah, Karpenter mengidentifikasi NodeClaim sebagai tergeser dan mengubah simpul untuk memenuhi spesifikasi tersebut.

Penting

Karpenter memantau perubahan konfigurasi subnet dan mendeteksi penyimpangan saat vnetSubnetID dimodifikasi dalam AKSNodeClass. Memahami perilaku ini sangat penting saat mengelola konfigurasi jaringan kustom. Untuk informasi selengkapnya, lihat Perilaku penyimpangan subnet.

Untuk informasi selengkapnya, lihat Drift Design.

Masa tenggang penghentian

Anda dapat mengatur masa tenggang penghentian untuk simpul NAP menggunakan spec.template.spec.terminationGracePeriod bidang dalam spesifikasi kumpulan simpul. Pengaturan ini memungkinkan Anda untuk mengonfigurasi berapa lama Karpenter menunggu sebelum pod diakhiri secara lembut. Pengaturan ini memiliki prioritas lebih tinggi daripada terminationGracePeriodSeconds pada pod dan mengabaikan PodDisruptionBudgets serta anotasi karpenter.sh/do-not-disrupt.

Contoh konfigurasi masa tenggang penghentian

Contoh berikut menunjukkan cara mengatur masa tenggang penghentian 30 detik untuk simpul NAP:

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

Anggaran disrupsi

Anda dapat membatasi gangguan Karpenter dengan memodifikasi spec.disruption.budgets bidang dalam spesifikasi kumpulan simpul. Jika Anda membiarkan pengaturan ini tidak terdefinisi, Karpenter akan menggunakan satu anggaran secara default dengan nodes: 10%. Anggaran memperhitungkan simpul yang mungkin dihapus karena alasan apa pun, dan mereka hanya memblokir Karpenter dari gangguan yang dilakukan secara sukarela melalui kedaluarsa, pergeseran, kekosongan, dan konsolidasi.

Saat menghitung apakah anggaran memblokir simpul dari gangguan, Karpenter menghitung total simpul yang dimiliki oleh kumpulan simpul dan kemudian mengurangi simpul yang sedang dihapus dan simpul yang adalah NotReady. Jika anggaran dikonfigurasi dengan nilai persentase, seperti 20%, Karpenter menghitung jumlah gangguan yang diizinkan sebagai allowed_disruptions = roundup(total * percentage) - total_deleting - total_notready. Untuk beberapa anggaran dalam kumpulan simpul, Karpenter mengambil nilai minimum (paling ketat) dari setiap anggaran.

Bidang jadwal dan durasi

Saat menggunakan anggaran, Anda dapat secara opsional mengatur schedule bidang dan duration untuk membuat anggaran berbasis waktu. Bidang-bidang ini memungkinkan Anda menentukan jendela pemeliharaan atau jangka waktu tertentu ketika batas gangguan lebih ketat.

  • Jadwal menggunakan sintaks pekerjaan cron dengan makro khusus seperti @yearly, , @monthly@weekly, @daily. @hourly
  • Durasi memungkinkan durasi senyawa seperti 10h5m, , 30matau 160h. Durasi dan Jadwal harus didefinisikan bersama-sama.

Contoh jadwal dan durasi

Anggaran jadwal pemeliharaan

Mencegah gangguan selama jam kerja:

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

Hanya izinkan gangguan pada akhir pekan:

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

Perbolehkan peningkatan tingkat gangguan:

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

Contoh konfigurasi anggaran

Spesifikasi berikut NodePool memiliki tiga anggaran yang dikonfigurasikan:

  • Pengaturan pertama memungkinkan 20% simpul yang berada dalam kumpulan simpul terhenti operasinya sekaligus.
  • Anggaran kedua bertindak sebagai plafon, hanya memungkinkan lima gangguan ketika terdapat lebih dari 25 simpul.
  • Anggaran terakhir memblokir gangguan selama 10 menit pertama setiap hari.
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

Gangguan simpul manual

Anda dapat mengganggu simpul NAP secara manual menggunakan kubectl atau dengan menghapus NodePool sumber daya.

Menghapus simpul dengan kubectl

Anda dapat menghapus simpul secara manual menggunakan kubectl delete node perintah . Anda dapat menghapus simpul tertentu, semua simpul yang dikelola NAP, atau simpul dari kumpulan simpul tertentu dengan menggunakan label, misalnya:

# 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

Menghapus NodePool sumber daya

NodePool memiliki NodeClaims melalui referensi pemilik. NAP dengan anggun mengakhiri simpul melalui penghapusan berjenjang saat Anda menghapus yang terkait NodePool.

Mengontrol gangguan menggunakan anotasi

Anda dapat memblokir atau menonaktifkan gangguan untuk pod, simpul, atau seluruh kumpulan simpul tertentu menggunakan anotasi.

Kontrol pod

Blokir NAP agar tidak mengganggu pod tertentu dengan mengatur anotasi karpenter.sh/do-not-disrupt: "true".

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

Anotasi ini mencegah gangguan yang tidak disengaja untuk kedaluwarsa, konsolidasi, dan penyimpangan. Namun, itu tidak mencegah gangguan dari sistem eksternal atau gangguan manual melalui kubectl atau NodePool penghapusan.

Kontrol node

Blokir NAP agar tidak mengganggu simpul jaringan tertentu:

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

Kontrol kumpulan simpul

Nonaktifkan gangguan untuk semua simpul dalam NodePool:

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

Langkah selanjutnya

Untuk informasi selengkapnya tentang node auto-provisioning di AKS, lihat artikel berikut ini:

  • Last updated on