Container Service for Kubernetes:FAQ penskalaan instan node

Kendala penyimpanan tidak terlihat oleh autoscaler

Autoscaler tidak mengetahui kendala penyimpanan tingkat pod, seperti:

• Harus berjalan di zona ketersediaan tertentu untuk mengakses persistent volume (PV).

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

Solusi: Konfigurasikan kelompok node khusus untuk aplikasi yang memiliki ketergantungan penyimpanan sebelum mengaktifkan Auto Scaling. Tetapkan zona ketersediaan, tipe instans, dan tipe disk dalam konfigurasi kelompok node untuk memastikan node baru yang disediakan memenuhi persyaratan penyimpanan pod.

Pastikan juga pod Anda tidak mereferensikan PVC dalam status Terminating. Pod yang tidak dapat dijadwalkan karena PVC-nya sedang terminating akan terus-menerus gagal, yang dapat menyebabkan cluster-autoscaler membuat keputusan scale-out atau scale-in yang salah (misalnya, mengeluarkan pod tersebut).

Jenis sumber daya apa saja yang dapat dievaluasi oleh node instant scaling?

Simulasi penskalaan menggunakan jenis sumber daya berikut:

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

Node instant scaling: Apakah mendukung scale-out tipe instans yang sesuai dalam kelompok node berdasarkan permintaan sumber daya Pod?

Ya. Autoscaler secara cerdas memilih tipe instans yang paling efisien dalam penggunaan sumber daya dan dapat memenuhi kebutuhan pod. Misalnya, pertimbangkan kelompok node yang dikonfigurasi dengan dua tipe instans: tipe kecil 4-core, 8 GB dan tipe besar 12-core, 48 GB. Jika sebuah pod meminta 2 core, node instant scaling memprioritaskan pembuatan node 4-core, 8 GB untuk pod tersebut. Jika Anda kemudian mengganti tipe 4-core, 8 GB dengan tipe 8-core, 16 GB, node instant scaling secara otomatis menyesuaikan dan menempatkan pod baru dengan permintaan serupa pada node 8-core, 16 GB.

Bagaimana node instant scaling memilih tipe instans secara default ketika kelompok node berisi beberapa tipe instans?

Berdasarkan tipe instans yang dikonfigurasi untuk kelompok node, node instant scaling secara berkala mengecualikan tipe instans dengan inventaris tidak mencukupi, lalu mengurutkan tipe instans yang tersisa berdasarkan jumlah core CPU, dan memeriksanya satu per satu untuk menentukan apakah tipe tersebut dapat memenuhi permintaan sumber daya pod yang tidak dapat dijadwalkan. Begitu tipe instans yang sesuai ditemukan, node instant scaling memilih tipe instans tersebut dan menghentikan pemeriksaan terhadap tipe lainnya.

Bagaimana cara melacak perubahan real-time inventaris tipe instans dalam kelompok node saat menggunakan Node Instant Scaling?

Node instant scaling menyediakan metrik kesehatan yang diperbarui secara berkala untuk mencerminkan perubahan inventaris tipe instans dalam kelompok node auto-scaling. Ketika status inventaris tipe instans berubah, node instant scaling mengirim event Kubernetes bernama InstanceInventoryStatusChanged. Anda dapat berlangganan event ini untuk memantau kesehatan inventaris kelompok node, menilai apakah inventaris saat ini mencukupi, dan menyesuaikan konfigurasi tipe instans Anda lebih awal. Untuk informasi lebih lanjut, lihat Lihat status kesehatan node instant scaling.

Mencegah kegagalan scale-out

Kami menyarankan Anda menggunakan konfigurasi berikut untuk memperluas rentang tipe instans yang tersedia:

• Konfigurasikan beberapa tipe instans untuk kelompok node atau gunakan konfigurasi generik.

• Konfigurasikan beberapa zona untuk kelompok node.

Mengapa node instant scaling gagal meluncurkan node?

Periksa masalah berikut:

• Tipe instans yang dikonfigurasi untuk kelompok node memiliki inventaris tidak mencukupi.

• Tipe instans yang dikonfigurasi untuk kelompok node tidak dapat memenuhi permintaan sumber daya pod. Spesifikasi yang diiklankan untuk tipe instans ECS berbeda dari sumber daya aktual yang tersedia setelah penyediaan. Cadangan sumber daya berikut harus dipertimbangkan saat runtime:

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

  • ACK memerlukan sejumlah sumber daya node tertentu untuk menjalankan add-on Kubernetes dan proses sistem, seperti kubelet, kube-proxy, Terway, dan container runtime. Untuk informasi lebih lanjut tentang kebijakan cadangan, lihat Kebijakan cadangan sumber daya node.

  • 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.

