Container Service for Kubernetes：FAQ penskalaan instan node

Batasan penyimpanan

Autoscaler tidak mengetahui batasan penyimpanan spesifik yang mungkin dimiliki oleh sebuah pod. Ini termasuk persyaratan seperti:

• Harus berjalan di Availability Zone tertentu untuk mengakses volume persisten (PV).

• Memerlukan node yang mendukung tipe disk tertentu (seperti ESSD).

Solusi: Konfigurasikan node pool khusus

Jika aplikasi Anda memiliki ketergantungan penyimpanan seperti ini, konfigurasikan node pool khusus untuknya sebelum mengaktifkan Auto Scaling pada pool tersebut.

Dengan menyetel terlebih dahulu Availability Zone, tipe instans, dan tipe disk dalam konfigurasi node pool, Anda memastikan bahwa setiap node yang baru disediakan akan memenuhi persyaratan pemasangan penyimpanan pod. Hal ini mencegah kegagalan penjadwalan dan error startup pod akibat ketidaksesuaian sumber daya.

Jenis resource apa saja yang dapat disimulasikan oleh node instant scaling?

Jenis resource berikut didukung untuk simulasi dan penentuan perilaku penskalaan.

cpu
memory
ephemeral-storage 
aliyun.com/gpu-mem # Hanya GPU bersama yang didukung.
nvidia.com/gpu

Apakah node instant scaling mendukung penyediaan tipe instans yang sesuai dari node pool berdasarkan permintaan resource pod?

Ya, ini adalah fitur yang didukung. Autoscaler secara cerdas memilih tipe instans yang paling efisien dalam penggunaan sumber daya dan biaya untuk memenuhi kebutuhan pod tersebut.

Sebagai contoh, pertimbangkan node pool yang dikonfigurasi dengan dua tipe instans: tipe yang lebih kecil 4 vCPU / 8 GiB dan tipe yang lebih besar 12 vCPU / 48 GiB.

• Jika sebuah pod meminta 2 vCPU, node instant scaling akan memprioritaskan penyediaan node baru 4 vCPU / 8 GiB untuk menjadwalkan pod tersebut.

• Jika Anda kemudian memperbarui konfigurasi node pool, mengganti tipe 4 vCPU / 8 GiB dengan tipe 8 vCPU / 16 GiB, node instant scaling akan secara otomatis menyesuaikan dan mulai menyediakan node 8 vCPU / 16 GiB untuk permintaan serupa di masa depan.

Jika node pool memiliki beberapa tipe instans, bagaimana node instant scaling memilih tipe instans yang akan disediakan?

Saat beberapa tipe instans dikonfigurasi dalam satu node pool, node instant scaling mengikuti logika pemilihan default berikut:

1. Filter berdasarkan ketersediaan: Secara berkala mengidentifikasi dan memfilter tipe instans yang saat ini mengalami kekurangan stok di wilayah tersebut.

2. Urutkan berdasarkan ukuran: Kemudian mengurutkan tipe instans yang tersedia berdasarkan jumlah core vCPU secara menaik.

3. Pilih kecocokan pertama: Mulai dari tipe instans terkecil, memeriksa satu per satu apakah dapat memenuhi permintaan sumber daya pod yang tidak dapat dijadwalkan. Tipe instans pertama dalam daftar terurut yang memenuhi persyaratan pod dipilih untuk disediakan. Node instant scaling tidak mengevaluasi tipe instans yang lebih besar setelah ditemukan kecocokan yang sesuai.

Saat menggunakan node instant scaling, bagaimana cara melacak ketersediaan tipe instans di node pool saya saat ini?

Node instant scaling menyediakan metrik kesehatan yang secara berkala memperbarui stok tipe instans di node pool dengan Auto Scaling yang diaktifkan. Ketika status stok tipe instans berubah, node instant scaling menghasilkan event Kubernetes bernama InstanceInventoryStatusChanged. Anda dapat memantau event ini untuk mengawasi kesehatan stok node pool Anda. Hal ini membantu Anda mengevaluasi apakah tipe instans yang Anda pilih tersedia secara andal dan memungkinkan Anda melakukan penyesuaian konfigurasi lebih awal. Untuk informasi lebih lanjut, lihat Lihat status kesehatan node instant scaling.

Bagaimana cara mengoptimalkan konfigurasi node pool untuk mencegah kegagalan scale-out akibat stok tidak mencukupi?

Pertimbangkan saran konfigurasi berikut untuk memperluas rentang tipe instans yang tersedia:

• Konfigurasikan beberapa tipe instans opsional untuk node pool, atau gunakan konfigurasi yang lebih umum.

• Konfigurasikan beberapa zona untuk node pool.

Mengapa node instant scaling gagal menambahkan node?

Periksa apakah kondisi berikut ada:

• Tipe instans yang dikonfigurasi untuk node pool memiliki stok tidak mencukupi.

• Tipe instans yang dikonfigurasi untuk node pool tidak dapat memenuhi permintaan sumber daya pod. Ukuran sumber daya tipe instans ECS adalah spesifikasi yang tercantum. Pertimbangkan pemesanan sumber daya berikut selama runtime.

  • Saat pembuatan instans, beberapa sumber daya dikonsumsi oleh virtualisasi dan OS. Untuk informasi lebih lanjut, lihat Mengapa instans yang dibeli memiliki ukuran memori yang berbeda dari ukuran memori yang didefinisikan dalam tipe instans?

  • Container Service for Kubernetes (ACK) memerlukan sejumlah sumber daya node untuk menjalankan add-on Kubernetes dan proses sistem, seperti kubelet, kube-proxy, Terway, dan container runtime. Lihat Kebijakan pemesanan sumber daya node untuk detailnya.

  • Secara default, add-on sistem diinstal pada node. Sumber daya yang diminta oleh pod harus kurang dari spesifikasi instans.

