Jika permintaan sumber daya bisnis Anda tidak dapat diprediksi atau berubah secara periodik, kami menyarankan agar Anda mengaktifkan penskalaan otomatis untuk bisnis Anda. Misalnya, Anda dapat mengaktifkan penskalaan otomatis untuk aplikasi web, layanan game, atau aplikasi pendidikan daring. Penskalaan workload secara otomatis menyesuaikan jumlah replika pod atau jumlah sumber daya yang dialokasikan ke workload guna memenuhi persyaratannya. Fitur ini membantu Anda menangani lonjakan lalu lintas sekaligus menghemat biaya sumber daya.
Catatan penggunaan
Topik ini memperkenalkan penskalaan workload dan penskalaan node kepada insinyur O&M dan pengembang. Kami menyarankan agar Anda terlebih dahulu memahami solusi penskalaan yang disediakan oleh komunitas Kubernetes, seperti Horizontal Pod Autoscaler (HPA) dan Vertical Pod Autoscaler (VPA), serta solusi penskalaan node, seperti Cluster Autoscaling.
Jika kluster Anda memiliki lebih dari 500 node atau 10.000 pod, rujuk catatan penggunaan dalam Rencanakan laju penskalaan sumber daya kluster untuk memastikan stabilitas kluster dan lapisan kontrol kluster.
Penskalaan workload dan penskalaan sumber daya komputasi
Fitur penskalaan otomatis Container Service for Kubernetes (ACK) menyediakan elastisitas dari aspek-aspek berikut:
Penskalaan workload: Solusi pada lapisan penjadwalan ini beroperasi pada tingkat pod dengan secara dinamis menyesuaikan jumlah pod atau jumlah sumber daya yang dialokasikan ke pod berdasarkan perubahan workload. Sebagai contoh, HPA secara otomatis menyesuaikan jumlah pod aplikasi berdasarkan perubahan lalu lintas untuk menyesuaikan jumlah sumber daya yang digunakan oleh workload saat ini.
Penskalaan sumber daya komputasi: Solusi pada lapisan sumber daya ini mencakup penskalaan node dan penskalaan node virtual. Anda dapat menggunakan solusi ini untuk menambah atau mengurangi jumlah sumber daya yang dialokasikan ke aplikasi berdasarkan hasil penjadwalan pod dan penggunaan sumber daya.
Kami menyarankan agar Anda menggabungkan solusi-solusi di atas. Pendekatan ini memungkinkan Anda melakukan skala keluar replika pod guna meningkatkan pemanfaatan sumber daya sekaligus melakukan penskalaan sumber daya komputasi dalam kluster untuk memenuhi kebutuhan sumber daya pod.
Penskalaan workload solutions
Anda dapat menjalankan perintah kubectl scale untuk menyesuaikan jumlah pod secara manual. Metode ini cocok untuk kebutuhan penskalaan sementara. Tabel berikut menjelaskan cara memilih di antara solusi penskalaan workload yang disediakan oleh ACK berdasarkan skenario bisnis Anda. Solusi-solusi ini dapat memenuhi persyaratan seperti pengendalian biaya, peningkatan stabilitas, dan manajemen sumber daya yang fleksibel.
Solusi | Deskripsi | Metrik penskalaan | Skenario | Referensi |
HPA | HPA melakukan skala keluar pod selama jam sibuk untuk menangani lonjakan lalu lintas dan melakukan skala-masuk pod selama jam sepi untuk mengurangi biaya sumber daya. HPA cocok untuk sebagian besar skenario. |
| HPA ideal untuk layanan daring yang mencakup sejumlah besar pod dan memerlukan penskalaan sering untuk menangani fluktuasi lalu lintas, seperti layanan e-commerce, pendidikan daring, dan layanan keuangan. | |
CronHPA | CronHPA menggunakan strategi mirip Crontab untuk menskalakan pod berdasarkan jadwal yang telah ditentukan. Anda dapat menentukan zona waktu dan tanggal pelaksanaan penskalaan dalam jadwal tersebut. Anda juga dapat mengecualikan tanggal tertentu, seperti hari libur, dari jadwal tersebut. CronHPA dapat digunakan bersamaan dengan HPA. | Penskalaan terjadwal | CronHPA ideal untuk aplikasi yang memiliki pola lalu lintas yang dapat diprediksi dan skenario di mana Anda perlu menjalankan tugas pada waktu tertentu. | |
VPA | VPA memantau pola konsumsi sumber daya pod dan memberikan rekomendasi mengenai alokasi CPU dan memori. VPA menyesuaikan alokasi sumber daya tetapi tidak mengubah jumlah replika pod. | VPA memberikan rekomendasi mengenai request CPU, limit CPU, request memori, dan limit memori untuk pod. Selain itu, VPA dapat secara otomatis menyesuaikan request dan limit sumber daya tersebut. | VPA ideal untuk skenario yang memerlukan alokasi sumber daya stabil, seperti skala keluar aplikasi berstatus dan penerapan aplikasi monolitik besar. Dalam sebagian besar kasus, VPA berlaku ketika pod pulih dari anomali. | |
Kubernetes-based Event Driven Autoscaling (KEDA) | KEDA mendukung berbagai macam sumber event dan memungkinkan penskalaan otomatis berbasis event untuk workload. | Jumlah event, seperti panjang antrian. | KEDA ideal untuk skenario yang memerlukan penskalaan instan, terutama pekerjaan offline berbasis event. Misalnya, Anda dapat mengaktifkan KEDA untuk pekerjaan transkoding video dan audio offline, pekerjaan berbasis event, dan pekerjaan pemrosesan aliran. | |
Advanced Horizontal Pod Autoscaler (AHPA) | AHPA dapat secara otomatis mempelajari pola fluktuasi workload dan memprediksi permintaan sumber daya berdasarkan data metrik historis untuk membantu Anda menerapkan penskalaan prediktif. |
| AHPA ideal untuk skenario di mana lalu lintas berfluktuasi secara periodik, seperti siaran langsung, pendidikan daring, dan layanan game. |
Selain solusi-solusi di atas, Anda dapat menggunakan controller UnitedDeployment untuk mendefinisikan workload. Controller ini memungkinkan Anda mengelola beberapa workload jenis yang sama pada beberapa subset secara fleksibel dan nyaman, serta menyesuaikan jumlah replika pod pada setiap subset secara dinamis. Anda dapat mengombinasikan controller UnitedDeployment dengan solusi-solusi di atas untuk mengaktifkan penskalaan dan penjadwalan workload yang fleksibel pada skenario yang menggunakan berbagai jenis sumber daya komputasi. Untuk informasi lebih lanjut, lihat Skala workload menggunakan UnitedDeployment.
Penskalaan sumber daya komputasi
Pada skenario yang memerlukan penskalaan instan untuk menangani fluktuasi lalu lintas, Anda perlu mengaktifkan kluster agar secara otomatis menyesuaikan sumber daya komputasi berdasarkan perubahan workload. Hal ini meningkatkan elastisitas bisnis Anda dan mengurangi beban kerja O&M Anda. Komponen penskalaan sumber daya komputasi mendengarkan pod yang tertunda untuk menentukan apakah diperlukan node ECS baru atau instance kontainer elastis guna penjadwalan pod.
Untuk informasi lebih lanjut tentang penskalaan node, lihat Penskalaan node.
Statistik pengiriman sumber daya yang disediakan dalam tabel berikut hanya merupakan nilai teoretis. Nilai aktual dapat bervariasi tergantung lingkungan Anda.
Solusi | Deskripsi | Skenario | Efisiensi pengiriman sumber daya | Referensi |
Penskalaan otomatis node | Anda dapat menggunakan fitur penskalaan otomatis node untuk mengaktifkan ACK agar secara otomatis menskalakan node ketika sumber daya dalam kluster Anda tidak dapat memenuhi penjadwalan pod. | Fitur penskalaan otomatis node cocok untuk semua skenario dan terutama ideal untuk layanan daring, tugas pembelajaran mendalam, aktivitas penskalaan skala kecil, serta workload yang hanya memerlukan satu aktivitas penskalaan setiap kali. Misalnya, Anda dapat mengaktifkan penskalaan otomatis node untuk kluster yang berisi kurang dari 20 kelompok node dengan penskalaan otomatis diaktifkan atau kelompok node yang memiliki penskalaan otomatis diaktifkan, masing-masing berisi kurang dari 100 node. | Waktu yang dibutuhkan untuk menambahkan 100 node ke kluster:
| |
Penskalaan instan node | Dibandingkan dengan penskalaan otomatis node, penskalaan instan node menyediakan kecepatan penskalaan yang lebih tinggi, efisiensi penskalaan yang lebih baik, dan tingkat keberhasilan pengiriman sumber daya yang lebih tinggi. Selain itu, Anda dapat melihat status kesehatan penskalaan instan node berdasarkan inventaris instance ECS. Untuk informasi lebih lanjut mengenai perbandingan antara penskalaan otomatis node dan penskalaan instan node, lihat Perbandingan solusi. | Fitur penskalaan instan node cocok untuk semua skenario dan terutama ideal untuk kluster skala besar atau kluster yang memerlukan penskalaan sumber daya lebih cepat, penskalaan otomatis lintas berbagai tipe instans dan zona, serta strategi penjadwalan lanjutan seperti topology spread constraints. Kluster dianggap besar jika kelompok node yang memiliki penskalaan otomatis diaktifkan dalam kluster tersebut berisi lebih dari 100 node atau kluster memiliki lebih dari 20 kelompok node yang memiliki penskalaan otomatis diaktifkan. | Waktu yang dibutuhkan untuk menambahkan 100 node ke kluster:
| |
Node virtual | Node virtual menghilangkan kebutuhan akan manajemen node atau perencanaan kapasitas. Dengan node virtual, Anda dapat menerapkan hingga 50.000 pod dalam satu kluster. Anda dapat menggunakan node virtual untuk melakukan skala keluar pod aplikasi guna menangani lonjakan lalu lintas. Saat melakukan skala keluar aplikasi, hingga 10.000 pod dapat dibuat dalam waktu 1 menit. | Node virtual cocok untuk semua skenario dan terutama ideal untuk tugas, tugas terjadwal, pekerjaan komputasi data, aplikasi AI, dan skenario yang mengalami lonjakan workload. | Waktu yang dibutuhkan untuk membuat 1.000 pod dalam kluster:
|
Penagihan
Fitur penskalaan otomatis tidak dikenai biaya. Komponen penskalaan otomatis diterapkan dalam pod. Oleh karena itu, Anda harus menerapkan setidaknya satu node dalam kluster Anda. Anda akan dikenai biaya untuk node yang ditambahkan menggunakan fitur penskalaan otomatis. Untuk informasi lebih lanjut, lihat Ikhtisar penagihan.
FAQ
Untuk informasi lebih lanjut mengenai jawaban atas beberapa pertanyaan umum tentang fitur penskalaan otomatis, lihat FAQ penskalaan otomatis.
Referensi
Pada skenario yang memerlukan pra-instalasi atau performa tinggi, Anda dapat menggunakan citra OS kustom untuk memfasilitasi penskalaan otomatis. Untuk informasi lebih lanjut, lihat Buat citra kustom.
Untuk informasi lebih lanjut tentang cara mengumpulkan log penskalaan otomatis, lihat Kumpulkan file log komponen sistem.
Saat mengonfigurasi workload Anda, kami menyarankan agar Anda mengikuti saran yang diberikan oleh Konfigurasi workload yang direkomendasikan.
Pada skenario yang menggunakan kontainer arsitektur tanpa server, Anda dapat mengonfigurasi Knative untuk memicu aktivitas penskalaan berdasarkan jumlah permintaan dan jumlah permintaan yang diproses secara konkuren. Saat tidak ada permintaan yang diterima, Knative secara otomatis menskalakan jumlah pod menjadi nol. Untuk informasi lebih lanjut, lihat Knative dan Aktifkan penskalaan otomatis untuk menahan fluktuasi lalu lintas.