Bagaimana Mode Otomatis EKS mengoptimalkan biaya Built-in kolam simpul dan pagar pembatas biaya Apa yang menghalangi konsolidasi Gunakan NodePool batas sebagai plafon biaya Kecualikan keluarga contoh untuk pengendalian biaya Pola yang direkomendasikan untuk beban kerja yang meledak Siklus hidup dan biaya node

Optimalisasi biaya dalam Mode Otomatis EKS

Mode Otomatis EKS terus mengoptimalkan biaya komputasi klaster Anda melalui konsolidasi, pengemasan sampah, dan ukuran yang tepat. Namun, konfigurasi beban kerja tertentu dapat mencegah pengoptimalan ini. Topik ini menjelaskan cara kerja pengoptimalan biaya, apa yang dapat memblokirnya, dan cara mengonfigurasi klaster Anda untuk mempertahankan efisiensi biaya.

Bagaimana Mode Otomatis EKS mengoptimalkan biaya

Mode Otomatis EKS mengurangi biaya komputasi melalui mekanisme berikut:

Bin-packing— Saat menjadwalkan pod ke node, Mode Otomatis EKS memilih jenis instance yang sangat cocok dengan permintaan sumber daya agregat, meminimalkan kapasitas yang tidak digunakan.
Konsolidasi — Mode Otomatis EKS secara berkala mengevaluasi node yang sedang berjalan dan mengganti atau menghapusnya saat beban kerja dapat berjalan pada instance yang lebih sedikit atau lebih murah.
Right-sizing— Saat beban kerja berkurang, Mode Otomatis EKS mengkonsolidasikan pod ke node yang lebih kecil dan menghentikan instance yang kurang dimanfaatkan.

Pengoptimalan ini berjalan terus menerus tanpa intervensi manual. Namun, anotasi dan NodePool konfigurasi pod tertentu dapat mencegah konsolidasi diterapkan.

Built-in kolam simpul dan pagar pembatas biaya

Kumpulan bawaan general-purpose dan system node sudah menerapkan beberapa default pelindung biaya:

Keluarga instans terbatas pada C, M, dan R — Tidak ada jenis instans yang dipercepat (P, G, Inf, Trn) atau eksotis yang diizinkan.
On-demand kapasitas saja — Tidak ada instans Spot, yang menghindari churn yang digerakkan oleh interupsi tetapi juga berarti tidak ada penghematan Spot.
Generasi 5 atau yang lebih baru - Generasi instans yang lebih tua dan hemat biaya tidak termasuk.

Jika Anda hanya menggunakan kumpulan node bawaan, Anda sudah mendapat manfaat dari pagar pembatas ini. Panduan dalam topik ini tentang mengecualikan keluarga instans dan membatasi ukuran instans paling relevan saat Anda membuat kustom NodePools, yang tidak mewarisi batasan ini.

Namun, bahkan dengan kumpulan node bawaan, bagian berikut masih berlaku untuk Anda:

Apa yang menghalangi konsolidasi— do-not-disrupt Anotasi dan PDB restriktif memblokir konsolidasi terlepas dari mana yang NodePool menyediakan node.
Gunakan NodePool batas sebagai plafon biaya— Kolam node bawaan tidak memiliki sumber daya yang limits dikonfigurasi. Jika beban kerja Anda dapat menskalakan secara signifikan, pertimbangkan untuk membuat kustom NodePool dengan batas daripada mengandalkan kumpulan bawaan yang tidak terbatas.
Siklus hidup dan biaya node— Tumpang tindih penggantian node berlaku untuk semua node, termasuk yang disediakan oleh kolam bawaan.

Pagar pembatas	Built-in kolam simpul	Kustom NodePools
Pengecualian instance yang dipercepat	Ditegakkan	Anda harus mengkonfigurasi
Batas ukuran instans	Tidak diatur	Anda harus mengkonfigurasi
Sumber daya `limits` (CPU/memory langit-langit)	Tidak diatur	Anda harus mengkonfigurasi
On-demand hanya	Ditegakkan	Anda memilih (Spot/On-Demand)
Perlindungan konsolidasi (`do-not-disrupt`/PDB)	Tanggung jawab Anda	Tanggung jawab Anda

Apa yang menghalangi konsolidasi

Konsolidasi diblokir ketika Mode Otomatis EKS menentukan bahwa mengganggu node akan melanggar persyaratan ketersediaan beban kerja. Konfigurasi berikut mencegah konsolidasi:

`Anotasi jangan ganggu`

karpenter.sh/do-not-disruptAnotasi menginstruksikan EKS Auto Mode untuk mempertahankan sebuah node selama pod beranotasi berjalan di atasnya. Ini mencegah node dikonsolidasikan, diganti, atau dihentikan, bahkan jika node kurang dimanfaatkan.


metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

penting

Implikasi biaya: Ketika sebuah pod membawa do-not-disrupt anotasi, node yang dijalankannya dibebaskan dari konsolidasi. Ini berarti:

Node terus berjalan pada ukuran instans saat ini terlepas dari pemanfaatan aktual.
VCPU dan penggunaan memori pada node itu dapat tetap meningkat bahkan saat permintaan beban kerja menurun.
Jika beberapa pod di banyak node membawa anotasi ini, konsolidasi seluruh cluster berkurang secara signifikan, yang mengarah ke biaya yang lebih tinggi.

do-not-disruptAnotasi adalah mekanisme ketersediaan. Itu tidak memperhitungkan biaya. Gunakan hanya untuk beban kerja di mana gangguan eksekusi tengah menyebabkan kehilangan data atau pengerjaan ulang yang signifikan — misalnya, pekerjaan batch yang berjalan lama atau proses stateful tanpa checkpointing.

Alternatif untuk dipertimbangkan:

Pod Disruption Budgets (PDBs) — Gunakan PDB untuk mengontrol tingkat gangguan daripada memblokirnya sepenuhnya. PDB memungkinkan konsolidasi untuk dilanjutkan sambil memastikan jumlah replika minimum tetap tersedia.
Shorter-lived beban kerja — Untuk CI/CD pelari dan agen build, izinkan gangguan dan andalkan logika coba ulang bawaan sistem CI Anda daripada menggunakan. do-not-disrupt
Time-limited anotasi — Terapkan do-not-disrupt hanya selama operasi kritis, lalu hapus secara terprogram saat operasi selesai.

Anggaran Gangguan Pod (PDB)

PDB yang menyetel maxUnavailable: 0 atau minAvailable sama dengan jumlah replika saat ini secara efektif memblokir semua konsolidasi untuk pod yang terpengaruh. Tinjau PDB Anda untuk memastikan bahwa mereka mengizinkan setidaknya satu pod terganggu pada satu waktu.

Gunakan NodePool batas sebagai plafon biaya

NodePool limitsmenetapkan batas atas total sumber daya komputasi yang disediakan oleh NodePool kaleng. Ketika batas tercapai, Mode Otomatis EKS berhenti meluncurkan node baru untuk itu NodePool. Ini terjadi bahkan jika pod tertunda.

Gunakan limits sebagai pagar pembatas biaya, terutama untuk NodePools yang melayani beban kerja non-produksi, pengujian, atau meledak di mana penskalaan tanpa batas tidak sesuai.


apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
  limits:
    cpu: "500"
    memory: 1000Gi

Dalam contoh ini, total ci-runners NodePool tidak boleh melebihi 500 vCPU atau 1000 GiB memori di semua node yang disediakannya. Pod yang melebihi batas ini tetap dalam Pending status sampai kapasitas dibebaskan.

Tip

Setel limits berdasarkan ukuran burst maksimum yang Anda harapkan ditambah buffer untuk penggantian node. Tinjau NodePool pemanfaatan Anda secara teratur dan sesuaikan batas saat pola beban kerja berubah.

Kecualikan keluarga contoh untuk pengendalian biaya

Secara default, Mode Otomatis EKS memilih dari berbagai jenis instans untuk memaksimalkan fleksibilitas penjadwalan. Untuk beban kerja yang tidak memerlukan perangkat keras khusus, batasi keluarga instance untuk mencegah jenis instans yang mahal diluncurkan.

Kecualikan instance yang dipercepat

Jika beban kerja Anda tidak meminta sumber daya GPU atau akselerator, kecualikan keluarga instans yang dipercepat dari Anda. NodePool Ini mencegah skenario di mana instance yang dipercepat dipilih selama kendala kapasitas.


spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]

Dengan hanya menentukan kategori yang dioptimalkan untuk komputasi, tujuan umum, dan dioptimalkan memori, Anda mengecualikan akselerasi (P, G, Inf, Trn) dan keluarga instans khusus lainnya dari seleksi.

Bagaimana pemilihan instance berinteraksi dengan kendala kapasitas

Mode Otomatis EKS tidak memprioritaskan tipe instans yang dipercepat dan eksotis selama pemilihan instans normal. Namun, ketika kegagalan peluncuran berkelanjutan terjadi, Mode Otomatis EKS akan diluncurkan dari jenis instans yang tersisa yang tersedia untuk memprioritaskan ketersediaan beban kerja. Misalnya, ini terjadi ketika kuota layanan EC2 habis sementara untuk semua jenis instans pilihan.