• Anda belum menyelesaikan otorisasi seperti yang dijelaskan dalam Aktifkan elastisitas instan untuk node.

• Node pool dengan Auto Scaling yang diaktifkan gagal melakukan scale-out instans.

Untuk memastikan akurasi penskalaan berikutnya dan stabilitas sistem, node instant scaling tidak melakukan operasi penskalaan hingga masalah pada node abnormal diselesaikan.

Bagaimana cara mengonfigurasi custom resource untuk node pool dengan node instant scaling yang diaktifkan?

Konfigurasikan tag ECS dengan awalan tetap berikut untuk node pool dengan node instant scaling yang diaktifkan. Hal ini memungkinkan add-on penskalaan mengidentifikasi custom resource yang tersedia di node pool atau nilai pasti dari resource tertentu.

goatscaler.io/node-template/resource/{resource-name}:{resource-size}

Contoh:

goatscaler.io/node-template/resource/hugepages-1Gi:2Gi

Mengapa node instant scaling gagal menghapus node?

Periksa keberadaan hal-hal berikut:

• Opsi untuk hanya melakukan scale-in pada node kosong diaktifkan, tetapi node yang diperiksa tidak kosong.

• Ambang batas permintaan sumber daya pod pada node lebih tinggi daripada ambang batas scale-in yang dikonfigurasi.

• Pod dari namespace kube-system sedang berjalan di node tersebut.

• Pod pada node memiliki kebijakan penjadwalan wajib yang mencegah node lain menjalankannya.

• Pod pada node memiliki PodDisruptionBudget, dan jumlah minimum pod yang tersedia telah tercapai.

• Jika node baru ditambahkan, node instant scaling tidak akan melakukan operasi scale-in pada node tersebut dalam waktu 10 menit.

• Ada node offline. Node offline adalah instans yang sedang berjalan tetapi tidak memiliki objek node yang sesuai. Add-on node instant scaling mendukung fitur pembersihan otomatis mulai versi 0.5.3 dan seterusnya. Untuk versi sebelumnya, Anda harus menghapus instans sisa tersebut secara manual.

  Versi 0.5.3 sedang dalam rilis canary. Untuk menggunakannya, kirim tiket dan minta akses.

  Lihat Add-on untuk melakukan upgrade.

  Pada halaman Node Pools, klik Sync Node Pool, lalu klik Details. Pada tab Nodes, periksa apakah ada node dalam status offline.

Jenis pod apa saja yang dapat mencegah node instant scaling menghapus node?

Jika sebuah pod tidak dibuat oleh controller Kubernetes native, seperti Deployment, ReplicaSet, Job, atau StatefulSet, atau jika pod pada suatu node tidak dapat dihentikan atau dimigrasikan secara aman, node instant scaling mungkin dicegah untuk menghapus node tersebut.

Bagaimana cara mengontrol perilaku scale-in node instant scaling berdasarkan pod?

Gunakan anotasi pod goatscaler.io/safe-to-evict untuk menentukan apakah pod tertentu harus mencegah node tempatnya berjalan di-scale-in oleh add-on node instant scaling.

• Untuk MENCEGAH node di-scale-in, tambahkan anotasi "goatscaler.io/safe-to-evict": "false" ke pod tersebut.

• Untuk MENGIZINKAN node di-scale-in, tambahkan anotasi "goatscaler.io/safe-to-evict": "true" ke pod tersebut.

Bagaimana cara menentukan node mana yang akan dihapus selama scale-in node instant scaling?

Tambahkan taint goatscaler.io/force-to-delete:true:NoSchedule ke node yang ingin Anda hapus. Setelah menambahkan taint ini, node instant scaling langsung menghapus node tersebut tanpa memeriksa status pod atau melakukan drain pod. Gunakan fitur ini dengan hati-hati karena dapat menyebabkan gangguan layanan atau kehilangan data.

Bagaimana cara mencegah node instant scaling menghapus node tertentu?

Gunakan anotasi node "goatscaler.io/scale-down-disabled": "true" pada node target untuk mencegahnya di-scale-in oleh add-on node instant scaling. Berikut adalah contoh perintah untuk menambahkan anotasi tersebut:

kubectl annotate node <nodename> goatscaler.io/scale-down-disabled=true

Dapatkah node instant scaling dikonfigurasi hanya untuk melakukan scale-in pada node kosong?

Ya, Anda dapat mengonfigurasi perilaku ini baik di tingkat node maupun tingkat kluster. Jika pengaturan dikonfigurasi di kedua tingkat, pengaturan tingkat node akan diutamakan.

• Konfigurasi tingkat node

  Tambahkan label ke node tertentu untuk mengontrol perilaku scale-in-nya.

  • Untuk mengaktifkan (hanya scale-in jika kosong): goatscaler.io/scale-down-only-empty:true

  • Untuk menonaktifkan (izinkan scale-in meskipun ada pod):goatscaler.io/scale-down-only-empty:false

• Konfigurasi tingkat kluster

  1. Di Konsol ACK, buka halaman Add-ons.

  2. Temukan add-on node instant scaling (ACK GOATScaler) dan ikuti petunjuk di layar untuk mengatur ScaleDownOnlyEmptyNodes menjadi true atau false.

Apakah add-on node instant scaling diperbarui secara otomatis?

Tidak. Kecuali untuk maintenance sistem secara keseluruhan atau upgrade platform utama, ACK tidak secara otomatis memperbarui add-on node instant scaling (ACK GOATScaler). Anda harus melakukan upgrade secara manual di halaman Add-ons di Konsol ACK.