• Kelompok node gagal melakukan scale-out instans baru karena masalah infrastruktur mendasar.

Untuk memastikan akurasi operasi penskalaan berikutnya dan stabilitas sistem, add-on node instant scaling menjeda operasi penskalaan hingga Anda menyelesaikan masalah pada node abnormal.

Cara mengonfigurasi resource kustom untuk kelompok node yang telah mengaktifkan node instant scaling?

Anda dapat mengonfigurasi kelompok node yang diaktifkan node instant scaling dengan tag ECS yang memiliki awalan tetap. Hal ini memungkinkan add-on penskalaan mengidentifikasi resource kustom yang tersedia dalam kelompok node atau nilai pasti dari sumber daya tertentu.

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

Contoh:

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

Mengapa node instant scaling gagal melakukan scale-in node?

Periksa masalah berikut:

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

• Total permintaan sumber daya pod pada node melebihi ambang batas utilisasi scale-in yang dikonfigurasi.

• Node menjalankan pod dari namespace kube-system.

• Sebuah pod pada node memiliki persyaratan penjadwalan ketat yang mencegahnya dijadwalkan ulang ke node lain.

• Sebuah pod pada node dilindungi oleh PodDisruptionBudget (PDB), dan penghapusan node akan melanggar PDB tersebut.

• Jika node baru saja ditambahkan, node instant scaling tidak akan melakukan scale-in terhadap node tersebut selama 10 menit pertama.

• Ada node offline. Node offline adalah instans yang berjalan tetapi tidak memiliki objek node yang sesuai dalam kluster. Mulai dari v0.5.3, add-on node instant scaling dapat membersihkan instans ini secara otomatis. Untuk versi sebelumnya, Anda harus menghapusnya secara manual.

  Versi 0.5.3 sedang dalam rilis canary. Untuk meminta akses, ajukan tiket. Untuk informasi cara meningkatkan add-on, lihat Kelola add-on.

  Anda dapat memeriksa keberadaan node offline di halaman Node Pools. Klik Sync Node Pool, lalu klik Details untuk kelompok node terkait, dan lihat tab Nodes.

Jenis Pod apa saja yang dapat mencegah Node Instant Scaling menghapus sebuah node?

Jika sebuah pod tidak dibuat oleh controller Kubernetes asli—seperti Deployment, ReplicaSet, Job, atau StatefulSet—atau jika pod pada sebuah node tidak dapat dihentikan atau dimigrasikan dengan aman, node instant scaling mungkin tidak dapat menghapus node tersebut.

Bagaimana cara menggunakan pod untuk mengontrol scale-in node oleh node instant scaling?

Anda dapat menggunakan anotasi pod goatscaler.io/safe-to-evict untuk mengontrol apakah node instant scaling dapat melakukan scale-in terhadap node tempat pod tersebut berjalan.

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

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

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

Untuk memaksa penghapusan node, tambahkan taint goatscaler.io/force-to-delete:true:NoSchedule. node instant scaling kemudian segera menghapus node tersebut tanpa memeriksa statusnya atau mengosongkan pod. Gunakan fitur ini dengan hati-hati karena dapat menyebabkan gangguan layanan atau kehilangan data.

Bagaimana cara mencegah node agar tidak di-scale-in oleh node instant scaling?

Anda dapat mencegah node agar tidak di-scale-in oleh add-on node instant scaling dengan menambahkan anotasi "goatscaler.io/scale-down-disabled": "true" ke node tersebut. Gunakan perintah berikut untuk menambahkan anotasi:

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

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

Anda dapat mengonfigurasi perilaku ini baik di tingkat node maupun tingkat kluster. Jika pengaturan dikonfigurasi di kedua tingkat, pengaturan tingkat node yang berlaku.

• Konfigurasi tingkat node: Tambahkan label goatscaler.io/scale-down-only-empty:true ke node untuk mengaktifkan perilaku ini, atau label goatscaler.io/scale-down-only-empty:false untuk menonaktifkannya.

• Konfigurasi tingkat kluster: Di Konsol ACK, buka halaman Add-ons. Temukan add-on ACK GOATScaler dan konfigurasikan parameter ScaleDownOnlyEmptyNodes menjadi true atau false.

Apakah ada operasi yang akan memicu pembaruan otomatis add-on Node Instant Scaling?

Tidak. Kecuali untuk maintenance sistem dan peningkatan platform, ACK tidak secara otomatis memperbarui add-on ACK GOATScaler. Anda harus memperbaruinya secara manual dari halaman Add-ons di Konsol ACK.