Untuk mencegah perilaku fallback ini, batasi NodePool persyaratan Anda secara eksplisit hanya pada kategori instance yang dibutuhkan beban kerja Anda. Ketika tipe pilihan tidak tersedia dan tidak ada tipe lain yang diizinkan oleh NodePool konfigurasi Anda, pod tetap dalam Pending status daripada dijadwalkan ke instance yang mahal.

Membatasi ukuran instance

Selain membatasi keluarga instans, Anda dapat membatasi ukuran instans maksimum di dalam. NodePool Membatasi ukuran instans membatasi eksposur biaya dari setiap node tunggal yang tidak dapat dikonsolidasikan. Misalnya, node yang diblokir oleh do-not-disrupt anotasi tidak dapat menyusut meskipun beban kerjanya kecil.

Gunakan eks.amazonaws.com/instance-cpu label untuk membatasi ukuran instans maksimum dalam NodePool kebutuhan Anda:


requirements:
  - key: "eks.amazonaws.com/instance-cpu"
    operator: Lte
    values: ["32"]

Konfigurasi ini mencegah Mode Otomatis EKS meluncurkan instance yang lebih besar dari 32 vCPU dalam hal ini. NodePool

Untuk mengidentifikasi peluang pengoptimalan di klaster yang ada, tinjau instance berjalan terbesar Anda. Jika node besar secara konsisten diblokir dari konsolidasi, biaya per node dari kapasitas idle tersebut secara proporsional lebih tinggi.

Pola yang direkomendasikan untuk beban kerja yang meledak

CI/CD jaringan pipa, pekerjaan batch, dan pelari sementara menciptakan pola burst-and-idle yang memerlukan konfigurasi khusus untuk mempertahankan efisiensi biaya.

Default yang direkomendasikan untuk beban kerja yang meledak

Konfigurasi	Rekomendasi
`do-not-disrupt`	Jangan gunakan untuk CI/CD pelari. Andalkan mekanisme coba ulang dan antrian sistem CI Anda sebagai gantinya.
NodePool `limits`	Tetapkan CPU/memory plafon berdasarkan konkurensi maksimum yang diharapkan ditambah buffer untuk tumpang tindih penggantian node.
Kategori contoh	Batasi untuk `c` dan `m` keluarga. Kecualikan keluarga instans yang dipercepat (P, G, Inf, Trn) untuk beban kerja non-GPU.
Ukuran instans	Pertimbangkan untuk membatasi ukuran sedang (misalnya, 4-32 vCPU) untuk membatasi eksposur biaya dari setiap node tunggal yang diblokir dari konsolidasi.
Waktu konsolidasi	Gunakan `consolidateAfter` pengaturan default. Hindari pengaturan penundaan lama yang menjaga kapasitas burst online setelah pelari selesai.
Jenis kapasitas	Gunakan instance Spot untuk pelari yang toleran terhadap kesalahan. Kombinasikan dengan On-Demand untuk agen build yang memegang status selama eksekusi.

Contoh: CI runner NodePool


apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: Lte
          values: ["32"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
  limits:
    cpu: "500"
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Konfigurasi ini:

Membatasi keluarga contoh yang hemat biaya
Membatasi NodePool kapasitas total pada 500 vCPU
Memungkinkan konsolidasi agresif (30 detik setelah pod dihapus)
Memungkinkan Spot dan kapasitas On-Demand

Siklus hidup dan biaya node

Mode Otomatis EKS menggantikan node melalui gangguan anggun ketika mereka melayang dari spesifikasi yang diinginkan (misalnya, setelah rilis AMI Mode Otomatis baru) atau ketika masa pakai node mendekati kedaluwarsa. Selama penggantian anggun:

Node pengganti baru diluncurkan dan menjadi siap.
Pod terkuras dari node lama, dengan memperhatikan Anggaran Gangguan Pod.
Untuk waktu yang singkat, baik node lama dan pengganti berjalan secara bersamaan.

Untuk cluster dengan node besar atau banyak, tumpang tindih ini dapat membuat kenaikan biaya berkala. Untuk meminimalkan dampak:

Tinjau anggaran gangguan — Pastikan anggaran gangguan Anda memungkinkan pengeringan tepat waktu. Anggaran terbatas memperpanjang periode tumpang tindih di mana node lama dan baru berjalan.
Right-size contoh — Instans yang lebih kecil mengurangi biaya absolut jendela tumpang tindih.
Kurangi masa pakai node maksimum - Nilai kedaluwarsa yang lebih pendek (misalnya, 7 hari) membuat peristiwa penggantian yang lebih sering tetapi lebih kecil. Ini menyebarkan biaya lebih merata dari waktu ke waktu daripada memusatkannya.

Untuk informasi selengkapnya tentang siklus hidup node, lihat Pelajari tentang instans Terkelola Mode Otomatis Amazon EKS.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Keamanan tingkat lanjut

Cara kerjanya