Optimasi biaya klaster bertujuan untuk menggunakan sumber daya klaster secara ekonomis dan efisien, mengurangi pengeluaran yang tidak perlu. Topik ini memberikan praktik terbaik untuk membantu Anda mengoptimalkan biaya klaster, menyeimbangkan pengeluaran, serta memastikan stabilitas dan keandalan beban kerja dan klaster. Setelah membaca praktik terbaik ini, Anda akan mempelajari cara mengonfigurasi klaster dengan biaya rendah, menggunakan kemampuan penskalaan beban kerja dan node, serta memantau biaya klaster secara real-time.
Tentang topik ini
Topik ini ditujukan untuk administrator klaster Container Service for Kubernetes (ACK). Topik ini memberikan saran umum tentang pengurangan biaya klaster. Saran dalam topik ini tidak disusun dalam urutan tertentu. Anda dapat memilih dan menerapkan saran berdasarkan kebutuhan bisnis Anda. Kami menyarankan Anda mempelajari istilah Kubernetes berikut sebelum membaca topik ini: pod dan sumber daya kontainer, namespace, autoscaling (penskalaan beban kerja dan penskalaan node), dan penjadwalan.
Untuk memastikan stabilitas aplikasi yang diterapkan di klaster ACK, kami sarankan Anda menggabungkan konfigurasi yang disarankan dalam topik Konfigurasi yang Disarankan untuk Membuat Klaster HA dan Konfigurasi Beban Kerja yang Direkomendasikan.
Jika klaster Anda adalah Klaster ACK Pro dan berisi lebih dari 500 node atau 10.000 pod, kami sarankan Anda mengikuti panduan dalam topik Saran Penggunaan Klaster Skala Besar.
Topik ini bertujuan untuk membantu Anda membangun sistem dan tim FinOps serta menetapkan tujuan strategis FinOps. FinOps adalah singkatan dari "Finance + DevOps". Ini merupakan kombinasi budaya dan praktik untuk manajemen keuangan cloud perusahaan. FinOps dapat membantu perusahaan memperkirakan biaya sumber daya cloud dan membuat penggunaan sumber daya cloud menjadi transparan. FinOps juga dapat mengontrol dan mengoptimalkan biaya secara efisien untuk memfasilitasi perkembangan dan inovasi bisnis. Untuk informasi lebih lanjut, lihat Suite Biaya.
Konfigurasikan klaster dengan biaya rendah
Sebelum menerapkan klaster, evaluasi permintaan sumber daya aplikasi yang akan diterapkan di klaster, dan pilih jenis instance yang tepat serta metode penagihan klaster untuk mengurangi biaya keseluruhan.
Pilih jenis instance ECS yang tepat
Saat memilih jenis instance untuk pool node, Anda perlu mempertimbangkan performa, harga, dan faktor beban kerja untuk memastikan stabilitas dan efisiensi biaya. Dalam banyak kasus, jenis instance Elastic Compute Service (ECS) dengan spesifikasi tinggi (spesifikasi CPU dan memori) atau jenis instance ECS yang berspesialisasi dalam sektor tertentu (seperti instans yang dipercepat GPU atau instans heterogen) ditawarkan dengan harga tinggi.
Pilih jenis instance berdasarkan skenario bisnis
Pilih jenis instance yang paling hemat biaya berdasarkan skenario bisnis Anda. Misalnya, dalam skenario caching terdistribusi, aplikasi berat memori biasanya digunakan. Dibandingkan dengan jenis instance lainnya, jenis instance yang dioptimalkan untuk memori dengan rasio vCPU-memori 1:8 dapat secara efisien meningkatkan utilisasi CPU dan mengurangi biaya. Dalam skenario pembelajaran mendalam, tugas pembelajaran mendalam biasanya memerlukan banyak sumber daya GPU dan juga menggunakan sumber daya CPU untuk melakukan pra-pemrosesan data dan operasi I/O. Oleh karena itu, rasio GPU-vCPU yang disarankan adalah dari 1:8 hingga 1:12. Untuk informasi lebih lanjut tentang saran memilih jenis instance ECS, lihat Saran Memilih Spesifikasi ECS untuk Klaster ACK.
Untuk menghindari hambatan sumber daya dan fragmen sumber daya, kami sarankan Anda tidak menggunakan jenis instance dengan spesifikasi rendah di lingkungan produksi, seperti jenis instance dengan 2 vCPU dan 4 GB memori atau kurang. Untuk informasi lebih lanjut, lihat Rekomendasi Spesifikasi ECS untuk Klaster ACK.
Gunakan keluarga instance bersama
Kami sarankan Anda menggunakan keluarga instance bersama jika Anda seorang pengembang individu atau ingin membangun aplikasi situs web kecil atau menengah. Dibandingkan dengan keluarga instance tingkat perusahaan, keluarga instance bersama dapat menyebabkan fluktuasi performa. Oleh karena itu, harga keluarga instance bersama lebih rendah. Keluarga instance bersama cocok untuk situs web kecil dan menengah, aplikasi web, lingkungan pengembangan, database ringan, dan aplikasi perusahaan ringan.
Untuk informasi lebih lanjut tentang pengenalan keluarga instance bersama dan cara memilih jenis instance, lihat Keluarga Instance Bersama.
Pilih metode penagihan yang tepat
Jenis bisnis yang berbeda memiliki persyaratan yang berbeda pada siklus hidup sumber daya. Anda perlu memilih metode penagihan yang tepat untuk mengoptimalkan biaya.
Langganan
Metode penagihan langganan memungkinkan Anda menggunakan sumber daya secara terus-menerus dengan harga diskon. Jika bisnis Anda memiliki karakteristik berikut, kami sarankan Anda menggunakan metode penagihan langganan:
Siklus hidup sumber daya yang dapat diprediksi.
Beban kerja stabil tanpa fluktuasi.
Permintaan sumber daya jangka panjang.
Sebagai contoh, untuk terus menyediakan layanan web atau basis data, kami sarankan Anda menggunakan metode penagihan langganan.
Bayar Sesuai Pemakaian
Bayar sesuai pemakaian adalah metode penagihan yang fleksibel, yang memungkinkan Anda membayar sumber daya aktual yang Anda gunakan. Anda tidak perlu membeli sejumlah besar sumber daya di muka. Sumber daya bayar sesuai pemakaian lebih hemat biaya dibandingkan pusat data yang dikelola sendiri. Jika bisnis Anda memiliki karakteristik berikut, kami sarankan Anda menggunakan metode penagihan bayar sesuai pemakaian:
Beban kerja Anda secara berkala berfluktuasi atau lalu lintas sesekali melonjak. Permintaan sumber daya sulit diprediksi.
Permintaan sumber daya berfluktuasi. Anda perlu sering menerapkan dan melepaskan sumber daya.
Sebagai contoh, untuk sementara memperluas beban kerja untuk pengujian, pengembangan bisnis, atau acara promosi e-commerce, kami sarankan Anda menggunakan metode penagihan bayar sesuai pemakaian.
Instans Preemptible
Instans preemptible adalah instans bayar sesuai pemakaian yang harganya berubah berdasarkan inventaris secara real-time. Dibandingkan dengan instans bayar sesuai pemakaian reguler, instans preemptible dapat membantu Anda mengurangi total biaya hingga 90%. Namun, instans preemptible dapat ditarik kembali kapan saja setelah kedaluwarsa. Oleh karena itu, instans preemptible hanya cocok untuk beban kerja stateless dengan kemampuan toleransi kesalahan yang kuat, seperti pemrosesan batch dan beban kerja pembelajaran mesin, pekerjaan ETL data besar (seperti Apache Spark), aplikasi pemrosesan transaksi antrian, dan aplikasi yang menggunakan REST API. Instans preemptible tidak cocok untuk bisnis jangka panjang atau aplikasi yang memerlukan stabilitas tinggi. Untuk informasi lebih lanjut, lihat Praktik Terbaik untuk Pool Node Berbasis Instans Preemptible.
Gunakan rencana penghematan
Jika Anda perlu menggunakan instance ECS atau instance kontainer elastis untuk bisnis jangka panjang, Anda dapat membeli rencana penghematan untuk menikmati diskon besar. Rencana penghematan memungkinkan Anda menikmati harga bayar sesuai pemakaian dengan diskon dengan berkomitmen pada jumlah pembayaran tertentu dalam satu, tiga, atau lima tahun. Untuk informasi lebih lanjut, lihat Ikhtisar Rencana Penghematan dan Pembelian dan Penerapan Rencana Penghematan.
Pilih wilayah yang tepat untuk klaster Anda
Harga instance ECS dapat bervariasi berdasarkan wilayah. Dalam banyak kasus, pengguna dapat menikmati latensi jaringan yang lebih rendah dan kecepatan transmisi yang lebih tinggi jika klaster Anda diterapkan di wilayah yang dekat dengan pengguna. Jika bisnis Anda dapat mentolerir latensi jaringan yang tinggi, Anda dapat menerapkan klaster di wilayah yang menawarkan harga instance rendah. Untuk informasi lebih lanjut tentang harga instance ECS di wilayah yang berbeda, lihat Elastic Compute Service.
Gunakan klaster terkelola ACK
Bidang kontrol klaster klaster terkelola ACK dibuat dan dihosting oleh ACK. Anda hanya perlu membuat node pekerja. Anda tidak perlu mengelola bidang kontrol (node master) atau membayar biaya sumber daya untuk mereka. Oleh karena itu, klaster terkelola ACK lebih hemat biaya dibandingkan dengan klaster khusus ACK.
Jika Anda ingin menjalankan bisnis skala besar dan bisnis Anda memerlukan stabilitas atau keamanan tinggi, kami sarankan Anda menggunakan klaster ACK Pro. Klaster ACK Pro dilindungi oleh SLA yang mencakup klausa kompensasi, dan menyediakan keandalan, keamanan, dan kemampuan penjadwalan yang ditingkatkan. Untuk informasi lebih lanjut, lihat Ikhtisar Klaster ACK Pro.
Optimalkan alokasi sumber daya untuk beban kerja
Konfigurasikan permintaan dan batas sumber daya yang sesuai
Anda harus mengonfigurasi permintaan dan batas sumber daya dengan benar. Permintaan dan batas sumber daya yang terlalu tinggi dapat mengakibatkan pemborosan sumber daya dan permintaan serta batas sumber daya yang terlalu rendah dapat mengganggu stabilitas klaster selama jam sibuk. Dalam banyak kasus, Anda dapat merujuk statistik seperti pemanfaatan sumber daya historis kontainer dan hasil uji stres aplikasi untuk mengevaluasi tingkat stabilitas aplikasi dan tingkat pemanfaatan sumber daya. Hal ini membantu Anda menyesuaikan alokasi sumber daya berdasarkan status kontainer.
Kami sarankan Anda menggunakan konfigurasi sumber daya yang disarankan oleh profil sumber daya. Profil sumber daya menganalisis data penggunaan sumber daya historis dalam klaster untuk menghasilkan spesifikasi sumber daya kontainer yang disarankan. Profil sumber daya tidak hanya mengurangi kompleksitas pengaturan permintaan dan batas sumber daya, tetapi juga memungkinkan Anda menetapkan spesifikasi sumber daya untuk setiap kontainer untuk meningkatkan pemanfaatan sumber daya. Untuk informasi lebih lanjut, lihat Profil Sumber Daya.
Kelola namespace dan kuota sumber daya
Dalam skenario multi-tenant, Anda mungkin perlu menerapkan aplikasi di namespace yang berbeda untuk bisnis atau tim yang berbeda. Anda dapat membuat namespace untuk mengisolasi sumber daya dan menetapkan kuota sumber daya untuk namespace yang berbeda untuk membatasi jumlah sumber daya yang dapat digunakan oleh setiap aplikasi atau tim. Anda dapat mengonfigurasi kuota CPU, memori, penyimpanan, dan pod untuk namespace. Untuk informasi lebih lanjut, lihat Kelola Namespace dan Kuota Sumber Daya.
Gunakan kemampuan penskalaan yang tepat
Jika beban kerja Anda berfluktuasi secara signifikan, kami sarankan Anda mengonfigurasi autoscaling berdasarkan kebutuhan bisnis Anda. Autoscaling dapat dengan cepat menskalakan pod selama jam sibuk untuk menangani lonjakan lalu lintas, dan menskalakan pod selama jam sepi untuk mengurangi biaya sumber daya. Anda hanya perlu membayar sumber daya yang sebenarnya Anda gunakan, tanpa harus mengonfigurasi dan membayar sumber daya berdasarkan permintaan puncak, yang sangat mengurangi biaya klaster.
Penskalaan Beban Kerja: Solusi lapisan penjadwalan ini beroperasi pada level pod dengan menyesuaikan jumlah pod atau jumlah sumber daya yang dialokasikan ke pod berdasarkan perubahan beban kerja. Sebagai contoh, HPA dapat secara otomatis menyesuaikan jumlah pod aplikasi berdasarkan perubahan lalu lintas untuk lebih menyesuaikan jumlah sumber daya yang digunakan oleh beban kerja saat ini.
Penskalaan Sumber Daya Komputasi: Solusi lapisan sumber daya ini terdiri dari penskalaan node dan penskalaan node virtual. Anda dapat menggunakan solusi ini untuk menambah atau mengurangi jumlah sumber daya yang dialokasikan ke aplikasi Anda berdasarkan hasil penjadwalan pod dan penggunaan sumber daya.
Penskalaan beban kerja
Solusi | Deskripsi |
HPA secara otomatis menskalakan pod berdasarkan penggunaan CPU, penggunaan memori, atau metrik kustom. HPA dapat menskalakan pod selama jam sibuk untuk menangani lonjakan lalu lintas dan menskalakan pod selama jam sepi untuk mengurangi biaya sumber daya. HPA cocok untuk skenario di mana Anda perlu menerapkan sejumlah besar layanan dan sering kali menskalakan sumber daya untuk beban kerja yang berfluktuasi secara signifikan. Kami sarankan Anda memperhatikan item berikut saat mengonfigurasi HPA untuk memastikan stabilitas aplikasi:
| |
CronHPA secara berkala menskalakan sumber daya berdasarkan kebijakan mirip crontab. CronHPA cocok untuk skenario di mana Anda perlu menjalankan tugas atau menangani lonjakan lalu lintas pada waktu yang dijadwalkan. Saat mengonfigurasi CronHPA, kami sarankan Anda memperhatikan item berikut untuk memastikan stabilitas aplikasi:
| |
VPA menghasilkan spesifikasi CPU dan memori yang disarankan berdasarkan data penggunaan sumber daya historis pod, dan menyesuaikan konfigurasi sumber daya untuk memenuhi permintaan sumber daya. VPA cocok untuk aplikasi stateful yang memerlukan pasokan sumber daya yang stabil. Saat mengonfigurasi VPA, kami sarankan Anda memperhatikan item berikut untuk memastikan stabilitas aplikasi:
| |
AHPA secara otomatis mengidentifikasi siklus penskalaan dan memperkirakan kapasitas sumber daya yang diperlukan dengan menganalisis statistik sumber daya historis aplikasi, serta secara dinamis menskalakan pod untuk memastikan bahwa sumber daya disediakan sebelum terjadinya lonjakan lalu lintas. Selain itu, AHPA dapat dengan cepat menskalakan pod selama jam sepi. Saat mengonfigurasi AHPA, kami sarankan Anda memperhatikan item berikut untuk memastikan stabilitas aplikasi:
| |
KEDA secara berkala mengonsumsi peristiwa dari sumber peristiwa seperti Kafka, MySQL, PostgreSQL, RabbitMQ, dan MongoDB dan menskalakan sumber daya sesuai dengan itu. KEDA cocok untuk transkoding video/audio offline, pekerjaan berbasis peristiwa, dan streaming data. Saat mengonfigurasi KEDA, kami sarankan Anda memperhatikan item berikut untuk memastikan stabilitas aplikasi:
|
Penskalaan node
Saat menggunakan kemampuan penskalaan beban kerja, kami sarankan Anda mengaktifkan penskalaan node untuk menghindari kegagalan penjadwalan pod karena sumber daya node tidak mencukupi. Untuk informasi lebih lanjut tentang cara memilih antara autoscaling node dan instant scaling node, lihat Solusi Penskalaan: autoscaling node dan instant scaling node.
Solusi | Deskripsi |
Anda dapat menggunakan autoscaling node untuk secara otomatis menskalakan node ketika sumber daya dalam klaster Container Service for Kubernetes (ACK) saat ini tidak dapat memenuhi penjadwalan pod. Fitur autoscaling node berlaku untuk skenario dengan persyaratan penskalaan yang terbatas. Ini mencakup klaster yang memiliki kurang dari 20 pool node dengan autoscaling diaktifkan, atau di mana jumlah node per pool node tetap di bawah 100. Autoscaling node optimal untuk beban kerja dengan pola lalu lintas stabil, permintaan sumber daya periodik atau dapat diprediksi, dan operasi di mana penskalaan satu batch memenuhi kebutuhan bisnis. Saat mengonfigurasi autoscaling node, kami sarankan Anda memperhatikan item berikut untuk memastikan stabilitas aplikasi:
| |
Dibandingkan dengan autoscaling node, instant scaling node memungkinkan penskalaan klaster pada skala besar atau dengan kecepatan lebih tinggi. Fitur ini menurunkan persyaratan keterampilan teknis bagi pengembang, meningkatkan efisiensi penskalaan sumber daya, dan mengurangi kebutuhan upaya O&M manual. Instant scaling node memiliki batasan tertentu. Untuk informasi lebih lanjut, lihat Batasan instant scaling node. | |
Saat menggunakan klaster ACK, Anda mungkin perlu meluncurkan sejumlah besar pod dalam waktu singkat. Jika Anda memilih untuk membuat instance ECS untuk pod, proses pembuatannya bisa memakan waktu. Jika Anda memilih untuk memesan instance ECS, instance tersebut menganggur sebelum pembuatan pod dan setelah penghentian pod, sehingga menyebabkan pemborosan sumber daya. Anda dapat membuat node virtual ACK untuk dengan cepat menjadwalkan pod ke instance kontainer elastis. Dengan cara ini, Anda tidak perlu membeli atau mengelola instance ECS. Untuk informasi lebih lanjut, lihat Pengenalan penjadwalan node virtual dan perbandingan solusi dan Jadwalkan pod ke instance kontainer elastis. |
Optimalkan penjadwalan pod
Overkomitmen sumber daya dinamis
Jika pod dengan kelas QoS Guaranteed dan Burstable ditempatkan bersama dalam klaster, Anda dapat mengonfigurasi overkomitmen sumber daya dinamis untuk menggunakan sumber daya yang dialokasikan tetapi tidak digunakan.
Untuk menangani fluktuasi beban kerja di layanan hulu dan hilir dalam klaster ACK, administrator aplikasi biasanya perlu mengonfigurasi buffer sumber daya untuk setiap pod Guaranteed atau Burstable. Akibatnya, jumlah sumber daya yang digunakan jauh lebih rendah daripada jumlah sumber daya yang diminta. Untuk menggunakan sumber daya yang dialokasikan tetapi tidak digunakan, Anda dapat mengonfigurasi overkomitmen sumber daya dinamis untuk meningkatkan pemanfaatan sumber daya.
Overkomitmen sumber daya dinamis memungkinkan Anda mendefinisikan laju redundansi sumber daya untuk secara dinamis melakukan overkomitmen sumber daya yang melebihi laju redundansi. Jumlah sumber daya yang dapat dioverkomit secara dinamis pada node berubah berdasarkan penggunaan sumber daya aktual. Anda dapat memprioritaskan pod Best Effort (BE) saat menjadwalkan pod ke node. Untuk informasi lebih lanjut, lihat Aktifkan Overkomitmen Sumber Daya Dinamis.
Sebagai contoh, dalam skenario kolokasi, Anda perlu menerapkan pod Latency Sensitive (LS) dan pod BE berat sumber daya dalam klaster atau pada node. Untuk memenuhi persyaratan QoS pod LS, kami sarankan Anda mengonfigurasi overkomitmen sumber daya untuk pod BE untuk melakukan manajemen CPU dan memori secara halus. Hal ini membantu meningkatkan pemanfaatan sumber daya secara keseluruhan. Untuk informasi lebih lanjut, lihat Memulai.
Berbagi GPU
Untuk menjalankan beberapa kontainer pada satu GPU demi optimasi biaya GPU, Anda dapat menggunakan berbagi GPU.
Berbagi GPU tunggal dan berbagi GPU ganda tersedia. Dalam mode berbagi GPU tunggal, setiap pod meminta satu GPU dan menggunakan sebagian sumber daya GPU. Mode ini cocok untuk skenario inferensi model. Dalam mode berbagi GPU ganda, setiap pod meminta beberapa GPU. Jumlah sumber daya yang sama dialokasikan dari setiap GPU. Mode ini cocok untuk pengembangan dan pelatihan model terdistribusi. Anda juga dapat mengonfigurasi kebijakan berbagi dan isolasi GPU. Sebagai contoh, Anda dapat mengonfigurasi beberapa pod untuk lebih memilih menggunakan satu GPU atau menyebarkan pod ke beberapa GPU. Untuk informasi lebih lanjut, lihat Berbagi GPU.
Atur pemantauan sumber daya dan biaya
Gunakan fitur wawasan biaya untuk memantau biaya departemen atau aplikasi
Administrator pengeluaran TI biasanya perlu memahami penggunaan sumber daya klaster dan tren perubahan biaya sumber daya dari berbagai dimensi. Hal ini membantu mereka mengurangi biaya sumber daya dan meningkatkan pemanfaatan sumber daya. Anda dapat menggunakan fitur wawasan biaya yang disediakan oleh klaster ACK untuk melihat biaya dan penggunaan sumber daya klaster, departemen, atau aplikasi dalam siklus tata kelola biaya yang ditentukan. Untuk informasi lebih lanjut, lihat Wawasan Biaya.
Pod adalah unit terkecil yang dapat diterapkan dalam klaster ACK. Biaya pod adalah faktor penting dalam perhitungan biaya klaster. Pod yang berbeda mungkin memiliki spesifikasi sumber daya, kebijakan penjadwalan, dan siklus hidup yang berbeda. Oleh karena itu, memperkirakan biaya pod cukup kompleks. Fitur wawasan biaya menggunakan model data biaya untuk memperkirakan biaya dan rasio biaya setiap pod dan kemudian mengalokasikan total biaya ke unit bisnis yang berbeda. Anda juga dapat menggunakan dasbor biaya multidimensi untuk menganalisis tren penggunaan sumber daya historis dan detail biaya untuk menemukan penyebab biaya tak terduga.
Pindai sumber daya idle secara berkala
Anda dapat memindai dan melepaskan sumber daya idle secara berkala di klaster ACK, seperti sumber daya CPU, memori, penyimpanan, dan jaringan, untuk mengurangi biaya sumber daya.
Anda juga dapat mengaktifkan fitur wawasan biaya untuk melihat sumber daya idle dalam pod, menemukan penyebabnya, dan kemudian mengoptimalkan kebijakan alokasi sumber daya. Untuk informasi lebih lanjut, lihat Metode Penagihan dan Penggunaan Pod.
Klaster ACK juga menyediakan fitur untuk membantu Anda mengidentifikasi sumber daya idle terkait klaster, seperti instance ECS, sumber daya Elastic Block Storage (EBS), instance Classic Load Balancer (CLB), dan elastic IP addresses (EIPs). Untuk informasi lebih lanjut, lihat Optimasi Sumber Daya Idle.