Optimasi biaya kluster berarti memanfaatkan sumber daya kluster secara ekonomis tanpa mengorbankan stabilitas workload. Panduan ini mencakup pemilihan instans, metode penagihan, auto scaling, penjadwalan pod, dan pemantauan biaya—menyediakan kerangka praktis untuk menerapkan praktik FinOps di Alibaba Cloud.
Panduan ini ditujukan bagi administrator kluster Container Service for Kubernetes (ACK). Rekomendasi ini tidak diurutkan berdasarkan prioritas—terapkan sesuai kebutuhan bisnis Anda. Sebelum memulai, pahami konsep Kubernetes berikut: pod dan sumber daya kontainer, namespace, auto scaling (scaling workload dan scaling node), serta penjadwalan.
Topik terkait:
Untuk memastikan stabilitas aplikasi, gabungkan rekomendasi ini dengan Konfigurasi yang disarankan untuk membuat kluster HA dan Konfigurasi workload yang direkomendasikan.
Jika kluster ACK Pro Anda memiliki lebih dari 500 node atau 10.000 pod, ikuti Saran penggunaan kluster skala besar.
Untuk membangun sistem FinOps dan menetapkan tujuan biaya strategis, lihat Cost Suite. FinOps (Finance + DevOps) adalah serangkaian praktik untuk manajemen keuangan cloud yang membantu tim memperkirakan, melacak, dan mengoptimalkan biaya sumber daya cloud.
Pilih tipe instans dan metode penagihan
Sebelum membuat kluster, evaluasi kebutuhan sumber daya workload Anda dan pilih tipe instans serta metode penagihan yang menyeimbangkan kinerja dan biaya.
Sesuaikan tipe instans dengan profil workload
Tabel berikut merangkum profil workload umum beserta tipe instans dan metode penagihan yang direkomendasikan untuk masing-masing.
| Workload Profile | Tipe instans yang direkomendasikan | Metode penagihan yang direkomendasikan | Catatan |
|---|---|---|---|
| Layanan web dan database (stabil, berjalan lama) | Tujuan umum (misalnya, seri ecs.g) | Langganan atau rencana penghematan | Siklus hidup dapat diprediksi; langganan dan rencana penghematan mengurangi biaya per unit |
| Distributed caching (intensif memori) | Dioptimalkan memori (rasio vCPU-memori 1:8) | Langganan atau pay-as-you-go | Instans dioptimalkan memori meningkatkan utilisasi CPU dengan biaya lebih rendah untuk aplikasi yang intensif memori |
| Pembelajaran mendalam dan pelatihan model | Dipercepat GPU | Pay-as-you-go atau preemptible | Rasio GPU-vCPU: 1:8 hingga 1:12; gunakan instans preemptible untuk pekerjaan pelatihan yang toleran kesalahan |
| Pemrosesan batch, ETL, pekerjaan berbasis event | Apa saja | Preemptible | Hingga 90% lebih murah daripada pay-as-you-go; cocok untuk workload tanpa status dan toleran kesalahan |
| Lingkungan dev/test dan situs web kecil | Famili instans bersama | Pay-as-you-go | Harga lebih rendah; mungkin mengalami fluktuasi kinerja; tidak cocok untuk produksi |
| Lonjakan trafik dan promosi e-commerce | Tujuan umum | Pay-as-you-go | Fleksibel; tidak memerlukan komitmen di muka |
Hindari tipe instans dengan 2 vCPU dan memori 4 GB atau kurang di lingkungan produksi untuk mencegah bottleneck dan fragmentasi sumber daya. Lihat Rekomendasi spesifikasi ECS untuk kluster ACK untuk detail selengkapnya.
Untuk panduan umum pemilihan instans, lihat Saran pemilihan spesifikasi ECS untuk kluster ACK.
Gunakan instans preemptible
Instans preemptible adalah instans pay-as-you-go yang harganya didasarkan pada inventaris real-time dan dapat mengurangi total biaya hingga 90% dibandingkan instans pay-as-you-go reguler.
Instans preemptible dapat ditarik kembali setelah masa berlakunya habis. Gunakan hanya untuk workload tanpa status dan toleran kesalahan seperti:
Pemrosesan batch dan pembelajaran mesin
Pekerjaan ETL big data (misalnya, Apache Spark)
Pemrosesan transaksi dalam antrian
Aplikasi yang menggunakan REST API
Untuk praktik terbaik, lihat Praktik terbaik untuk kelompok node berbasis instans preemptible.
Gunakan famili instans bersama
Famili instans bersama cocok untuk pengembang individu, situs web atau aplikasi web skala kecil-menengah, lingkungan pengembangan, database ringan, serta aplikasi enterprise kelas ringan. Karena sumber daya CPU dibagi, kinerja dapat berfluktuasi di bawah beban tinggi. Untuk detail selengkapnya, lihat Famili instans bersama.
Gunakan rencana penghematan
Untuk instans ECS atau instans kontainer elastis yang berjalan lama, beli rencana penghematan untuk mendapatkan harga diskon dari tarif pay-as-you-go. Rencana penghematan memerlukan komitmen selama 1, 3, atau 5 tahun. Lihat Ikhtisar rencana penghematan dan Beli dan terapkan rencana penghematan.
Pilih wilayah
Harga instans ECS bervariasi berdasarkan wilayah. Jika workload Anda dapat mentolerir latensi jaringan yang lebih tinggi, men-deploy di wilayah berbiaya lebih rendah dapat mengurangi pengeluaran. Untuk harga berdasarkan wilayah, lihat Elastic Compute Service.
Gunakan kluster ACK yang dikelola
Kluster ACK yang dikelola menyediakan lapisan kontrol (node master) di Alibaba Cloud—Anda hanya menyediakan node pekerja dan tidak dikenai biaya sumber daya untuk lapisan kontrol. Hal ini menjadikan kluster yang dikelola lebih hemat biaya dibandingkan kluster khusus.
Untuk workload skala besar yang memerlukan stabilitas dan keamanan tinggi, gunakan kluster ACK Pro. Kluster ACK Pro dilindungi SLA dengan klausa kompensasi serta menawarkan keandalan, keamanan, dan kemampuan penjadwalan yang ditingkatkan. Lihat Ikhtisar kluster ACK Pro.
Optimalkan alokasi sumber daya workload
Konfigurasikan permintaan dan batas sumber daya
Tetapkan permintaan dan batas sumber daya secara akurat. Permintaan yang terlalu tinggi akan membuang kapasitas; permintaan yang terlalu rendah berisiko menyebabkan ketidakstabilan saat beban puncak. Gunakan data historis utilisasi kontainer dan hasil uji stres untuk mengkalibrasi nilai-nilai ini.
Gunakan profiling sumber daya untuk menghasilkan spesifikasi sumber daya kontainer yang disarankan berdasarkan data penggunaan historis. Profiling sumber daya mengurangi kompleksitas penyetelan pengaturan sumber daya dan meningkatkan utilisasi secara keseluruhan. Lihat Profiling sumber daya.
Secara berkala tinjau ulang permintaan dan batas sumber daya seiring evolusi aplikasi Anda—konfigurasi yang akurat saat deployment mungkin menjadi usang seiring waktu.
Atur namespace dan kuota sumber daya
Pada kluster multi-penyewa, gunakan namespace untuk mengisolasi sumber daya bagi tim atau workload berbeda dan tetapkan kuota sumber daya untuk membatasi konsumsi per namespace. Jenis kuota yang dapat dikonfigurasi mencakup CPU, memori, penyimpanan, dan jumlah pod. Lihat Mengelola namespace dan kuota sumber daya.
Gunakan auto scaling untuk mengurangi kapasitas menganggur
Auto scaling merupakan salah satu cara paling efektif untuk memangkas biaya kluster. Perluas kapasitas pod saat jam sibuk untuk menangani trafik, dan kurangi kapasitas saat jam sepi sehingga Anda hanya membayar yang digunakan—tanpa over-provisioning untuk permintaan puncak.
ACK mendukung dua lapisan auto scaling:
Penskalaan beban kerja: menyesuaikan jumlah Pod atau alokasi sumber daya Pod sesuai dengan tingkat beban kerja
Scaling sumber daya komputasi: menyesuaikan jumlah node atau menyediakan node virtual berdasarkan permintaan penjadwalan pod
Scaling workload
| Solusi | Kapan Digunakan | Pertimbangan Utama |
|---|---|---|
| Horizontal Pod Autoscaling (HPA) | Layanan dengan trafik fluktuatif; scale berdasarkan penggunaan CPU, penggunaan memori, atau metrik kustom | Konfigurasikan permintaan dan batas sumber daya; konfigurasikan pemeriksaan kesehatan pod dan pemulihan otomatis; pastikan Metrics Server berjalan |
| Cron Horizontal Pod Autoscaling (CronHPA) | Pola trafik yang dapat diprediksi; scale-out terjadwal pada waktu tetap | Konfigurasikan permintaan dan batas sumber daya; konfigurasikan pemeriksaan kesehatan pod dan pemulihan otomatis; jika menggunakan HPA dan CronHPA bersamaan, hindari konflik—lihat Buat CronHPA kompatibel dengan HPA |
| Vertical Pod Autoscaling (VPA) | Aplikasi stateful dengan permintaan sumber daya stabil; sesuaikan ukuran CPU dan memori pod berdasarkan penggunaan historis | Konfigurasikan anggaran gangguan pod (PDB); pastikan Metrics Server berjalan; tinjau tindakan pencegahan VPA |
| Adaptive Horizontal Pod Autoscaling (AHPA) | Workload dengan siklus trafik berulang; perluas kapasitas secara proaktif sebelum lonjakan berdasarkan pola historis | Konfigurasikan permintaan dan batas sumber daya; konfigurasikan pemeriksaan kesehatan pod dan pemulihan otomatis |
| Kubernetes Event-driven Autoscaling (KEDA) | Workload berbasis event yang mengonsumsi dari Kafka, MySQL, PostgreSQL, RabbitMQ, atau MongoDB; transkoding video/audio, streaming data | Konfigurasikan permintaan dan batas sumber daya; konfigurasikan pemeriksaan kesehatan pod dan pemulihan otomatis |
Scaling node
Aktifkan scaling node bersamaan dengan scaling workload untuk mencegah kegagalan penjadwalan pod saat sumber daya node kluster tidak mencukupi. Untuk memilih antara auto scaling node dan instant scaling node, lihat Solusi scaling: auto scaling node dan instant scaling node.
| Solusi | Kapan Digunakan | Pertimbangan Utama |
|---|---|---|
| Auto scaling node | Kluster dengan kurang dari 20 kelompok node yang diaktifkan auto scaling, atau kurang dari 100 node per kelompok node; pola trafik stabil atau dapat diprediksi | Konfigurasikan permintaan dan batas sumber daya; konfigurasikan anggaran gangguan pod (PDB) |
| Instant scaling node | Kebutuhan scaling skala besar atau cepat yang melebihi batas auto scaling node | Tinjau batas instant scaling node sebelum mengaktifkan |
| Node virtual | Workload burst yang memerlukan banyak pod dalam jendela waktu singkat tanpa menyediakan instans ECS | Lihat Pengantar penjadwalan node virtual dan perbandingan solusi dan Jadwalkan pod ke instans kontainer elastis |
Optimalkan penjadwalan pod
Overcommitment sumber daya dinamis
Saat pod Guaranteed dan Burstable berbagi kluster, administrator aplikasi biasanya mengonfigurasi buffer sumber daya untuk setiap pod guna menyerap fluktuasi workload—meninggalkan celah antara permintaan dan penggunaan sumber daya aktual. Overcommitment sumber daya dinamis memungkinkan Anda mereklaim kapasitas yang tidak terpakai tersebut untuk pod Best Effort (BE).
Konfigurasikan tingkat redundansi sumber daya untuk menentukan berapa banyak buffer yang harus dipertahankan. Sumber daya di luar tingkat redundansi tersebut secara dinamis tersedia untuk pod BE. Jumlah yang dapat di-overcommit pada setiap node disesuaikan secara real time berdasarkan penggunaan aktual. Anda dapat memprioritaskan pod Best Effort (BE) saat menjadwalkan pod ke node tersebut.
Untuk skenario kolokasi di mana pod Latency Sensitive (LS) dan pod BE yang intensif sumber daya berbagi node, konfigurasikan overcommitment sumber daya untuk pod BE guna memungkinkan manajemen CPU dan memori detail halus. Lihat Aktifkan overcommitment sumber daya dinamis dan Memulai.
Berbagi GPU
Jalankan beberapa kontainer pada satu GPU untuk mengurangi biaya GPU.
Dua mode tersedia:
Berbagi GPU tunggal: setiap pod meminta satu GPU dan menempati sebagian sumber dayanya. Cocok untuk skenario inferensi model.
Berbagi GPU ganda: setiap pod meminta beberapa GPU, dengan jumlah sumber daya yang sama dialokasikan dari masing-masing. Cocok untuk pengembangan dan pelatihan model terdistribusi.
Konfigurasikan kebijakan berbagi dan isolasi GPU—misalnya, tempatkan beberapa pod pada satu GPU atau sebarkan ke beberapa GPU. Lihat Berbagi GPU.
Pantau biaya dan identifikasi pemborosan
Gunakan Cost Insights
Cost Insights memungkinkan Anda melihat penggunaan sumber daya dan biaya untuk kluster, departemen, atau aplikasi dalam siklus tata kelola biaya tertentu. Fitur ini menggunakan model data biaya untuk memperkirakan biaya setiap pod—unit deployable terkecil di ACK—dan mengalokasikan total biaya ke unit bisnis. Dasbor multidimensi memungkinkan Anda menganalisis tren penggunaan historis dan mengidentifikasi sumber biaya tak terduga. Lihat Cost Insights.
Pindai sumber daya menganggur
Lakukan pemindaian secara berkala dan lepaskan sumber daya menganggur—termasuk CPU, memori, penyimpanan, dan sumber daya jaringan—untuk menghindari pembayaran atas kapasitas yang tidak digunakan.
Gunakan Cost Insights untuk mengidentifikasi pod menganggur dan sesuaikan kebijakan alokasi sumber daya yang sesuai. Lihat Metode penagihan dan penggunaan pod.
ACK juga menyediakan alat untuk mendeteksi sumber daya terkait kluster yang menganggur seperti instans Elastic Compute Service (ECS), volume Elastic Block Storage (EBS), instans Classic Load Balancer (CLB), dan elastic IP addresses (EIPs). Lihat Optimasi sumber daya menganggur.